From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12115 invoked by alias); 26 Nov 2013 17:45:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 12101 invoked by uid 89); 26 Nov 2013 17:45:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-ie0-f179.google.com Received: from Unknown (HELO mail-ie0-f179.google.com) (209.85.223.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 26 Nov 2013 17:45:01 +0000 Received: by mail-ie0-f179.google.com with SMTP id x13so9509021ief.24 for ; Tue, 26 Nov 2013 09:44:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hH9bhUDshZiVos39LHRRlGfkVvN+6YxniiopbH0z+cs=; b=dSc9XXFK9Y0nq2rjsMfrZU/7OW0TwYI+/h5oswnN0L0mY7uyh5lU5C8/1yn6PFj+BT mYASeuml9sdhYBm2hCyc2qDa8xQN690Oy+s2iewnXDSRRk4X3D1zuBKVwuiOyCrmS6/n zdJCF7w689R2qX2hs8mr3Xrlfg8AurvcgFRFoKatLMzn/MKEC16kveffH+2efi9vxlZW CscdUvfvitGIGWAmumi/bUl4glmxd2FHRiw1GuTXbzG+uKk5W8k3VP0+zYIQd7VFnqEe biplGRd03jKd+QotDXEMTNUZVkCBjE5ZJ6EZqkKK5mbXdko4AFhbgYStiiG0beRbQXY5 vZnA== X-Gm-Message-State: ALoCoQkiP9hyjzyKFR2xGk0MgdDHIa5mtWaPQjaUYBLx+kfDKhCE9S2R3XpssrsPq7Ea1HOmYtfdgakMsPNjtbhXCtSVqOrLMYZpL4ceVa2b86bu1KQHSFxE8jJuK6yn0HJ6F6x+AIYPJ34665+Tkayn9t17ihkqCKYvg2FU0kQNggKhgJchjzLOLCl0HoaPG9znJSapqr14JJfUXp6hLW6FSL/NK1T8/A== MIME-Version: 1.0 X-Received: by 10.43.71.200 with SMTP id yl8mr2175145icb.74.1385487893895; Tue, 26 Nov 2013 09:44:53 -0800 (PST) Received: by 10.64.14.97 with HTTP; Tue, 26 Nov 2013 09:44:53 -0800 (PST) In-Reply-To: References: <20131120090429.GT30563@lug-owl.de> <5294CCB0.7010706@redhat.com> <12486579.sdiQgXsXIt@polaris> Date: Tue, 26 Nov 2013 20:52:00 -0000 Message-ID: Subject: Re: gcc's obvious patch policy From: Diego Novillo To: "Iyer, Balaji V" Cc: Eric Botcazou , "gcc-patches@gcc.gnu.org" , Jeff Law , Steven Bosscher Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg03397.txt.bz2 On Tue, Nov 26, 2013 at 12:40 PM, Iyer, Balaji V wrote: > > >> -----Original Message----- >> From: Eric Botcazou [mailto:ebotcazou@adacore.com] >> Sent: Tuesday, November 26, 2013 12:33 PM >> To: Iyer, Balaji V >> Cc: gcc-patches@gcc.gnu.org; Diego Novillo; Jeff Law; Steven Bosscher >> Subject: Re: gcc's obvious patch policy >> >> > Can I make a suggestion that if someone is making an "obvious" change >> > (with the exception of changing non-working code (comments, things >> > inside #if 0, etc)), have a patch on the mailing list for 12-24 hrs. >> > before putting it in? Maybe they could say something like, I will >> > check this in by X time tomorrow since this looks obvious >> > to me. This way if the change hurts someone who is working on a >> > feature in their local machine that is using the existing framework can >> chime in. >> >> I disagree, obvious patches cannot reasonably invalidate the work of others, >> or else they are simply not obvious. At worst they can privatize a public >> function or remove an unused one, but then it's easy to undo that later. >> > > Those at worst examples you have mentioned is the ones that scare me. Sometimes when a function becomes private, making it public back > again is sometimes an uphill battle. I am not saying they shouldn't commit it, but at least give a heads-up. Nah. Simple patches like that are always easy to pinpoint and address afterwards. Obvious patches will always be on the small side, after all. Diego.