From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17806 invoked by alias); 18 Nov 2005 19:50:46 -0000 Received: (qmail 17788 invoked by uid 22791); 18 Nov 2005 19:50:43 -0000 Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 19:50:43 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 8BF6E48CFC6; Fri, 18 Nov 2005 14:50:41 -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 16228-01-2; Fri, 18 Nov 2005 14:50:41 -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 0519F48CDA3; Fri, 18 Nov 2005 14:50:41 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 51CB047E79; Fri, 18 Nov 2005 11:50:40 -0800 (PST) Date: Fri, 18 Nov 2005 19:50:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb@sourceware.org, cagney@gnu.org, jtc@acorntoolworks.com, fnf@ninemoons.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, ezannoni@redhat.com Subject: Re: Maintainer policy for GDB Message-ID: <20051118195040.GW1635@adacore.com> References: <20051117044801.GA4705@nevyn.them.org> <20051117231020.GJ1635@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00401.txt.bz2 Eli, I understand your position, and the rationale behind it. I still think that the addition of rules as you suggest will be causing extra work and delays. I won't argue much more about this, since the overhead will hopefully be small. This remains to be verified. It does seem however that one particular individual caused you to lose the trust you had in all the other maintainers, and that is very unfortunate. Otherwise, why would you insist on adding an overhead that essentially allows us to restrain a maintainer. Giving your trust, and letting them commit without approval does not prevent monitoring of your peers' work, nor does it prevent you from commenting and helping improve his work. The situation in GDB has, in my opinion, changed a great deal in the past year. For one thing, the SC committee is now more organized, and able to make decisions. My opinion is that we should avoid going to the SC if we can deal ourselves with a situation. This is what I mean by "reduce the use of the SC as much as possible". However, we should not hesitate to go to them should we need to. That's what they are here for. I prefer not to draw any parallel between society (laws) and our group (rules). Our group (the group of maintainers) is by invitation only. One has to demonstrate that one is able to work cooperatively with the rest of the maintainers before he gets nominated. I still deeply belive that all of us are good natured and willing to listen to the others, just as much as I'm trying to listen to you. I believe that abusive behavior will not happen overnight, and that the threat of losing one's priviledges by SC decision will be enough to prevent abuse repeats. Cf the GCC maintainer story I told in my previous message. I listened to your arguments, I understand where they come from. But I think you are asking for unnecessary measures. I've exposed my arguments as best as I could. Hopefully you understood my arguments and the group is able to make the decision that will benefit the project the most. Also, it just occurred to me that this discussion is only a small part of the overal discussion. The rest of the discussion seemed much more important to me: The distinction between reponsibility (who promised to review), and the authority (who has the priviledge). -- Joel