From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1988 invoked by alias); 26 Feb 2003 17:01:34 -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 1975 invoked from network); 26 Feb 2003 17:01:33 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 26 Feb 2003 17:01:33 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7A4B52A9C; Wed, 26 Feb 2003 12:03:49 -0500 (EST) Message-ID: <3E5CF375.4050009@redhat.com> Date: Wed, 26 Feb 2003 17:01: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: David Carlton Cc: gdb Subject: Re: [maint] GDB needs more local maintainers References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00568.txt.bz2 David, I wish it were this simple. At one point, in the deep dark past the `solution' adopted was to `throw more maintainers at the problem'. If you think this is starting to sound like `throwing more programmers at the problem' then it is :-( One thing that has changed since then is for for developers to recognize that that while they might have a short (weeks) to medium (months) term interest in a specific aspect of GDB, they don't have the level of commitment needed to maintain that body of code. This is why the maintainers file contains things like: send tricky ones to person XXX; or person XXX can make changes. While XXX can take certain liberties it is clear that `the buck' doesn't stop with them. A more senior maintainer is free to approve/make changes. I would be wasting my time if I try to chase after them with a patch. This is also why I try to encourage developers (remember I also act in that role) to discuss / negotiate technical issues up front. That way they can be largly pre-approved. Such `fairly obvious' change can (especially when the issues have been trialed on a branch, but with the help of a global maintainer and 100% public) then be committed using a 24-48hr rolling schedule (but with with definite timeouts so that everyone has a chance to clean up the fallout - cf the interps patch). Finally, this is also why it is important for maintainers to recognize that it is some times time to let go and move on. Perhaphs dropping certain areas of responsibility (and picking others up). (On this last point, it is good to see that all the maintainers are currently doing this.) Andrew