- GDB Maintainers
+ GDB Maintainers
+ ===============
- Global Maintainers
- (alphabetic)
+ 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.
- Various Maintainers
+ - The Authorized Committers.
-Note individuals who maintain parts of the debugger need approval to
-check in changes outside of the immediate domain that they maintain.
+ These are developers who are trusted to make changes within a specific
+ area of GDB without additional oversight.
-If there is no maintainer for a given domain then the responsibility
-falls to a global maintainer.
+ - The Write After Approval Maintainers.
-If there are several maintainers for a given domain then
-responsibility falls to the first maintainer. The first maintainer is
-free to devolve that responsibility among the other 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 Obvious Fix Rule
+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!
-All maintainers listed in this file are allowed to check in obvious
-fixes.
+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.
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 (CodeSourcery)
+ 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):
+
+
+
+ Release Manager
+ ---------------
+
+
+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):
+
+
+
+
+ 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:
-Generic ISA (Instruction Set Architecture) issues, API variants, CPU
-variants. *-tdep.c. The Target/Architecture maintainer works with the
-host maintainer when resolving build issues. The Target/Architecture
-maintainer works with the native maintainer when resolving API issues.
+The *-tdep.c files. ISA (Instruction Set Architecture) and OS-ABI
+(Operating System / Application Binary Interface) issues including CPU
+variants.
- a29k Deleted.
+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
- Maintenance only
-
- arc Deleted.
arm --target=arm-elf ,-Werror
avr --target=avr ,-Werror
cris --target=cris-elf ,-Werror
- d10v --target=d10v-elf ,-Werror
- Maintenance only
-
- d30v Deleted.
-
- fr30 Deleted.
+ d10v OBSOLETE
frv --target=frv-elf ,-Werror
- Maintenance only
-
- h8300 --target=h8300hms ,-Werror
- Maintenance only
- h8500 Deleted.
+ h8300 --target=h8300-elf ,-Werror
i386 --target=i386-elf ,-Werror
- i960 Deleted.
-
ia64 --target=ia64-linux-gnu ,-Werror
(--target=ia64-elf broken)
+
+ m32c --target=m32c-elf ,-Werror
m32r --target=m32r-elf ,-Werror
m68k --target=m68k-elf ,-Werror
- Maintenance only
- m88k Deleted.
+ m88k --target=m88k-openbsd ,-Werror
- mcore --target=mcore-elf ,-Werror
- Maintenance only
+ mcore Deleted
mips --target=mips-elf ,-Werror
- mn10200 Deleted.
+ mn10300 --target=mn10300-elf broken
+ (sim/ dies with make -j)
- mn10300 --target=mn10300-elf ,-Werror
- Maintenance only
+ ms1 --target=ms1-elf ,-Werror
- ns32k --target=ns32k-netbsd ,-Werror
- Maintenance only
+ ns32k Deleted
- pa (--target=hppa-elf broken)
- Maintenance only
+ 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
- Maintenance only
-
- tic80 Deleted.
v850 --target=v850-elf ,-Werror
- Maintenance only
vax --target=vax-netbsd ,-Werror
- Maintenance only
-
- w65 Deleted.
x86-64 --target=x86_64-linux-gnu ,-Werror
- Maintenance only
- xstormy16 --target=xstormy16-elf ,-Werror
+ xstormy16 --target=xstormy16-elf
- z8k Deleted.
-
All developers recognized by this file can make arbitrary changes to
OBSOLETE targets.
-All maintainers can test and thence approve non-trivial changes to
-``maintenance only'' targets submitted by recognized developers.
-
-All recognized developers can make mechanical changes (by virtue of
-the obvious fix rule) to ``maintenance only'' targets. The change
-shall be sanity checked by compiling with one of the listed targets.
-
The Bourne shell script gdb_mbuild.sh can be used to rebuild all the
above targets.
The host maintainer ensures that gdb can be built as a cross debugger on
their platform.
MS Windows (NT, '00, 9x, Me, XP) host & native
- Chris Faylor cgf@redhat.com
+ Chris Faylor cgf@alum.bu.edu
GNU/Linux/x86 native & host
GNU/Linux MIPS native & host
-Solaris/x86 native & host (devolved)
-Solaris/SPARC native & host (devolved)
- (Global Maintainers)
Core: Generic components used by all of GDB
- Any host/target maintainer can add to
- gdbarch.{c,h,sh}. Send tricky ones to cagney.
-
- For the part of top.c related to the event loop,
-
- xcoff reader Any maintainer can modify this; please send tricky
- HP/UX readers Any [past] maintainer can modify this.
- Please send tricky ones to the symtabs maintainers.
-
-breakpoints (Global Maintainers)
-language support (Blanket Write Privs Maintainers)
+language support
- Java support (Global Maintainers)
-
-include/remote-sim.h, remote-sim.c
-sds protocol (vacant)
-rdi/adp protocol (vacant)
+
-testsuite (Global Maintainers)
+ (including NEWS)
+testsuite
- hp tests (gdb.hp) (vacant)
UI: External (user) interfaces.
-command interpreter (Global Maintainers)
- (Global Maintainers)
Misc:
- (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/
+ ALL
Host maintainers (host dependant parts)
(but get your changes into the master version)
+tcl/ tk/ itcl/ ALL
+
+
+ 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!
+
+ [Please use this address to contact DJ about DJGPP]
+
Write After Approval
(alphabetic)
FSF assignment and have submitted one good patch.
-Joel Brobecker brobecker@act-europe.fr
+Joel Brobecker brobecker@adacore.com
-David Carlton carlton@kealia.com
+David Carlton carlton@bactrian.org
-Nick Roberts nick@nick.uklinux.net
-Richard Sandiford rsandifo@redhat.com
-Peter Schauer Peter.Schauer@regent
+Richard Sandiford richard@codesourcery.com
+Peter Schauer Peter.Schauer@mytum.de
-Jason Thorpe thorpej@wasabisystems.com
+Jason Thorpe thorpej@netbsd.org
-
Past Maintainers
+Whenever removing yourself, or someone else, from this file, consider
+listing their areas of development here for posterity.
+
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
+J.T. Conklin (dcache, NetBSD, remote, global) jtc at acorntoolworks 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, KOD) fnasser at redhat dot com
+Mark Salter (testsuite/lib+config) msalter at redhat dot com
+Jim Kingdon (web pages) kingdon at panix dot com
+Jim Ingham (gdbtk, libgui) jingham at apple dot com
+Mark Kettenis (hurd native) kettenis at gnu dot org
+Ian Roxborough (in-tree tcl, tk, itcl) irox at redhat dot com
+Robert Lipe (SCO/Unixware) rjl at sco dot com
+Peter Schauer (global, AIX, xcoffsolib,
+ Solaris/x86) Peter.Schauer at mytum dot de
+Scott Bambrough (ARM) scottb at netwinder dot org
+Philippe De Muyter (coff) phdm at macqel dot be
+Michael Chastain (testsuite) mec.gnu at mindspring dot com
Folks that have been caught up in a paper trail:
-
---
-
-(*) Indicates folks that don't have a Kerberos/SSH account in the GDB
-group.
projects / binutils.git / blobdiff