From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9769 invoked by alias); 27 Mar 2002 06:39:54 -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 9729 invoked from network); 27 Mar 2002 06:39:53 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by sources.redhat.com with SMTP; 27 Mar 2002 06:39:53 -0000 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 6E4971E3E3; Wed, 27 Mar 2002 07:39:52 +0100 (MET) Received: from aj by arthur.inka.de with local (Exim 3.34 #1) id 16q765-0004Wp-00; Wed, 27 Mar 2002 07:39:49 +0100 Mail-Copies-To: never To: Tom Lord Cc: neil@daikokuya.demon.co.uk, rth@redhat.com, zack@codesourcery.com, jimb@redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com 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> <200203262330.PAA01597@emf.net> From: Andreas Jaeger Date: Tue, 26 Mar 2002 22:39:00 -0000 In-Reply-To: <200203262330.PAA01597@emf.net> (Tom Lord's message of "Tue, 26 Mar 2002 15:30:16 -0800 (PST)") Message-ID: User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-03/txt/msg00270.txt.bz2 Tom Lord writes: > 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. I think GCC is going already slowly in this direction, the barrier is higher than it was, a year or two ago: - we have automatic testers and benchmarks so that the trunk is build and tested on a daily basis on different platforms - we have a policy of patch reversion for patches that are too broken - we have a policy that patches should have testcases with them for regression testing I agree that it's better to analyze the effects of a patch directly after it went in (or even better before) instead of some months later. Further enhancing the testing infrastructure is one objective that I'd like to see and where I've worked on already, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj