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
