On Tue, Nov 26, 2013 at 12:40 PM, Iyer, Balaji V <balaji.v.i...@intel.com> wrote: > > >> -----Original Message----- >> From: Eric Botcazou [mailto:ebotca...@adacore.com] >> Sent: Tuesday, November 26, 2013 12:33 PM >> To: Iyer, Balaji V >> Cc: gcc-patches@gcc.gnu.org; Diego Novillo; Jeff Law; Steven Bosscher >> Subject: Re: gcc's obvious patch policy >> >> > 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. >> >> I disagree, obvious patches cannot reasonably invalidate the work of others, >> or else they are simply not obvious. At worst they can privatize a public >> function or remove an unused one, but then it's easy to undo that later. >> > > Those at worst examples you have mentioned is the ones that scare me. > Sometimes when a function becomes private, making it public back > again is sometimes an uphill battle. I am not saying they shouldn't commit > it, but at least give a heads-up.
Nah. Simple patches like that are always easy to pinpoint and address afterwards. Obvious patches will always be on the small side, after all. Diego.
