Maintainer policy for GDB

[Daniel Jacobowitz <drow at false dot org>]

We've discussed various times in the past several years whether we needed
to change the maintainer policies for GDB.  It's been a little while since
the last time, and a couple things have changed - the set of active
developers is a bit different, and the steering committee is properly in
place now in case of dispute.  Let's try again, please.

I have put together one possible alternative, drawing heavily on comments
from Ian, Jim, and Andrew on the steering committee list last year. 
Obviously I like my own proposal or I wouldn't be sharing it :-) But I want
to know what everyone else involved thinks!

One of my goals with this proposal is to acknowledge the current reality of
GDB development, which is that no one has very much time for it.  I want to
make it easier for those who do have time to make progress, and I want to
make it easier to draw on outside contributions.  In the long term, I hope
that this will let us all have more time for GDB, and give it a much-needed
boost.

So, first some proposed text, and then some additional rationale.  Please,
let the list know your opinions.

=========================

Working With Other Maintainers

All maintainers are encouraged to post major patches to gdb-patches for
comments, even if they have the authority to commit the patch without
review.  This especially includes patches which change internal interfaces
(e.g. global functions, data structures) or external interfaces (e.g. user,
remote, MI, et cetera).

Global Maintainers

The global maintainers may review and commit any change to GDB.  For major
changes, or changes to areas with other active developers, global
maintainers are encouraged to post patches for comment and review before
committing.

The global maintainers are responsible for reviewing patches to any area
for which no one else is listed as responsible.

In case of abuse, e.g. committing patches without approval or patches which
go against an agreed-upon and documented roadmap for GDB, global maintainers
have the authority to revert _any_ applied patch.  No one may reapply a
reverted patch without either persuading the reverter, or bringing the issue
to the GDB Steering Committee for discussion.

(NOTE: documentation links to roadmap items would be good here; we don't
have any today but we could at least create a placeholder in gdbint.texi for
them.  Alternatively, we could use a freeform Wiki for this; that seems to
work well for other projects...  END NOTE.)

  *LIST*


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.

  *LIST*


Changes to the List of Maintainers

Most changes (especially additions) to the list of recognized maintainers
are handled by consensus among the global maintainers.  Final authority
resides with the GDB Steering Committee.

Some maintainers are listed as responsible for patch review in particular
areas.  If a maintainer is not currently able or willing to review patches,
please contact the global maintainers or the steering committee, who will
resolve the situation and find a replacement or assistant if necessary.


Responsible Maintainers

These are active developers who have agreed to review patches to particular
areas of GDB, in which they have particular knowledge and experience.  The
areas are expected to be broad; multiple maintainers responsible for an area
may wish to informally subdivide the area further to improve review.

  *LIST*


Authorized Committers

These are developers working on particular areas of GDB, who are trusted to
commit their own (or others') patches in those areas without further review
(but see Working With Other Maintainers, above).

  *LIST*

=========================

Comments on the text:

Separating responsibility for patch review from authority for patch review
is a new concept for GDB; I believe the suggestion was Ian's.  The more time
I've spent working on this proposal the more I've come to like it.  I
envision the areas of responsibility as broad, but the areas of authority as
possibly more specialized.

The biggest advantage I see in the split is a very clear image of who to
pester about pending patches, which does not necessarily include every GDB
developer who wants to be able to work in that area.


I have always been in favor of the concept that global maintainers should be
able to approve patches anywhere, without having to wait for area
maintainers.  If we don't trust each other enough for that, then we need to
work on the trust and/or the list of maintainers.


Patch champion is definitely not a role suitable for one person.  Just trust
me on this one.  Two at minimum.  Who else can we get to do it?  I don't
know yet but we'll find somebody.  I've been doing essentially this for
months and I'm willing to continue as time permits.


I would like for every defined "area" of approval to be fairly well defined,
possibly a specific list of files.  I believe it's reasonable to include
most changes to users of an interface under the umbrella of approval which
covers the implementation of the interface, so files which include
maintained headers would be somewhat under the authority of the maintainers
involved.  This may need to be clarified.


The set of current maintainers, and their areas, should probably be
consolidated.  I have no idea yet how to go about doing this.  At a bare
minimum, inactive maintainers should be pinged and pruned, with appropriate
credits in the manual.  We have a lot of them right now!


This does not replace the entire explanatory text of the MAINTAINERS file of
course.  Bits like the Obvious Fix rule or the bits about Joel's role as RM
would remain.  I've just covered the section highlights.


-- 
Daniel Jacobowitz
CodeSourcery, LLC