From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32305 invoked by alias); 17 Nov 2005 04:48:10 -0000 Received: (qmail 32294 invoked by uid 22791); 17 Nov 2005 04:48:07 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 04:48:07 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Ecbgn-0001F4-8U; Wed, 16 Nov 2005 23:48:01 -0500 Date: Thu, 17 Nov 2005 04:48:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Cc: Jim Blandy , Kevin Buettner , Andrew Cagney , "J.T. Conklin" , Fred Fish , Mark Kettenis , Peter Schauer , Stan Shebs , Michael Snyder , Eli Zaretskii , Elena Zannoni Subject: Maintainer policy for GDB Message-ID: <20051117044801.GA4705@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org, Jim Blandy , Kevin Buettner , Andrew Cagney , "J.T. Conklin" , Fred Fish , Mark Kettenis , Peter Schauer , Stan Shebs , Michael Snyder , Eli Zaretskii , Elena Zannoni Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i 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: 2005-11/txt/msg00339.txt.bz2 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