> > 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 < andrew.purt...@gmail.com> 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 < > wellington.chevre...@gmail.com> 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 < > >> andrew.purt...@gmail.com> 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 <bus...@apache.org> 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 <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 > >> >
