From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22354 invoked by alias); 17 Nov 2005 23:52:27 -0000 Received: (qmail 22311 invoked by uid 22791); 17 Nov 2005 23:52:23 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 23:52:23 +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 jAHNqKnC026114; Fri, 18 Nov 2005 00:52:20 +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 jAHNqJke020909; Fri, 18 Nov 2005 00:52:20 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jAHNqJCj022112; Fri, 18 Nov 2005 00:52:19 +0100 (CET) Date: Thu, 17 Nov 2005 23:52:00 -0000 Message-Id: <200511172352.jAHNqJCj022112@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb@sourceware.org, jimb@redhat.com, kevinb@redhat.com, cagney@gnu.org, jtc@acorntoolworks.com, fnf@ninemoons.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, shebs@apple.com, msnyder@redhat.com, eliz@gnu.org, ezannoni@redhat.com In-reply-to: <20051117044801.GA4705@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 16 Nov 2005 23:48:01 -0500) Subject: Re: Maintainer policy for GDB References: <20051117044801.GA4705@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: 2005-11/txt/msg00363.txt.bz2 > Date: Wed, 16 Nov 2005 23:48:01 -0500 > From: Daniel Jacobowitz > > 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