Re: [Gdbheads] proposed change to GDB maintainership rules

[Andrew Cagney]

[oops, got to line wrong on first attempt]
 > 1) Do we believe that the current lists of local maintainers represent
 >    the only people whose judgment we trust on those pieces of code?
 >    For example, do we believe that nobody other than Jim Blandy and
 >    Elena Zannoni can be trusted to work on symbol table code?  Do we
 >    believe that nobody other than Michael Chastain and myself can be
 >    trusted with the C++ testsuite?  Do we believe that nobody other
 >    than Michael Snyder and Mark Kettenis can be trusted with GDB's
 >    threads code?

BTW, Michael Synder and Mark Kettenis both indicated that they are no
longer comfortable with being thread maintainers.  see the mysteriously 
dangling October 2003 thread:
http://sources.redhat.com/ml/gdb-patches/2003-10/msg00226.html

Anyway,

We all first need to appreciate the current process.  The maintainers
file reads:

"If there are several maintainers for a given domain then responsibility
falls to the first maintainer.   The first maintainer is free to
devlolve that responsibility among the other maintainers."

We're saying that the lead developer developer for a specific
domain has overall _responsibility_ for that domain:

- responsible for the resolution of that area's patches and changes

- responsible for maintaining and updating that area's code and updated

- responsible for making technical decisions
Which we in turn respect.

With this in mind, the area lead:

- if they need help they ask
Fernando was always doing this.

- if they feel a developer should be a more direct participant, they can
nominate them
Fernand and Scott both nominated RichardE (and even on the same day!)

- If they feel that core maintainers should continue be involved that 
gets stated
As Stephane has done for the tui.

Significantly, our "trust" isn't only and solely about patch review, it 
is about something far greater, we've entrusted responsability for that 
area in that developer.

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.

How did this come to be?

It occured in 2000.  After constant complaints that GDB was a closed 
project run solely by Cygnus, the project opend up: the lead developer
changed' the repository became public; the patch review process was made
public; the criteria for being a committer became public (it was no
longer "employee of cygnus"); the expecations for a patch approval were 
made more transparent;  with significant personal effor, technical 
debate was forced into the open.

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