[Serusers] Re: [Serdev] openser/ser - avoiding forks

[Cesc]

Hi,

Finally we move from philosophy to specifics. 

I think there are 3 parties involved in here: iptel, voice-systems and
users. Iptel and voice-systems have their own agenda's, and fights
between them end up harming users.

The project model started by iptel took us very far and made ser a
great application,
but it's own success should make them realize that changes are needed.
Greger's and Iqbal's email are I think mostly right and layout a good
view of what is going on here. And Andrei's email is a good way to
start "peace talks".

Clearly, SER has grown far so that different interests apply and this
has caused friction.
Friction means there is a problem. I do think that forking is not the
best solution, but
things MUST change. 
Contributions must have an easy way into SER: starting maybe as
experimental, then moving into unstable, then as testing and finally
into stable (kind of debian approach). And this process must be
well-defined and NOT CONTROLLED exclusively by a company (be iptel or
voice-systems, same-o, same-o). If the contribution is voted as
desirable by a community of users, it is well tested and so on, it
should be accepted.
TLS is only the first, but what will happen when someone develops a
free-LDAP module  (actually, i think there is one ... just never
became  mainstream) or any other module which now is kept private by
iptel/voice-systems?? If SER is opensource, let it be the whole way.

Summarizing ... I think the shake up by the voice-system's guys is
good and desirable,
but now it is time to stick together and work out a compromise which
works for everybody
(and specially for the user).
I think Andrei's email is a good start. Let's work on it.

Cesc


On 6/15/05, Andrei Pelinescu-Onciul <andrei at iptel.org> wrote:
> 
> 
> 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
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>