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/.
Harald Welte laforge at gnumonks.orgHi 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 at 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.
--
- 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)