Hi Sukchan, thanks for sharing your thoughts. On Fri, Aug 23, 2019 at 09:00:34PM +0900, Sukchan Lee wrote: 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. 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 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(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)