From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6237 invoked by alias); 14 Apr 2002 05:36:02 -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 6229 invoked from network); 14 Apr 2002 05:36:01 -0000 Received: from unknown (HELO localhost.localdomain) (210.86.60.56) by sources.redhat.com with SMTP; 14 Apr 2002 05:36:01 -0000 Received: from waitaki.otago.ac.nz ([192.168.2.2]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id g3E511T23948; Sun, 14 Apr 2002 17:01:01 +1200 Message-ID: <3CB914BD.4080007@waitaki.otago.ac.nz> Date: Sat, 13 Apr 2002 23:07:00 -0000 From: Bryce McKinlay User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9+) Gecko/20020327 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Toon Moene CC: Neil Booth , Mark Mitchell , gcc@gcc.gnu.org Subject: Re: GCC 3.1 Release References: <46690000.1018660657@gandalf.codesourcery.com> <20020413091819.GA16217@daikokuya.demon.co.uk> <3CB823A0.136EF4E3@moene.indiv.nluug.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00557.txt.bz2 Toon Moene wrote: >>>I have a proposal before the SC to slip the GCC 3.2 schedule even >>>further; so that the first phase of GCC 3.2 development will now end >>>one month beyond the release of GCC 3.1 -- June 1st -- pushing the >>>GCC 3.2 release date back to October 1st so as to give people time to >>>work on major changes for GCC 3.2 *after* GCC 3.1 is released. >>> >>IMO this is still too short; I think there should be two months after >>the previous release for the first phase, giving us an 8-month cycle >>instead of a 6-month one. >> One could argue that the long cycle between 3.0 and 3.1 is partly responsible for the 3.1 release problems, by allowing a longer period for bugs to creep in before developer focus shifted to fixing them. I think we should try for at least one release on the shorter cycle, with an option to re-evaluate its effectiveness as the 3.2 release approaches or after it is made. For GCJ, having more than 6 months between major releases is (IMO) an uncomfortably long time, given the rate at which it is moving. We find that a lot of bugs only get discovered after releases, but it becomes impractical to continue applying fixes to release branches because the mainline diverges quickly. Perhaps we should try to keep applying GCJ changes to release branches for longer, but to be always committing patches to two trees is quite time-consuming. >Because then a whole group of "new" testers comes along and finds new >bugs that we (and our "regular" testers) haven't found. For 3.0 this >effect was so bad that basically only the 3.0.4 release can be described >as "generally useful". > >I do not have a good solution to that problem. > Perhaps we could go by a stable/unstable release cycle, similar to Linux. Unstable releases would follow a shorter period of stabilization/freezing/testing/branching than is done for a full, stable release. This would give users wanting to test and play with new features something which is known to be better tested than the average snapshot, but without the pain and major disruption to development that full releases seem to require. regards Bryce.