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

[Daniel-Constantin Mierla]

Hello,

On 06/15/05 16:59, Cesc wrote:

>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
>
see my previous mail to know exactly how it was.

> 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.
>  
>
It is exactly what openser aims. I may leave for 6 month for an island 
to drink and smoke, the community should not wait for me ... Hopefully 
this situation could have been avoided if some would accept to delegate 
a replacement maintainers if they have no time. Half an year is way too 
much, as it was pointed out, many users requested new features from 
unstable to be released as stable (e.g., lcr), should they wait another 
half an year?!? They tested, they are using it for long time, so I think 
they are right.

>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.
>  
>
I already sent my contribution there. Waiting now ...

Daniel

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