[OpenSER-Devel] Call for opinion - new rules for the release process

[Daniel-Constantin Mierla]

Hello,

On 06/20/08 00:45, Dan Pascu wrote:
> On Monday 09 June 2008, Bogdan-Andrei Iancu wrote:
>   
>> Hi,
>>
>> In the last days, there was an obvious need for more strict rules to
>> control the process of preparing new release.
>>     
>
> It is one of the common myths that more strict rules provide better 
> control over the unexpected or even the expected. In practice, they are 
> only providing extra annoyances to those that wish to respect them and no 
> protection from those that want to abuse them. Otherwise, all the copy 
> protection systems invented in the world should have stopped piracy by 
> now, instead they have only made it flourish and the result is that 
> people going against the system have it easier and with less annoyances 
> that people who are working within the system and got legal copies.
>
> What we need in this particular context is people that are more 
> responsible, more tolerant and more willing to work together to improve 
> this software than fighting each other. In this context a simple set of 
> rules, which are there only to provide a common ground and a common point 
> of reference for all developers would suffice. Otherwise we can add as 
> many and strict rules as we want, they will never prevent someone who 
> wants to pick the horse teeth from doing so, but instead will become a 
> certain source of annoyances for people that wish to respect the system.
>   

I second that. The open source project is in the first place a 
collaborative environment. Unless people accept that and become aware 
that they must be open for discussions, allow the others time for 
integration so everything works as expected, coherent and robust, 
thousands of rules offer no protection.

All involved in such project invested resources: time, money, knowledge, 
a.s.o. Some have their head between running openser with 2 million users 
and the boss, some guarantee in personal name for the quality of this 
application, some run and rely the business (and advertise that) on 
openser. Nobody wants a bad product, just a better one.

Cheers,
Daniel


> This may not matter for core developers, but contributors will certainly 
> be put off if they have to do a lot of work only to get their work 
> accepted.
>
>   
>> Now, there was some unhappy people because some code (neither minor,
>> neither major) was committed into SVN with one day before the freeze.
>> Reason were more or less "religious" as no rules was broken or anything
>> broken (on the contrary, it was new functionality, a quite needed one).
>>
>> So, I suggest putting more strict rules to avoid any "religious" reason
>> when come to committing new code on SVN.
>>     
>
> That is the point. By using another rule, you cannot avoid _any_ religious 
> or non-religious reason in the future. You _may_ avoid at most the reason 
> for which it was introduced, but even in that case people may find ways 
> to interpret a future case as not falling under that rule.
>
>   
>> Some ideas for new rules (resulting from a discussion with Olle
>> Johansson from Asterisk):
>>
>>     - Major commits (new modules, design and architectural changes) no
>> sooner then one month before the freeze
>>     
>
> I agree that big changes, that affect architecture and change things in a 
> significant matter should not be committed in the last minute. But then 
> we need to define what big changes mean, otherwise my opinion is as good 
> as anybody's else. If we consider this example of the local_route, some 
> consider it a big change, some others do not. So even with this new rule 
> in place a religious dispute about it could not have been avoided.
>
> As for major changes I do not think we should include new modules here. In 
> my opinion, a major change is something that affects other developers, in 
> a way that they need to analyze the change and adapt their code to work 
> properly with it. A new module affects none else. As an example I would 
> not consider a signature change for a function in the core as a major 
> change, because even though it affects others is an automatic change that 
> needs no analysis and intervention and can be automatically done for all 
> modules as a bug fix.
>
>   
>>     - other commits - any time before the freeze.
>>
>>     - any major commit must be followed by a detailed description
>> (devel+users) mailing list to inform people about the new stuff and to
>> give them a chance to have a word about.
>>
>>     - major commits (see above definitions) should not be made without
>> a prior discussion on the devel+users list.
>>     
>
> I disagree that any development should be discussed on the users list. 
> People interested in development should be subscribed on the devel list, 
> that is its purpose. The users list is for discussing usage cases and 
> help with using openser. I for one am not subscribed there because I find 
> the signal noise ratio to be too low. If I'm required to discuss my work 
> there, where Joe Doe who doesn't even know how to use openser properly, 
> yet he somehow has ideas of how to develop it, I think I would rather 
> keep my work private and not publish anything anymore. As I said, the 
> more work one is required to do to get something integrated, the less 
> willing to do so he'll be.
>
>
>   

-- 
http://www.asipto.com