[Serusers] openser/ser - avoiding forks

Andrei Pelinescu-Onciul andrei at iptel.org
Wed Jun 15 15:06:17 CEST 2005



I think that a fork is bad for everybody. Whatever way you put it, it
will still involve extra overhead at least for each code merge.

So this mail is an attempt to come to a compromise that would be
acceptable for everybody.

My first proposal would be to have another branch on ser cvs (berlios).
Something like openser_0.x.y (where the version number should reflect
somehow that it's newer than 0.9 but not unstable).
Bogdan and Daniel would mantain this branch and they would be able to
release from it as often as they want. It would be some kind of stable
on steroids :-)

This would have the main advantage that code merges/diffs/fixes
propagation would be much easier and much faster. Administrating all the
stuff will be also easier (like common bug tracking system a.s.o).
It would be also easier for users, it will be much more easier to keep
track of the changes and to choose an appropiate version.

There must be however some rules. Something like: backporting/forwadporting
from unstable/stable should be ok, the same for minor patches (e.g. xlog
colors), but not major code changes, not present in unstable and without
the code maintainer approval (to maintain future compatibility).
Adding new stuff (new modules) should also be ok, but it would be
preferable that these module come from either unstable or experimental.

The mailing list for development should remain serdev. For users it
could  be a different one (if the changes or the mail traffic gets too big).


As far as integrating new contributions faster in unstable, I agree that
this is a problem, but I think we can sort it out. The experimental
repository is a beginning and if there are better ideeas on how to speed
things up while maintaing sanity, please speak. Maybe some kind of
reviewed patches (e.g: someone sends a patch that adds a new feature in
core, Bogdan reviews it decides it's ok and  blesses it => I will
integrate much faster something blessed by other ser developer).


If you don't agree with my proposal, please say what you don't like and
what you would like changed so that  it would be acceptable for you.
I'm sure that we can reach a compromise and hopefully improve ser
development pace in the process.



Andrei




More information about the sr-users mailing list