On Feb 24, 2009 at 15:43, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 02/24/2009 01:13 PM, Andrei Pelinescu-Onciul wrote:
Hi,
We've reached the point where we should start adding modules.
indeed, we got to a good milestone already, thanks everybody. I have also couple of kamailio/openser modules updated for sip router, some available for download, but it is better with a repository.
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,
I expect that we will start adding kamailio/openser modules after 1.5.0 release which should happen next Monday/Tuesday.
We had a IRC devel meeting and decided to use the git for development of core and common modules and pull them in SVN so people can take everything from one place, until everything is integrated in git. Practically here the issues are duplicated modules, that will take some time to combine and get all functionalities from both versions in one module.
Great, that would make things much easier.
Henning has some tool in place able to get the sip-router git in SVN. Over time, we will get everything in GIT.
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) - 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. - 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.
Having one for core+tm+common modules and two other for the rest of modules in each side should be ok. Jan's email explains how to get core+ser_modules, it is not very complex.
The problem is not that's it's very complex, the problem is that's too difficult to do development on modules. What Jan did, was create a local branch in his local repository (derived from sip-router = core+ common) and then merge/pull into it ser modules (from the ser_modules repo). This is easy and good for testing. However suppose I do a fix/update to the tls module. Now if I want to push the changes to ser_modules things get complicated: I cannot push directly, because that would push also core+tm in ser_modules, so I have to checkout the ser_modules repository, apply all the changes to tls I did in my local repo (either using git cherry-pick or plain old diff & patch) and then push the changes back. So for every module change (which I expect to happen quite frequently) there are more steps involved.
I do not like working on three repos with replicated code tree -- to much overhead to manage and quite exposed to mistakes. I am already tired of tracking core+tm in sip-router and kamailio. Each piece of code should reside in one place, with proper documentation of how to fetch them to get entire source tree.
I think (1) or (2) are superior to working with separate modules only repositories (let's name this option (3)), because of the less steps involved in pushing changes to modules. One would still have to use more steps when changing core, but that happens less.
Actually I'm slightly in favor of using the sip-router repo with ser and kamailio branches (1). I don't find (2) bad either. The biggest danger is somebody pushing by mistake the whole kamailio or ser into the master branch, but we could restrict the access to the master branch to only a small number of people and if a big mistake would happen we can still revert (albeit everybody who updated in the meantime would have to do a git fetch -f).
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).
3 sounds like a good idea as major for version number. The issue I see with v.v.X is just one number for project releases, while both used 2, last one being for minor/patch releases. I expect core releases to be less often, so we can have v.X.X, or to use 4 numbers for relase v.v.X.X, but this is not very common.
At least in the beginning I hope core changes will happen quite often (I have a huge backlog :-)). The problem with 3.x.y is what happens when we release a new core, do we go to 4?
What's important is to (very) quickly decide on the repository layout (because this will slow us down) and on the names for the branches or for the different repos.
I guess I map myself better to second choice you proposed (hope I got it right, kamailio-ng pulling sip-router from sip-router repo and kamailio modules from "k modules" repo).
Actually what I meant was:
kamailio-ng = sip-router + kamailio_modules, where kamailio_modules is a read-only repository (it's just for svn->git). All modules developement goes on kamailio-ng. The core is merged from time to time from sip-router.
With git you cannot push only a subtree (so if you have sip-router + modules and you do a push everything will be pushed), so it's hard to work with a separate module-only repository. It would be nice to have completely separated modules and core repos, but that would involve extra steps both for changes to core and modules. Given the alternative I think easier to change/work-on modules are preferable to the core (to work on a module in general you need the core for testing, while for working on the core you need the modules only in some limited cases).
Things like using git submodules will not work because we do no have completely separated directories (it would work only if we would have a /common dir and a /project_specific dir). There is also the alternative of declaring each module as a git submodule, but that would be a lot of work and would make for lots of repositories (we would need one repository for _each_ module, so for both project we will end up with something close to 150 repositories).
Andrei
[...]