httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: New commit rules
Date Sat, 10 Jan 1998 18:39:00 GMT
I would have to say that I agree with Pauls concerns and ideas.

I would ask that everyone read over again the current voting
guidelines, not for what's said specifically, but the tone that
runs through everything. And, with that in mind, let's maintain that
"feeling" with the implementation of the new development process.

(eg: even the Lazy Voting mode has a caveat that if one plans
 on using that, it must be specifically mentioned that the
 patcher plans on using the LV mode... it's obvious that throughout
 the present voting guidelines there is a real desire to make
 sure that everyone knows whats going one, and that "prolific"
 do not have more say in Apache's development than other
 team members).

Paul Sutton wrote:
> 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 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.

A clear guide for what direction we want Apache to take will go
a long way. Here's the reason; team members come and go, people
who are doing serious coding right now will eventually cool
down, and which point one or more coding maniacs will take up
the slack. Unless we have a clear goal, during these phases Apache
could zig-zag if the direction is defined by the present maniacs
rather than the team as a guide. One of the strengths of the Apache
team isn't the capability or the wizardry of it's coding, but the
experience of the team combined with people with the talent to
implement that.

      Jim Jagielski            |       jaguNET Access Services           |
            "Look at me! I'm wearing a cardboard belt!"

View raw message