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
