26 Feb
2009
26 Feb
'09
3:15 a.m.
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.