From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11714 invoked by alias); 22 Feb 2003 23:25:57 -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 11707 invoked from network); 22 Feb 2003 23:25:57 -0000 Received: from unknown (HELO bilbo.inter.net.il) (192.114.186.18) by 172.16.49.205 with SMTP; 22 Feb 2003 23:25:57 -0000 Received: from zaretsky (adsl-ayalon-pc-129-174.inter.net.il [213.8.129.174]) by bilbo.inter.net.il (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AGN70962; Sun, 23 Feb 2003 01:25:52 +0200 (IST) Date: Sat, 22 Feb 2003 23:25:00 -0000 From: "Eli Zaretskii" To: dberlin@dberlin.org Message-Id: <4634-Sun23Feb2003012208+0200-eliz@is.elta.co.il> CC: gdb@sources.redhat.com In-reply-to: <53C2C20C-44E6-11D7-BE9F-000393575BCC@dberlin.org> (message from Daniel Berlin on Thu, 20 Feb 2003 10:16:46 -0500) Subject: Re: [maint] The GDB maintenance process Reply-to: Eli Zaretskii References: <53C2C20C-44E6-11D7-BE9F-000393575BCC@dberlin.org> X-SW-Source: 2003-02/txt/msg00501.txt.bz2 > Date: Thu, 20 Feb 2003 10:16:46 -0500 > From: Daniel Berlin > > > > 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? I think we have too many bugs already. How about computing some statistics about how many changes repair breakage made by previous changes? Committing unreviewed changes will necessarily make the situation worse. > > 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. I didn't say that. But breaking even a single important feature could make someone out there totally helpless to find some bug. > > 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? Yes, it does. A simple reading of the ChangeLog will show you. > This isn't grade school anymore, we all know how to write good code. Yes, we do. But GDB's internals being as complex and not too documented as they are, it doesn't surprise me that excellent programmers still break things. > > 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. That was was simply broken. But even the latest 3.2.x series are too buggy for serious production-quality code, at least in systems where reliability is a requirement. People are still using 2.95.x for that reason. > And we *knew* it was going to be like this, because of the new ABI. > You couldn't do much about it. Yes, you could. You could refrain from releasing it.