From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27342 invoked by alias); 26 Mar 2002 23:30:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27321 invoked from network); 26 Mar 2002 23:30:23 -0000 Received: from unknown (HELO emf.net) (205.149.0.20) by sources.redhat.com with SMTP; 26 Mar 2002 23:30:23 -0000 Received: (from lord@localhost) by emf.net (K/K) id PAA01597; Tue, 26 Mar 2002 15:30:16 -0800 (PST) Date: Tue, 26 Mar 2002 15:30:00 -0000 From: Tom Lord Message-Id: <200203262330.PAA01597@emf.net> To: neil@daikokuya.demon.co.uk CC: rth@redhat.com, zack@codesourcery.com, jimb@redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com In-reply-to: <20020326231730.GA1283@daikokuya.demon.co.uk> (message from Neil Booth on Tue, 26 Mar 2002 23:17:30 +0000) Subject: Re: gcc development schedule [Re: sharing libcpp between GDB and GCC] References: <20020325234047.127345EA11@zwingli.cygnus.com> <20020326040735.GM23331@codesourcery.com> <20020326142901.B16366@redhat.com> <20020326231730.GA1283@daikokuya.demon.co.uk> X-SW-Source: 2002-03/txt/msg00258.txt.bz2 I agree. I think the releases should be an 8-month cycle rather than a 6-month cycle. In other words, 4 months for destabilizing changes. Given the distributed and opportunistic nature of development, wouldn't a phaseless approach be worth considering? Ultimately lower cost for all participants? Certainly put GCC in the position of being better able to make near-instant "emergency releases" to correct defects that escape up-front testing? Certainly avoid snafus like Red Hat experienced a little while back? By "phaseless" I mean an approach in which there is a permanently, continuously QA'd trunk with a high barrier for changes. Presumably along with that, a collection of advanced trunks on which related destabilizing changes are collected and worked-out. This is sometimes called "hierarchical software management" (where the hierarchy is of lines-of-development, not people). The path from here to there would seem to be one of simply beefing up the infrastructure with better automation, and better testing tools. -t