I don’t have a problem with releasing out of branches. I think I (or someone) proposed this in the past and there was not consensus but it seems like a good time to revisit the issue.
On Wed, Nov 25, 2020 at 7:41 PM Jacques Nadeau <jacq...@apache.org> wrote: > I'm catching up here. A couple questions. > > - I don't think we should require the inclusion of the release commits > in the main branch. Having leafs created right before release seems to > simplify this and resolve any issues around force PRs, no? Or maybe I'm > misunderstanding something? Maybe to put another way, why do we have to > force push anything to main ever? That seems like the real problem. > - I'm not sure I follow the comments about the java release process > requiring any interactions with the Apache repo or a particular branch. > In > the past (note, it has been a while), I used mvn properties to override > any > of this behavior so that I might do any pushes to a personal repo rather > than the Apache one (or an apache release branch rather than the main > branch). > > - The local release branch has some unpushed commits such as bumping to the > > next snapshot version. > > > Most projects I've worked on work this way: > > We decide to do a release. At that point, we create a branch for the > release. In the main branch, we bump the version up immediately. > In the release branch, we do minimal commits as needed for hotfixes etc > (and all cherry pick to main). > We do release steps and push those commits (excluding the post-release > version bump) to the release branch. > We vote on the release commit and artifacts. > If there is a release failure, we revert any release commits in the release > branch and then apply addiitonal fixes. > Then do the process again. > > This way main never has a force push. > > (Full disclosure, the one exception I've worked on is that Calcite uses > force pushes as well as process-based branch locking. I think we should > avoid both of those patterns). > > I'd also clarify, while I'm against merge commits, I think that a release > branch that forks slightly off the main branch should be fine. Do people > disagree with this? > > > > On Wed, Nov 25, 2020 at 5:52 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 > > >
