From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17079 invoked by alias); 18 Feb 2003 04:28:46 -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 17070 invoked from network); 18 Feb 2003 04:28:45 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 04:28:45 -0000 Received: by localhost.redhat.com (Postfix, from userid 1008) id 50F2E3CE5; Mon, 17 Feb 2003 23:28:47 -0500 (EST) Subject: Re: [maint] The GDB maintenance process In-Reply-To: <20030217180709.GA19866@nevyn.them.org> "from Daniel Jacobowitz at Feb 17, 2003 01:07:09 pm" To: Daniel Jacobowitz Date: Tue, 18 Feb 2003 04:28:00 -0000 Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20030218042847.50F2E3CE5@localhost.redhat.com> From: ac131313@redhat.com (Andrew Cagney) X-SW-Source: 2003-02/txt/msg00298.txt.bz2 > 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. This isn't correct. The MAINTAINERS file reads: Various Maintainers Note individuals who maintain parts of the debugger need approval to check in changes outside of the immediate domain that they maintain. If there is no maintainer for a given domain then the responsibility falls to a global maintainer. If there are several maintainers for a given domain then responsibility falls to the first maintainer. The first maintainer is free to devolve that responsibility among the other maintainers. so it makes definite references to `responsibility'. Put simply, `the buck stops'. Perhaps you should ask a different question `is the buck ignored?' and what should be done if/when it is. Even though GDB is developed by volunteers, it is entirely reasonable to expect the volunteers to take their duties seriously. Monitoring the bug data base; approving patches; where helpful, contributing to discussions. Now that I typically file patches into the bug database, this should be much easier. However, what is unreasonable is to place un-realistic expectations on the said maintainers. The assumption that a volunteer is working 24x7 and living in north america isn't, for instance, reasonable. A significant number of GDB maintainers have real jobs and real timezones. > 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. `write' was a simple typo. From the outset (i.e., from when I got handed this job) it was made very clear that neither I, nor any other global maintainer, could override the decision of a specific maintainer. This was, and still is, very important. It ensures that the area has a certain level of continuity, and it ensures that I (or another global maintainer) doesn't ride gunshot over a specific 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. The interaction dynamics of a committed patch are very different to those of an unapproved patch. Once a patch is committed, the person with objections is, unequestionably, put in the back seat. > 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. (ROFL.) The GCC model involves a number of development phases and the above comments would only relate to one of those phases. At other times increasingly strict controls are placed on what can be committed/approved. The GCC group spend a significant (out of control?) amount of their time trying to re-stablize GCC for their releases. For GDB, on the other hand, interesting development can and does get approved/committed at any time. GDB snaps are of such quality that we can confidently refer someone to current sources for fixes (except when I have a bad day like today :-). Further, instead of using official releases (and as you yourself have done) arbitrary snaps can even make their way into a distro. > - 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. The only way I've got my patches into GCC is by acting as a champion for their cause. Exactly like Elena described. Having worked on other open source projects I'd have to conclude the same also applied to them. Sounds like it really is time to drag out "aegis". Andrew