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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)