Note that at any time you can change your GitHub settings to disallow your branches from being edited by maintainers.
On Wed, Nov 25, 2020 at 7:51 AM Wes McKinney <wesmck...@gmail.com> wrote: > > > 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
