From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22210 invoked by alias); 8 Jan 2006 17:52:45 -0000 Received: (qmail 22164 invoked by uid 22791); 8 Jan 2006 17:52:44 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 08 Jan 2006 17:52:41 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k08Hq6kA014087; Sun, 8 Jan 2006 18:52:06 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k08Hq5gE017306; Sun, 8 Jan 2006 18:52:05 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k08Hq51D010282; Sun, 8 Jan 2006 18:52:05 +0100 (CET) Date: Sun, 08 Jan 2006 17:52:00 -0000 Message-Id: <200601081752.k08Hq51D010282@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb@sourceware.org In-reply-to: <20060106194007.GA9104@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 6 Jan 2006 14:40:07 -0500) Subject: Re: Maintainer policy for GDB - take N References: <20060106194007.GA9104@nevyn.them.org> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00062.txt.bz2 > Date: Fri, 6 Jan 2006 14:40:07 -0500 > From: Daniel Jacobowitz > > 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