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

[Dan Pascu]

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.

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.


-- 
Dan