AaronBallman wrote: > Is it appropriate to auto-revert on downstream failures? I don't believe > we've taken that approach previously, and I'm not sure I would feel > comfortable doing that even it is allowed. > > I'd just like to have @AaronBallman clarify what is expected in this scenario.
It can be appropriate to auto-revert on downstream failures, but isn't always. If there's a reproducer that shows the changes were incorrect in upstream, it's fine to do a timely revert. However, 1) the revert has to be timely but without jumping the gun; there may be additional failures to be found and we want to avoid revert/reland dances as much as we can, 2) the changes have to be incorrect; there needs to be a real analysis of the failure to determine the test was correct and the changes were wrong, not just "behavior changed downstream, revert upstream", and 3) the failure needs to have a reproducer at the time of the revert which shows the failure can be reproduced upstream (and we'd love for a minimal reproducer as soon as possible). Outside of that kind of situation, it's more negotiable. e.g., we've had folks who can't share the reproducer immediately because it's customer code, but can share the crash log showing a failing assert added in the PR, with a promise that the public reproducer will be coming in a few hours, and ask if it's okay to revert. Or sometimes downstream testing finds an issue four days after the changes land and so there's questions as to whether a revert is better than fixing forward, so ask if it's okay to revert. That kind of thing. https://github.com/llvm/llvm-project/pull/215619 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
