From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18639 invoked by alias); 14 Apr 2002 06:27:27 -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 18632 invoked from network); 14 Apr 2002 06:27:27 -0000 Received: from unknown (HELO rwcrmhc51.attbi.com) (204.127.198.38) by sources.redhat.com with SMTP; 14 Apr 2002 06:27:27 -0000 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020414062727.IFXO1143.rwcrmhc51.attbi.com@ocean.lucon.org>; Sun, 14 Apr 2002 06:27:27 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id AC9CD125C3; Sat, 13 Apr 2002 23:27:25 -0700 (PDT) Date: Sun, 14 Apr 2002 01:33:00 -0000 From: "H . J . Lu" To: Toon Moene Cc: Neil Booth , Mark Mitchell , gcc@gcc.gnu.org Subject: Re: GCC 3.1 Release Message-ID: <20020413232725.A18949@lucon.org> References: <46690000.1018660657@gandalf.codesourcery.com> <20020413091819.GA16217@daikokuya.demon.co.uk> <3CB823A0.136EF4E3@moene.indiv.nluug.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CB823A0.136EF4E3@moene.indiv.nluug.nl>; from toon@moene.indiv.nluug.nl on Sat, Apr 13, 2002 at 02:25:04PM +0200 X-SW-Source: 2002-04/txt/msg00559.txt.bz2 On Sat, Apr 13, 2002 at 02:25:04PM +0200, Toon Moene wrote: > Neil Booth wrote: > > > Mark Mitchell 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. > > The problem with Mark's "mental model" of the release process is that > bug fixing doesn't screech to a grinding halt the moment 3.1 is out. > > 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. Let's face it. It is next to impossible to make a major gcc release without regressions or other serious bugs. The question is how the gcc developers deal with it. I think a quick bug fix minor release should be put out every week or two after a major release. That may mean the gcc developers may not be able to run regression tests themselves on all platforms. But it won't be a big problem as long as some regressions known after the major release are fixed in each minor release. The reason I like frequent releases is it is easier to track down and fix regressions. You always get a better gcc in each minor release. H.J.