On Tue, Nov 26, 2013 at 05:14:22PM +0000, 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. >
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
