"NITB split" and implications for OsmoSGSN

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.org
Sat Sep 23 04:23:01 UTC 2017


Hi Neels,

On Thu, Sep 21, 2017 at 08:04:26PM +0200, Neels Hofmeyr wrote:
> The entire openbsc.git repository will cease to be used. We will not remove
> parts from it, we will basically lay it to rest as a whole.

This is unrealistic, as there are people who will likely want to
continue to use OsmoNITB for at least some time to come.   I'm thinking
of Rhizomatica or Fairwaves, for example.  Or even various of our 'sysmoBTS starter
kit' users until they do a major upgrade to 201705.  There still might
be the occasional important bug fix that needs to be applied to
openbsc.git

My idea would be: In order to avoid anyone to submit patches against the
GPRS components in there, I think it makes sense to remove those parts
and make sure that we have no two [except for 3G support] identical
copies of the SGSN (plus gtphub, plus gb-proxy) code lying around.  This
will help people who are continuing to use OsmoNITB to get the benefits
of newer versions of SGSN & co, without 'accidentially' sticking to old
versions.

For the remaining NITB code , there should be a strict policy of first
applying any change to OsmoBSC or OsmoMSC, and only then optionally
apply it to openbsc.git.

For sure we should still accept at a minimum clear bug fix commits for
the NITB.  If somebody in the community (or a paying sysmocom customer)
wants to maintain even new features going into the NITB, then we should
simply bless one such person as the legacy NITB maintainer.  The
policy remains: New features and fixes must first be applied to BSC/MSC
and only then to NITB.

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)



More information about the OpenBSC mailing list