RFC: OpenGGSN split/rename

historical

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