On 24-02 12:13, Andrei Pelinescu-Onciul wrote:
Hi,
We've reached the point where we should start adding modules. Me and Jan would like to start moving ser modules to sip-router. ser modules are particularly easy because we can move changes from ser cvs semi-automatically (only a git pull required), so we don't need to stop development on cvs.
Soon we will have to add kamailio modules too, but for kamailio it would be more painful, both because of the bigger number of changes required and because it's difficult to update from svn (so it would be better if all developers would move to git or use patches).
We must decide if we use separate repositories or a branch in sip-router and we should also start thinking about the version number of the first ser and first kamailio based on sip-router.
Repositories:
- we use branches inside sip-router: master - like now, only core, tm and common modules ser_30 - master merged with ser_modules, next version of ser will come out of it kamailio_30 - same like above
Disadvantages: - one big repo - people must be careful _not_ to merge ser_30 or kamailio_30 into master (that would bring all the modules into master which is not what we want)
I would say that this is ultimately what we want to. Ideally we would add more and more modules to the master branch as we expand our common ground. Surely it will be a lenghty process, but from what I can tell so far from my migration attempts of ser and kamailio modules, we should be able to move a decent group of modules to the master branch quickly--should we want to.
If we decide that we will keep both projects as branches inside the main repository, how do we guarantee that people do not commit lots of unrelated stuff into the master branch by accident? This probably calls for some draconian access control rules on the master branch and I am not sure that this is something we should do.
Besides this one big repository will contain commits from both projects, I mean commits in which developers of the other project might not be interested and which are not related to the common parts.
- if someone working on the ser_30 branch (for example) finds a problem in the core and wants to fix it, it has to do it on the master branch.
Switching branches in git is not that convenient if you are in the middle of some bigger changes and you have lots of uncommited changes. That practically means that you would have to clone the repository again, discard your local changes in the new clone and checkout another branch (master). Then you need to switch back to your original repository and merge the changes you just did on the master branch.
Because of this I tend to keep multiple local repositories with different branches checked out, so speaking for myself I am already used to having multiple repositories and having separate repositores would feel natural.
- if the above requirement cannot be avoided and someone does a specific core change in ser_30 or k_30 (e.g. name in makefile), it should always do it in a separate commit (no commits touching both core/tm and some project specific module, instead separate commits for the common part so that they might be cherry-picked)
- we use 3 repositories: sip-router - like now, only the common part: core, tm and common modules ser-ng - sip-router + ser modules kamailio-ng - sip-router + k modules
Advantages: - 3 smaller repos - more difficult to make mistakes and merge kamailio or ser into sip-router/master Disadvantages: - 3 smaller repos :-) - same as for (1)
In general whatever we can do with branches in the same repo we can with branches in different repos, so a complete kamailio-ser merge would not be affected if we use separate repos.
I would personally vote for 3 smaller repositories. If things are separated then people will be less worried about screwing the work of other people, their mistakes will be isolated.
Also pulling/pushing from/to multiple separate repositories, each of which contains parts of a large project is one of the key features of git. This is what is described in most howtos and guides on git.
I have also viewed the repositories we have on git.sip-router.org as nothing more than a rendezvous point, a place where people synchronize their work and where we can do automated things such as doxygen generation, packging, and so on.
Even on my local machine I have several git repositories with various modifications of the ser code.
Version numbers:
I think it would be a good idea to come up with a versioning scheme that would reflect the common part used for future ser and kamailio releases. Maybe 3.x (3 being > then both current ser and kamailio version), or mabye v.v.X , where v.v is the sip-router version (common part) and X is the project version (ser or kamailio).
Yeas, I fully agree.
Jan.