[Kamailio-Devel] [SR-Dev] sip-router: modules & repositories

[Andrei Pelinescu-Onciul]

On Feb 24, 2009 at 15:43, Daniel-Constantin Mierla <miconda at 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:
> >
> >1. 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)
> >
> >2. 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

[...]