Re: Maintainer policy for GDB

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Wed, 16 Nov 2005 23:48:01 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> So, first some proposed text, and then some additional rationale.  Please,
> let the list know your opinions.

Here we go:

> 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).

I like this formulation.

> 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.)

I think gdbint.texi should document what is implemented, and not what
will be implemented.  A Wiki seems to be a more appropriate place for
roadmap items.  They can be moved to gdbint.texi when they've been
implemented.

> 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.

Interesting idea.  

> 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.

Is everybody currently on the "Write After Approval" list considered
to be a Maintainer?  If so, I don't hope adding someone to that list
will require explicit permision from the SC.

> 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.

Fair enough.

> 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.

That's probably a good idea.  Right now we have quite a number of
vacua, i.e. areas where it is not clear who to pester.  In some cases
that's because no one is listed, in others someone is listed who
hasn't show any recent activity.

> 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.

Do we consider it a as a goal to have someone listed for every "area"
(file?) in gdb?

Mark