From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11632 invoked by alias); 2 Nov 2004 04:51:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11617 invoked from network); 2 Nov 2004 04:51:15 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sourceware.org with SMTP; 2 Nov 2004 04:51:15 -0000 Received: from zaretski ([80.230.159.47]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DVQ82626 (AUTH halo1); Tue, 2 Nov 2004 06:49:58 +0200 (IST) Date: Tue, 02 Nov 2004 04:51:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c4c096$Blat.v2.2.2$d4f57520@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <20041101223716.GB28889@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 1 Nov 2004 17:37:16 -0500) Subject: Re: [commit] Add add_setshow_enum_cmd, use in mips Reply-to: Eli Zaretskii References: <4183BD22.3090905@gnu.org> <01c4bed6$Blat.v2.2.2$fa231b20@zahav.net.il> <41856ECA.2060701@gnu.org> <01c4bfcd$Blat.v2.2.2$299ef260@zahav.net.il> <20041101051257.GA11134@nevyn.them.org> <01c4c057$Blat.v2.2.2$4cacd760@zahav.net.il> <20041101223716.GB28889@nevyn.them.org> X-SW-Source: 2004-11/txt/msg00032.txt.bz2 > Date: Mon, 1 Nov 2004 17:37:16 -0500 > From: Daniel Jacobowitz > Cc: cagney@gnu.org, gdb-patches@sources.redhat.com > > I only see a point for maintainers to post RFAs when (A) they can > not approve the patch themselves or (B) they are not > confident/happy/sure with the approach. I'm astonished: you are, in effect, saying that the patch review process exists only because some meaningless bureaucratic rule does not permit a single person to do whatever he/she wants. I kinda thought that the patch review is the default, except when the patch comes from an expert whom we trust to be good enough not to need that. > We don't operate on consensus I thought we should. If not, I don't see much sense in the machinery that we have in place. To me, the reason for our procedures is to produce quality code, not just to make an impression of due process.