From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11593 invoked by alias); 26 Feb 2003 18:08:02 -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 11586 invoked from network); 26 Feb 2003 18:08:02 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 26 Feb 2003 18:08:02 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h1QI7so04664; Wed, 26 Feb 2003 10:07:54 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb Subject: Re: [maint] GDB needs more local maintainers References: <3E5CF375.4050009@redhat.com> From: David Carlton Date: Wed, 26 Feb 2003 18:08:00 -0000 In-Reply-To: <3E5CF375.4050009@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00570.txt.bz2 On Wed, 26 Feb 2003 12:03:49 -0500, Andrew Cagney said: > 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 :-( My understanding is that the reasons why "throwing more programmers at the problem" is a bad idea are, roughly speaking, as follows: * New programmers need training time to come up to speed; not only does this mean that the extra programmers aren't as effective as the earlier programmers, but the earlier programmers actually become less effective as well because they have to spend time training the newbies. * If the work that is to be done is too atomic, then multiple people can't simultaneously do the work effectively. I don't see why either of those problems should arise when adding new maintainers. > 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 more to the core of the issue. The maintainers right now have two or three functions: 1) They can make changes to the code in question without needing as much approval as non-maintainers. 2) They can approve others' changes to the code. 3) They should, ideally, actually maintain the code, in the sense of overseeing its future development, getting rid of structural flaws in the code, weeding out bit rot and thorny code, etc. Long term commitment is necessary for part 3; long term commitment is not necessary for parts 1 and 2. If you want to be trusted to make changes to a body of code, what is important is whether or not you are familiar with the issues impacting the code right now, not whether or not you'll still be around in a couple of years. Obviously your judgment about what changes are appropriate now should be informed by a desire for the code to be healthy in a couple of years, but that doesn't actually mean you actually have to plan to stick around for another couple of years. If we wanted to try to split off these three roles into a few different categories (senior maintainers and junior maintainers, or whatever), fine; I don't think that level of bureaucracy would be useful, but maybe I'm wrong. But what I do claim is: * There are many people contributing to GDB right now who aren't recognized as maintainers in areas even though they're competent in areas 1) and 2) above. * In practice, maintainers don't do function 3). (With exceptions, of course: Eli comes to mind as a wonderfully proactive documentation maintainer.) Long-term fixes typically get made whenever their absence is causing somebody problems; the person doing that fix may be a maintainer, or may not. If your criterion for being a maintainer is to "have the level of commitment needed to maintain that body of code", you'd have to empty out almost all of the current MAINTAINERS file, and you wouldn't find anybody to replace them. > This is also why I try to encourage developers (remember I also act > in that role) to discuss / negotiate technical issues up front. Of course this is a good idea. But, I continue (with my mania for bullet points): * People can/should/will and talk with others about technical issues whether or not they're maintainers. * Negotiating those issues in advance is great if you can get somebody to listen to you in the first place, and if the technical issues are such that they can be discussed without a concrete patch. That's frequently not the case. Obviously, I'm a newbie here, so I can't really speak from experience: all I can do is make suggestions that seem to make sense from my limited perspective. But if you go back to the responses to Daniel's original message, a majority of the participants agree with him that there's a problem that won't be fixed simply by making it easier to track patches, or by nagging maintainers to be more responsive. And some of those people agreeing with him _do_ have a lot of experience with GDB, and with other software products with different, effective maintenance strategies. David Carlton carlton@math.stanford.edu