<div dir="ltr">The first option sounds good to me. I can make a redmine issue to document this workflow.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jan 31, 2017 at 7:30 AM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>+1 to making Pulp3 have all PRs target master and cherry picking backwards when necessary. I won't recap the benefits, but there are many.<br><br></div>If we adopt this, the only thing I think we need with this also do (besides documenting this) is a way to track the cherry picking. There are several options:<br><br>* Use a second/different redmine issue to track the inclusion of the backport into a given release and associate the two somehow. Maybe a custom field called 'cherry picks' could record issue numbers as a comma separated list which would be clickable into a redmine query.<br><br>* Use an associated commit. With this a redmine issue will show the original commits and any cherry picks. We could have a new commit keyword so a commit could contain "cherrypick #1234" which would associate the cherry pick commit with issue 1234. It would not modify the state of the issue so whatever state it's in, e.g. CLOSED - CURRENT RELEASE or MODIFIED would remain as-is.<br><br></div>* Use a custom field to track the cherry picks. This is convenient for release engineering queries, but would not show the actual cherry pick commits themselves.<br><br><br></div><div>+1 the first option because it allows users to request backports as they desire and we can track them very clearly. It also should let the existing release engineering processes work well as-is in terms of making release notes. With that, I also prefer using a custom field to track the redmine issue numbers of the associated cherry pick commits so that for any given issue you can see if cherry picks are requested and then go look at those issues easily for more info.<br><br></div><div>Thank you so much for bringing this up. If consensus is reached we should make a Redmine issue to document this new process for Pulp3.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Jan 30, 2017 at 5:16 PM, Sean Myers <span dir="ltr"><<a href="mailto:sean.myers@redhat.com" target="_blank">sean.myers@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><span>On 01/30/2017 04:55 PM, David Davis wrote:<br>
> I was wondering if it might be worth considering cherrypicking commits to<br>
> release branches instead of merging them forward from release branches. I<br>
> might be a bit biased coming from Katello where we have done this for a<br>
> while. For one thing I noticed that the git history in Pulp is very<br>
> convoluted because of all the merge commits. Here is the git history of<br>
> master in katello (bottom) compared to the git history of master in pulp<br>
> (top):<br>
><br>
> <a href="https://i.imgur.com/PR5vNBZ.png" rel="noreferrer" target="_blank">https://i.imgur.com/PR5vNBZ.pn<wbr>g</a><br>
><br>
> I think cherrypicking commits from master to release branches could also<br>
> simplify our workflow a bit. Right now you have to identify what branch<br>
> needs a hotfix before you open the PR and then you also have to update the<br>
> appropriate branch(es) after merging. I think this presents a barrier to<br>
> entry for community contributors by asking them to open a PR against a<br>
> specific branch if they want to fix a bug instead of just master (which is<br>
> the common paradigm in open source). Instead, with cherrypicking hotfixes,<br>
> we’d only have to worry about updating branches as part of merging—which we<br>
> have to do anyway as part of merging forward commits.<br>
><br>
> There might instances where this workflow doesn’t work as well as merging<br>
> forward commits—namely when there are conflicts on a rebase branch or we<br>
> need to test something specifically against a release—but I think we could<br>
> just handle those one-off cases as they arise.<br>
><br>
> Thoughts?<br>
<br>
</span>We've had similar discussions in the past and, iirc, we're generally in favor<br>
of moving to a cherry-picking model from master to release branches. The (a?)<br>
problem is that the Pulp 2 build system is heavily dependent on the merge<br>
forward logic, so if we did switch to cherry-picking, it would be for Pulp 3.<br>
<br>
That said, I'm +1 for cherry-picking from master to release branches for Pulp<br>
3+, and largely for the reasons you state here. As the current "guy who knows<br>
which branch to open PRs against", it would be great if, when asked what branch<br>
to open PRs against, the answer was always "master".<br>
<br>
<br></div></div>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>