httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: Voting meta-discussion (was Re: cvs commit: apache/src
Date Mon, 18 Nov 1996 19:43:49 GMT
Paul Richards wrote:

>Paul Sutton <> writes:
>>   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
>I disagree with this. You're advocating that cvs be used to combine
>code after it has been tested, this is going back to the patch-n-vote
>days where we'd have to apply patches on our own boxes to test them
>out before they go into cvs. This is very difficult to do, it was then
>and it would be more so now, with more frequent contributions.

This is not my idea of how it'd work or Paul Sutton's I'd suspect.

All that's being asked is that people agree to stuff being added to the
cvs tree before it is committed.

For 1.2b1 and "satisfy" I asked that only something that had been tried
and tested be added. As the release date nears, it's more important to
keep commits to a minimum and only for stuff that doesn't need to be
pulled out within an hour of being committed.

For 2.0 and beyond, I'd like to see the voting used to okay ideas before
they're committed. There'll be more time to test after comitting than we
have now for 1.2b1. Voting before 1.2b1 commits focuses everyone on what's
going in at the last minute. Perhaps when there's more time, we can say
that voting +1 on a commit means you agree with the idea and are
willing (or already have) tested it.

>None of the strong advocates of voting have yet shown why the current
>development practices are failing? Is Apache any less stable?

The beta users will tell us that. I'd hope it isn't less stable.

>My view
>is that a hell of a lot more progress has been made since we started
>using cvs than when we had to patch-n-vote.

That's clear and nobody will deny that, but at the same time we've also
lost a valuable tool that introduced order, more testing and wider

>>   4.  A feature freeze does not imply a free-for-all to commit their
>>       favourite patches just prior to the freeze
>This was hardly a free for all. The desire for a satisfy patch has
>been there all along and all I did was take item no 1 off Rob's todo
>list and actually do it.

The motivation was good, but the execution left a lot to be desired. Had
you offered the patch last night, you would not have gained enough support
to get it committed. It would have saved Roy from undoing it and everyone
else jumping on your back.

View raw message