At 03:01 PM 11/23/2002, Jeff Trawick wrote: >"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > >> At 01:25 PM 11/23/2002, Aaron Bannert wrote: >> >> >On Saturday, November 23, 2002, at 11:15 AM, [EMAIL PROTECTED] 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.
FWIW I agree with Jeff here. I retracted the statement since JimJ, Cliff and Aaron all seem to want to err on the side of C-T-R. So count this R-T-C: Jeff, Will C-T-R: JimJ, Cliff, Aaron More voices are always welcome. Bill
