Lack of maintenance for osmo-bts-trx

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Tom Tsou tom.tsou at ettus.com
Wed Apr 6 07:01:05 UTC 2016


Hi Harald,

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
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
> 1) consistently follows the developments in master and checks for
>    regressiosn
> 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
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



More information about the OpenBSC mailing list