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/.
Choukou Moun choukoumoun at gmail.comTroll : "clash of titans" Sorry im running .....:) Le 4 avr. 2016 22:35, "Alexander Chemeris" <alexander.chemeris at 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 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 >> 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 >> -- >> - Harald Welte <laforge at gnumonks.org> >> http://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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160404/af70eeff/attachment.htm>