From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17233 invoked by alias); 24 Feb 2003 07:18:07 -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 17226 invoked from network); 24 Feb 2003 07:18:06 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.209.173) by 172.16.49.205 with SMTP; 24 Feb 2003 07:18:06 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 53097294F; Mon, 24 Feb 2003 02:20:22 -0500 (EST) Message-ID: <3E59C7B6.1000308@redhat.com> Date: Mon, 24 Feb 2003 07:18:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <20030217180709.GA19866@nevyn.them.org> <86isvao9yk.fsf@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00508.txt.bz2 > I mostly agree with Daniel here. We have too many single points of > failure. I still have testsuite patches sitting in my tree, dating > months back since they were never approved. Similarly, Daniel > probably has been held back more than once since I wasn't able to > review threads-related patches in a timely fashion. I think we should > allow our global maintainers to approve patches even for parts of GDB > where we have a specific maintainer, if they feel they have the > necessary expertise. Depends on what `single point failure' means. If you look through the MAINTAINERS file you'll notice that all but one of the problem areas is double, if not triple maintained. Even with all that dedundency, patches in certain areas continues to stall. While there might be three maintainers, the reality is only one or none are reliable. The first, and most obvious thing is for the global maintainers to review their current number of responsibilities and compare that against their actual level of commmitment. I'm down to just target/arch, remote, mips and sim/ppc. The second, is for maintainers to always be on the lookout for potential new maintainers (global or not) and, where possible, step aside to let new commers in. Finally, the GDB `tradition' (that appears to have been forgotten) is to up front reach consensus on stuff so that the final patches are trivial to review. cf, the block.[hc] change. enjoy, Andrew