Re: [Gdbheads] proposed change to GDB maintainership rules

[Andrew Cagney]

> Andrew Cagney <address@hidden> writes:
>
>
> > Significantly, this dynamic is often absent in open groups.  Typically
> > an "area maintainer" title serves no real purpose other than to provide
> > a fast-path for that individual's (or their employeers) changes.  The
> > mutual obligation of ensuring that patches are resolved, and
> > development continues a pace being absent.  That responsibility instead
> > falls to the groups core developers.
>
>
> ...
>
>
> > Since Cygnus was dominating development, and had most of the GDB
> > developers on their payroll (at that time it including me), and to
> > this day "Cygnus" still has the largest single block of devlopers, it
> > had to be clear that no core developer, nor I as overall lead
> > developer could override an area lead's decision (if we disagreed we
> > had to present a pervasive technical argument).
>
>
> Andrew, I'm having a hard time working out precisely what you are
> saying, so, just to be crystal clear: do you object to that part of
> the proposed change in the e-mail from Kevin Buettner, to wit, that
> any global maintainer may approve any patch, even to an area which has
> an area maintainer?

I'm trying to compare the two systems, and note the benefits offered by 
the current GDB.

At present I, along with the other core maintainers, clearly defer to 
specific maintainer when it comes to a technical decision (or patch 
approval) in that area.  There is certainly latitude in this - the more 
experienced you are the more broad the "obvious" definition becomes. 
The benefit here is that it provides greater level of even handedness 
which is very important in areas where GDB interfaces to the user - 
(eli always keeps us honest) CLI (Fernando is dadly missed), and even 
less obvious user interfaces such as the remote protocol.

In GCC, on the other hand, global developers are able to directly, and 
immedatly approve patches - without any need to defer or refer to the 
relevant maintainer.  I suspect, however, that there is something of an 
unwritten convention?

Also as I mentioned, in the case of the TUI, core maintainers, do still 
have blanket write (but it is mentioned explicitly) -  hmm, I'm 
attatching the bulk of the maintainers file, my original quote could be 
read as out-of-context - you can even think of this as making GDB a 
superset of GCC.

Either way, the thing to study, is what happens when things go wrong.

In GCC, people complain, and the global maintainers step in.

In GDB, people complain, and unfortunatly, there's no short term relief 
valve - [typically] I pester the area developer and often I'll end up 
helping out short term (fine with me).  A more automatic mechanism might 
be of benefit here.

Andrew

                        GDB Maintainers


                        Global Maintainers
                           (alphabetic)

Jim Blandy                      jimb@
Kevin Buettner                  kevinb@
Andrew Cagney                   ac131313@
J.T. Conklin                    jtc@
Fred Fish                       fnf@
Daniel Jacobowitz               dan@
Mark Kettenis                   kettenis@
Peter Schauer                   Peter.Schauer@
Stan Shebs                      shebs@
Michael Snyder                  msnyder@
Elena Zannoni                   ezannoni@
Eli Zaretskii                   eliz@


                        Various Maintainers

Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.

If there is no maintainer for a given domain then the responsibility
falls to a global maintainer.

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.


                        The Obvious Fix Rule

All maintainers listed in this file 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.


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.

        a29k            Deleted.

        alpha           --target=alpha-elf ,-Werror
                        Maintenance only

        arc             Deleted.

        arm             --target=arm-elf ,-Werror
                        Scott Bambrough         scottb@
                        Richard Earnshaw        rearnsha@

        avr             --target=avr ,-Werror
                        Theodore A. Roth        troth@

        cris            --target=cris-elf ,-Werror
                        Orjan Friberg           orjanf@

        d10v            --target=d10v-elf ,-Werror
                        Maintenance only

        d30v            Deleted.

        fr30            Deleted.

        frv             --target=frv-elf ,-Werror
                        Maintenance only

        h8300           --target=h8300hms ,-Werror
                        Maintenance only

        h8500           Deleted.

        i386            --target=i386-elf ,-Werror
                        Mark Kettenis           kettenis@

        i960            Deleted.

        ia64            --target=ia64-linux-gnu ,-Werror
                        (--target=ia64-elf broken)
                        Kevin Buettner          kevinb@

        m32r            --target=m32r-elf ,-Werror

        m68hc11         --target=m68hc11-elf ,-Werror ,
                        Stephane Carrez         stcarrez@

        m68k            --target=m68k-elf ,-Werror
                        Maintenance only

        m88k            Deleted.

        mcore           --target=mcore-elf ,-Werror
                        Maintenance only

        mips            --target=mips-elf ,-Werror
                        Andrew Cagney           cagney@

        mn10200         Deleted.

        mn10300         --target=mn10300-elf ,-Werror
                        Maintenance only

        ns32k           --target=ns32k-netbsd ,-Werror
                        Maintenance only

        pa              (--target=hppa-elf broken)
                        Maintenance only

        powerpc         --target=powerpc-eabi ,-Werror
                        Kevin Buettner          kevinb@

        s390            --target=s390-linux-gnu ,-Werror
                        (contact DJ Barrow      djbarrow@

        sh              --target=sh-elf ,-Werror
                        Elena Zannoni           ezannoni@

        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
                        Corinna Vinschen        vinschen@

        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.


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@
                        Kevin Buettner          kevinb@

djgpp native            Eli Zaretskii           eliz@
                        DJ Delorie              dj@
MS Windows (NT, '00, 9x, Me, XP) host & native
                        Chris Faylor            cgf@
GNU/Linux/x86 native & host
                        Mark Kettenis           kettenis@
GNU/Linux PPC native    Kevin Buettner          kevinb@
GNU/Linux MIPS native & host
                        Daniel Jacobowitz       dan@
GNU/Linux m68k          Andreas Schwab          schwab@
FreeBSD native & host   Mark Kettenis           kettenis@
                        David O'Brien           obrien@
hurd native             Mark Kettenis           kettenis@
NetBSD native & host    Jason Thorpe            thorpej@
SCO/Unixware            Robert Lipe             rjl@
GNU/Linux ARM native    Scott Bambrough         scottb@
Solaris/x86 native & host (devolved)
                        Peter Schauer           Peter.Schauer@
Solaris/SPARC native & host (devolved)
                        (Global Maintainers)



Core: Generic components used by all of GDB

generic arch support    Andrew Cagney           cagney@
                        Any host/target maintainer can add to
                        gdbarch.{c,h,sh}.  Send tricky ones to cagney.
target vector           Andrew Cagney           cagney@

event loop              Elena Zannoni           ezannoni@
                        For the part of top.c related to the event loop,
                        send questions to ezannoni@

generic symtabs         Jim Blandy              jimb@
                        Elena Zannoni           ezannoni@
  dwarf readers         Jim Blandy              jimb@
                        Elena Zannoni           ezannoni@
  elf reader            Jim Blandy              jimb@
                        Elena Zannoni           ezannoni@
  stabs reader          Jim Blandy              jimb@
                        Elena Zannoni           ezannoni@
  coff reader           Philippe De Muyter      phdm@
  xcoff reader          Any maintainer can modify this; please send tricky
                        ones to Kevin Buettner <kevinb@
  linespec              Elena Zannoni           ezannoni@
  HP/UX readers         Any [past] maintainer can modify this.
                        Please send tricky ones to the symtabs maintainers.

tracing bytecode stuff  Jim Blandy              jimb@
tracing                 Michael Snyder          msnyder@
threads                 Michael Snyder          msnyder@
                        Mark Kettenis           kettenis@
breakpoints             (Global Maintainers)
language support        (Blanket Write Privs Maintainers)
  C++                   Daniel Jacobowitz       dan@
  Java support          (Global Maintainers)
  Pascal support        Pierre Muller           muller@
  Objective C support   Adam Fedor              fedor@
shared libs (devolved)  Kevin Buettner          kevinb@
  xcoffsolib            Peter Schauer           Peter.Schauer@

remote.c                Andrew Cagney           cagney@
include/remote-sim.h, remote-sim.c
                        Andrew Cagney           cagney@
sds protocol            (vacant)
rdi/adp protocol        (vacant)
documentation           Eli Zaretskii           eliz@
testsuite               (Global Maintainers)
  config                Mark Salter             msalter@
  lib                   Fernando Nasser         fnasser@
                        Mark Salter             msalter@
  gdbtk (gdb.gdbtk)     Keith Seitz             keiths@
  c++ (gdb.cp)          Michael Chastain        mec.gnu@
                        David Carlton           carlton@
  mi tests (gdb.mi)     Elena Zannoni           ezannoni@
                        Andrew Cagney           cagney@
  stabs (gdb.stabs)     Elena Zannoni           ezannoni@
  threads (gdb.threads) Michael Snyder          msnyder@
  trace (gdb.trace)     Michael Snyder          msnyder@
  hp tests (gdb.hp)     (vacant)
  Java tests (gdb.java) Anthony Green           green@
Kernel Object Display   Fernando Nasser         fnasser@


UI: External (user) interfaces.

command interpreter     (Global Maintainers)
gdbtk (c & tcl)         Jim Ingham              jingham@
                        Fernando Nasser         fnasser@
                        Keith Seitz             keiths@
libgui (w/foundry, sn)  Jim Ingham              jingham@
                        Keith Seitz             keiths@
mi (gdb/mi)             Andrew Cagney           cagney@
                        Elena Zannoni           ezannoni@
                        Fernando Nasser         fnasser@
tui                     Stephane Carrez         stcarrez@
                        (Global Maintainers)


Misc:

gdb/gdbserver           Daniel Jacobowitz       dan@

Web pages.              Jim Kingdon             jkingdon@
                        (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@
                        Host maintainers (host dependant parts)
                        (but get your changes into the master version)

tcl/ tk/ itcl/          Ian Roxborough          irox@

                        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.

[...]


                        Past Maintainers

[...]



Folks that have been caught up in a paper trail:

[...]

--

(*) Indicates folks that don't have a Kerberos/SSH account in the GDB
group.