[SR-Dev] [Serdev] sip-router: modules & repositories

[Jan Janak]

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

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

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.