Hi Neels,
On Sat, Sep 02, 2017 at 01:29:27AM +0200, Neels Hofmeyr wrote:
If we really require to strictly treat git trees as *either* library *or* program project, we would need to do a lot more splitting. It seems to me that we unfortunately rather should have more complex helpers instead.
ACK. I also don't see why users should have to deal with even more repositories just so that the maintainer can have simpler scripts.
I'll soon bump the new osmo-{msc,bsc,mgw,sgsn} repositories to version 2.0.0, so I need to look at the new release process anyway. Let me comment on that in a separate mail. I hope that I will thus gain a better understanding of the difference or complexity from mixing libraries with programs. (https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release) I still want some more tweaks to go into the new repositories before bumping, but can review releasing now as good as any other time.
You could also do a 1.99.0 before as an exercise :)
The osmo-sgsn rename is something I've been pondering in the laforge/osmo-sgsn
- I assume typo: osmo-ggsn
branch where the VTY is introduced. I've almost decided against it meanwhile, given that > 90% of the code still is OpenGGSN code, and credit belongs to the creators of that and not to Osmocom.
If we are the sole maintainers now, it makes sense to embed openggsn in our naming scheme of osmo-* and libosmo-*, especially when openbsc.git is gone. We should still credit the origins in README and/or header comments of course.
Ok, then let's aim for that.
There is some sense in separating lib(osmo-)gtp from the GGSN, i.e. that building osmo-sgsn only needs the GTP lib and not the GGSN binary. But I have listed numerous similar instances above, so no real reason to split.
I agree, no split (for now).
IOW, install libosmo-gtp and osmo-ggsn from a joint osmo-ggsn.git. But I'm unsure about: if we rename libgtp to libosmo-gtp, do we confuse the hell out of the rest of the world? So far I found 'libgtp' confusing ("is it osmocom??").
well, we didn't reinvent the wheel where it wasn't required (such as libgtp and libsmpp34).
In any case, this now is an ideal time to do renames like this, while we're busy rejiggering half the core network anyway. It will just be part of the new way that everyone needs to adjust to.
I would time a rename with the introduction of significant user-visible changes.
For the GGSN, this is when the VTY is introduced (ggsn binary to osmo-ggsn, which is already in a branch and could be merged any day.
For libgtp, I would time this with introducing all the API/ABI breakage needed for maintaining pdp contexts per GSN and for supporting IPv6 transport layer addresses. This has currently not been a priority, though :/
Regards, Harald