Date: Sat, 10 Jan 1998 17:45:59 +0000 (GMT)
From: Paul Sutton <paul@eu.c2.net>
To: new-httpd@apache.org
Subject: New commit rules
In-Reply-To: <19980109225929.3930.qmail@hyperreal.org>
Message-ID: <Pine.LNX.3.96.980110173806.14700H-100000@ecstasy.localnet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

I think the new commit rules look good, although I'd would still prefer on
balnce the current review-then-commit model. The reason is that that
Apache is a democratic process where all participants have a roughly equal
interest in the direction Apache takes. The risk with commit-then-review
is that the overall development path could be determined by those who do
the most active coding, at the expense of those who concentrate on (say)
documentation or bug-tracking/solving. I'm not saying that this will
happen, but as people change over time it could. I think we should
remember that Apache is a product that happens to be free, and we should
try, within the limits of such a loose organisation, to ensure that we
follow a considered development path.

On 9 Jan 1998 brian@hyperreal.org wrote:
>   <LI> Experimental new features must be discussed before implemented

If commit-then-review is implemented, I'd like to see this item changed to
the unqualified:

  <LI>New features must be discussed before implemented

Otherwise anyone implementing a new feature, whether required or not,
could call it experimental and get it into the code base. Every new
feature should be discussion in advance to ensure that the feature is
desired, useful and not going to bloat or otherwise negatively impact
Apache. 

There should also be some rules to enable us to change the
commit-then-review process at critical times (say, the week before a final
release), which should be under the control of the release manager.

//pcs