You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Nick Dimiduk <nd...@apache.org> on 2020/02/19 16:08:24 UTC
[DISCUSS] Defining a process for merging and back-porting feature branches
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
Re: [DISCUSS] Defining a process for merging and back-porting feature branches
Posted by Nick Dimiduk <nd...@apache.org>.
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 <
wellington.chevreuil@gmail.com> 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 <
> andrew.purtell@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.chevreuil@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.purtell@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 <bu...@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 <nd...@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
> > >>
> >
>
Re: [DISCUSS] Defining a process for merging and back-porting feature branches
Posted by Wellington Chevreuil <we...@gmail.com>.
>
> 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.purtell@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.chevreuil@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.purtell@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 <bu...@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 <nd...@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
> >>
>
Re: [DISCUSS] Defining a process for merging and back-porting feature branches
Posted by Andrew Purtell <an...@gmail.com>.
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 <we...@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.purtell@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 <bu...@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 <nd...@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
>>
Re: [DISCUSS] Defining a process for merging and back-porting feature branches
Posted by Wellington Chevreuil <we...@gmail.com>.
>
> 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.purtell@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 <bu...@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 <nd...@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
>
Re: [DISCUSS] Defining a process for merging and back-porting feature branches
Posted by Andrew Purtell <an...@gmail.com>.
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 <bu...@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 <nd...@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
Re: [DISCUSS] Defining a process for merging and back-porting feature branches
Posted by Bharath Vissapragada <bh...@apache.org>.
+1. Preserving sub-commit history also lets others "git blame" stuff on a
per commit basis rather than the whole squashed commit.
On Wed, Feb 19, 2020 at 8:25 AM Sean Busbey <bu...@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 <nd...@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
>
Re: [DISCUSS] Defining a process for merging and back-porting feature branches
Posted by Sean Busbey <bu...@apache.org>.
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 <nd...@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