From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28490 invoked by alias); 17 Nov 2005 21:10:25 -0000 Received: (qmail 28479 invoked by uid 22791); 17 Nov 2005 21:10:23 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.207) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 21:10:23 +0000 Received: by zproxy.gmail.com with SMTP id x3so25116nzd for ; Thu, 17 Nov 2005 13:10:21 -0800 (PST) Received: by 10.36.177.11 with SMTP id z11mr7951297nze; Thu, 17 Nov 2005 13:10:21 -0800 (PST) Received: by 10.37.2.35 with HTTP; Thu, 17 Nov 2005 13:10:21 -0800 (PST) Message-ID: <8f2776cb0511171310m556a37c5r723cef451735a96a@mail.gmail.com> Date: Thu, 17 Nov 2005 21:10:00 -0000 From: Jim Blandy To: Eli Zaretskii Subject: Re: Maintainer policy for GDB Cc: gdb@sourceware.org, Andrew Cagney , "J.T. Conklin" , Fred Fish , Peter Schauer , Elena Zannoni In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051117044801.GA4705@nevyn.them.org> 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/msg00359.txt.bz2 [I've dropped individuals from the CC list that I know to read gdb@ regular= ly.] On 11/17/05, Eli Zaretskii wrote: > > I have always been in favor of the concept that global maintainers shou= ld 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 nee= d to > > work on the trust and/or the list of maintainers. > > The problem is, trust is built by following rules which are initially > intentionally restrictive. As the trust grows, the restrictions can > be gradually lifted. That's not the pattern I'm familiar with. An organization can have strict rules, and as trust is built up, people will tolerate those rules being bent or set aside in specific cases. But I've never seen the restrictions be explicitly lifted as a result of that. We have restrictions in place that many of GDB's contributors don't like, and which are definitely hampering progress. > 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? You need to be more specific. I agree with your characterization that we trusted too much in 1999 that everything would just work out, but I don't see that this proposal makes the same mistake. What particular passages concern you? What are their consequences?