> The first two sound logical, but why couldn't those version bumps be a merge commit into master?
We've made the commitment to maintaining a linear commit history in this project. Auto-rebasing the PRs at this point is best described as "harm reduction". The root cause is GitHub's UI which shows a bunch of unrelated commits in the UI when a PR is based on a commit that no longer exists due to the rebase. This can confuse people and sometimes cause them to engage in incorrect actions (trying to "git merge" in various ways) that cause their branches to get very messed up. If we were using another code review system (like Gerrit), this problem wouldn't exist. We can stop rebasing PRs after releases, but it *is* overall going to make life more difficult for the project's maintainers and contributors -- we know this based on what has occurred in the past. The current policy is the most pragmatic policy, even if it is not the most technically pure. > 2. stop pushing to others' PRs without their explicit consent Since I've edited people's branches to fix problems or address minor issues countless times, this would create a lot of hardship for me and other maintainers. This is another pragmatism vs. technical purity question. One possible middle ground here is to create a "disallow-list" for contributors who don't want their PRs edited by tools. On Wed, Nov 25, 2020 at 4:33 AM Jörn Horstmann <joern.horstm...@signavio.com> wrote: > > Is there more documentation why a force push to master is necessary? > > I read > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Mainsourcereleaseandvote > which says > > - The local release branch has some unpushed commits such as bumping to the > next snapshot version. > - So you need to add these commits to the master branch. > - This needs force push. > > The first two sound logical, but why couldn't those version bumps be a > merge commit into master? > > If this is somehow required only by the java/mvn setup, I'd be happy to > help with that. I haven't worked on the java part of arrow yet, but have > good experience with java and maven. > > Cheers, > Jörn > > > On Wed, Nov 25, 2020 at 10:11 AM Uwe L. Korn <uw...@xhochy.com> wrote: > > > 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 > > > > > > > > -- > *Jörn Horstmann* | Senior Backend Engineer > > www.signavio.com > Kurfürstenstraße 111, 10787 Berlin, Germany > > Work with us! <https://hubs.ly/H0wwzcr0> > > > <https://www.linkedin.com/company/signavio/> > <https://www.twitter.com/signavio> <https://www.facebook.com/signavio> > <https://www.youtube.com/user/signavio> > <https://www.xing.com/companies/signaviogmbh> > > <https://t-eu.xink.io/Tracking/Index/kBwAALBtAAAnu0MA0> > > HRB 121584 B Charlottenburg District Court, VAT ID: DE265675123 > Managing Directors: Dr. Gero Decker, Daniel Rosenthal
