From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31412 invoked by alias); 19 Feb 2003 02:24:18 -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 31402 invoked from network); 19 Feb 2003 02:24:17 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by 172.16.49.205 with SMTP; 19 Feb 2003 02:24:17 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h1J2Hf8A028977; Tue, 18 Feb 2003 21:17:41 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h1J2HejB028973; Tue, 18 Feb 2003 21:17:40 -0500 To: gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <20030217180709.GA19866@nevyn.them.org> From: Jim Blandy Date: Wed, 19 Feb 2003 02:24:00 -0000 In-Reply-To: <20030217180709.GA19866@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00329.txt.bz2 I agree with what Daniel has said here. I'm concerned that some people have misunderstood his points, so I'll put it differently. I think GDB could get better use of the contributors it has now by adjusting the rules for patch approval. - Slow patch review is a real problem on GDB --- even acknowledging the legitimate reasons for some delays that Elena has mentioned. - It's true that "... some maintainers should try to review patches in their areas of responsibility more often", but merely saying so doesn't have any effect. Folks have been saying that ever since Cygnus loosened its grip on GDB and the process opened to the public. That statement seems to express a hope that the maintainers will somehow "wake up" and everything will get better. It's been years, now, and we need to stop waiting for this to happen. Let's work with the people we've got, rather than hoping they'll transform themselves somehow. - If we accept that the maintainers' behavior is stable, then the next alternative is to adjust the organization that they operate under. Is there some way to re-organize the people we have, accepting their job committments and personal limitations (I have myself in mind here as much as anyone else, so don't be affronted), so that things progress better? Is the current organization optimal? Set that line of thinking aside, and consider another problem: As far as I can tell, the Global Maintainers don't really have the privileges that one would expect. A Global Maintainer ought to be someone who can make or approve a change anywhere in GDB. This means, in addition to having good technical judgement, that we trust them to ask others as appropriate, and that we consider them good people to debate with when a disagreement does come up. This is different from the current definition --- as far as I can tell, Global Maintainers aren't really that much different from anyone else. I've seen them criticized for approving changes, not because of any specific problem with the changes, but because it was seen as outside their purview. I would personally be happy to see the current list of Global Maintainers, of which I am a member, emptied out, and have people re-establish their reputations to be added to the list, if it would make folks more comfortable about straightening out the definition this way. So, to bring the two threads together: I think GDB could get better use of the contributors it has now by relaxing the rules about who is allowed to approve a patch. With the redefinition of Global Maintainer we're suggesting, more people would have the right to review and approve a patch, so there are more chances someone will. When I was maintaining Guile, I ended up replacing my dictatorship with a group of four maintainers --- Mikael Djurfeldt, Maciej Stachowiak, and Marius Vollmer. Any one of those guys I trusted as much as I trust myself. There was no risk in making them my peers, since I was just as likely to make a poor decision as they were (if not more so), and if they didn't like something, it would certainly benefit from a re-examination. Surely we have people in the GDB community in addition to Andrew who have earned that level of trust. Just to add another idea to the mix: I was talking to a friend of mine about the way GDB is run, and he was amazed that we give individual people complete power, and complete responsibility, for sections of code. Everyone is going to be wrong sometimes, he said, and it's easy to protect against, without being too bureaucratic. In the Apache system, which is used now in a lot of projects, they have a pretty big group of global maintainers. Any non-obvious core change needs to be described on the list, and get three "+1" votes from other global maintainers. But if anyone posts a "-1", the change is vetoed: it gets discussed for a longer period, and then put up for a straight vote. The nice thing here is that *nobody* has absolute power --- come on, even the most talented among us is going to do something questionable every so often, and would benefit from some more discussion --- but it's still easy enough to get buy-in for most changes that it's efficient. But whether or not you like that idea, GDB has been operating under basically the same system, and suffering the same problems, long enough to confidently conclude that we, at least, are always going to operate the way we do now under the system we have now. This delegated dictatiorship (with all due respect to our hard-working and conscientious dictator) is more of an inherited legacy from ancient days than a well-tuned process. I think it's time to try to bring in good ideas from other projects, like GCC and Apache.