What's next plan?

historical

See inline below.

On Tue, Aug 27, 2019 at 5:10 AM Harald Welte <laforge at gnumonks.org> wrote:

> Hi 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.
>

Also I don't enough knowledge of 5G Core either. I really want to remove
the freeDiameter library in 5G. But DIAMETER still needs to connect the IMS
core on 5G. If true, I need to separate freeDiameter and NextEPC.

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

I missed the library compatibility part. In split repository, I agreed that
it would be really hard to manage this. Hmm..IMHO, I need to reduce the
number of library since my time and ability is limited.

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

I will do it definitely!

>
>
Of course the above is just my opinion.  It's your project, you get to
> decide :)
>

I'm really appreciated for your comments. From your advice, I'll revise the
REPO like the followings.

Repo1 : libogscore - apt install libogscore-dev

Repo2 : libogs-asn1c
   - common : apt install libogs-asn1c-common-dev
   - s1ap : apt install libogs-asn1c-s1ap-dev

Repo3 : libogs-freeDiameter - apt install libogs-freeDiameter-dev
   - libfdcore
   - libfdproto

Repo4 : Changes nextepc to ogs-epc.

Best Regards,
      Sukchan

>
> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190827/650d2f29/attachment.htm>