From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9790 invoked by alias); 4 Jun 2006 20:03:54 -0000 Received: (qmail 9781 invoked by uid 22791); 4 Jun 2006 20:03:54 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 04 Jun 2006 20:03:53 +0000 Received: (qmail 7408 invoked by uid 1010); 4 Jun 2006 20:03:51 -0000 From: Richard Sandiford To: Mike Stump Mail-Followup-To: Mike Stump ,Steven Bosscher , Andrew Pinski , GCC Mailing List , richard@codesourcery.com Cc: Steven Bosscher , Andrew Pinski , GCC Mailing List Subject: Re: Release Schedule issues and doubts References: <4F2DF74A-5348-4D27-83A9-8F97110DA1B5@physics.uc.edu> <87lksde4h5.fsf@talisman.home> <571f6b510606040208m31e5e99bm80d0b8751e630ece@mail.gmail.com> Date: Sun, 04 Jun 2006 20:03:00 -0000 In-Reply-To: (Mike Stump's message of "Sun, 4 Jun 2006 10:13:09 -0700") Message-ID: <87mzcslmc9.fsf@talisman.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2006-06/txt/msg00116.txt.bz2 Mike Stump writes: > On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote: >> On 6/4/06, Richard Sandiford wrote: >>> Even if it's not intended that way, your proposal is probably >>> going to >>> be interpreted at some stage as a way of punishing maintainers. >> >> And what is wrong with that? > > I have a different take... I think people should be responsible for > the patches they put in, and that means that in general, they should > work on bugs and regressions in those patches before going off on fun > new work. This, if we wanted, could be enforced by accepting patches > to fix regressions before accepting (any) other work by that person. > This transfers responsibility from the person that approved the work, > which, I'd rather not see in general, as it can discourage patch > review, to the person doing the work. I agree. And I don't think a new gcc by-law is needed here (we seem so many of those already). Maintainers can already refuse to review a "fun new feature" patch until the submitter has fixed some problem with one of the submitter's earlier patches (if the maintainer thinks that's appropriate). I remember at least one case where it has already happened. Richard