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... R.
