> -----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. Thanks, Balaji V. Iyer. > jeff
