From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18977 invoked by alias); 30 Mar 2004 18:46:55 -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 18970 invoked from network); 30 Mar 2004 18:46:53 -0000 Received: from unknown (HELO kiruna.synopsys.com) (198.182.44.80) by sources.redhat.com with SMTP; 30 Mar 2004 18:46:53 -0000 Received: from crone.synopsys.com (crone.synopsys.com [146.225.7.23]) by kiruna.synopsys.com (Postfix) with ESMTP id 328BEF3F1; Tue, 30 Mar 2004 10:46:47 -0800 (PST) Received: from piper.synopsys.com (localhost [127.0.0.1]) by crone.synopsys.com (8.9.1/8.9.1) with ESMTP id KAA00609; Tue, 30 Mar 2004 10:46:52 -0800 (PST) Received: (from jbuck@localhost) by piper.synopsys.com (8.11.6/8.11.6) id i2UIkqj27934; Tue, 30 Mar 2004 10:46:52 -0800 X-Authentication-Warning: piper.synopsys.com: jbuck set sender to Joe.Buck@synopsys.com using -f Date: Tue, 30 Mar 2004 23:59:00 -0000 From: Joe Buck To: Gabriel Dos Reis Cc: Wolfgang Bangerth , gcc@gcc.gnu.org Subject: Re: GCC-3.3.4 release status report Message-ID: <20040330104651.B25072@synopsys.com> References: <200403291410.59630.bangerth@ices.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gdr@integrable-solutions.net on Tue, Mar 30, 2004 at 01:57:26PM +0200 X-SW-Source: 2004-03/txt/msg01722.txt.bz2 Gabriel Dos Reis wrote: > | >> The number of open PRs targetted for 3.3.4 has grown up to 46 > | >> (from 41 last report). I wrote: > | > 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. Wolfgang Bangerth writes: > | Indeed. My feeling is that way too many patches are going into 3.3.4 without > | any analysis as to the risk of them. Gabriel Dos Reis wrote: > I believe that is too much a strong statement. No patch is blindly > applied to GCC-3.3.4 Of course the patches are not being applied "blindly". But I've been in the biz long enough to expect that no matter how careful or skillful the development team is, if it introduces 10 new bug fixes into a software system as complex as GCC in a short time, it will introduce at least one new significant failure (and often a "paper bag" failure, as in you'll want to put a paper bag over your head if the new bug escapes testing). In environments where fixes are done under tight deadline pressure the number gets closer to 4 to 1 (and fortunately GCC does not have such pressure). That's why it would be a good idea to scale back your ambitions, focus only on the truly most important bugs, and allow a long enough shake-out period to allow time to find the newly introduced failures before release. > I could come tomorrow with a release note saying that only two PRs are > targetted for 3.3.4; I doubt that would make GCC-3.3.4 better than it > looks now. I could also come and say I have 100 open PRs for > GCC-3.3.4; I doubt it would make GCC-3.3.4 worse than it is now. The question boils down to how we want to manage point releases. I think that the user expectation should be that we see a montonically increasing quality from x.y.z to x.y.z+1. To achieve this, we should not be overly ambitious and try to fix all regressions, though anything that works in x.y.z and fails in the x.y branch can't be tolerated. Regressions that prevent distros from being built are most critical (e.g. 14640). Almost everything else can probably wait. Given the volume of fixes that have gone into 3.3.4 already, I would advise a long period of freeze, and encourage people to build whole distros with the compiler on as many platforms as possible. It should be rock-solid, but it will inevitably still contain regressions with respect to 2.95.