From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26251 invoked by alias); 25 Mar 2004 02:05:15 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26233 invoked from network); 25 Mar 2004 02:05:14 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 25 Mar 2004 02:05:14 -0000 Received: from rms by fencepost.gnu.org with local (Exim 4.24) id 1B6KAZ-0001ro-Mf; Wed, 24 Mar 2004 21:00:31 -0500 From: Richard Stallman To: Eli Zaretskii CC: cagney@gnu.org, gdbheads@gnu.org, gdb-patches@sources.redhat.com In-reply-to: (message from Eli Zaretskii on 24 Mar 2004 08:16:23 +0200) Subject: Re: [Gdbheads] Re: Feb's patch resolution rate Reply-to: rms@gnu.org References: <20040225040059.GB19094@white> <16456.65451.461753.66554@localhost.redhat.com> <20040306155700.GA9439@white> <20040311132508.GA2504@white> <20040323130900.GA17339@white> <4060A523.6010801@gnu.org> <4060ACC8.10209@gnu.org> Message-Id: Date: Thu, 25 Mar 2004 02:05:00 -0000 X-SW-Source: 2004-03/txt/msg00587.txt.bz2 That's because no one, to the best of my knowledge, is claiming that GDB development is dysfunctional. As long as GDB maintenance as a whole works fairly well, the average figures of any reasonable performance estimator will be good. IMHO, it is the (relatively rare) exceptions from the rule that bothered and continue to bother those among us who came up with suggestions to modify the existing practices. I can understand that these occasional long delays cause annoyance to the people who wrote those particular patches. However, I don't think that occasional long delays indicate a fundamental problem in the way gdb is being maintained. It seems to be basically adequate. That doesn't mean it couldn't be better. I will ask the gdb committee, whose membership I have just updated, to look into finding a procedure to help deal with these long-delayed patches.