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

[Daniel-Constantin Mierla]

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.

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.

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.

>
> 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.

>
> 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).

Cheers,
Daniel

> Once this is decided we want to quickly make a test ser version based
> on sip-router and start testing it. If everything looks ok we want to
> start using it on iptel.org.
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com