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/.
Tom Tsou tom.tsou at ettus.comHi Harald, On Mon, Apr 4, 2016 at 8:10 AM, Harald Welte <laforge at 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