gcc's obvious patch policy

[Richard Earnshaw]

On 26/11/13 17:14, 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.
> 

There may be times when that is undesirable.  For example, the obvious
fix to something that prevents the compiler from building.

I think we have enough checks and balances in place.  Anyone
repeatedly/gratuitously abusing the obvious rule is likely to lose their
commit bit pretty quickly.  We're a community that works by
co-operation, so lets co-operate as much as possible.

R.