From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31333 invoked by alias); 12 Jan 2004 19:22:13 -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 31312 invoked from network); 12 Jan 2004 19:22:12 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sources.redhat.com with SMTP; 12 Jan 2004 19:22:12 -0000 Received: (qmail 14843 invoked from network); 12 Jan 2004 19:22:03 -0000 Received: from 227.148-60-66-fuji-dsl.static.surewest.net (HELO minax.codesourcery.com) (mitchell@66.60.148.227) by mail.codesourcery.com with SMTP; 12 Jan 2004 19:22:03 -0000 Subject: Re: gcc 3.5 integration branch proposal From: Mark Mitchell To: Geoffrey Keating Cc: Phil Edwards , gcc@gcc.gnu.org In-Reply-To: References: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com> <20040110002526.GA13568@disaster.jaj.com> <82D6F34E-4306-11D8-BDBD-000A95B1F520@apple.com> <20040110154129.GA28152@disaster.jaj.com> Content-Type: text/plain Organization: CodeSourcery, LLC Message-Id: <1073935323.3458.42.camel@minax.codesourcery.com> Mime-Version: 1.0 Date: Mon, 12 Jan 2004 19:22:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00724.txt.bz2 > I hope the rules can be fixed, to avoid these problems happening again > for 3.5. I hear your pain, and I sympathize. Believe me, I wish 3.4 were long since out the door. The fundamental problem remains the following: (1) Our very high rate of change, coupled with our relatively fragile system, causes lots of regressions. (2) We don't do a good job of making the people who caused the problems fix them -- and sometimes they are unable to do so, for valid reasons. Sometimes we don't detect the problems quickly enough to figure out what caused them easily. (3) We have no dedicated bug-fixers, who simply treat fixing regressions as their sole calling. (I have actually been doing this for the C++ front end since the new parser went in; I've deliberately not worked on a single piece of new functionality.) My job here is to try to serve as best I can. To me, the regression-elimination goal has always been a good one; it's certainly the one that I want most from the software I use. But, if timeliness is the imperative, I can manage the releases with that goal instead. In fact, that was my initial inclination -- but people resisted that strategy somewhat strongly. What's somewhat disappointing to me is that we clearly have the resources to fix the regressions -- we just don't have the willingness. If every skilled GCC developer fixed four or five regressions, we'd have zero open regressions at this point -- or, at least, the ones that were open would be due to huge structural problems that we have no practical way of fixing quickly. I'll make you a deal -- if you will commit to fixing five Bugzilla regressions between now and January 31st, and five more after the branch is made, then I'll create the branch on January 31st, come hell or high water. Deal? -- Mark Mitchell CodeSourcery, LLC