Re: coverity scan for vlr_2G and vlr_3G

Hi Neels, On Thu, Mar 16, 2017 at 08:31:57PM +0100, Neels Hofmeyr wrote: 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: I really don't care ;) -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)