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

[Iqbal]

who going away forr 6 mnths, when and what are they smoking....more 
importantly why are we NOT invited :-)

Iqbal

Daniel-Constantin Mierla wrote:

> 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
>>>
>>>   
>>
>>
>>  
>>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
> .
>