From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27134 invoked by alias); 10 Jan 2004 15:41:34 -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 27116 invoked from network); 10 Jan 2004 15:41:32 -0000 Received: from unknown (HELO disaster.jaj.com) (24.123.75.82) by sources.redhat.com with SMTP; 10 Jan 2004 15:41:32 -0000 Received: from disaster.jaj.com (localhost.localhost [127.0.0.1]) by disaster.jaj.com (8.12.10/8.12.9) with ESMTP id i0AFfT8n028284; Sat, 10 Jan 2004 10:41:29 -0500 Received: (from phil@localhost) by disaster.jaj.com (8.12.10/8.12.9/Submit) id i0AFfTKg028283; Sat, 10 Jan 2004 10:41:29 -0500 Date: Sat, 10 Jan 2004 15:41:00 -0000 From: Phil Edwards To: Geoffrey Keating Cc: gcc@gcc.gnu.org Subject: Re: gcc 3.5 integration branch proposal Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82D6F34E-4306-11D8-BDBD-000A95B1F520@apple.com> User-Agent: Mutt/1.5.4i X-SW-Source: 2004-01/txt/msg00612.txt.bz2 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. > 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. 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. 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. Phil -- =========0=========0=========0=========0=========0=========0=========0=========0