<div><div dir="ltr"><div>See inline below.</div><div><br></div><div class="gmail_quote"></div></div></div><div><div dir="ltr" class="gmail_attr">On Tue, Aug 27, 2019 at 5:10 AM Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sukchan,<br>
<br>
thanks for sharing your thoughts.<br>
<br>
On Fri, Aug 23, 2019 at 09:00:34PM +0900, Sukchan Lee wrote:<br>
> Anyway, in order to share the code used by 4G/5G, I will separate the<br>
> repository as follows:<br>
> [...]<br>
<br>
In general, I think it may make sense to split things up, but only to the extent<br>
that the related [library] code is really going to be used by multiple applications<br>
which logically don't belong together.<br>
<br>
I currently don't know sufficiently about 5G to know how much of the<br>
existing code would be needed in a 5G core. For example, I don't think<br>
DIAMETER is used in a true/native 5G core.<br></blockquote><div><br></div></div><div><div>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.</div></div><div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> This approach is similar to the osmocom project. In fact, I'm not sure<br>
> whether this is good or not. However, osmocom manages 2G/3G like this and I<br>
> believe that experience.<br>
<br>
Beware there are consequences. For example, if you have libraries in a<br>
separate repository, you must be very careful about maintaining ABI and<br>
API compatibility, as well as managing LIBVERSION properly. This means<br>
in general it's best to never modify any existing symbol (function) but<br>
to only introduce new ones. Otherwise a library upgrade without<br>
application upgrade would break.<br>
<br>
Also, you typically want to ensure backwards API compatibility, so that<br>
any old application can be build with any new library version. In order<br>
to ensure this, it is best to have automatic testing that e.g. builds<br>
all old/existing tags of applications against the 'master of the day'<br>
of libraries.<br>
<br>
So given the limited resources (time/developers), it requires careful<br>
thinking whether all the related overhead makes sense. Some things can<br>
be automatized, but it also requires quite a bit of discipline from the<br>
developer[s]. So be warned :P<br></blockquote><div><br></div></div><div><div><div>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.</div></div></div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Please, feel free to give any idea the above plan. Expecially, 'NAMING'. ^^;<br>
<br>
I think it's a good idea to avoid nextepc naming confusion related to<br>
the U.S. entity nextepc inc. using an older codebase and your new<br>
project.<br>
<br>
I agree it is a good idea to separate any shared libraries into separate<br>
repositories, but only *if* they are used by multiple other<br>
repositories, and if you are committed to providing a rather stable API<br>
and ABI.<br>
<br>
I am not sure if moving towards the full set of repositories as<br>
described is the best choice at this point. It might be an idea to only<br>
separate those which you will need from your new 5G core elements?<br>
<br>
by the way: When creating the new repositories, make sure the git<br>
history remains. You can create the new repositories using 'git<br>
filter-branch' of the current nextepc.git repository, keeping the<br>
history of all the relevant commits. Finally, you can then rename/move<br>
files in one new commit.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The git commit history is just as important or sometimes even more<br>
important for any future developers than the actual code.</blockquote><div><br></div></div><div><div>I will do it definitely!</div></div><div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course the above is just my opinion. It's your project, you get to<br>
decide :)<br></blockquote><div><br></div></div><div><div>I'm really appreciated for your comments. From your advice, I'll revise the REPO like the followings.</div><div><br></div><div></div></div><div><div>Repo1 : libogscore - apt install libogscore-dev</div><div dir="auto"><br></div><div dir="auto">Repo2 : libogs-asn1c </div><div dir="auto"> - common : apt install libogs-asn1c-common-dev</div><div dir="auto"> - s1ap : apt install libogs-asn1c-s1ap-dev</div><div dir="auto"><br></div><div dir="auto">Repo3 : libogs-freeDiameter - apt install libogs-freeDiameter-dev</div><div dir="auto"><div dir="auto"> - libfdcore</div><div> - libfdproto</div></div><div dir="auto"><br></div></div><div><div><div>Repo4 : Changes nextepc to ogs-epc.<br></div><div><br></div><div>Best Regards,</div><div> Sukchan</div><div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,해</blockquote></div><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Harald<br>
-- <br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" rel="noreferrer" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
</blockquote></div></div>
</div>