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/.
Sukchan Lee acetcom at gmail.comSee 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>