Hi Harald,
On Mon, Apr 4, 2016 at 8:10 AM, Harald Welte laforge@gnumonks.org wrote:
Ever since the merge in August 2015, as far as I recall, I never saw a single message from any osmo-bts-trx user whether a) the L1SAP merge back then works for them b) it introduced any regressions
I suspect that there were issues since the beginning of the merge. The issue that I saw with master was reported by Sipos Csaba back in Nov 2015.
http://lists.osmocom.org/pipermail/openbsc/2015-November/000856.html
Unlike Alexander, I was never able to setup a working version with older commits including the one specified in this post.
http://lists.osmocom.org/pipermail/openbsc/2015-September/000398.html
I guess there is something wrong with the OML setup since trx->mo.nm_state is reporting NM_OPSTATE_NULL during the post-RACH channel allocation, but I am not familiar enough with those procedures to debug more.
While some people think I sometimes write good code, I fail to believe that all those intrusive changes didn't break anything for OsmoTRX users. Still, no feedback and no fall-out was reported.
I suspect the case was that very few users, if any, had working setups to break or to report regressions.
Like any larger project, particularly one with different hardware support, we need somebody with essential interest in that hardware to maintain the respective back-end. Think of device driver maintainers in the Linux kernel as an example.
Agreed.
We need a sub-maintainer for osmo-bts-trx, one who
- consistently follows the developments in master and checks for regressiosn
- fixes osmo-bts-trx specific bugs like the fact that GPRS measurment values are not passed to the PCU, breaking rate/link adaption for this platform
- tests interoperability with OsmoTRX and other OpenBTS transceivers out three
- ensures that important osmo-bts-trx related patches/branches end up in master, ensuring that master is what people use. Telling users to use a branch different than master is *wrong* for anything but the most bleeding edge / experiemental code which is to be merged ASAP.
i I can provide a supporting role in the above tasks on behalf of Ettus but we do need a working starting point - that makes number 4 the most critical item. Unfortunately, I am not able to resolve the patch differences (I painfully tried) to make master the main user branch. I agree that directing users to the Fairwaves branch is the wrong approach, but right now it is the only branch for osmo-bts-trx that works.
-TT