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 Fairwaves).
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: http://lists.osmocom.org/pipermail/openbsc/2014-August/007657.html
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 http://lists.osmocom.org/pipermail/openbsc/2015-September/000379.html
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 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 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.
Regards, Harald
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@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 Fairwaves).
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: http://lists.osmocom.org/pipermail/openbsc/2014-August/007657.html
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 http://lists.osmocom.org/pipermail/openbsc/2015-September/000379.html
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
- consistently follows the developments in master and checks for regressiosn
- 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
- tests interoperability with OsmoTRX and other OpenBTS transceivers out three
- 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.
Regards, Harald --
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Troll : "clash of titans" Sorry im running .....:) Le 4 avr. 2016 22:35, "Alexander Chemeris" alexander.chemeris@gmail.com a écrit :
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@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 Fairwaves).
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: http://lists.osmocom.org/pipermail/openbsc/2014-August/007657.html
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 http://lists.osmocom.org/pipermail/openbsc/2015-September/000379.html
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
- consistently follows the developments in master and checks for regressiosn
- 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
- tests interoperability with OsmoTRX and other OpenBTS transceivers out three
- 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.
Regards, Harald --
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
-- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co
Hi Alexander,
On Mon, Apr 04, 2016 at 09:35:31PM +0100, Alexander Chemeris wrote:
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.
Indeed it took long to get L1SAP tested + merged. To be fair though, L1SAP was the single biggest infrastructure change in the history of the OsmoBTS project, and even careful review didn't prevent a lot of fall-out from the merge which we subsequently had to fix.
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.
I very well understand the need for _also_ maintaining a stable branch for existing users, of course. That's a frequent pratise and makes a lot of sense.
But companies with a lot of experience in FOSS (e.g. Redhat in case of the Linux kernel) have long adopted an "upstream first" policy, i.e. you first fix a bug or add a feature in master and submit it upstream, and then back-port it to your stable version(s). That's the only sustainable way in the long term, rather than spending more and more time catching up and forward-porting an every growing pile of out-of-master patches.
But the question the even goes as far as 'why have osmo-bts-trx in master then in the first place?'. Now I certainly don't want to intentionally push anything out of master, but what's the point of keeping something in master for many months (August 2015 to April 2016) if it is known to be broken, and none of the users or proponents of the respective hardware have the interest or time in investigating and/or fixing it? It just creats a situation that's confusing to everyone involved, including the users.
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.
But where is the detailed analysis? Where are the related fixes submitted to the mailing lists?
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.
Thanks. Then we "just" have to find somebody who finally, after many months of apparently/allegedly broken master, thinks it is worth to investigate the actual issue or issues that may exist.
On Mon, Apr 4, 2016 at 4:10 PM, Harald Welte laforge@gnumonks.org wrote: [...]
As an unrelated side note, I would appreciate if you could avoid top-posting/full-quoting on the mailing lists, if possible. Just a friendly reminder, I'd like to avoid anyone interpreting more into that.
On 04/04/2016 16:10, Harald Welte 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 Fairwaves).
Hi all,
I also am interested in this topic, as a user of Osmo* with a USRP SDR, which is what I have right now at home for doing tests involving an MS. Also because I assume that diversity in hardware cannot be a bad thing for the community GSM projects that are happening, ours included.
I'm not a programmer and would not expect to be submitting patches at this level, but I can help with testing and going forward, hopefully contributing in other ways.
More than anything I just wanted to add another voice to the support for getting Harald's concerns sorted out, and having a working master branch to support SDR hardware including such as BladeRF, or more economically accessable options that may become available in the future.
Keith.
-
'kino más -
Alexander Chemeris -
Choukou Moun -
Harald Welte