On 26/11/13 17:14, Iyer, Balaji V wrote: > > >> -----Original Message----- >> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- >> ow...@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 <amo...@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.
