Re: Maintainer policy for GDB - take N

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Fri, 6 Jan 2006 14:40:07 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> Hi folks,
> 
> Below I have a complete copy of the MAINTAINERS file, adjusted for all
> the changes I've proposed and for all the feedback I received when I
> posted them in November.  Sorry about the delay; the end of the year
> was unexpectedly hectic.
> 
> I'm going to be traveling much of next week.  I'll have access to
> email, but limited time to respond, so I may be out of touch from
> Sunday to Friday.  I'm eager to hear any feedback on this revision,
> especially from Eli, Chris, and Mark.

In general, this seems to be something I certainly can live with ;-).

> Some next steps after discussion of this, assuming we finalize on
> something similar:
>   - Ping maintainers about continued interest in / availability for their
>     listed positions.
>   - Potentially redo the set of areas covered under Responsible Maintainers
>     (in broader chunks instead of fine-grained, maybe move the fine-grained
>     ones down to Authorized Committers).
> 
> Replacement text for MAINTAINERS:
> 
> 
> 		GDB Maintainers
> 		===============
> 
> 
> 		   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.
> 
> The groups are:
> 
>   - 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, but they are not involved in day-to-day
>     development.

Ah Daniel, sad to hear that you're no longer doing any day-to-day
development ;-).  Perhaps you stick in a "in general" somewhere in the
last sentence..

>   - 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 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.
> 
>   - 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.
> 
>   - The Authorized Committers.
> 
>     These are developers who are trusted to make changes within a specific
>     area of GDB without additional oversight.
> 
>   - The Write After Approval 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).

I really think these definitions are silly; there are more categories
here than we have active developers it seems.  But if this is what's
needed to reach consensus, well, I don't really care that much.

Mark