From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28459 invoked by alias); 10 Jan 2004 00:47:03 -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 28451 invoked from network); 10 Jan 2004 00:47:03 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 10 Jan 2004 00:47:03 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id i0A0l2hc016885 for ; Fri, 9 Jan 2004 16:47:02 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Fri, 9 Jan 2004 16:47:02 -0800 Received: from [17.219.197.129] ([17.219.197.129]) by relay2.apple.com (8.12.10/8.12.9) with ESMTP id i0A0l2aO022124; Sat, 10 Jan 2004 00:47:02 GMT In-Reply-To: <20040110002526.GA13568@disaster.jaj.com> References: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com> <20040110002526.GA13568@disaster.jaj.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <82D6F34E-4306-11D8-BDBD-000A95B1F520@apple.com> Content-Transfer-Encoding: 7bit Cc: "'gcc@gcc.gnu.org'" From: Geoffrey Keating Subject: Re: gcc 3.5 integration branch proposal Date: Sat, 10 Jan 2004 00:47:00 -0000 To: Phil Edwards X-SW-Source: 2004-01/txt/msg00580.txt.bz2 On 09/01/2004, at 4:25 PM, Phil Edwards wrote: > On Fri, Jan 09, 2004 at 04:11:39PM -0800, Geoffrey Keating wrote: >> 1. This branch is for fully-tested, approved patches. The rules for >> committing to it are the same as the rules that apply during Stage 1 >> of >> GCC development. Experimental or incomplete work should not be put on >> the branch. >> 2. The intention is that immediately after GCC 3.4 branches, this >> branch will be merged back to mainline. >> 3. I will be making regular (probably weekly) merges from mainline >> onto >> this branch. I will be testing these merges with a powerpc-darwin >> native bootstrap. Anyone who commits anything to the branch that >> can't >> be fully tested with a powerpc-darwin native bootstrap should watch >> for >> the mail I send out saying the merge is done, and then run a test on >> their own platform and send the results to gcc-testresults. >> 4. Anyone who commits to the branch is still responsible for >> maintaining the patch on the branch: fixing regressions that it >> causes, >> and sometimes updating or reintegrating it after merges. I expect >> that >> for most patches, this will be much less work than maintaining the >> patch on their own. >> 5. I may back a patch out of the branch if it (a) causes bootstrap >> failure or significant regressions on any platform and the author >> doesn't appear to be able to fix it quickly, or (b) don't appear to >> have followed Rule 1 or Rule 3. > > This sounds no different than the normal trunk rules, and so it > strikes me as > just a bypass of the 3-stage rules so as to not wait for 3.4. If > there's > a significant difference between these rules and the trunk rules, then > please explain what I've missed. Otherwise I object, on the grounds > that > those rules are in place for a reason, and that deliberately bypassing > them instead of helping to get 3.4 branched does more harm than good. The significant difference is that this is not the trunk. Yes, this branch is being created because 3.4 is taking too long. If it was up to me, it would branch today and ship in two months exactly, bugs or no bugs. I don't believe I ever signed up to a process where new GCC development would be halted for months in order to meet some arbitrary quality goal; in fact, if anyone had ever proposed that the three-stage process should consist of an initial two-month stage 1, then a four-month stage 2, then a six-month stage 3, I would have objected greatly, on the grounds that such a release cycle is too long and provides too little time for development. (You'll recall that the original proposal was for three two-month stages; at the time, I thought that was a fair compromise. It's a shame the compromise is not being honoured.)