httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: cvs commit: httpd-2.0 STATUS ROADMAP
Date Sat, 23 Nov 2002 20:20:59 GMT

On Saturday, November 23, 2002, at 11:51  AM, William A. Rowe, Jr. 

> At 01:25 PM 11/23/2002, Aaron Bannert wrote:
>> On Saturday, November 23, 2002, at 11:15  AM, wrote:
>>>  +    * This branch is operating under R-T-C guidelines.
>> Huh? No way. We're all adults here. If someone commits something
>> that you are uncomfortable with, bring it up on the list. There's
>> no reason for any ASF project to be R-T-C, IMHO. Our voting
>> rules are sufficient enough to protect against bogus commits to
>> stable or "maintenance" trees.
> One 'advantage' of R-T-C is eliminating the 'last minute breakage'
> of trees as we approach releases.  I understand that most httpd'ers
> haven't operated under R-T-C for a very long time, we enjoy treating
> cvs as a sandbox for rapid development.

It is up to the release manager to decide what goes in to their
own release. If they want to take something that was just committed,
then that's their choice. R-T-C may improve that, but only as
a side-effect of a more global slowing down of commits.

> I think Jeff's original appeal for some known, stable branch (he 
> actually
> asked for in perpetutity) was that the release should not be
> the sandbox for new ideas.


> But I was only interpreting other's comments, committers, how do you
> feel about this policy?  Should we operate C-T-R on 2_0_BRANCH?
> Aaron, if you like, put this to a vote in 2_0_BRANCH'es STATUS.

Let's discuss this a little more, I'm curious what others think. Is
there really a problem now with people committing things that shouldn't
be committed? Take the 1.3 branch for example.

Lets put this another way. Why would we want to stop anyone from 
wherever they wanted?

>   +    * The 'modules/experimental' tree will evaporate soon.  Anything
>>>  +      in the development branch should be located under it's 
>>> eventual
>>>  +      home (such as modules/cache/.)
>> There's no reason to remove this from the 2.0 releases. They are 
>> experimental
>> not matter way, and if someone grabs a 2.0 tarball and wants to start
>> hacking on experimental stuff, all the better!
> I'm taking this from the vote.  Again, if you want to phrase this very 
> specific
> issue as a vote (in 2_0_BRANCH'es STATUS) I sure won't object.

Again, let's discuss this a little more before we jump to vote. Does 
really see a reason to remove this? I'm just thinking that they are 
very explicitly as "experimental", and so by having them there we're not
hurting anything. OTOH, if they are there, maybe it'll give those new
ideas a little visibility in to what we have coming down the pipe, and
maybe encourage some other contributions.


View raw message