From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7946 invoked by alias); 19 Feb 2003 23:53:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7933 invoked from network); 19 Feb 2003 23:53:43 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 19 Feb 2003 23:53:43 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1JNrhK09664 for ; Wed, 19 Feb 2003 18:53:43 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1JNrha10114; Wed, 19 Feb 2003 18:53:43 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1JNrfO28586; Wed, 19 Feb 2003 18:53:41 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id EBAAEFF79; Wed, 19 Feb 2003 18:57:47 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15956.6651.618272.345014@localhost.redhat.com> Date: Wed, 19 Feb 2003 23:53:00 -0000 To: Jim Blandy Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process In-Reply-To: References: <20030217180709.GA19866@nevyn.them.org> <3E53B2E0.2070801@redhat.com> X-SW-Source: 2003-02/txt/msg00387.txt.bz2 Jim Blandy writes: > Andrew Cagney writes: > > > > - It's true that "... some maintainers should try to review patches in > > > their areas of responsibility more often", but merely saying so > > > doesn't have any effect. > > > > For the record your name is top of the list of that `some maintainers'. > > > I think the explicit hierarchy we have now, outlined in MAINTAINERS, > is a real problem in this sense. It's a big, public, political deal > to rearrange that hierarchy. There are other systems where the > processes of promoting promising contributors and clearing dead wood > happen smoothly and automatically, without confrontation. People > contribute as they are able, and leaders emerge and recede in a > natural way, not by fiat. The Apache system, for example, encourages > newcomers to acquire expertise in different areas, and allows less > responsive people to simply fall to the wayside as irrelevant. > > These systems are in widespread use, and I think some are even > well-documented, like: http://httpd.apache.org/dev/guidelines.html "Membership as a Committer is by invitation only and must be approved by consensus of the active Apache PMC members. A Committer is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members (except the member in question if they are a PMC member)." How is being a member of the 'Committers' by "invitation only" not going to be another political deal? How is the 6 months inactivity period going to help? None of the current gdb maintainers perticipating in this discussion has ever disappeared for that long, really. If some person has disappeared from radar, like relocated, changed e-mail, etc, the person has been removed from the list. I can think of one such case. I don't like this one: "Ideas must be review-then-commit; patches can be commit-then-review. With a commit-then-review process, we trust that the developer doing the commit has a high degree of confidence in the change."