This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/nextepc@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Sukchan,
thanks for sharing your thoughts.
On Fri, Aug 23, 2019 at 09:00:34PM +0900, Sukchan Lee wrote:
> Anyway, in order to share the code used by 4G/5G, I will separate the
> repository as follows:
> [...]
In general, I think it may make sense to split things up, but only to the extent
that the related [library] code is really going to be used by multiple applications
which logically don't belong together.
I currently don't know sufficiently about 5G to know how much of the
existing code would be needed in a 5G core. For example, I don't think
DIAMETER is used in a true/native 5G core.
> This approach is similar to the osmocom project. In fact, I'm not sure
> whether this is good or not. However, osmocom manages 2G/3G like this and I
> believe that experience.
Beware there are consequences. For example, if you have libraries in a
separate repository, you must be very careful about maintaining ABI and
API compatibility, as well as managing LIBVERSION properly. This means
in general it's best to never modify any existing symbol (function) but
to only introduce new ones. Otherwise a library upgrade without
application upgrade would break.
Also, you typically want to ensure backwards API compatibility, so that
any old application can be build with any new library version. In order
to ensure this, it is best to have automatic testing that e.g. builds
all old/existing tags of applications against the 'master of the day'
of libraries.
So given the limited resources (time/developers), it requires careful
thinking whether all the related overhead makes sense. Some things can
be automatized, but it also requires quite a bit of discipline from the
developer[s]. So be warned :P
> Please, feel free to give any idea the above plan. Expecially, 'NAMING'. ^^;
I think it's a good idea to avoid nextepc naming confusion related to
the U.S. entity nextepc inc. using an older codebase and your new
project.
I agree it is a good idea to separate any shared libraries into separate
repositories, but only *if* they are used by multiple other
repositories, and if you are committed to providing a rather stable API
and ABI.
I am not sure if moving towards the full set of repositories as
described is the best choice at this point. It might be an idea to only
separate those which you will need from your new 5G core elements?
by the way: When creating the new repositories, make sure the git
history remains. You can create the new repositories using 'git
filter-branch' of the current nextepc.git repository, keeping the
history of all the relevant commits. Finally, you can then rename/move
files in one new commit.
The git commit history is just as important or sometimes even more
important for any future developers than the actual code.
Of course the above is just my opinion. It's your project, you get to
decide :)
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)