From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7624 invoked by alias); 29 Jun 2005 20:40:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7572 invoked by uid 22791); 29 Jun 2005 20:40:00 -0000 Received: from dumbledore.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.11) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 29 Jun 2005 20:40:00 +0000 Received: (qmail 7692 invoked from network); 29 Jun 2005 20:39:58 -0000 Received: from unknown (HELO ?10.253.176.18?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Jun 2005 20:39:58 -0000 Message-ID: <42C30712.5070109@codesourcery.com> Date: Wed, 29 Jun 2005 20:40:00 -0000 From: Mark Mitchell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Bryce McKinlay CC: tromey@redhat.com, Java Patch List , gcc@gcc.gnu.org Subject: Re: References: <42C2ECA9.3050707@redhat.com> In-Reply-To: <42C2ECA9.3050707@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg01274.txt.bz2 Bryce McKinlay wrote: > > Mark, > Could we get an exemption from the freeze rules for low-risk, runtime > only libgcj fixes as determined by the libgcj maintainers? I don't think we want to do that. First, we're close to a release. We've been waiting on one fix since Friday, and Jeff Law has promised to fix it today. Second, the whole point of freezes is to ensure stability. We're going to RC3 on this release because we've found bad problems in RC1 and RC2. If a change were to be checked in, for whatever reason, happens to break something, then we need an RC4, and everybody loses. > Alternatively, could we rethink our release policy to ensure that the > duration of freezes is minimized in the future? I do think that a hard > freeze in the days leading up to a release is useful and important, but > keeping it in place for weeks just because a couple of bugs remain > unfixed doesn't seem helpful. Obviously, I'd like to have a shorter freeze period. This is the longest pre-release freeze I can remember since I've been running releases. That reflects the fact that a lot of critical problems were uncovered in 4.0.0, including some during the 4.0.1 release process. The way to get a shorter freeze period is to have fewer bugs and to fix them more quickly. I think that this release is somewhat exceptional in that after we released 4.0.0, a lot of people started using a lot of new technology, and, unsurprisingly, there are more bugs in 4.0.0 than in the average release. Please hang in there. Thanks, -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304