From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5200 invoked by alias); 12 Jan 2004 18:47:40 -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 5192 invoked from network); 12 Jan 2004 18:47:38 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 12 Jan 2004 18:47:38 -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 i0CIlchc027650 for ; Mon, 12 Jan 2004 10:47:38 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Mon, 12 Jan 2004 10:47:38 -0800 Received: from [17.112.105.83] ([17.112.105.83]) by relay2.apple.com (8.12.10/8.12.9) with ESMTP id i0CIlYaO021831; Mon, 12 Jan 2004 18:47:35 GMT In-Reply-To: <20040110154129.GA28152@disaster.jaj.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> 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 From: Geoffrey Keating Subject: Re: gcc 3.5 integration branch proposal Date: Mon, 12 Jan 2004 18:47:00 -0000 To: Phil Edwards X-SW-Source: 2004-01/txt/msg00723.txt.bz2 On 10/01/2004, at 7:41 AM, Phil Edwards wrote: > On Fri, Jan 09, 2004 at 04:47:05PM -0800, Geoffrey Keating wrote: >> On 09/01/2004, at 4:25 PM, Phil Edwards wrote: >>> >>> 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. > > That's a tautology, not an explanation. It is not the trunk. Therefore, it does not have any of the impacts on people working on GCC that it would have if it was 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. > > And I largely agree with you. > > >> 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.) > > No argument there. So, let's fix that, rather than abandon it. If we > get > "this is exactly like the trunk, except it's not THE trunk, so we don't > have to follow the rules" branches every time we're waiting to proceed > from stage 3, then something is wrong. I agree; something is wrong. It was visible that something was wrong in the 3.3 timeframe, too. Perhaps this time we will do something about it. > What if there were a harder cap on the length of time we spend in a > stage? > At the end of 2 months, we push hard to go to the next stage, after > another month, if we're still not there, then too bad, we do it anyway. > The "tough love" approach to release cycles. I would support this, although I would prefer a hard cap of 2 months. IMO, if it's not fixed in 2 months it won't be fixed in 3. > No, I don't know that it's a viable solution, but I'd rather try to > fix the > rules we've got than just do an end run around them. Better > suggestions > solicited. I hope the rules can be fixed, to avoid these problems happening again for 3.5.