Lack of maintenance for osmo-bts-trx
alexander.chemeris at gmail.com
Mon Apr 4 20:35:31 UTC 2016
I guess the frustration was mutual - about a year ago we had a chat that
the branch couldn't be merged only because Sysmocom didn't have time to
test it with their hardware. We even offered to pay for that testing, but
it never happened. So I guess it took some other incentives to get it
merged. Now it's our time to take time and test the latest master for
compatibility with our hardware. Meanwhile we unfortunately have to
maintain a version which works for us.
There were reports that the latest master of osmo-bts-trx doesn't work and
I can confirm that that's the case. There were also a report from me that
the branch right after the merge with master "basically worked". So you
can't blame community for not reporting.
That said, once we get over the potential barrier of fixing the master and
porting our changes to it, we'll be happy to maintain it further on, as we
do with our branch right now. If there are anyone else who want to take the
burden - we would welcome that as well.
On Mon, Apr 4, 2016 at 4:10 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Dear all,
> I am growing incredibly frustrated at the fact that osmo-bts-trx is
> effectively unmaintained, despite the fact that there are plenty of
> users as well as even commercial users / companies (particularly
> I'm not pointing Fairwaves out because I am associated with sysmocom.
> I'm pointing them out as for me as Osmocom project founder and
> co-maintainer, I sincerely think something is wrong here. And
> particuarly commercial vendors of BTSs using the Osmocom stack should
> at the very absolute minimum ensure proper maintenance of their own
> hardware support in the respective Osmocom projects. They should
> equally consider contributing to maintenance and developemnt of the
> 'core' code of those projects, too, in order to fairly share the burden
> of that effort.
> I explicitly asked for proper maintenance of osmo-bts-trx first in
> August 2014 in this post:
> Back in 2014 and the first half of 2015 I spent a lot of time in
> forward-porting and cleaning up the the (fairwaves-commissioned?) l1sap
> changes, as well as the associated osmo-bts-trx port. Back then, there
> were several patches in related (several) branches that I could not
> merge. See my mail (and follow-up mails) from
> 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
> The same happened after the phy_link/phy_interface merge.
> 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.
> 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.
> For osmo-bts-sysmo, it is clear that sysmocom has such a vital interest,
> and that it is the primary hardware on whcih Holger and I are working
> on. For osmo-bts-octphy, Octasic funds related maintenance work to be
> done at sysmocom.
> 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 thus strongly suggest that the users and proponents of osmo-bts-trx
> get together and see how they can ensure the proper maintenance of this
> port. Thanks for your consideration.
> - Harald Welte <laforge at gnumonks.org>
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch.
CEO, Fairwaves, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenBSC