Return-Path: Mailing-List: contact community-help@apache.org; run by ezmlm Delivered-To: mailing list community@apache.org Received: (qmail 21885 invoked from network); 8 Nov 2002 23:48:26 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 8 Nov 2002 23:48:26 -0000 Received: (qmail 16116 invoked from network); 8 Nov 2002 23:48:32 -0000 Received: from unknown (HELO apache.org) (217.158.110.78) by pulse.betaversion.org with SMTP; 8 Nov 2002 23:48:32 -0000 Message-ID: <3DCC4D57.5090807@apache.org> Date: Fri, 08 Nov 2002 23:48:39 +0000 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: community@apache.org Subject: Re: Rules for Revolutionaries References: <3DCBEF1C.CB7D6174@Golux.Com> <3DCC318F.8070408@apache.org> <1036793103.1927.746.camel@costinm.sfo.covalent.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Costin Manolache wrote: > 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 --------------------------------------------------------------------