Message-Id: <199611181716.LAA02137@sierra.zyzzyva.com>
To: Paul Sutton <paul@ukweb.com>, new-httpd@hyperreal.com
Subject: Re: Voting meta-discussion (was Re: cvs commit: apache/src
 mod_rewrite.h Makefile.tmpl (fwd)) 
In-reply-to: paul's message of Mon, 18 Nov 1996 17:59:17 +0000.
         <Pine.LNX.3.95.961118173824.28058B-100000@star.ukweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 18 Nov 1996 11:16:45 -0600
From: Randy Terbush <randy@zyzzyva.com>
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com


While I agree with Paul Sutton's comments here, there are always
shades of grey that need to be accomodated.

One of the primary problems with voting on everything is that there
has be considerable lack of comment/votes on patches, ideas and
design issues. I'm as guilty as anyone lately. It's not due to lack
of interest but rather lack of coherent time. I'm sure it is no
different for any others.

Flexibility is the key...

> On 18 Nov 1996, Paul Richards wrote:
> > I've always been against voting. This is the only project I've ever
> > been involved in that has these procedures and Apache is a lot simpler
> > than most of them. Using cvs the way we have been has accelerated
> > progress considerably. I don't see that we've got a less stable product
> 
> I would prefer not to comment on this, but in case silence is taken as
> agreement I'd just like to make it clear that I disagree with what you say
> here.
> 
> I think:
> 
>   1.  Voting is a valuable part of the development process. It
>       ensures that new features are developed with at least some
>       degree of consistancy, and prevents it being side-tracked
>       by an individual's personal preferences. Whether the 
>       three-vote approval/one-vote veto are correct numbers of
>       votes to use is another issue
> 
>   2.  Voting has no relationship with CVS access rights. I don't
>       think it is helpful to critisise developers who do not
>       use CVS, or try to disenfranchise from from the development
>       process
> 
>   3.  It is wrong to develop code on the principle of first
>       putting it into the current code then taking it out if it fails.
>       New code and features should be discussed first and tested before
>       being applied after an approval vote
> 
>   4.  A feature freeze does not imply a free-for-all to commit their
>       favourite patches just prior to the freeze
> 
> Paul
> UK Web Ltd
>