From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25056 invoked by alias); 20 Feb 2003 15:16:53 -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 25040 invoked from network); 20 Feb 2003 15:16:53 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by 172.16.49.205 with SMTP; 20 Feb 2003 15:16:53 -0000 Received: from [128.164.132.31] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 2901087; Thu, 20 Feb 2003 10:16:52 -0500 Date: Thu, 20 Feb 2003 15:16:00 -0000 Subject: Re: [maint] The GDB maintenance process Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Daniel Jacobowitz , Elena Zannoni , Andrew Cagney , gdb@sources.redhat.com To: Zaretskii Eli From: Daniel Berlin In-Reply-To: <4D19136444628A40840EFE8C5AE04147017A44@ELTIMAIL1.elta.co.il> Message-Id: <53C2C20C-44E6-11D7-BE9F-000393575BCC@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00408.txt.bz2 > > >> From: Daniel Berlin [mailto:dberlin@dberlin.org] >> Sent: Wednesday, February 19, 2003 3:24 PM >> >>> I guess I just don't see this to be as much of a problem as others > do. >>> For one thing, with the higher entropy level, more development > actually >>> happens. >> Bingo. >> I don't think we should stall development (and in the >> extreme, even if >> it means we can't make quality releases any day of the year) because >> mistakes occasionally happen in patches, or because not every >> maintainer in existence has said something about a patch. That's a >> recipe for no progress. > > For some definition of ``progress''. > > Who said that adding code at a faster rate at the price of having more > bugs is more ``progress'' than what we have now? Who said we'd necessarily have more bugs? Can you back this up? > There are people out > there who need GDB to actually do something _useful_, not just to debug > and/or develop GDB itself, you know. You've assumed that it would make GDB completely unusable. You know, it's funny you mention "people out there", since *every* GDB user i know not on the gdb mailing list is a desktop developer, working with C++ (KDE friends) or Java (Weirdo friends :P) , and yet these are *exactly* the portions of GDB that work least well. It's almost as if our focus on what features are important is wrong. But anyway, that's a rant for another time. > What about frustration of those > GDB users when their favorite feature is broken by some > committed-before-review patch that adds a hot new feature? > Does that > ever count? Does it ever happen? I mean, seriously. Ever? I doubt it would have been suggested if anyone seriously though it was going to happen. This isn't grade school anymore, we all know how to write good code. > > Does anyone remember that latest GCC releases are practically unusable > for any production-quality work due to bugs? Does anyone even care? > Latest? There was *one* release that was like this, GCC 3.0. And we *knew* it was going to be like this, because of the new ABI. You couldn't do much about it. That's why 3.1 was planned as a completely "make it faster, fix bugs", not "add new features" release. > I say thanks God for slower development of GDB. At least I can _debug_ > buggy code produced by buggy development tools ;-) > > Of course, if contributors are frustrated by the slow review rate, > let's > try to improve that (see my other mail). But let's not obscure our > view > of the problem by discussing abstract issues of ``progress''. An > official release every 3 months is more than enough progress for my > taste. Only if they contain some useful feature.