* Maintainer policy for GDB - take N
@ 2006-01-06 19:40 Daniel Jacobowitz
2006-01-06 23:15 ` Eli Zaretskii
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: Daniel Jacobowitz @ 2006-01-06 19:40 UTC (permalink / raw)
To: gdb
Hi folks,
Below I have a complete copy of the MAINTAINERS file, adjusted for all
the changes I've proposed and for all the feedback I received when I
posted them in November. Sorry about the delay; the end of the year
was unexpectedly hectic.
I'm going to be traveling much of next week. I'll have access to
email, but limited time to respond, so I may be out of touch from
Sunday to Friday. I'm eager to hear any feedback on this revision,
especially from Eli, Chris, and Mark.
Some next steps after discussion of this, assuming we finalize on
something similar:
- Ping maintainers about continued interest in / availability for their
listed positions.
- Potentially redo the set of areas covered under Responsible Maintainers
(in broader chunks instead of fine-grained, maybe move the fine-grained
ones down to Authorized Committers).
Replacement text for MAINTAINERS:
GDB Maintainers
===============
Overview
--------
This file describes different groups of people who are, together, the
maintainers and developers of the GDB project. Don't worry - it sounds
more complicated than it really is.
The groups are:
- The GDB Steering Committee.
These are the official (FSF-appointed) maintainers of GDB. They have
final and overriding authority for all GDB-related decisions, including
anything described in this file, but they are not involved in day-to-day
development.
- The Global Maintainers.
These are the developers in charge of most daily development. They
have wide authority to apply and reject patches, but defer to the
Responsible Maintainers (see below) within their spheres of
responsibility.
- The Release Manager.
This developer is in charge of making new releases of GDB.
- The Patch Champions.
These volunteers make sure that no contribution is overlooked or
forgotten.
- The Responsible Maintainers.
These are developers who have expertise and interest in a particular
area of GDB, who are generally available to review patches, and who
prefer to enforce a single vision within their areas.
- The Authorized Committers.
These are developers who are trusted to make changes within a specific
area of GDB without additional oversight.
- The Write After Approval Maintainers.
These are developers who have write access to the GDB source tree. They
can check in their own changes once a developer with the appropriate
authority has approved the changes; they can also apply the Obvious
Fix Rule (below).
All maintainers are encouraged to post major patches to the gdb-patches
mailing list for comments, even if they have the authority to commit the
patch without review from another maintainer. This especially includes
patches which change internal interfaces (e.g. global functions, data
structures) or external interfaces (e.g. user, remote, MI, et cetera).
Most changes to the list of maintainers in this file are handled by
consensus among the global maintainers and any other involved parties.
In cases where consensus can not be reached, the global maintainers may
ask the Steering Committee for a final decision.
The term "review" is used in this file to describe several kinds of feedback
from a maintainer: approval, rejection, and requests for changes or
clarification with the intention of approving a revised version. Review is
a privilege and/or responsibility of various positions among the GDB
Maintainers. Of course, anyone - whether they hold a position but not the
relevant one for a particular patch, or are just following along on the
mailing lists for fun, or anything in between - may suggest changes or
ask questions about a patch!
The Obvious Fix Rule
--------------------
All maintainers listed in this file, including the Write After Approval
developers, are allowed to check in obvious fixes.
An "obvious fix" means that there is no possibility that anyone will
disagree with the change.
A good mental test is "will the person who hates my work the most be
able to find fault with the change" - if so, then it's not obvious and
needs to be posted first. :-)
Something like changing or bypassing an interface is _not_ an obvious
fix, since such a change without discussion will result in
instantaneous and loud complaints.
GDB Steering Committee
----------------------
The members of the GDB Steering Committee are the FSF-appointed
maintainers of the GDB project.
The Steering Committee has final authority for all GDB-related topics;
they may make whatever changes that they deem necessary, or that the FSF
requests. However, they are generally not involved in day-to-day
development.
The current members of the steering committee are listed below, in
alphabetical order. Their affiliations are provided for reference only -
their membership on the Steering Committee is individual and not through
their affiliation, and they act on behalf of the GNU project.
Jim Blandy (Red Hat)
Andrew Cagney (Red Hat)
Robert Dewar (AdaCore, NYU)
Klee Dienes (Apple)
Paul Hilfinger (UC Berkeley)
Dan Jacobowitz (CodeSourcery)
Stan Shebs (Apple)
Richard Stallman (FSF)
Ian Lance Taylor (C2)
Todd Whitesel
Global Maintainers
------------------
The global maintainers may review and commit any change to GDB, except in
areas with a Responsible Maintainer available. For major changes, or
changes to areas with other active developers, global maintainers are
strongly encouraged to post their own patches for feedback before
committing.
The global maintainers are responsible for reviewing patches to any area
for which no Responsible Maintainer is listed.
Global maintainers also have the authority to revert patches which should
not have been applied, e.g. patches which were not approved, controversial
patches committed under the Obvious Fix Rule, patches with important bugs
that can't be immediately fixed, or patches which go against an accepted and
documented roadmap for GDB development. Any global maintainer may request
the reversion of a patch. If no global maintainer, or responsible
maintainer in the affected areas, supports the patch (except for the
maintainer who originally committed it), then after 48 hours the maintainer
who called for the reversion may revert the patch.
No one may reapply a reverted patch without the agreement of the maintainer
who reverted it, or bringing the issue to the GDB Steering Committee for
discussion.
At the moment there are no documented roadmaps for GDB development; in the
future, if there are, a reference to the list will be included here.
The current global maintainers are (in alphabetical order):
Jim Blandy jimb@redhat.com
Kevin Buettner kevinb@redhat.com
Andrew Cagney cagney@gnu.org
J.T. Conklin jtc@acorntoolworks.com
Fred Fish fnf@ninemoons.com
Daniel Jacobowitz dan@debian.org
Mark Kettenis kettenis@gnu.org
Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
Stan Shebs shebs@apple.com
Michael Snyder msnyder@redhat.com
Elena Zannoni ezannoni@redhat.com
Eli Zaretskii eliz@gnu.org
Release Manager
---------------
The current release manager is: Joel Brobecker <brobecker@adacore.com>
His responsibilities are:
* organizing, scheduling, and managing releases of GDB.
* deciding the approval and commit policies for release branches,
and can change them as needed.
Patch Champions
---------------
These volunteers track all patches submitted to the gdb-patches list. They
endeavor to prevent any posted patch from being overlooked; work with
contributors to meet GDB's coding style and general requirements, along with
FSF copyright assignments; remind (ping) responsible maintainers to review
patches; and ensure that contributors are given credit.
Current patch champions (in alphabetical order):
Joel Brobecker <brobecker@adacore.com>
Daniel Jacobowitz <dan@debian.org>
Responsible Maintainers
-----------------------
These developers have agreed to review patches in specific areas of GDB, in
which they have knowledge and experience. These areas are generally broad;
the role of a responsible maintainer is to provide coherent and cohesive
structure within their area of GDB, to assure that patches from many
different contributors all work together for the best results.
Global maintainers will defer to responsible maintainers within their areas,
as long as the responsible maintainer is active. Active means that
responsible maintainers agree to review submitted patches in their area
promptly; patches and followups should generally be answered within a week.
If a responsible maintainer is interested in reviewing a patch but will not
have time within a week of posting, the maintainer should send an
acknowledgement of the patch to the gdb-patches mailing list, and
plan to follow up with a review within a month. These deadlines are for
initial responses to a patch - if the maintainer has suggestions
or questions, it may take an extended discussion before the patch
is ready to commit. There are no written requirements for discussion,
but maintainers are asked to be responsive.
If a responsible maintainer misses these deadlines occasionally (e.g.
vacation or unexpected workload), it's not a disaster - any global
maintainer may step in to review the patch. But sometimes life intervenes
more permanently, and a maintainer may no longer have time for these duties.
When this happens, he or she should step down (either into the Authorized
Committers section if still interested in the area, or simply removed from
the list of Responsible Maintainers if not).
If a responsible maintainer is unresponsive for an extended period of time
without stepping down, please contact the Global Maintainers; they will try
to contact the maintainer directly and fix the problem - potentially by
removing that maintainer from their listed position.
If there are several maintainers for a given domain then any one of them
may review a submitted patch.
Target Instruction Set Architectures:
The *-tdep.c files. ISA (Instruction Set Architecture) and OS-ABI
(Operating System / Application Binary Interface) issues including CPU
variants.
The Target/Architecture maintainer works with the host maintainer when
resolving build issues. The Target/Architecture maintainer works with
the native maintainer when resolving ABI issues.
alpha --target=alpha-elf ,-Werror
arm --target=arm-elf ,-Werror
Scott Bambrough scottb@netwinder.org
Richard Earnshaw rearnsha@arm.com
avr --target=avr ,-Werror
Theodore A. Roth troth@openavr.org
cris --target=cris-elf ,-Werror
d10v OBSOLETE
frv --target=frv-elf ,-Werror
h8300 --target=h8300-elf ,-Werror
i386 --target=i386-elf ,-Werror
Mark Kettenis kettenis@gnu.org
ia64 --target=ia64-linux-gnu ,-Werror
(--target=ia64-elf broken)
Kevin Buettner kevinb@redhat.com
m32r --target=m32r-elf ,-Werror
m68hc11 --target=m68hc11-elf ,-Werror ,
Stephane Carrez stcarrez@nerim.fr
m68k --target=m68k-elf ,-Werror
m88k --target=m88k-openbsd ,-Werror
Mark Kettenis kettenis@gnu.org
mcore Deleted
mips --target=mips-elf ,-Werror
mn10300 --target=mn10300-elf broken
(sim/ dies with make -j)
Michael Snyder msnyder@redhat.com
ms1 --target=ms1-elf ,-Werror
Kevin Buettner kevinb@redhat.com
ns32k Deleted
pa --target=hppa-elf ,-Werror
powerpc --target=powerpc-eabi ,-Werror
s390 --target=s390-linux-gnu ,-Werror
sh --target=sh-elf ,-Werror
--target=sh64-elf ,-Werror
sparc --target=sparc-elf ,-Werror
v850 --target=v850-elf ,-Werror
vax --target=vax-netbsd ,-Werror
x86-64 --target=x86_64-linux-gnu ,-Werror
xstormy16 --target=xstormy16-elf
Corinna Vinschen vinschen@redhat.com
All developers recognized by this file can make arbitrary changes to
OBSOLETE targets.
The Bourne shell script gdb_mbuild.sh can be used to rebuild all the
above targets.
Host/Native:
The Native maintainer is responsible for target specific native
support - typically shared libraries and quirks to procfs/ptrace/...
The Native maintainer works with the Arch and Core maintainers when
resolving more generic problems.
The host maintainer ensures that gdb can be built as a cross debugger on
their platform.
AIX Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
Kevin Buettner kevinb@redhat.com
Joel Brobecker brobecker@gnat.com
djgpp native Eli Zaretskii eliz@gnu.org
DJ Delorie dj@redhat.com
MS Windows (NT, '00, 9x, Me, XP) host & native
Chris Faylor cgf@alum.bu.edu
GNU/Linux/x86 native & host
Mark Kettenis kettenis@gnu.org
GNU/Linux PPC native Kevin Buettner kevinb@redhat.com
GNU/Linux MIPS native & host
Daniel Jacobowitz dan@debian.org
GNU/Linux m68k Andreas Schwab schwab@suse.de
FreeBSD native & host Mark Kettenis kettenis@gnu.org
David O'Brien obrien@freebsd.org
hurd native Mark Kettenis kettenis@gnu.org
NetBSD native & host Jason Thorpe thorpej@netbsd.org
SCO/Unixware Robert Lipe rjl@sco.com
GNU/Linux ARM native Scott Bambrough scottb@netwinder.org
Solaris/x86 native & host (devolved)
Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
Solaris/SPARC native & host (devolved)
(Global Maintainers)
Core: Generic components used by all of GDB
generic arch support (Global Maintainers)
Any host/target maintainer can add to
gdbarch.{c,h,sh}.
target vector (Global Maintainers)
event loop Elena Zannoni ezannoni@redhat.com
For the part of top.c related to the event loop,
send questions to ezannoni@redhat.com
generic symtabs Elena Zannoni ezannoni@redhat.com
dwarf readers Elena Zannoni ezannoni@redhat.com
elf reader Elena Zannoni ezannoni@redhat.com
stabs reader Elena Zannoni ezannoni@redhat.com
coff reader Philippe De Muyter phdm@macqel.be
xcoff reader Any maintainer can modify this; please send tricky
ones to Kevin Buettner <kevinb@redhat.com>
HP/UX readers Any [past] maintainer can modify this.
Please send tricky ones to the symtabs maintainers.
tracing bytecode stuff (Global Maintainers)
tracing Michael Snyder msnyder@redhat.com
threads Michael Snyder msnyder@redhat.com
Mark Kettenis kettenis@gnu.org
breakpoints (Global Maintainers)
language support (Blanket Write Privs Maintainers)
C++ Daniel Jacobowitz dan@debian.org
Java support (Global Maintainers)
Pascal support Pierre Muller muller@sources.redhat.com
Objective C support Adam Fedor fedor@gnu.org
shared libs (devolved) Kevin Buettner kevinb@redhat.com
xcoffsolib Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
sds protocol (vacant)
rdi/adp protocol (vacant)
documentation Eli Zaretskii eliz@gnu.org
testsuite Michael Chastain mec.gnu@mindspring.com
(Global Maintainers)
lib/, config/, gdb.base/, ...
Michael Chastain mec.gnu@mindspring.com
(Global Maintainers)
gdbtk (gdb.gdbtk) Keith Seitz keiths@redhat.com
c++ (gdb.cp) Michael Chastain mec.gnu@mindspring.com
threads (gdb.threads) Michael Snyder msnyder@redhat.com
Michael Chastain mec.gnu@mindspring.com
trace (gdb.trace) Michael Snyder msnyder@redhat.com
hp tests (gdb.hp) (vacant)
Java tests (gdb.java) Anthony Green green@redhat.com
Kernel Object Display Fernando Nasser fnasser@redhat.com
UI: External (user) interfaces.
command interpreter (Global Maintainers)
gdbtk (c & tcl) Jim Ingham jingham@apple.com
Fernando Nasser fnasser@redhat.com
Keith Seitz keiths@redhat.com
libgui (w/foundry, sn) Jim Ingham jingham@apple.com
Keith Seitz keiths@redhat.com
tui Stephane Carrez stcarrez@nerim.fr
(Global Maintainers)
Misc:
gdb/gdbserver Daniel Jacobowitz dan@debian.org
Web pages. Jim Kingdon jkingdon@engr.sgi.com ++
(anyone can edit; kingdon is just lead maintainer)
Makefile.in, configure* ALL
mmalloc/ ALL Host maintainers
NEWS ALL
sim/ See sim/MAINTAINERS
readline/ Master version: ftp://ftp.cwru.edu/pub/bash/
Elena Zannoni ezannoni@redhat.com
Host maintainers (host dependant parts)
(but get your changes into the master version)
tcl/ tk/ itcl/ Ian Roxborough irox@redhat.com
Authorized Committers
---------------------
These are developers working on particular areas of GDB, who are trusted to
commit their own (or other developers') patches in those areas without
further review from a Global Maintainer or Responsible Maintainer. They are
under no obligation to review posted patches - but, of course, are invited
to do so!
Andrew Cagney (powerpc, powerpc-linux)
Hans-Peter Nilsson (cris)
Jeff Johnston (ia64)
Joel Brobecker (mips)
Kei Sakamoto (m32r)
Kevin Buettner (powerpc)
Orjan Friberg (cris)
Randolph Chung (pa)
Ulrich Weigand (s390)
Write After Approval
(alphabetic)
To get recommended for the Write After Approval list you need a valid
FSF assignment and have submitted one good patch.
David Anderson davea@sgi.com
John David Anglin dave.anglin@nrc-cnrc.gc.ca
Shrinivas Atre shrinivasa@kpitcummins.com
Scott Bambrough scottb@netwinder.org
Jan Beulich jbeulich@novell.com
Jim Blandy jimb@redhat.com
Philip Blundell philb@gnu.org
Per Bothner per@bothner.com
Joel Brobecker brobecker@gnat.com
Dave Brolley brolley@redhat.com
Paul Brook paul@codesourcery.com
Kevin Buettner kevinb@redhat.com
Andrew Cagney cagney@gnu.org
David Carlton carlton@bactrian.org
Stephane Carrez stcarrez@nerim.fr
Michael Chastain mec.gnu@mindspring.com
Eric Christopher echristo@apple.com
Randolph Chung tausq@debian.org
Nick Clifton nickc@redhat.com
Brendan Conoboy blc@redhat.com
DJ Delorie dj@redhat.com
Philippe De Muyter phdm@macqel.be
Dhananjay Deshpande dhananjayd@kpitcummins.com
Klee Dienes kdienes@apple.com
Richard Earnshaw rearnsha@arm.com
Steve Ellcey sje@cup.hp.com
Frank Ch. Eigler fche@redhat.com
Ben Elliston bje@gnu.org
Adam Fedor fedor@gnu.org
Fred Fish fnf@ninemoons.com
Brian Ford ford@vss.fsi.com
Orjan Friberg orjanf@axis.com
Paul Gilliam pgilliam@us.ibm.com
Raoul Gough RaoulGough@yahoo.co.uk
Anthony Green green@redhat.com
Matthew Green mrg@eterna.com.au
Jerome Guitton guitton@act-europe.fr
Ben Harris bjh21@netbsd.org
Richard Henderson rth@redhat.com
Aldy Hernandez aldyh@redhat.com
Paul Hilfinger hilfinger@gnat.com
Matt Hiller hiller@redhat.com
Kazu Hirata kazu@cs.umass.edu
Jeff Holcomb jeffh@redhat.com
Don Howard dhoward@redhat.com
Martin Hunt hunt@redhat.com
Jim Ingham jingham@apple.com
Baurzhan Ismagulov ibr@radix50.net
Manoj Iyer manjo@austin.ibm.com
Daniel Jacobowitz dan@debian.org
Andreas Jaeger aj@suse.de
Jeff Johnston jjohnstn@redhat.com
Geoff Keating geoffk@redhat.com
Mark Kettenis kettenis@gnu.org
Jim Kingdon jkingdon@engr.sgi.com ++
Jonathan Larmour jlarmour@redhat.co.uk
Jeff Law law@redhat.com
David Lecomber david@streamline-computing.com
Robert Lipe rjl@sco.com
H.J. Lu hjl@lucon.org
Michal Ludvig mludvig@suse.cz
Glen McCready gkm@redhat.com
Greg McGary greg@mcgary.org
Roland McGrath roland@redhat.com
Bryce McKinlay mckinlay@redhat.com
Jason Merrill jason@redhat.com
David S. Miller davem@redhat.com
Mark Mitchell mark@codesourcery.com
Marko Mlinar markom@opencores.org
Alan Modra amodra@bigpond.net.au
Jason Molenda jmolenda@apple.com
Pierre Muller muller@sources.redhat.com
Joseph Myers joseph@codesourcery.com
Fernando Nasser fnasser@redhat.com
Nathanael Nerode neroden@gcc.gnu.org
Hans-Peter Nilsson hp@bitrange.com
David O'Brien obrien@freebsd.org
Alexandre Oliva aoliva@redhat.com
Ramana Radhakrishnan ramana.radhakrishnan@codito.com
Frederic Riss frederic.riss@st.com
Tom Rix trix@redhat.com
Nick Roberts nickrob@snap.net.nz
Bob Rossi bob_rossi@cox.net
Theodore A. Roth troth@openavr.org
Ian Roxborough irox@redhat.com
Grace Sainsbury graces@redhat.com
Kei Sakamoto sakamoto.kei@renesas.com
Mark Salter msalter@redhat.com
Richard Sandiford richard@codesourcery.com
Peter Schauer Peter.Schauer@regent
Andreas Schwab schwab@suse.de
Keith Seitz keiths@redhat.com
Stan Shebs shebs@apple.com
Aidan Skinner aidan@velvet.net
Jiri Smid smid@suse.cz
David Smith dsmith@redhat.com
Stephen P. Smith ischis2@cox.net
Jackie Smith Cashion jsmith@redhat.com
Michael Snyder msnyder@redhat.com
Petr Sorfa petrs@caldera.com
Andrew Stubbs andrew.stubbs@st.com
Ian Lance Taylor ian@airs.com
Gary Thomas gthomas@redhat.com
Jason Thorpe thorpej@netbsd.org
Tom Tromey tromey@redhat.com
David Ung davidu@mips.com
D Venkatasubramanian dvenkat@noida.hcltech.com
Corinna Vinschen vinschen@redhat.com
Keith Walker keith.walker@arm.com
Kris Warkentin kewarken@qnx.com
Ulrich Weigand uweigand@de.ibm.com
Nathan Williams nathanw@wasabisystems.com
Jim Wilson wilson@specifixinc.com
Elena Zannoni ezannoni@redhat.com
Eli Zaretskii eliz@gnu.org
Wu Zhou woodzltc@cn.ibm.com
Yoshinori Sato ysato@users.sourceforge.jp
Past Maintainers
Jimmy Guo (gdb.hp, tui) guo at cup dot hp dot com
Jeff Law (hppa) law at cygnus dot com
Daniel Berlin (C++ support) dan at cgsoftware dot com
Nick Duffek (powerpc, SCO, Sol/x86) nick at duffek dot com
David Taylor (d10v, sparc, utils, defs,
expression evaluator, language support) taylor at candd dot org
J.T. Conklin (dcache, NetBSD, remote) jtc at redback dot com
Frank Ch. Eigler (sim) fche at redhat dot com
Per Bothner (Java) per at bothner dot com
Anthony Green (Java) green at redhat dot com
Fernando Nasser (testsuite/, mi, cli) fnasser at redhat dot com
Mark Salter (testsuite/lib+config) msalter at redhat dot com
Folks that have been caught up in a paper trail:
Chris Faylor cgf@alum.bu.edu
Jim Kingdon jkingdon@engr.sgi.com
David Carlton carlton@bactrian.org
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maintainer policy for GDB - take N
2006-01-06 19:40 Maintainer policy for GDB - take N Daniel Jacobowitz
@ 2006-01-06 23:15 ` Eli Zaretskii
2006-01-08 17:52 ` Mark Kettenis
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2006-01-06 23:15 UTC (permalink / raw)
To: gdb
> Date: Fri, 6 Jan 2006 14:40:07 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> Below I have a complete copy of the MAINTAINERS file, adjusted for all
> the changes I've proposed and for all the feedback I received when I
> posted them in November. Sorry about the delay; the end of the year
> was unexpectedly hectic.
>
> I'm going to be traveling much of next week. I'll have access to
> email, but limited time to respond, so I may be out of touch from
> Sunday to Friday. I'm eager to hear any feedback on this revision,
> especially from Eli, Chris, and Mark.
The structure of the maintainership, with all the different kinds of
maintainers, sounds too complicated. (Yes, I know that you wrote it's
simpler than it sounds, but I'm trying to read this through the eyes
of a casual contributor.) Can we simplify that? For example, Patch
Champions and Past Maintainers have no responsibilities under this
scheme, so perhaps we should exclude them from the system description.
Or maybe we should have a separate description of the system,
explaining its checks and balances, and referring to the lists of
maintainers further down the document (the point being that the lists
are sometimes quite long, and reading through them distracts from
getting the coherent picture of the system of responsibilities and
authorities).
Other than that, I have no open issues with this suggestion.
Thank you for all the hard work of getting this suggested, discussed,
rewritten, refined, redone, etc. etc...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maintainer policy for GDB - take N
2006-01-06 19:40 Maintainer policy for GDB - take N Daniel Jacobowitz
2006-01-06 23:15 ` Eli Zaretskii
@ 2006-01-08 17:52 ` Mark Kettenis
2006-01-09 5:53 ` Jim Blandy
2006-01-09 18:00 ` Christopher Faylor
2006-01-17 22:09 ` Daniel Jacobowitz
3 siblings, 1 reply; 8+ messages in thread
From: Mark Kettenis @ 2006-01-08 17:52 UTC (permalink / raw)
To: drow; +Cc: gdb
> Date: Fri, 6 Jan 2006 14:40:07 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> Hi folks,
>
> Below I have a complete copy of the MAINTAINERS file, adjusted for all
> the changes I've proposed and for all the feedback I received when I
> posted them in November. Sorry about the delay; the end of the year
> was unexpectedly hectic.
>
> I'm going to be traveling much of next week. I'll have access to
> email, but limited time to respond, so I may be out of touch from
> Sunday to Friday. I'm eager to hear any feedback on this revision,
> especially from Eli, Chris, and Mark.
In general, this seems to be something I certainly can live with ;-).
> Some next steps after discussion of this, assuming we finalize on
> something similar:
> - Ping maintainers about continued interest in / availability for their
> listed positions.
> - Potentially redo the set of areas covered under Responsible Maintainers
> (in broader chunks instead of fine-grained, maybe move the fine-grained
> ones down to Authorized Committers).
>
> Replacement text for MAINTAINERS:
>
>
> GDB Maintainers
> ===============
>
>
> Overview
> --------
>
> This file describes different groups of people who are, together, the
> maintainers and developers of the GDB project. Don't worry - it sounds
> more complicated than it really is.
>
> The groups are:
>
> - The GDB Steering Committee.
>
> These are the official (FSF-appointed) maintainers of GDB. They have
> final and overriding authority for all GDB-related decisions, including
> anything described in this file, but they are not involved in day-to-day
> development.
Ah Daniel, sad to hear that you're no longer doing any day-to-day
development ;-). Perhaps you stick in a "in general" somewhere in the
last sentence..
> - The Global Maintainers.
>
> These are the developers in charge of most daily development. They
> have wide authority to apply and reject patches, but defer to the
> Responsible Maintainers (see below) within their spheres of
> responsibility.
>
> - The Release Manager.
>
> This developer is in charge of making new releases of GDB.
>
> - The Patch Champions.
>
> These volunteers make sure that no contribution is overlooked or
> forgotten.
>
> - The Responsible Maintainers.
>
> These are developers who have expertise and interest in a particular
> area of GDB, who are generally available to review patches, and who
> prefer to enforce a single vision within their areas.
>
> - The Authorized Committers.
>
> These are developers who are trusted to make changes within a specific
> area of GDB without additional oversight.
>
> - The Write After Approval Maintainers.
>
> These are developers who have write access to the GDB source tree. They
> can check in their own changes once a developer with the appropriate
> authority has approved the changes; they can also apply the Obvious
> Fix Rule (below).
I really think these definitions are silly; there are more categories
here than we have active developers it seems. But if this is what's
needed to reach consensus, well, I don't really care that much.
Mark
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maintainer policy for GDB - take N
2006-01-08 17:52 ` Mark Kettenis
@ 2006-01-09 5:53 ` Jim Blandy
0 siblings, 0 replies; 8+ messages in thread
From: Jim Blandy @ 2006-01-09 5:53 UTC (permalink / raw)
To: Mark Kettenis; +Cc: drow, gdb
On 1/8/06, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > These are the official (FSF-appointed) maintainers of GDB. They have
> > final and overriding authority for all GDB-related decisions, including
> > anything described in this file, but they are not involved in day-to-day
> > development.
>
> Ah Daniel, sad to hear that you're no longer doing any day-to-day
> development ;-). Perhaps you stick in a "in general" somewhere in the
> last sentence..
This sounded funny to me, too. It would be sufficient to just
preserve the word "generally" from the more detailed description of
the steering committee below.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maintainer policy for GDB - take N
2006-01-06 19:40 Maintainer policy for GDB - take N Daniel Jacobowitz
2006-01-06 23:15 ` Eli Zaretskii
2006-01-08 17:52 ` Mark Kettenis
@ 2006-01-09 18:00 ` Christopher Faylor
2006-01-17 22:09 ` Daniel Jacobowitz
3 siblings, 0 replies; 8+ messages in thread
From: Christopher Faylor @ 2006-01-09 18:00 UTC (permalink / raw)
To: gdb
On Fri, Jan 06, 2006 at 02:40:07PM -0500, Daniel Jacobowitz wrote:
>I'm going to be traveling much of next week. I'll have access to
>email, but limited time to respond, so I may be out of touch from
>Sunday to Friday. I'm eager to hear any feedback on this revision,
>especially from Eli, Chris, and Mark.
No objections from me. Nice job, and thanks for doing this, Daniel.
cgf
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maintainer policy for GDB - take N
2006-01-06 19:40 Maintainer policy for GDB - take N Daniel Jacobowitz
` (2 preceding siblings ...)
2006-01-09 18:00 ` Christopher Faylor
@ 2006-01-17 22:09 ` Daniel Jacobowitz
2006-01-17 23:28 ` Mark Kettenis
2006-01-18 11:17 ` Christopher Faylor
3 siblings, 2 replies; 8+ messages in thread
From: Daniel Jacobowitz @ 2006-01-17 22:09 UTC (permalink / raw)
To: gdb
On Fri, Jan 06, 2006 at 02:40:07PM -0500, Daniel Jacobowitz wrote:
> Replacement text for MAINTAINERS:
There was some dissatisfaction with my Overview :-) Is this any
better? The only changes from the last posting are in the Overview,
above the section heading for the Obvious Fix Rule, but it doesn't lend
itself to diff well.
Assuming this version's a little better, I think we've evolved as far
as we're going to. If no one objects I will commit this at the end of
the week and then send out pings to everyone with listed
responsibilities, off-list.
GDB Maintainers
===============
Overview
--------
This file describes different groups of people who are, together, the
maintainers and developers of the GDB project. Don't worry - it sounds
more complicated than it really is.
There are four groups of GDB developers, covering the patch development and
review process:
- The Global Maintainers.
These are the developers in charge of most daily development. They
have wide authority to apply and reject patches, but defer to the
Responsible Maintainers (see below) within their spheres of
responsibility.
- The Responsible Maintainers.
These are developers who have expertise and interest in a particular
area of GDB, who are generally available to review patches, and who
prefer to enforce a single vision within their areas.
- The Authorized Committers.
These are developers who are trusted to make changes within a specific
area of GDB without additional oversight.
- The Write After Approval Maintainers.
These are developers who have write access to the GDB source tree. They
can check in their own changes once a developer with the appropriate
authority has approved the changes; they can also apply the Obvious
Fix Rule (below).
All maintainers are encouraged to post major patches to the gdb-patches
mailing list for comments, even if they have the authority to commit the
patch without review from another maintainer. This especially includes
patches which change internal interfaces (e.g. global functions, data
structures) or external interfaces (e.g. user, remote, MI, et cetera).
The term "review" is used in this file to describe several kinds of feedback
from a maintainer: approval, rejection, and requests for changes or
clarification with the intention of approving a revised version. Review is
a privilege and/or responsibility of various positions among the GDB
Maintainers. Of course, anyone - whether they hold a position but not the
relevant one for a particular patch, or are just following along on the
mailing lists for fun, or anything in between - may suggest changes or
ask questions about a patch!
There's also a couple of other people who play special roles in the GDB
community, separately from the patch process:
- The GDB Steering Committee.
These are the official (FSF-appointed) maintainers of GDB. They have
final and overriding authority for all GDB-related decisions, including
anything described in this file. The committee is not generally
involved in day-to-day development (although its members may be, as
individuals).
- The Release Manager.
This developer is in charge of making new releases of GDB.
- The Patch Champions.
These volunteers make sure that no contribution is overlooked or
forgotten.
Most changes to the list of maintainers in this file are handled by
consensus among the global maintainers and any other involved parties.
In cases where consensus can not be reached, the global maintainers may
ask the Steering Committee for a final decision.
The Obvious Fix Rule
--------------------
All maintainers listed in this file, including the Write After Approval
developers, are allowed to check in obvious fixes.
An "obvious fix" means that there is no possibility that anyone will
disagree with the change.
A good mental test is "will the person who hates my work the most be
able to find fault with the change" - if so, then it's not obvious and
needs to be posted first. :-)
Something like changing or bypassing an interface is _not_ an obvious
fix, since such a change without discussion will result in
instantaneous and loud complaints.
GDB Steering Committee
----------------------
The members of the GDB Steering Committee are the FSF-appointed
maintainers of the GDB project.
The Steering Committee has final authority for all GDB-related topics;
they may make whatever changes that they deem necessary, or that the FSF
requests. However, they are generally not involved in day-to-day
development.
The current members of the steering committee are listed below, in
alphabetical order. Their affiliations are provided for reference only -
their membership on the Steering Committee is individual and not through
their affiliation, and they act on behalf of the GNU project.
Jim Blandy (Red Hat)
Andrew Cagney (Red Hat)
Robert Dewar (AdaCore, NYU)
Klee Dienes (Apple)
Paul Hilfinger (UC Berkeley)
Dan Jacobowitz (CodeSourcery)
Stan Shebs (Apple)
Richard Stallman (FSF)
Ian Lance Taylor (C2)
Todd Whitesel
Global Maintainers
------------------
The global maintainers may review and commit any change to GDB, except in
areas with a Responsible Maintainer available. For major changes, or
changes to areas with other active developers, global maintainers are
strongly encouraged to post their own patches for feedback before
committing.
The global maintainers are responsible for reviewing patches to any area
for which no Responsible Maintainer is listed.
Global maintainers also have the authority to revert patches which should
not have been applied, e.g. patches which were not approved, controversial
patches committed under the Obvious Fix Rule, patches with important bugs
that can't be immediately fixed, or patches which go against an accepted and
documented roadmap for GDB development. Any global maintainer may request
the reversion of a patch. If no global maintainer, or responsible
maintainer in the affected areas, supports the patch (except for the
maintainer who originally committed it), then after 48 hours the maintainer
who called for the reversion may revert the patch.
No one may reapply a reverted patch without the agreement of the maintainer
who reverted it, or bringing the issue to the GDB Steering Committee for
discussion.
At the moment there are no documented roadmaps for GDB development; in the
future, if there are, a reference to the list will be included here.
The current global maintainers are (in alphabetical order):
Jim Blandy jimb@redhat.com
Kevin Buettner kevinb@redhat.com
Andrew Cagney cagney@gnu.org
J.T. Conklin jtc@acorntoolworks.com
Fred Fish fnf@ninemoons.com
Daniel Jacobowitz dan@debian.org
Mark Kettenis kettenis@gnu.org
Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
Stan Shebs shebs@apple.com
Michael Snyder msnyder@redhat.com
Elena Zannoni ezannoni@redhat.com
Eli Zaretskii eliz@gnu.org
Release Manager
---------------
The current release manager is: Joel Brobecker <brobecker@adacore.com>
His responsibilities are:
* organizing, scheduling, and managing releases of GDB.
* deciding the approval and commit policies for release branches,
and can change them as needed.
Patch Champions
---------------
These volunteers track all patches submitted to the gdb-patches list. They
endeavor to prevent any posted patch from being overlooked; work with
contributors to meet GDB's coding style and general requirements, along with
FSF copyright assignments; remind (ping) responsible maintainers to review
patches; and ensure that contributors are given credit.
Current patch champions (in alphabetical order):
Joel Brobecker <brobecker@adacore.com>
Daniel Jacobowitz <dan@debian.org>
Responsible Maintainers
-----------------------
These developers have agreed to review patches in specific areas of GDB, in
which they have knowledge and experience. These areas are generally broad;
the role of a responsible maintainer is to provide coherent and cohesive
structure within their area of GDB, to assure that patches from many
different contributors all work together for the best results.
Global maintainers will defer to responsible maintainers within their areas,
as long as the responsible maintainer is active. Active means that
responsible maintainers agree to review submitted patches in their area
promptly; patches and followups should generally be answered within a week.
If a responsible maintainer is interested in reviewing a patch but will not
have time within a week of posting, the maintainer should send an
acknowledgement of the patch to the gdb-patches mailing list, and
plan to follow up with a review within a month. These deadlines are for
initial responses to a patch - if the maintainer has suggestions
or questions, it may take an extended discussion before the patch
is ready to commit. There are no written requirements for discussion,
but maintainers are asked to be responsive.
If a responsible maintainer misses these deadlines occasionally (e.g.
vacation or unexpected workload), it's not a disaster - any global
maintainer may step in to review the patch. But sometimes life intervenes
more permanently, and a maintainer may no longer have time for these duties.
When this happens, he or she should step down (either into the Authorized
Committers section if still interested in the area, or simply removed from
the list of Responsible Maintainers if not).
If a responsible maintainer is unresponsive for an extended period of time
without stepping down, please contact the Global Maintainers; they will try
to contact the maintainer directly and fix the problem - potentially by
removing that maintainer from their listed position.
If there are several maintainers for a given domain then any one of them
may review a submitted patch.
Target Instruction Set Architectures:
The *-tdep.c files. ISA (Instruction Set Architecture) and OS-ABI
(Operating System / Application Binary Interface) issues including CPU
variants.
The Target/Architecture maintainer works with the host maintainer when
resolving build issues. The Target/Architecture maintainer works with
the native maintainer when resolving ABI issues.
alpha --target=alpha-elf ,-Werror
arm --target=arm-elf ,-Werror
Scott Bambrough scottb@netwinder.org
Richard Earnshaw rearnsha@arm.com
avr --target=avr ,-Werror
Theodore A. Roth troth@openavr.org
cris --target=cris-elf ,-Werror
d10v OBSOLETE
frv --target=frv-elf ,-Werror
h8300 --target=h8300-elf ,-Werror
i386 --target=i386-elf ,-Werror
Mark Kettenis kettenis@gnu.org
ia64 --target=ia64-linux-gnu ,-Werror
(--target=ia64-elf broken)
Kevin Buettner kevinb@redhat.com
m32r --target=m32r-elf ,-Werror
m68hc11 --target=m68hc11-elf ,-Werror ,
Stephane Carrez stcarrez@nerim.fr
m68k --target=m68k-elf ,-Werror
m88k --target=m88k-openbsd ,-Werror
Mark Kettenis kettenis@gnu.org
mcore Deleted
mips --target=mips-elf ,-Werror
mn10300 --target=mn10300-elf broken
(sim/ dies with make -j)
Michael Snyder msnyder@redhat.com
ms1 --target=ms1-elf ,-Werror
Kevin Buettner kevinb@redhat.com
ns32k Deleted
pa --target=hppa-elf ,-Werror
powerpc --target=powerpc-eabi ,-Werror
s390 --target=s390-linux-gnu ,-Werror
sh --target=sh-elf ,-Werror
--target=sh64-elf ,-Werror
sparc --target=sparc-elf ,-Werror
v850 --target=v850-elf ,-Werror
vax --target=vax-netbsd ,-Werror
x86-64 --target=x86_64-linux-gnu ,-Werror
xstormy16 --target=xstormy16-elf
Corinna Vinschen vinschen@redhat.com
All developers recognized by this file can make arbitrary changes to
OBSOLETE targets.
The Bourne shell script gdb_mbuild.sh can be used to rebuild all the
above targets.
Host/Native:
The Native maintainer is responsible for target specific native
support - typically shared libraries and quirks to procfs/ptrace/...
The Native maintainer works with the Arch and Core maintainers when
resolving more generic problems.
The host maintainer ensures that gdb can be built as a cross debugger on
their platform.
AIX Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
Kevin Buettner kevinb@redhat.com
Joel Brobecker brobecker@gnat.com
djgpp native Eli Zaretskii eliz@gnu.org
DJ Delorie dj@redhat.com
MS Windows (NT, '00, 9x, Me, XP) host & native
Chris Faylor cgf@alum.bu.edu
GNU/Linux/x86 native & host
Mark Kettenis kettenis@gnu.org
GNU/Linux PPC native Kevin Buettner kevinb@redhat.com
GNU/Linux MIPS native & host
Daniel Jacobowitz dan@debian.org
GNU/Linux m68k Andreas Schwab schwab@suse.de
FreeBSD native & host Mark Kettenis kettenis@gnu.org
David O'Brien obrien@freebsd.org
hurd native Mark Kettenis kettenis@gnu.org
NetBSD native & host Jason Thorpe thorpej@netbsd.org
SCO/Unixware Robert Lipe rjl@sco.com
GNU/Linux ARM native Scott Bambrough scottb@netwinder.org
Solaris/x86 native & host (devolved)
Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
Solaris/SPARC native & host (devolved)
(Global Maintainers)
Core: Generic components used by all of GDB
generic arch support (Global Maintainers)
Any host/target maintainer can add to
gdbarch.{c,h,sh}.
target vector (Global Maintainers)
event loop Elena Zannoni ezannoni@redhat.com
For the part of top.c related to the event loop,
send questions to ezannoni@redhat.com
generic symtabs Elena Zannoni ezannoni@redhat.com
dwarf readers Elena Zannoni ezannoni@redhat.com
elf reader Elena Zannoni ezannoni@redhat.com
stabs reader Elena Zannoni ezannoni@redhat.com
coff reader Philippe De Muyter phdm@macqel.be
xcoff reader Any maintainer can modify this; please send tricky
ones to Kevin Buettner <kevinb@redhat.com>
HP/UX readers Any [past] maintainer can modify this.
Please send tricky ones to the symtabs maintainers.
tracing bytecode stuff (Global Maintainers)
tracing Michael Snyder msnyder@redhat.com
threads Michael Snyder msnyder@redhat.com
Mark Kettenis kettenis@gnu.org
breakpoints (Global Maintainers)
language support (Blanket Write Privs Maintainers)
C++ Daniel Jacobowitz dan@debian.org
Java support (Global Maintainers)
Pascal support Pierre Muller muller@sources.redhat.com
Objective C support Adam Fedor fedor@gnu.org
shared libs (devolved) Kevin Buettner kevinb@redhat.com
xcoffsolib Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
sds protocol (vacant)
rdi/adp protocol (vacant)
documentation Eli Zaretskii eliz@gnu.org
testsuite Michael Chastain mec.gnu@mindspring.com
(Global Maintainers)
lib/, config/, gdb.base/, ...
Michael Chastain mec.gnu@mindspring.com
(Global Maintainers)
gdbtk (gdb.gdbtk) Keith Seitz keiths@redhat.com
c++ (gdb.cp) Michael Chastain mec.gnu@mindspring.com
threads (gdb.threads) Michael Snyder msnyder@redhat.com
Michael Chastain mec.gnu@mindspring.com
trace (gdb.trace) Michael Snyder msnyder@redhat.com
hp tests (gdb.hp) (vacant)
Java tests (gdb.java) Anthony Green green@redhat.com
Kernel Object Display Fernando Nasser fnasser@redhat.com
UI: External (user) interfaces.
command interpreter (Global Maintainers)
gdbtk (c & tcl) Jim Ingham jingham@apple.com
Fernando Nasser fnasser@redhat.com
Keith Seitz keiths@redhat.com
libgui (w/foundry, sn) Jim Ingham jingham@apple.com
Keith Seitz keiths@redhat.com
tui Stephane Carrez stcarrez@nerim.fr
(Global Maintainers)
Misc:
gdb/gdbserver Daniel Jacobowitz dan@debian.org
Web pages. Jim Kingdon jkingdon@engr.sgi.com ++
(anyone can edit; kingdon is just lead maintainer)
Makefile.in, configure* ALL
mmalloc/ ALL Host maintainers
NEWS ALL
sim/ See sim/MAINTAINERS
readline/ Master version: ftp://ftp.cwru.edu/pub/bash/
Elena Zannoni ezannoni@redhat.com
Host maintainers (host dependant parts)
(but get your changes into the master version)
tcl/ tk/ itcl/ Ian Roxborough irox@redhat.com
Authorized Committers
---------------------
These are developers working on particular areas of GDB, who are trusted to
commit their own (or other developers') patches in those areas without
further review from a Global Maintainer or Responsible Maintainer. They are
under no obligation to review posted patches - but, of course, are invited
to do so!
Andrew Cagney (powerpc, powerpc-linux)
Hans-Peter Nilsson (cris)
Jeff Johnston (ia64)
Joel Brobecker (mips)
Kei Sakamoto (m32r)
Kevin Buettner (powerpc)
Orjan Friberg (cris)
Randolph Chung (pa)
Ulrich Weigand (s390)
Write After Approval
(alphabetic)
To get recommended for the Write After Approval list you need a valid
FSF assignment and have submitted one good patch.
David Anderson davea@sgi.com
John David Anglin dave.anglin@nrc-cnrc.gc.ca
Shrinivas Atre shrinivasa@kpitcummins.com
Scott Bambrough scottb@netwinder.org
Jan Beulich jbeulich@novell.com
Jim Blandy jimb@redhat.com
Philip Blundell philb@gnu.org
Per Bothner per@bothner.com
Joel Brobecker brobecker@gnat.com
Dave Brolley brolley@redhat.com
Paul Brook paul@codesourcery.com
Kevin Buettner kevinb@redhat.com
Andrew Cagney cagney@gnu.org
David Carlton carlton@bactrian.org
Stephane Carrez stcarrez@nerim.fr
Michael Chastain mec.gnu@mindspring.com
Eric Christopher echristo@apple.com
Randolph Chung tausq@debian.org
Nick Clifton nickc@redhat.com
Brendan Conoboy blc@redhat.com
DJ Delorie dj@redhat.com
Philippe De Muyter phdm@macqel.be
Dhananjay Deshpande dhananjayd@kpitcummins.com
Klee Dienes kdienes@apple.com
Richard Earnshaw rearnsha@arm.com
Steve Ellcey sje@cup.hp.com
Frank Ch. Eigler fche@redhat.com
Ben Elliston bje@gnu.org
Adam Fedor fedor@gnu.org
Fred Fish fnf@ninemoons.com
Brian Ford ford@vss.fsi.com
Orjan Friberg orjanf@axis.com
Paul Gilliam pgilliam@us.ibm.com
Raoul Gough RaoulGough@yahoo.co.uk
Anthony Green green@redhat.com
Matthew Green mrg@eterna.com.au
Jerome Guitton guitton@act-europe.fr
Ben Harris bjh21@netbsd.org
Richard Henderson rth@redhat.com
Aldy Hernandez aldyh@redhat.com
Paul Hilfinger hilfinger@gnat.com
Matt Hiller hiller@redhat.com
Kazu Hirata kazu@cs.umass.edu
Jeff Holcomb jeffh@redhat.com
Don Howard dhoward@redhat.com
Martin Hunt hunt@redhat.com
Jim Ingham jingham@apple.com
Baurzhan Ismagulov ibr@radix50.net
Manoj Iyer manjo@austin.ibm.com
Daniel Jacobowitz dan@debian.org
Andreas Jaeger aj@suse.de
Jeff Johnston jjohnstn@redhat.com
Geoff Keating geoffk@redhat.com
Mark Kettenis kettenis@gnu.org
Jim Kingdon jkingdon@engr.sgi.com ++
Jonathan Larmour jlarmour@redhat.co.uk
Jeff Law law@redhat.com
David Lecomber david@streamline-computing.com
Robert Lipe rjl@sco.com
H.J. Lu hjl@lucon.org
Michal Ludvig mludvig@suse.cz
Glen McCready gkm@redhat.com
Greg McGary greg@mcgary.org
Roland McGrath roland@redhat.com
Bryce McKinlay mckinlay@redhat.com
Jason Merrill jason@redhat.com
David S. Miller davem@redhat.com
Mark Mitchell mark@codesourcery.com
Marko Mlinar markom@opencores.org
Alan Modra amodra@bigpond.net.au
Jason Molenda jmolenda@apple.com
Pierre Muller muller@sources.redhat.com
Joseph Myers joseph@codesourcery.com
Fernando Nasser fnasser@redhat.com
Nathanael Nerode neroden@gcc.gnu.org
Hans-Peter Nilsson hp@bitrange.com
David O'Brien obrien@freebsd.org
Alexandre Oliva aoliva@redhat.com
Ramana Radhakrishnan ramana.radhakrishnan@codito.com
Frederic Riss frederic.riss@st.com
Tom Rix trix@redhat.com
Nick Roberts nickrob@snap.net.nz
Bob Rossi bob_rossi@cox.net
Theodore A. Roth troth@openavr.org
Ian Roxborough irox@redhat.com
Grace Sainsbury graces@redhat.com
Kei Sakamoto sakamoto.kei@renesas.com
Mark Salter msalter@redhat.com
Richard Sandiford richard@codesourcery.com
Peter Schauer Peter.Schauer@regent
Andreas Schwab schwab@suse.de
Keith Seitz keiths@redhat.com
Stan Shebs shebs@apple.com
Aidan Skinner aidan@velvet.net
Jiri Smid smid@suse.cz
David Smith dsmith@redhat.com
Stephen P. Smith ischis2@cox.net
Jackie Smith Cashion jsmith@redhat.com
Michael Snyder msnyder@redhat.com
Petr Sorfa petrs@caldera.com
Andrew Stubbs andrew.stubbs@st.com
Ian Lance Taylor ian@airs.com
Gary Thomas gthomas@redhat.com
Jason Thorpe thorpej@netbsd.org
Tom Tromey tromey@redhat.com
David Ung davidu@mips.com
D Venkatasubramanian dvenkat@noida.hcltech.com
Corinna Vinschen vinschen@redhat.com
Keith Walker keith.walker@arm.com
Kris Warkentin kewarken@qnx.com
Ulrich Weigand uweigand@de.ibm.com
Nathan Williams nathanw@wasabisystems.com
Jim Wilson wilson@specifixinc.com
Elena Zannoni ezannoni@redhat.com
Eli Zaretskii eliz@gnu.org
Wu Zhou woodzltc@cn.ibm.com
Yoshinori Sato ysato@users.sourceforge.jp
Past Maintainers
Jimmy Guo (gdb.hp, tui) guo at cup dot hp dot com
Jeff Law (hppa) law at cygnus dot com
Daniel Berlin (C++ support) dan at cgsoftware dot com
Nick Duffek (powerpc, SCO, Sol/x86) nick at duffek dot com
David Taylor (d10v, sparc, utils, defs,
expression evaluator, language support) taylor at candd dot org
J.T. Conklin (dcache, NetBSD, remote) jtc at redback dot com
Frank Ch. Eigler (sim) fche at redhat dot com
Per Bothner (Java) per at bothner dot com
Anthony Green (Java) green at redhat dot com
Fernando Nasser (testsuite/, mi, cli) fnasser at redhat dot com
Mark Salter (testsuite/lib+config) msalter at redhat dot com
Folks that have been caught up in a paper trail:
Chris Faylor cgf@alum.bu.edu
Jim Kingdon jkingdon@engr.sgi.com
David Carlton carlton@bactrian.org
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maintainer policy for GDB - take N
2006-01-17 22:09 ` Daniel Jacobowitz
@ 2006-01-17 23:28 ` Mark Kettenis
2006-01-18 11:17 ` Christopher Faylor
1 sibling, 0 replies; 8+ messages in thread
From: Mark Kettenis @ 2006-01-17 23:28 UTC (permalink / raw)
To: drow; +Cc: gdb
> Date: Tue, 17 Jan 2006 16:28:33 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> On Fri, Jan 06, 2006 at 02:40:07PM -0500, Daniel Jacobowitz wrote:
> > Replacement text for MAINTAINERS:
>
> There was some dissatisfaction with my Overview :-) Is this any
> better? The only changes from the last posting are in the Overview,
> above the section heading for the Obvious Fix Rule, but it doesn't lend
> itself to diff well.
I like it; I think it's much clearer.
Thanks for doing this,
Mark
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Maintainer policy for GDB - take N
2006-01-17 22:09 ` Daniel Jacobowitz
2006-01-17 23:28 ` Mark Kettenis
@ 2006-01-18 11:17 ` Christopher Faylor
1 sibling, 0 replies; 8+ messages in thread
From: Christopher Faylor @ 2006-01-18 11:17 UTC (permalink / raw)
To: gdb
On Tue, Jan 17, 2006 at 04:28:33PM -0500, Daniel Jacobowitz wrote:
>Chris Faylor cgf@alum.bu.edu
Other than this part (which is my fault for not checking in the change
that's been sitting in my sandbox for eons), it looks good to me.
cgf
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-01-17 23:28 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-06 19:40 Maintainer policy for GDB - take N Daniel Jacobowitz
2006-01-06 23:15 ` Eli Zaretskii
2006-01-08 17:52 ` Mark Kettenis
2006-01-09 5:53 ` Jim Blandy
2006-01-09 18:00 ` Christopher Faylor
2006-01-17 22:09 ` Daniel Jacobowitz
2006-01-17 23:28 ` Mark Kettenis
2006-01-18 11:17 ` Christopher Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).