I don’t think a PR per JIRA per backport is what we want. It could work of course but has downsides. Email explosion. How do I as committer know what order to apply them in? Confusion as random reviewers see some of the changes in some of the PRs but miss other changes in others.
> On Feb 21, 2020, at 4:13 AM, Wellington Chevreuil > <[email protected]> wrote: > > >> >> >> 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. >> > > How about also add the flexibility to do individual PRs for each jira > sub-task? That would still allow for tracking a commit per Jira. It > wouldn't be as easier for tracking backports, but there may be scenarios > where would make sense to commit individual jira sub-tasks ahead of the > whole, completed feature. > >> Em qua., 19 de fev. de 2020 às 20:05, Andrew Purtell < >> [email protected]> escreveu: >> >> The committer guide in the book says squash merges are always preferred. >> When I was faced with a backport PR I referred to this and opted for >> squash-and-merge rather than rebase-and-merge as consequence. Let’s update >> that guidance with the extra process detail for backports of features >> spanning multiple commits/JIRAs. >> >>>> On Feb 19, 2020, at 8:25 AM, Sean Busbey <[email protected]> wrote: >>> >>> 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 <[email protected]> >> 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 >>
