From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21683 invoked by alias); 25 Mar 2004 11:08: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 21658 invoked from network); 25 Mar 2004 11:08:30 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 25 Mar 2004 11:08:30 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i2PB6sw2000311; Thu, 25 Mar 2004 12:06:54 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i2PB6svw000712; Thu, 25 Mar 2004 12:06:54 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i2PB6sbB000709; Thu, 25 Mar 2004 12:06:54 +0100 (CET) Date: Thu, 25 Mar 2004 11:08:00 -0000 Message-Id: <200403251106.i2PB6sbB000709@elgar.kettenis.dyndns.org> From: Mark Kettenis To: bob@brasko.net CC: rms@gnu.org, gdbheads@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <20040325041331.GD19966@white> (message from Bob Rossi on Wed, 24 Mar 2004 23:13:31 -0500) Subject: Re: [Gdbheads] Re: Feb's patch resolution rate 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> <20040325041331.GD19966@white> X-SW-Source: 2004-03/txt/msg00605.txt.bz2 Date: Wed, 24 Mar 2004 23:13:31 -0500 From: Bob Rossi Is quick linear with the size of the patch? Defenitely not. Even if the time I need to review a patch is linear with the size of the patch, the result would still be that longer patches will take significantly longer to review. Very often I will be able to review small patches immediately, i.e. right after I've read the message that contains the patch. But if the patch is longer I'll put it on my TODO list and come back to it when I've got some spare time that I think is enough to review the patch. I've got many small slots of spare time, but larger time slots are much scarcer. I wouldn't be surprised if this results in exponential behaviour. 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"? The simple fact that the patch works, doesn't mean that it is good. Blindly applying such patches will threaten the maintainability of GDB. Also, for everything but patches to target-dependent code, the testsuite will have to be run on a fair number of targets. Mark