From dev-return-34722-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Sat Nov 23 20:21:39 2002 Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 63878 invoked by uid 500); 23 Nov 2002 20:21:39 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 63865 invoked from network); 23 Nov 2002 20:21:39 -0000 Date: Sat, 23 Nov 2002 12:20:59 -0800 Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Aaron Bannert To: dev@httpd.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: <5.1.0.14.2.20021123134702.0282aad8@pop3.rowe-clan.net> Message-Id: <145CECA2-FF21-11D6-A8B6-000393B3C494@clove.org> X-Mailer: Apple Mail (2.548) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Saturday, November 23, 2002, at 11:51 AM, William A. Rowe, Jr. wrote: > 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. 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 2.0.43.xxx in perpetutity) was that the release should not be > the sandbox for new ideas. +1 > 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 volunteering 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 anyone really see a reason to remove this? I'm just thinking that they are marked 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. -aaron