From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20965 invoked by alias); 30 Mar 2004 12:56:47 -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 20956 invoked from network); 30 Mar 2004 12:56:44 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 30 Mar 2004 12:56:44 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id i2UBhO9b008993; Tue, 30 Mar 2004 13:43:24 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id i2UBhN6a008992; Tue, 30 Mar 2004 13:43:23 +0200 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Joe Buck Cc: gcc@gcc.gnu.org Subject: Re: GCC-3.3.4 release status report References: <20040329091650.B32489@synopsys.com> From: Gabriel Dos Reis In-Reply-To: <20040329091650.B32489@synopsys.com> Organization: Integrable Solutions Date: Tue, 30 Mar 2004 18:46:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03/txt/msg01712.txt.bz2 Joe Buck writes: | On Sat, Mar 27, 2004 at 11:09:52AM +0100, Gabriel Dos Reis wrote: | > The number of open PRs targetted for 3.3.4 has grown up to 46 | > (from 41 last report). | | That is a *huge* number of bugs to attempt to fix in the fourth point | release; an attempt to fix even half that number will probably result in | 3.3.4 being less stable than 3.3.3. That's because any bug fix adds the | risk of introducing a new bug. Of course, I recognize that you don't | seriously intend to fix that many, but we need to set everyone's | expectations correctly. Hi, I fully understand the potential risk of any single patch that gets applied to branch. You're right that I don't expect to fix that number of regressions before releasing -- that is just unrealistic. However, If can get rid of the 8 regressions I listed, I'll be more than happy. With no intent to make Mark feel uncomfortable (the RM position is where you get everybody wanting to eat you ;-)), I believe that the gcc-3_3-branch was created too early. Lots of bugs were found only later and could not make it into early releases. That explains a large part of the impressive release note we got for 3.3.3. Bugs and regressions are still being found, that contributes to the growing PRs; and some were unfortunately introduced in 3.3.3 at attempts to fix other bugs. That is inevitable, and I trust everybody commenting on GCC release process understand that. I think that the critical PR deserve a high priority (a truism, but that probably needs stating); however, I also feel that normal PRs with no disruptive patches should be accepted. It is true that GCC-3.4.0 is going out very soon and that it contains an uncomensurable number of fixes and functionalities. But that is also the principal reason why I volunteered to maintain GCC-3.3.x. It is going to reject lots of (C++) codes, not because it is much buggier but because it is much stricter and has some ABI changes. I do not believe that the set of bug-fixes we should offer should come in a form of whole-or-nothing, e.g take ABI change + various (non ABI) bug-fixes or nothing. If I have simple patches/backports for those, I would be happy, but I would not push hard to apply disruptive patches. I'll put resources to fulfill the release date and criteria for GCC-3.3.4. I hope that clarifies things as your expectations are concerned. -- Gaby