On 04/05/2011 02:16 PM, DJ Delorie wrote:
Diego Novillo<dnovi...@google.com> writes:
On Tue, Apr 5, 2011 at 00:51, Ian Lance Taylor<i...@google.com> wrote:
I agree.
At the summit in October there was a discussion about this. I was on
the side of fast rollback for new failures. Would anybody care to
present the opposite view with regard to a patch like this? Can we
agree on fast rollback for bootstrap failures on x86/x86_64 GNU/Linux
systems?
I completely support this approach.
I would agree with faster rollback *if* the person doing the revert
*first* proved that the patch they're reverting actually caused the bug,
and not just exposed some pre-existing bug elsewhere. And got someone
else to agree that reverting is the right thing to do.
What type of *proof* would you accept?
o Bisecting the commit history until it doesn't fail any more?
o A formal mathematical proof of some type?
As a maintainer of non-primary targets, I see lots of perfectly normal
patches that allow a bug elsewhere to exert itself, and I think that's a
completely different situation than a patch which introduces a bug.
You seem to suggest that there is a simple and reliable way to
differentiate uncovering of latent bugs and introduction of new bugs. I
don't think there is so the only practical thing to do is apply any rule
we have to all build breakers.
David Daney
