gcc's obvious patch policy

[James Greenhalgh]

On Tue, Nov 26, 2013 at 05:14:22PM +0000, Iyer, Balaji V wrote:
> 
> 
> > -----Original Message-----
> > From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
> > owner@gcc.gnu.org] On Behalf Of Jeff Law
> > Sent: Tuesday, November 26, 2013 11:31 AM
> > To: Diego Novillo; Steven Bosscher; gcc-patches
> > Subject: Re: gcc's obvious patch policy
> > 
> > On 11/26/13 08:21, Diego Novillo wrote:
> > > On Tue, Nov 26, 2013 at 12:17 AM, Alan Modra <amodra@gmail.com>
> > wrote:
> > >> Was Re: [buildrobot] [PATCH] mips: Really remove ENTRY_BLOCK_PTR On
> > >> Wed, Nov 20, 2013 at 10:08:45AM +0100, Steven Bosscher wrote:
> > >>> This patch is obvious and it fixes breakage. Please go ahead and commit
> > it.
> > >>
> > >> Sorry to pick on you here Steven, but this doesn't meet gcc's
> > >> definition of an obvious patch.  Don't believe me?  See
> > >> http://gcc.gnu.org/svnwrite.html#policies
> > >>
> > >> Allowed as obvious in the gcc sources are typo fixes for comments or
> > >> similar, or reverting a bad patch you made.  That's it.  The power to
> > >> change anything else is reserved to the relevant maintainer.
> > >
> > > Huh.  That's silly.  It allows nothing interesting!
> > As I've stated within the last few months, I'm certainly open to revisiting that
> > policy.  I believe we put that policy in place in circa
> > 1998 as we started up egcs.
> > 
> > >
> > >> Can I recommend gdb's obvious patch policy?  It even tickles my sense
> > >> of humour.  "will the person who hates my work the most be able to
> > >> find fault with the change" - if so, then it's not obvious..
> > >
> > > I like this one much better.  Anyone else opposed to changing the
> > > obvious-commit policy to something along these lines?
> > Seems reasonable to me.
> > 
> 
> 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  <TIMEZONE> 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.
> 

This would seem to exclude the most useful type of obvious fixes,
trivial changes which are currently preventing a bootstrap.

What benefit does waiting 24 hours to add a missing 'unsigned'
give?

Surely If the change were likely to impact someone else in a
non-trivial way, it cannot be considered an obvious change and
thus, this rule would not apply.

James