From dev-return-1623-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Mar 08 00:10:02 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 78540 invoked by uid 500); 8 Mar 2001 00:09:57 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 78496 invoked from network); 8 Mar 2001 00:09:54 -0000 Date: Wed, 7 Mar 2001 16:08:40 -0800 From: "Roy T. Fielding" To: rbb@covalent.net Cc: new-httpd@apache.org, dev@apr.apache.org Subject: Re: httpd-2.0/apr/apr-util Code Freeze Message-ID: <20010307160840.D818@waka.ebuilt.net> Mail-Followup-To: "Roy T. Fielding" , rbb@covalent.net, new-httpd@apache.org, dev@apr.apache.org References: <056201c0a724$c53e2760$96c0b0d0@roweclan.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: ; from rbb@covalent.net on Wed, Mar 07, 2001 at 09:00:36AM -0800 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > I agree, the no-freeze model just doesn't work in this environment. The no-freeze model hasn't even been tested in this environment. It is necessary for the code to be in a stable state in order to do a release at any time, regardless of a freeze. At no time in the past six months has the code been in a stable state, regardless of how many times you have called for and implemented a freeze. The code isn't going to get any better if you prevent people from fixing the problems. What has happened over the past month is is that some of the things that need doing which require more than a few hours effort to get right are actually being done, because we don't have to worry about someone else's arbitrary notion of a release date. I have no intention of stopping that now just because some people get their panties in a bind. If you want to create a release based on an ongoing frantic development tree, all you have to do is selectively tag the repository to include only those revisions that you consider to be stable. There is no rule that requires the entire HEAD to be tagged at once, and there is nothing wrong with moving tags from one revision to another within CVS *provided* that such moves are made before a tarball based on that tag is released. ....Roy