6 Apr
2016
6 Apr
'16
9:01 a.m.
Hi Harald,
On Mon, Apr 4, 2016 at 8:10 AM, Harald Welte <laforge(a)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