So long as the backport PRs are lazy consensus instead of the RTC that a PR generally implies (and the original branch went through) then this all reads as in line with my own preferences and what we've mostly done historically.
On Wed, Feb 19, 2020 at 10:08 AM Nick Dimiduk <ndimi...@apache.org> wrote: > > Hello, > > We have had a couple feature branches in flight recently. I would like to > review our project policy regarding how we account for the merging of these > feature branches to master and other release line branches. There has been > some discussion on this topic around HBASE-18095, but I want to bring it to > light outside of that context. Whatever we decide here, we should write up > and include in the book. > > By way of process, my preference is that when we merge a feature branch, we > retain all of the individual commits (one-to-one with Jira sub-tasks). > Mechanically this means something like the following: > (1) squash together all commits that correspond with a single Jira > sub-task, making the history into one commit for one sub-task. > (2) rebase the feature branch onto master; > (3) create a PR from the feature branch into master; > (4) use the "rebase and merge" option when merging the PR; > (5) update the fixVersion of the umbrella and all sub-tasks to the > version of master; > (6) repeat steps 2-5 for each back-port. > > My reason for preferring preservation of sub-commit history is that, in the > event of follow-on addendums and sub-task (something we have a habit of > doing), its easy for release line maintainers to account for which of those > follow-ons have been applied to their branches of interest. If the "squash > and merge" option is chosen, it becomes much more difficult for a release > manager (or indeed, curious historians) to identify exactly which Jira > issues are present in the history. > > My reason for preferring PRs for merging feature branches (and back-ports) > over a developer pushing manually is that it gives the maintainer an > opportunity to benefit from the pre-commit robot, and > back-port-branch-specific discussion to occur in the context of the code > changes proposed. > > There are certainly other ways of going about this. I'm curious what others > think of the above. > > Thanks, > Nick
