From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20406 invoked by alias); 18 Nov 2005 17:53:23 -0000 Received: (qmail 20396 invoked by uid 22791); 18 Nov 2005 17:53:20 -0000 Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 17:53:20 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAIHrJWu030664 for ; Fri, 18 Nov 2005 12:53:19 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAIHsaLY071272 for ; Fri, 18 Nov 2005 10:54:36 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAIHrHN6015521 for ; Fri, 18 Nov 2005 10:53:18 -0700 Received: from dyn9047022123-009047022095.beaverton.ibm.com (dyn9047022123-009047022095.beaverton.ibm.com [9.47.22.95]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAIHrGVk015500; Fri, 18 Nov 2005 10:53:17 -0700 From: Paul Gilliam Reply-To: pgilliam@us.ibm.com To: gdb@sourceware.org, Eli Zaretskii Subject: Re: Maintainer policy for GDB Date: Fri, 18 Nov 2005 17:53:00 -0000 User-Agent: KMail/1.6.2 Cc: Joel Brobecker , cagney@gnu.org, jtc@acorntoolworks.com, fnf@ninemoons.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, ezannoni@redhat.com References: <20051117044801.GA4705@nevyn.them.org> <20051117231020.GJ1635@adacore.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200511180956.14917.pgilliam@us.ibm.com> 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/msg00394.txt.bz2 On Friday 18 November 2005 04:39, Eli Zaretskii wrote: > > Date: Thu, 17 Nov 2005 15:10:20 -0800 > > From: Joel Brobecker > > > > 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. > > How far into the past does your history go? I've seen unsolvable > disagreements less than a year ago. Do you have a URL into the mailing list archive? > > > 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. > > I thought we wanted to minimize SC involvement. If that's true, we > should try to actively avoid situations where we need to go to the SC, > not simply assume they will happen seldom enough to be insignificant. > > One problem with going to the SC is that their procedures take a lot > of time. See how much time it took to resolve the last feud we had. Do you have a URL into the mailing list archive? > I think we don't want the adverse effect the SC's slow judgement has > on GDB development. > > > 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. > > What ``waste of time''? It normally takes a few day--a week, say--to > wait for objections, comments, etc. We could limit that period to > something reasonable, like 10 days. We could do any number of other > things to prevent the delay from getting unreasonably long. What I > cannot understand is why people are arguing for DOING NOTHING AT ALL. > > > How many developers have been bulies in GDB in the past 5 years? > > One thing I've learned about risk management is that you need to This sounds like "the voice of authority". Could you tell us your bona fides? > consider the damage caused in case an event actually happens, not only > the probability of the event. Some events are so damaging that you > might take extreme measures to make sure they never happen again. > > > Let's not penalize the "nice guys", the majority of you, and deal with > > the few "bad guys" when the situation demands it. > > I hate to lecture, but let me remind you that laws were invented > because leaving rules of conduct to the people, assuming they are > reasonable and fair, was found to not work. > > More to the point, if the ``penalty'' is reasonably tolerable, I don't > understand why we cannot ``penalize'' ourselves a bit, if in return we > regain trust and cooperation. > > Let me say this in another way: This community, good-willing as > it may be, failed a serious test of its ability to cooperate just a > few months ago! Isn't it reasonable to step back a bit and practice > self-restraint for a while, until we have more than a few months of > good cooperation behind us? > > > 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. > > That's not what happened last time. Experience should teach us that Do you have a URL into the mailing list archive? > such situations tend to create much uglier dynamics than the idyllic > picture you envision. Somehow, that experience taught us nothing, or > so it seems. > > Or maybe it's the old man in me talking, I don't know. > > > > (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. > > Since Daniel sets up his mailer to prevent replies getting to him by > direct email, I find it ironic, to say the least, that he forces us to > get the same message twice. > Is there a technological solution to this problem? Something that could tell if a person were NOT subscribed to the list and send the mail directly?