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 Neels,
On Thu, Mar 16, 2017 at 08:31:57PM +0100, Neels Hofmeyr wrote:
> It seems that we won't be merging vlr_2G or vlr_3G into openbsc.git's
> master, at least not soon. Instead we're likely to move to a new git
> repository altogether to mark the changed setup.
yes, I think basically as soon as the naming is clear. Do you have any
ideas?
The [post-VLR] repository currently contains the following main programs
(excluding various utilities like abisip-find, isdnsync, measurement
stuff, ... :
* osmo-bsc
* osmo-bsc_nat
* osmo-msc (NITB without HLR and BSC)
On the GPRS side we have
* osmo-sgsn
* osmo-gbproxy
* osmo-gtphub
So in terms of clean-up, one of the questions is: what exactly do the
circuit switched programs share with the packet-switched ones? Maybe
there's a chance for even splitting up those two unrelated parts?
But whether CS+PS are still in one repo, or whether they will continue
in two repositories: The question of naming is the difficult one.
Getting rid of the OpenBSC name is good. It served us well initially,
but it is a mis-nomer for a long time. Osmocom is very generic and
covers all the various projects, even those not 3GPP related.
In redmine we have the 'cellular infrastructure' project as a parent to
all the 2G/3G related projects. Maybe we should call it
'osmo-cell-infra', 'osmo-2g3g' or even more generic 'osmo-cellular'?
that's actually again a bit too generic, as the BTS and PCU are prime
example of other cellular infrastructure projects that are not part of
that repo. Also, there's the HLR which lives in a separate repo -
simply because it shares no code with the other projects. Still, it
might actually be worth to consider merging it into the same repo as the
MSC.
Maybe a non-descriptive name should be used? Or, in the great tradition
of the telecom world, yet another acronym?
In general, when we do the "fork" to the new repo, I would like to use
the opportunity to get rid of the extra 'openbsc' sub directory, which
currently really only exists because everyone's spec file / OE recipe /
debian-rules expects it to be that way.
In terms of your question about coverity:
> Any preferences?
I really don't care ;)
--
- 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)