We have observed instances of changes being reverted in master that have been authored following the contributor guidelines and pass all tests (post commit). While we generally seem to have quite a bit of revert action happening [1], this thread is about those instances that are outside of our documented policies.
For a contributor, it isn't a good experience to see reverts (especially not out of the blue) after a PR has been reviewed, all tests pass and generally care has been taken to do the right things. Changes can have unforeseen effects downstream. Usually releases provide the opportunity to mitigate such issues, not necessarily by a revert, but in many cases by another change that keeps everyone happy. Unexpected reverts can break someone else and are disruptive. Some discussion already took place on one specific PR [3], but that is just an example and by no means an isolated incident. On some of these reverts, "internal" problems with an important runner are cited, with little to no explanation. It would be nice if folks with more insight can shed more light on this. I hope that as outcome of this discussion, we can arrive at a better understanding of why and when such reverts were necessary and possibly find ways to largely avoid them going forward. Thanks! Thomas [1] https://github.com/apache/beam/search?o=desc&q=Revert&s=committer-date&type=Commits [2] https://beam.apache.org/contribute/postcommits-policies/ [3] https://github.com/apache/beam/pull/7012
