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 _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
