From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17535 invoked by alias); 25 Mar 2004 04:13:33 -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 17522 invoked from network); 25 Mar 2004 04:13:30 -0000 Received: from unknown (HELO lakemtao01.cox.net) (68.1.17.244) by sources.redhat.com with SMTP; 25 Mar 2004 04:13:30 -0000 Received: from white ([68.9.64.121]) by lakemtao01.cox.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP id <20040325041331.XINF26108.lakemtao01.cox.net@white>; Wed, 24 Mar 2004 23:13:31 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1B6MFH-0005J3-00; Wed, 24 Mar 2004 23:13:31 -0500 Date: Thu, 25 Mar 2004 04:13:00 -0000 From: Bob Rossi To: Richard Stallman Cc: Eli Zaretskii , gdbheads@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [Gdbheads] Re: Feb's patch resolution rate Message-ID: <20040325041331.GD19966@white> Mail-Followup-To: Richard Stallman , Eli Zaretskii , gdbheads@gnu.org, gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2004-03/txt/msg00589.txt.bz2 On Wed, Mar 24, 2004 at 09:00:31PM -0500, Richard Stallman wrote: > 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. Agreed. However, IMO, Ian is correct. Maintainers must take responsibility for looking over patches quickly, and approving them, rewriting them to be acceptable, rejecting them with an explanation, or suggesting changes. Maintainers who don't accomplish that are not effective maintainers. That is not to say that they can not be effective contributors, or that they can not be very good at maintaining code and making technical decisions. I think this is the bottom line. Maintainers need to review patches quickly. Everyone seems to agree that one week is considered quick. Is there a better definition of quick? Is quick linear with the size of the patch? To me one month is not quick. Is it to anyone else? Everyone seems to ignore this question :) > 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. I don't know much about the patches submitted to GDB and the average review time, but Andrew seemed to make it look as if most patches are reviewed quickly. What about the patches that are not reviewed quickly? The real question is, what incentive does a maintainer have to review a patch quickly? Also, if the testsuite passes, and the initial patch looks good, why would it take so long to accept the patch? Isn't the definition of "stable" for GDB, "The testsuite works the same way after the patch as before"? Thanks, Bob Rossi