From: Andrew Cagney <ac131313@redhat.com>
To: Mark Kettenis <kettenis@chello.nl>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb@sources.redhat.com
Subject: Re: [maint] The GDB maintenance process
Date: Mon, 24 Feb 2003 07:18:00 -0000 [thread overview]
Message-ID: <3E59C7B6.1000308@redhat.com> (raw)
In-Reply-To: <86isvao9yk.fsf@elgar.kettenis.dyndns.org>
> I mostly agree with Daniel here. We have too many single points of
> failure. I still have testsuite patches sitting in my tree, dating
> months back since they were never approved. Similarly, Daniel
> probably has been held back more than once since I wasn't able to
> review threads-related patches in a timely fashion. I think we should
> allow our global maintainers to approve patches even for parts of GDB
> where we have a specific maintainer, if they feel they have the
> necessary expertise.
Depends on what `single point failure' means. If you look through the
MAINTAINERS file you'll notice that all but one of the problem areas is
double, if not triple maintained. Even with all that dedundency,
patches in certain areas continues to stall. While there might be three
maintainers, the reality is only one or none are reliable.
The first, and most obvious thing is for the global maintainers to
review their current number of responsibilities and compare that against
their actual level of commmitment. I'm down to just target/arch,
remote, mips and sim/ppc.
The second, is for maintainers to always be on the lookout for potential
new maintainers (global or not) and, where possible, step aside to let
new commers in.
Finally, the GDB `tradition' (that appears to have been forgotten) is to
up front reach consensus on stuff so that the final patches are trivial
to review. cf, the block.[hc] change.
enjoy,
Andrew
next prev parent reply other threads:[~2003-02-24 7:18 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-17 18:07 Daniel Jacobowitz
[not found] ` <drow@mvista.com>
2003-02-17 18:58 ` Kevin Buettner
2003-02-17 21:01 ` Elena Zannoni
2003-02-19 1:49 ` Daniel Jacobowitz
2003-02-19 2:26 ` Joel Brobecker
2003-02-19 15:43 ` Andrew Cagney
2003-02-19 16:29 ` Daniel Jacobowitz
2003-02-19 22:04 ` Andrew Cagney
2003-02-19 13:24 ` Daniel Berlin
2003-02-19 15:51 ` Andrew Cagney
2003-02-19 14:50 ` Andrew Cagney
2003-02-19 17:33 ` David Carlton
2003-02-19 17:57 ` Kevin Buettner
2003-02-19 18:56 ` Andrew Cagney
2003-02-19 20:39 ` Christopher Faylor
2003-02-19 23:17 ` Jason Molenda
2003-02-20 1:53 ` Christopher Faylor
2003-02-19 19:35 ` David Carlton
2003-02-20 18:32 ` Richard Earnshaw
2003-02-22 0:53 ` Andrew Cagney
2003-02-19 15:12 ` Andrew Cagney
2003-02-19 15:21 ` Daniel Jacobowitz
2003-02-19 16:24 ` Andrew Cagney
2003-02-19 18:36 ` Christopher Faylor
2003-02-19 23:36 ` Jason Molenda
2003-02-19 23:52 ` Andrew Cagney
2003-02-19 23:59 ` Jason Molenda
2003-02-20 0:16 ` Elena Zannoni
2003-02-20 0:21 ` Andrew Cagney
2003-02-18 2:39 ` Andrew Cagney
2003-02-18 4:28 ` Andrew Cagney
2003-02-19 3:49 ` Jim Blandy
2003-02-19 16:14 ` Andrew Cagney
2003-02-19 16:31 ` Daniel Jacobowitz
2003-02-19 2:24 ` Jim Blandy
2003-02-19 16:33 ` Andrew Cagney
2003-02-19 22:24 ` Jim Blandy
2003-02-19 22:39 ` Christopher Faylor
2003-02-19 22:53 ` Andrew Cagney
2003-02-19 23:53 ` Elena Zannoni
2003-02-20 1:27 ` Andrew Cagney
2003-02-20 2:48 ` Andrew Cagney
2003-02-21 23:43 ` Andrew Cagney
2003-02-21 23:57 ` Andrew Cagney
2003-02-19 6:05 ` David Carlton
2003-02-23 23:26 ` Mark Kettenis
2003-02-24 7:18 ` Andrew Cagney [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-02-24 5:29 Michael Elizabeth Chastain
2003-02-20 20:11 Zaretskii Eli
2003-02-20 20:11 Zaretskii Eli
2003-02-20 14:58 ` Daniel Jacobowitz
2003-02-20 15:56 ` Andrew Cagney
2003-02-20 16:39 ` Andrew Cagney
2003-02-20 15:16 ` Daniel Berlin
2003-02-20 16:19 ` Andrew Cagney
2003-02-20 16:24 ` Daniel Berlin
2003-02-20 16:31 ` Daniel Berlin
2003-02-20 17:13 ` Daniel Berlin
2003-02-22 23:25 ` Eli Zaretskii
2003-02-23 1:57 ` Daniel Berlin
2003-02-23 19:23 ` Eli Zaretskii
2003-02-18 6:08 Zaretskii Eli
[not found] <1024952640.13693.ezmlm@sources.redhat.com>
2002-06-25 1:48 ` GDB support for thread-local storage James Cownie
2002-06-25 8:05 ` Daniel Jacobowitz
2002-06-25 8:31 ` James Cownie
2002-06-25 8:42 ` Daniel Jacobowitz
2002-06-25 8:53 ` James Cownie
2002-06-25 8:56 ` Daniel Jacobowitz
2002-06-25 9:11 ` James Cownie
2002-06-25 9:29 ` Daniel Jacobowitz
2002-06-25 10:44 ` Andrew Cagney
2002-06-25 10:02 ` Daniel Jacobowitz
2002-06-26 12:45 ` Jim Blandy
2002-06-26 19:31 ` Andrew Cagney
2002-06-26 21:57 ` Jim Blandy
2002-06-27 8:13 ` Andrew Cagney
2002-08-19 9:05 ` Daniel Jacobowitz
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=3E59C7B6.1000308@redhat.com \
--to=ac131313@redhat.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
--cc=kettenis@chello.nl \
/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