Whatever we write up in our contributors section is ultimately a recommended workflow, not fixed in stone. Until such time as we automate entirely the contribution process, there will always be an element of human discretion involved.
That said, I generally echo Andrew's concern re: alert fatigue. On Fri, Feb 21, 2020 at 9:25 AM Wellington Chevreuil < [email protected]> wrote: > > > > 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. > > > Was not suggesting it to be the norm, but something to keep as an > alternative approach. The commit dependency can be tracked via jira, but > yeah, a bit harder then if all required commits are in same PR. > > Em sex., 21 de fev. de 2020 às 16:55, Andrew Purtell < > [email protected]> escreveu: > > > 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 > > >> > > >
