From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2340 invoked by alias); 27 Nov 2005 04:59:49 -0000 Received: (qmail 2331 invoked from network); 27 Nov 2005 04:59:48 -0000 Received: from unknown (205.217.158.180) by sourceware.org with QMTP; 27 Nov 2005 04:59:48 -0000 Received: (qmail 27253 invoked by uid 10); 27 Nov 2005 04:59:47 -0000 Received: (qmail 19753 invoked by uid 500); 27 Nov 2005 04:59:40 -0000 To: Michael Snyder Cc: gdb@sources.redhat.com Subject: Re: Maintainer policy for GDB References: <43893653.4080209@redhat.com> From: Ian Lance Taylor Date: Sun, 27 Nov 2005 05:00:00 -0000 In-Reply-To: <43893653.4080209@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00590.txt.bz2 Michael Snyder writes: > 2) Reverting a patch > > There hasn't been too much discussion of this, but it > makes me nervous. May I throw this out on the table? > How about if, except for area maintainers, it requires > the agreement of at least two maintainers to revert > another maintainer's patch? For comparison, a gcc patch which causes a testsuite or significant performance regression on a primary target may be reverted, if any two people with write privileges (i.e., not just maintainers, but also write-after-approval) agree, after waiting for 48 hours. In practice this is rarely actually done; the threat of it is normally enough to resolve the situation one way or another. Ian