From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11956 invoked by alias); 19 Feb 2003 16:14:23 -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 11949 invoked from network); 19 Feb 2003 16:14:22 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 19 Feb 2003 16:14:22 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 185EC2E96; Wed, 19 Feb 2003 11:19:08 -0500 (EST) Message-ID: <3E53AE7B.4090401@redhat.com> Date: Wed, 19 Feb 2003 16:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <20030218042847.50F2E3CE5@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00350.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. GDB is less stable then you might think. Right now while both: - interps - frame are causing problems they are not getting in the way of DavidC's dwarf2 stuff (gee wiz, both my doing :-/). GDB always builds, gdb always `break main; run'. Is that too much to ask? The problem with GDB's stability is that allows people to quickly forget: - what it is like with out it - how much gain there is from it - how relatively small the pain - how much more expensive it is to have to re-do something later - how, with a bit of peer revew, problematic code could have been done right the first time (and how much that fallout costs). Andrew