Hello Jorge, I know from the past on the Python/C++ side, we needed to do this for a lot of contributors to enable them to work with their branches/PRs again as they were overwhelmed with the complexity of these rebases. Personally, I wouldn't like to spend much time on whether we should rebase PRs after the release for everyone or not but actually get rid of the need to push to master to actually get a release candidate out. This is making the work of the release manager harder, confuses downstream packagers and also leads to the fact that all PRs are diverged when they were touched during the release process.
The main headache here is that currently the release tooling on the Java side requires us to do this. I know that in the last days someone opened a JIRA to get rid of that (and hopefully someone will link to that JIRA in this thread). Solving that would be a win for all and also make this discussion unnecessary. The main caveat is that the annoyance on the Java side pops up mostly with the non-Java devs and thus it was not solved yet. Cheers Uwe On Wed, Nov 25, 2020, at 5:26 AM, Jorge Cardoso Leitão wrote: > 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 >
