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/osmocom-net-gprs@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Pablo,
On Thu, Sep 21, 2017 at 01:44:02PM +0200, Pablo Neira Ayuso wrote:
> I understand there are a good reasons for this and that a lot of
> experimentation is going on to consolidate the project.
>
> But it would be good to keep in the horizon to have a more stricter
> policy on breaking backward compatibility, even if there are good
> reason to fix up inconsistent things, or fix in new software, eg.
> osmo-bsc while keeping the current behaviour around in the legacy
> openbsc.git tree.
That's of course hard if the given code is part of libosmocore, which is
used by all osmocom programs. However, you can (and will be able to)
build osmo-nitb still against older versions of libosmocore to retain
the old behavior.
One could of course introduce a runtime swithc or (beware) a
compile-time switch. But then, you also have to maintain two sets of
documentation, test both behaviours from the VTY tests, etc. - and the
effort quickly explodes.
> I don't want to create any long debate on this, just an observation.
Your thoughts are much appreciated, and I know that this is a
contentious issue.
The problem is that with the constant scarcity of resources and the
limited funding (and even more so, code contributions) to cover an
extremely large problem space - basically the entire 2G/3G cellular
network architecture, covering all network elements and all layers of
each of the protocol stacks on its interfaces. Supporting too many
different 'ways of doing things' is going make the matrix explode beyond
what a small team can manage to develop and maintain. We have to invest
our time wisely.
So, sometimes in earlier days there were now seemingly stupid choices
that we need to change later on. Or we inherited code with properties
that were not fully understood (like the VTY code from zebra/quagga,
with its "implicitly try commands of the parent node" feature that
caused fall-out now and had to be fixed).
Those kind of changes are not introduced lightly, and only when we see
no real alternative. What we could and probably should do better is to
properly document this, e.g. in form of a manually written changelog
that gets published at the time we tag a new version of a given project,
That changlog update should be part of the patch that introduces some
compatibility related code change. But if ti is missed, that changelog
update could also come from another developer or user who finds out and
who wants to ensure nobody else falls into the same trap.
The other thing we can possibly do is some scripts that can aid in the
conversion, like a "fix the indenting of my config file" script that you
can run once during a related upgrade.
At some point we intend to have formal "Osmocom releases", which would
then receive some amount of maintenance and bugfix backporting.
However, once again this consumes considerable resources. Putting all
this on sysmocom shoulders is unlikely to work. We will need some
people with significant interest in that to step up and say "yes, I'll
maintain Release X" similar to e.g. a given -stable maintainer of the
kernel.
We've tried to bundle a lot of the large changes with the NITB-split to
make sure there's going to be one time when people do that migration
where all even technically unrelated changes happen at once. That's for
example the OpenGGSN->OsmoGGSN transition, whih has nothing to do with
the NITB, but we thought it's a good idea to do that at the same time so
people migrating from NITB to BSC+MSC+HLR will not have to do one change
per month but all of them together.
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)