From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26371 invoked by alias); 29 Jun 2005 18:48:23 -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 26349 invoked by uid 22791); 29 Jun 2005 18:48:17 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 29 Jun 2005 18:48:17 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j5TIl6mG030157; Wed, 29 Jun 2005 14:47:06 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j5TIl6u17307; Wed, 29 Jun 2005 14:47:06 -0400 Received: from [172.16.14.67] (towel.toronto.redhat.com [172.16.14.67]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id j5TIl5jJ021551; Wed, 29 Jun 2005 14:47:05 -0400 Message-ID: <42C2ECA9.3050707@redhat.com> Date: Wed, 29 Jun 2005 18:48:00 -0000 From: Bryce McKinlay User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: tromey@redhat.com CC: Java Patch List , gcc@gcc.gnu.org, Mark Mitchell Subject: Re: References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg01272.txt.bz2 Tom Tromey wrote: >I'm checking this in on the trunk. If I remember I'll put it on the >4.0 branch once it reopens (there are a fair number of patches pending >for it ... I hope it reopens soon). > > Mark, The extended freeze of the 4.0 branch is making things difficult for libgcj because we have a large backlog of runtime patches which we are unable to apply at this time. The longer the freeze continues, the more difficult it becomes for us to keep track of what needs applying and increases the chances that something will be forgotten, resulting in problems and wasted time further down the line. Could we get an exemption from the freeze rules for low-risk, runtime only libgcj fixes as determined by the libgcj maintainers? 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. Thanks Bryce