Hi 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 ;)