Lack of maintenance for osmo-bts-trx
choukoumoun at gmail.com
Mon Apr 4 21:04:04 UTC 2016
Troll : "clash of titans"
Sorry im running .....:)
Le 4 avr. 2016 22:35, "Alexander Chemeris" <alexander.chemeris at gmail.com> a
> Hi Harald,
> 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.
> Alexander Chemeris.
> CEO, Fairwaves, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenBSC