From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27453 invoked by alias); 17 Nov 2005 23:10:32 -0000 Received: (qmail 27445 invoked by uid 22791); 17 Nov 2005 23:10:29 -0000 Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 23:10:29 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 67B0048CF2D; Thu, 17 Nov 2005 18:10:27 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04939-01-9; Thu, 17 Nov 2005 18:10:27 -0500 (EST) Received: from takamaka.act-europe.fr (s142-179-108-108.bc.hsia.telus.net [142.179.108.108]) by nile.gnat.com (Postfix) with ESMTP id BBDD048CF27; Thu, 17 Nov 2005 18:10:26 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id F35EF47E79; Thu, 17 Nov 2005 15:10:20 -0800 (PST) Date: Thu, 17 Nov 2005 23:10:00 -0000 From: Joel Brobecker To: gdb@sourceware.org, Jim Blandy , Kevin Buettner , Andrew Cagney , "J.T. Conklin" , Fred Fish , Mark Kettenis , Peter Schauer , Stan Shebs , Michael Snyder , Eli Zaretskii , Elena Zannoni Subject: Re: Maintainer policy for GDB Message-ID: <20051117231020.GJ1635@adacore.com> References: <20051117044801.GA4705@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051117044801.GA4705@nevyn.them.org> User-Agent: Mutt/1.4i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00362.txt.bz2 I'll try to put all the comments I have after having read the various messages that were posted. Overall, I like the proposal. > Patch Champions > > These volunteers track all patches submitted to the gdb-patches list. They > endeavor to prevent any posted patch from being overlooked; work with > contributors to meet GDB's coding style and general requirements, along with > FSF copyright assignments; remind (ping) responsible maintainers to review > patches; and ensure that contributors are given credit. I really like this idea. I can help out if nobody else volunteers. > Some maintainers are listed as responsible for patch review in particular > areas. If a maintainer is not currently able or willing to review patches, > please contact the global maintainers or the steering committee, who will > resolve the situation and find a replacement or assistant if necessary. I'm a bit unclear as who it is who should contact the GM or the SC. Is it the patch champion, or the submitter, or both? I'm more inclined to say "contact the GMs" first, and they will contact the SC if appropriate. Like some of us said previously, I'd like to keep the requests to the SC only for occasions where only the SC can solve the situation. If things can be sorted out by the GMs, let's do it that way, as they have a better knowledge of the GDB community. > Separating responsibility for patch review from authority for patch review > is a new concept for GDB; I believe the suggestion was Ian's. The more time > I've spent working on this proposal the more I've come to like it. I > envision the areas of responsibility as broad, but the areas of authority as > possibly more specialized. This is a winning concept, in my opinion. I agree with Eli that this concept needs to be made a little bit clearer, perhaps by adding a little paragraph, something resembling the above, as an introduction to the rest of the text. When I read the text, I was clear on what each category of developers had to do, as well as could do. Reading that same text after having a clear idea of this concept makes it have more sense. > I have always been in favor of the concept that global maintainers > should be able to approve patches anywhere, without having to wait for > area maintainers. If we don't trust each other enough for that, then > we need to work on the trust and/or the list of maintainers. Strongly agreed. About the voting system: I would also prefer to avoid this. The history of the GDB maintenance community since I joined shows that we're able to work together without unsolvable disagreements. In case a disagreement happens and cannot be resolved, which should be very seldom, the persons involved should present our arguments to the SC, and the SC makes a decision. They can vote if they want :-) (I heard they have a voting system in place). Eli said: > By contrast, you suggest to begin with unconditional trust. We > already tried that in the past, and we saw what happened. Why try > that again? why assume that what happened once, cannot happen again? I agree with Eli that an abusive developer/maintainer may happen again in the future. But I disagree that we should enforce stricter rules to prevent this from happening. This would be a waste of everybody's time for a situation which can only potentially happen very seldomly. How many developers have been bulies in GDB in the past 5 years? Let's not penalize the "nice guys", the majority of you, and deal with the few "bad guys" when the situation demands it. I'll take the example of something that I believe happened roughly a year ago with GCC. People complained about abusive commits from one of the global maintainers. I don't know the exact story, not following closely the GCC mailing lists, but I think the SC threatened to remove that person from the list of blanket maintainers, and perhaps even enacted on this decision. In any case, last I heard, he's playing much nicer now. (I know this guy personally, so I'm not criticizing him, just using his story as an example). So let's say we end up having somebody who is abusive and doesn't change his behavior after discussing the problem. Then let's collect the evidences of his behavior, and present them to the SC, who can then decide to revoke or not the priviledges that he's abusing from. > (Why CC everyone, if we all read the list?) I like this practice, because emails with my name in the recipients have a little flag, so I pay more attention to them (and look at them first). This is an easy way to make sure that the message gets some people's attention. -- Joel