Hi, Based on a discussion on PR #8481, I would like to raise a concern around git and the post-actions of a release. The background is that I was really confused that someone has force-pushed to a PR that I fielded, re-writing its history and causing the PR to break.
@wes and @kszucs quickly explained to me that this is a normal practice in this project on every release, to which I was a bit astonished. AFAIK, in open source, there is a strong expectation that PRs are managed by individual contributors, and committers of the project only request contributors to make changes to them, or kindly ask before pushing (not force-pushing) directly to the PR. IMO, by force-pushing to PRs, we are inverting all expectations and sometimes even breaking PRs without consent from the contributor. This drives any reasonable contributor to be pissed off at the team for what we just did after a release: - force-pushed to master - force-pushed to their PRs - broke their PRs's CI - no prior notice or request of any of the above IMO this is confusing and goes against what virtually every open source project does. This process also puts a lot of strain in our CIs when we have an average of 100 open PRs and force-push to all of them at once. As such, I would like to propose a small change in the post-release process and to the development practices more generally: 1. stop force-pushing to others' PRs 2. stop pushing to others' PRs without their explicit consent 3. document in the contributing guidelines <https://github.com/apache/arrow/blob/master/.github/CONTRIBUTING.md> that master is force-pushed on every release, and the steps that contributors need to take to bring their PRs to the latest master The underlying principles here are: - it is the contributor's responsibility to keep the PRs in a "ready to merge" state, rebasing them to master as master changes. - A force-push to master corresponds to a change in master - thus it is the contributor's responsibility to rebase their PRs against the new master. I understand the argument that it is a burden for the contributors to keep PRs up-to-date. However, I do not think that this justifies breaking one of the most basic assumptions that a contributor has on an open source project. Furthermore, they already have to do it anyways whenever the master changes with breaking changes: the contributor's process is already "git fetch upstream && git rebase upstream/master" whenever master changes. Whether it changes due to a normal push or a force-push does not really affect this burden when compared to when a merge conflict emerges. Any thoughts? Best, Jorge
