From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16247 invoked by alias); 13 Jan 2004 21:31:42 -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 16240 invoked from network); 13 Jan 2004 21:31:41 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 13 Jan 2004 21:31:41 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id i0DLVenM004422 for ; Tue, 13 Jan 2004 13:31:40 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Tue, 13 Jan 2004 13:31:40 -0800 Received: from [17.201.20.159] (keatge.apple.com [17.201.20.159]) by relay3.apple.com (8.12.10/8.12.9) with ESMTP id i0DLVeIE008495; Tue, 13 Jan 2004 21:31:40 GMT In-Reply-To: <1073951351.3458.162.camel@minax.codesourcery.com> 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> <1073935323.3458.42.camel@minax.codesourcery.com> <1073951351.3458.162.camel@minax.codesourcery.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: gcc@gcc.gnu.org, Phil Edwards From: Geoff Keating Subject: Re: gcc 3.5 integration branch proposal Date: Tue, 13 Jan 2004 21:31:00 -0000 To: Mark Mitchell X-SW-Source: 2004-01/txt/msg00822.txt.bz2 On Jan 12, 2004, at 3:49 PM, Mark Mitchell wrote: > On Mon, 2004-01-12 at 15:42, Geoff Keating wrote: >> On Jan 12, 2004, at 11:22 AM, Mark Mitchell wrote: >> >>> 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? >> >> I think January 31 would be too long to wait, sorry. > > No counter-offer? :-) I was going to, but it would have started with "Well, how about you create a branch two weeks ago, and then..." :-) > By the way, there's no question that there will be chaos when we > finally > do branch, and everyone starts putting stuff in for 3.5. That's > actually what's supposed to happen in Stage 1. :-) No, I don't think that is what's supposed to happen in Stage 1. I certainly don't remember the word 'chaos' being used. > I completely agree with Phil, however, that creating a proxy-mainline > is > inappropriate. I think that the release manager holding up GCC development for months in order to achieve an arbitrary regression goal is inappropriate, especially if this comes at the cost of other goals (most notably, timeliness) of one or more releases. In particular, I think that your excessive focus on avoiding regressions is contributing to GCC's serious problems in other areas, most notably speed of compilation and speed of generated code when compared against the best available commercial compilers (for me, that's CodeWarrior and icc/xlc respectively, and we're about 60% and 25% behind respectively). Just to remind you, here is a quote from our web pages: > Although maintaining a development branch, including merging new > changes from the mainline, is somewhat burdensome, the absolute worst > case is that such a branch will have to be maintained for four months. > During two of those months, the only mainline changes will be > bug-fixes, so it is unlikely that many conflicts will occur. Here's another one: > We think that we will better serve the user community by making > releases somewhat more frequently, and on a consistent schedule. I do not believe we are achieving this aim. > Apple (and some other vendors, including CodeSourcery) is in the > position of doing its own release management and bug-fixing based on > various versions of GCC. Therefore, having high-quality FSF releases > may not make much of a difference to Apple; Apple doesn't use it > directly anyhow. (Of course I do not know what Apple's management > wants > in this respect, nor do I know what your personal motivations might be, > independently of your Apple employeeship.) Apple would like to use FSF releases. Unfortunately, a prerequisite for this is that the FSF actually makes releases in a timely fashion, and this is not happening. > These releases, however, are FSF releases, and they should be of the > same high quality as the FSF releases for other packages, such as Emacs > or GNU Awk. Unless the SC says otherwise, of course. :-) So, why do you think the current mainline is not "high quality"? -- Geoff Keating