httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: cvs commit: httpd-2.0 STATUS ROADMAP
Date Sat, 23 Nov 2002 21:01:54 GMT
"William A. Rowe, Jr." <wrowe@apache.org> writes:

> At 01:25 PM 11/23/2002, Aaron Bannert wrote:
> 
> >On Saturday, November 23, 2002, at 11:15  AM, wrowe@apache.org wrote:
> >>   CURRENT RELEASE NOTES:
> >>
> >>  +    * 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.
> 
> I think Jeff's original appeal for some known, stable branch (he actually
> asked for 2.0.43.xxx 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.

I think that R-T-C is the most likely way we'll get good reviews of
code moved to the stable tree.  I don't see that it is a big burden
that several people have to actually agree with the purpose and
implementation of the patch.  It is very important to avoid the burden
on ourselves and the user community when the occasional patch turns
out to be a bad idea.

The R in C-T-R is often a skim of the change.  Not so rarely, C-T-R is
C-T-something-screws-up-T-R :)  That's okay with dev, where most
people want to travel light and move fast, but that's not okay with
stable (well, if you want to provide a very stable tree to our users
with a minimum of debugging work).

The problem we'll likely have with R-T-C is that people are out of
practice on the R part and sometimes we'll have to nag.  But I think
that is better than an occasionally-disrupted stable tree.  And people
who want to get fixes into the stable tree will be motivated to give
good feedback to colleagues with similar goals.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Mime
View raw message