From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5438 invoked by alias); 19 Feb 2003 03:49:07 -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 5429 invoked from network); 19 Feb 2003 03:49:05 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by 172.16.49.205 with SMTP; 19 Feb 2003 03:49:05 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h1J3gN8A029018; Tue, 18 Feb 2003 22:42:23 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h1J3gMEQ029014; Tue, 18 Feb 2003 22:42:22 -0500 To: Andrew Cagney CC: gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <20030218042847.50F2E3CE5@localhost.redhat.com> From: Jim Blandy In-Reply-To: <20030218042847.50F2E3CE5@localhost.redhat.com> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Date: Wed, 19 Feb 2003 03:49:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00331.txt.bz2 ac131313@redhat.com (Andrew Cagney) writes: > > Some noticeable differences between these two models: > > - In the GCC model, more people are able/likely to check in patches which > > break things. > > - But in the GCC model, more people are able/likely to check in patches to > > fix it afterwards. > > (ROFL.) > > The GCC model involves a number of development phases and the above > comments would only relate to one of those phases. At other times > increasingly strict controls are placed on what can be > committed/approved. The GCC group spend a significant (out of > control?) amount of their time trying to re-stablize GCC for their > releases. > > For GDB, on the other hand, interesting development can and does get > approved/committed at any time. GDB snaps are of such quality that we > can confidently refer someone to current sources for fixes (except > when I have a bad day like today :-). Further, instead of using > official releases (and as you yourself have done) arbitrary snaps can > even make their way into a distro. The problem is, being that stable has a cost associated with it. GCC pays that cost at certain parts in their cycle; we pay that cost all the time, every day. Sure, it's nice being able to grab an arbitrary GDB snapshot and distribute it. But the rules which give us that property also slow GDB's development into a more capable system. The decision to pay that particular price for that particular benefit is what we want to open up for discussion. Stability needs to be balanced with progress in features; although I'd hate to see it go too far towards the latter, I think the balance we have now is tipped too far in favor of the former.