Lack of maintenance for osmo-bts-trx
tom.tsou at ettus.com
Wed Apr 6 07:01:05 UTC 2016
On Mon, Apr 4, 2016 at 8:10 AM, Harald Welte <laforge at 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
Unlike Alexander, I was never able to setup a working version with
older commits including the one specified in this post.
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.
> We need a sub-maintainer for osmo-bts-trx, one who
> 1) consistently follows the developments in master and checks for
> 2) 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
> 3) tests interoperability with OsmoTRX and other OpenBTS transceivers
> out three
> 4) 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 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
More information about the OpenBSC