From: Bob Rossi <bob@brasko.net>
To: Richard Stallman <rms@gnu.org>
Cc: Eli Zaretskii <eliz@gnu.org>,
gdbheads@gnu.org, gdb-patches@sources.redhat.com
Subject: Re: [Gdbheads] Re: Feb's patch resolution rate
Date: Thu, 25 Mar 2004 04:13:00 -0000 [thread overview]
Message-ID: <20040325041331.GD19966@white> (raw)
In-Reply-To: <E1B6KAZ-0001ro-Mf@fencepost.gnu.org>
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
next prev parent reply other threads:[~2004-03-25 4:13 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-25 4:01 -file-list-exec-source-files Bob Rossi
2004-03-19 0:09 ` -file-list-exec-source-files Elena Zannoni
2004-03-05 22:36 ` -file-list-exec-source-files Elena Zannoni
2004-03-19 0:09 ` -file-list-exec-source-files Bob Rossi
2004-03-06 15:57 ` -file-list-exec-source-files Bob Rossi
2004-03-11 13:25 ` -file-list-exec-source-files Bob Rossi
2004-03-19 0:09 ` -file-list-exec-source-files Bob Rossi
2004-03-23 13:09 ` A small patch case study, -file-list-exec-source-files Bob Rossi
2004-03-23 15:49 ` [Gdbheads] " Robert Dewar
2004-03-23 16:13 ` Ian Lance Taylor
2004-03-25 4:36 ` Bob Rossi
2004-03-25 5:59 ` Joel Brobecker
2004-03-25 6:11 ` Ian Lance Taylor
2004-03-25 6:19 ` Robert Dewar
2004-03-25 12:43 ` Bob Rossi
2004-03-25 13:34 ` Ian Lance Taylor
2004-03-25 14:04 ` Robert Dewar
2004-03-25 14:34 ` Ian Lance Taylor
2004-03-25 15:08 ` Robert Dewar
2004-03-25 15:43 ` Ian Lance Taylor
2004-03-27 0:21 ` Robert Dewar
2004-03-27 1:02 ` Michael Snyder
2004-03-27 1:10 ` Ian Lance Taylor
2004-03-25 18:17 ` Christopher Faylor
2004-03-25 19:27 ` Michael Snyder
2004-03-25 19:51 ` Ian Lance Taylor
2004-03-25 7:35 ` Eli Zaretskii
2004-03-25 7:59 ` Joel Brobecker
2004-03-25 14:21 ` Bob Rossi
2004-03-25 19:16 ` Michael Snyder
2004-03-25 6:34 ` Eli Zaretskii
2004-03-25 19:31 ` Michael Snyder
2004-03-23 16:14 ` Bob Rossi
2004-03-23 16:56 ` Joel Brobecker
2004-03-23 21:27 ` David Carlton
2004-03-24 6:34 ` Eli Zaretskii
2004-03-23 21:25 ` David Carlton
2004-03-24 6:34 ` Eli Zaretskii
2004-03-24 5:39 ` Richard Stallman
2004-03-23 20:59 ` Feb's patch resolution rate Andrew Cagney
2004-03-23 21:15 ` David Carlton
2004-03-23 21:31 ` Andrew Cagney
2004-03-23 22:07 ` David Carlton
2004-03-24 6:16 ` Eli Zaretskii
2004-03-25 2:05 ` [Gdbheads] " Richard Stallman
2004-03-25 4:13 ` Bob Rossi [this message]
2004-03-25 6:11 ` Robert Dewar
2004-03-25 6:43 ` Eli Zaretskii
2004-03-25 11:08 ` Mark Kettenis
2004-03-25 16:53 ` Andrew Cagney
2004-03-29 20:55 ` -file-list-exec-source-files Bob Rossi
2004-04-05 21:40 ` -file-list-exec-source-files Bob Rossi
2004-04-12 15:06 ` -file-list-exec-source-files Bob Rossi
2004-04-21 1:10 ` -file-list-exec-source-files Bob Rossi
2004-04-21 4:52 ` -file-list-exec-source-files Eli Zaretskii
2004-04-21 12:20 ` -file-list-exec-source-files Bob Rossi
2004-04-21 18:41 ` -file-list-exec-source-files Eli Zaretskii
2004-04-22 15:43 ` -file-list-exec-source-files Elena Zannoni
2004-04-27 0:05 ` -file-list-exec-source-files Bob Rossi
2004-05-06 22:13 ` -file-list-exec-source-files Bob Rossi
2004-05-07 15:24 ` -file-list-exec-source-files Eli Zaretskii
[not found] ` <9743-Sat08May2004132930+0300-eliz@gnu.org>
2004-05-17 13:11 ` -file-list-exec-source-files Bob Rossi
2004-05-22 1:53 ` -file-list-exec-source-files Bob Rossi
2004-05-23 10:40 ` -file-list-exec-source-files Eli Zaretskii
2004-05-23 10:51 ` -file-list-exec-source-files Eli Zaretskii
2004-05-24 2:02 ` -file-list-exec-source-files Bob Rossi
2004-05-28 12:52 ` -file-list-exec-source-files Bob Rossi
2004-06-01 16:07 ` -file-list-exec-source-files Elena Zannoni
2004-06-01 18:01 ` -file-list-exec-source-files Bob Rossi
2004-06-01 18:56 ` -file-list-exec-source-files Jason Molenda
2004-06-01 21:22 ` -file-list-exec-source-files Bob Rossi
2004-06-02 19:22 ` -file-list-exec-source-files Elena Zannoni
2004-06-03 2:35 ` -file-list-exec-source-files Bob Rossi
2004-06-09 18:18 ` -file-list-exec-source-files Bob Rossi
2004-06-09 18:42 ` -file-list-exec-source-files Daniel Jacobowitz
2004-06-09 19:17 ` -file-list-exec-source-files Bob Rossi
2004-06-09 19:57 ` -file-list-exec-source-files Daniel Jacobowitz
2004-06-10 20:04 ` -file-list-exec-source-files Bob Rossi
2004-06-27 18:12 ` -file-list-exec-source-files Andreas Schwab
2004-06-27 19:07 ` -file-list-exec-source-files Bob Rossi
2004-06-27 20:33 ` -file-list-exec-source-files Andreas Schwab
2004-06-28 19:48 ` -file-list-exec-source-files Bob Rossi
2004-06-28 20:40 ` -file-list-exec-source-files Bob Rossi
2004-06-29 4:05 ` -file-list-exec-source-files Eli Zaretskii
2004-06-29 18:34 ` -file-list-exec-source-files Bob Rossi
2004-06-29 18:52 ` -file-list-exec-source-files Eli Zaretskii
2004-06-29 20:10 ` -file-list-exec-source-files Bob Rossi
2004-06-29 20:27 ` -file-list-exec-source-files Eli Zaretskii
2004-06-29 20:29 ` -file-list-exec-source-files Bob Rossi
2004-03-19 0:09 ` -file-list-exec-source-files Jason Molenda
2004-03-05 23:02 ` -file-list-exec-source-files Jason Molenda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040325041331.GD19966@white \
--to=bob@brasko.net \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=gdbheads@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox