<div dir="ltr">I was wondering if it might be worth considering cherrypicking commits to release branches instead of merging them forward from release branches. I might be a bit biased coming from Katello where we have done this for a while. For one thing I noticed that the git history in Pulp is very convoluted because of all the merge commits. Here is the git history of master in katello (bottom) compared to the git history of master in pulp (top):<div><br></div><div><a href="https://i.imgur.com/PR5vNBZ.png">https://i.imgur.com/PR5vNBZ.png</a></div><div><br></div><div>I think cherrypicking commits from master to release branches could also simplify our workflow a bit. Right now you have to identify what branch needs a hotfix before you open the PR and then you also have to update the appropriate branch(es) after merging. I think this presents a barrier to entry for community contributors by asking them to open a PR against a specific branch if they want to fix a bug instead of just master (which is the common paradigm in open source). Instead, with cherrypicking hotfixes, we’d only have to worry about updating branches as part of merging—which we have to do anyway as part of merging forward commits.</div><div><br></div><div>There might instances where this workflow doesn’t work as well as merging forward commits—namely when there are conflicts on a rebase branch or we need to test something specifically against a release—but I think we could just handle those one-off cases as they arise.</div><div><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>Thoughts?</div><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
</div></div>