On Wed, Apr 6, 2011 at 7:48 AM, Richard Earnshaw <rearn...@arm.com> wrote: > > On Tue, 2011-04-05 at 08:26 +0200, Steven Bosscher wrote: >> On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt <ber...@codesourcery.com> >> wrote: >> >> > For i686-linux bootstraps it's hard to argue against it, but in general >> > I find it easier to cope with the occasional broken tree than with >> > getting patches reverted when you can't reproduce the failure. >> >> Maybe you find that easier, but auto-testers do not. That's a point >> you completely ignore. And other people than you also do not find that >> easier. >> >> There are auto-testers for performance and regression hunting and they >> simply stop working if bootstrap breaks. Also, scripts to bisect to a >> regression have a higher risk of running into a broken tree if >> bootstrap is broken over a longer period of time. That's an effect >> that may be felt for months/years. There were ~80 checkins on the >> trunk since r171843, most of them non-trivial. If one of those >> introduced a regression it is now more difficult to automatically >> identify which patch introduced it. >> >> I don't understand, really, why it's such a big deal to revert a patch >> quickly if it broke something. Yes, it should be done with care. But >> not depending on weekends and holidays. For some people the weekend is >> the only time they can work on GCC (hi!) and autotesters don't care if >> it's weekend or not :-) You feel mobbed and I'm sorry you feel that >> way, but it shows that a lot of people tried to work on GCC in that >> weekend. > > The difficulty is often not one bad patch, it's two bad patches going in > that overlap. Tracking down the precise second patch can't be done with > a bisect operation. > > If we're not going to aggressively revert patches, then maybe we should > aggressively freeze commits when the tree is broken... >
Agree. -- H.J.
