From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2293 invoked by alias); 17 Feb 2003 18:07:13 -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 2284 invoked from network); 17 Feb 2003 18:07:12 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 17 Feb 2003 18:07:12 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18krYk-0001yS-00 for ; Mon, 17 Feb 2003 14:08:14 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18kpfZ-0005IZ-00 for ; Mon, 17 Feb 2003 13:07:09 -0500 Date: Mon, 17 Feb 2003 18:07:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: [maint] The GDB maintenance process Message-ID: <20030217180709.GA19866@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00277.txt.bz2 I get the feeling I'm already pretty unpopular for some of my opinions on how GDB maintenane should work. This isn't going to make it any better, but I feel it should be said. I believe that our current process has some problems. Let me try to explain. First, to make sure we're all on the same page... What does it mean to be a Global Maintainer, in practice? - A certain amount of autonomy in the areas of GDB that no one wants to take specific responsibility for. There's no specific maintainer for things like the frame support or the type/value systems. - A little more freedom in approving patches to other people's areas of GDB - not a lot, but it's definitely there. [In practice, this depends on: o How much risk you're willing to take of annoying people. o How likely other maintainers are to shout at you about it.] - Authority to approve patches covering general debugger issues. What does it mean to be a maintainer for a specific host/target/subsystem, in practice? - The authority to approve patches and apply your own patches to that area of the debugger. I'd like everyone to notice one thing missing from the above list. No one has the _responsibility_ for approving patches. This is a volunteer project, and anyone who's watched it in action for a little while will see that the volunteers are often busy and distracted. There's no one who can handle or should have to handle the responsibilities of patch approval. Another thing to think about: because of the layout of the above, there is frequently no one who has the _right_ to approve a patch. They require buy-in from a number of additional maintainers. In addition our volunteers are often too busy to find time to respond to patches. This impacts patches from other maintainers (frequently, but generally a small impact) and from outside contributors (happens less frequently, but larger impact - most of these never get approved at all, from what I've seen). Some other GNU projects have a similar setup and don't have this problem. GCC and binutils are my usual examples. How do they avoid it? They have a different definition of global maintainer. That's what ours used to be called - Blanket Write Privileges. The system works a little differently: - Maintainers for specific areas of the compiler can commit/approve patches to the areas they maintain without buy-in from a blanket maintainer. - Blanket maintainers can commit/approve patches anywhere without buy-in from a specific area maintainer. [I hope Richard will forgive me for using him as an example and for putting words in his mouth...] This doesn't replace common sense - you generally won't find Richard Henderson approving patches to the C++ frontend, because: - He knows he isn't familiar with it - He knows it has an active set of maintainers at all times Similarly, just because he can check in patches to any target backend, that doesn't mean he won't ask a target maintainer to look over it first. If someone objects to a patch in their area, he would generally not just check it in anyway. If they object to it after he checks it in, the two will discuss the problem like reasonable people and come to some agreement. Some noticeable differences between these two models: - In the GCC model, more people are able/likely to check in patches which break things. - But in the GCC model, more people are able/likely to check in patches to fix it afterwards. - Because more people have the privilege of approving a given patch, and fewer people's approvals are needed for any particular patch, patches (usually) get approved more quickly. - Development can happen more quickly, and does not get slowed to a standstill when (say) one of us is pulled off of community GDB work for an urgent customer project. This happens all the time - I've never seen all the GDB maintainers with time for GDB at the same time. Right now, we use stricter policies to prevent problems which cause breakage. I think these policies are stifling us. Loosening them (and maybe adding a formal patch reversion policy) would let more people fix problems more easily, as they arise, without slowing development. If there are people on our Global Maintainer list that we don't think should be trusted with the extra responsibility of the above, then perhaps we need to rethink who belongs in that list. I'm not pointing any fingers - I don't have anyone in mind, and I've been quite happy working with absolutely all of the current team. Just putting the idea out. I've discussed this general situation with a (small) sampling of other GDB developers and contributors - enough to know that I'm not alone in my concerns. These aren't entirely my own words, either. I'll let other people take credit/blame for them if they want to, and if I've represented their opinions accurately. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer