In my personal opinion they are just redundant :-)
The rule that matter is that the community control the code and the name - a majority vote in the community can decide ultimately what happens.
Agreed. At the same time, I would love to see something written down about 'how the ASF guidelines are'. They might not be binding, just recommendations, but I think this will help a lot communities becaue these guidelines are distilled after years of try/fail cycles (and lot of pain!)
This is a particular case ( again IMO ) of the "releases are majority
votes and can't be vetoed".
Definately agree.
A side effect of the 'revolution' rules is that a veto can be overriden - nobody can veto a revolution ( or a release ), and if you change the entire code base or a part of it you obviously can make changes that were vetoed.
Pier, Fede and I were talking about exactly this last night: I think the committer that proposes an internal fork looses the right to veto a release. Not to vote, but to veto. That's a very important distinction.
There are few important consequences:
1. No person ( or group ) can control a codebase by using veto. It is quite easy to find technical reasons against anything.
Agreed.
2. It removes some personal conflicts. A veto or someone blocking an idea can be painful. It's a big difference between a majority voting against a particular idea and one person vetoing it.
Same here.
3. To take tomcat as an example - it allows diverging groups or opinions to find the common ground. And that's the really great part IMO.
4. Some good ideas that may otherwise be rejected can eventually live.
perfectly agree with you 100%.
-- Stefano Mazzocchi <[EMAIL PROTECTED]> --------------------------------------------------------------------
