> What type of *proof* would you accept? > > o Bisecting the commit history until it doesn't fail any more?
That isn't even *evidence* that the patch caused the bug, much less proof. It only shows that the patch resulted in some bug happening, but that bug might have been latent. If this is really what we want for an auto-revert trigger, then what we need is a commit hook that builds every patch and rejects any that cause problems. I suspect we really don't want that though. > o A formal mathematical proof of some type? "I think the bug is caused by X,Y,Z... anyone agree?" "Yeah, that looks right." If anyone thinks that you can mathematically prove *anything* about software, they're on crack. I see "proof" as "shown evidence that they understand what really happened, and others agree." I absolutely do NOT want anyone, other than global maintainers, to have carte blanc to stomp on some other developer's toes without a fantastic reason and reasonable surety that they're doing the right thing. > 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. I don't agree that blindly applying any "you may revert" rule, without knowing what's going on, is a good idea. We *already* have a rule that applies to all build breakers - the 48 hour rule. We're talking about a new rule that shortens this time. If it's truly impossible to figure out why a bug suddenly starts happening, the old 48 hour rule is sufficient, and global maintainers can always override any policy anyway. Anything more drastic than that *should* require some barriers to "just doing it".
