<div dir="ltr"><div dir="ltr">On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* On an existing issue or a newly created issue, a user who wants to backport<br>
one or more commits to the release branch adds a comment:<br>
<br>
/cherry-pick <commit_sha> <..><br></blockquote><div><br></div><div>Hi Tom,</div><div><br></div><div>Would this be *any* user or users with certain permissions in the repo (like code owners, release managers)?</div><div><br></div><div>Ignoring malicious action, *any* user creating a cherry-pick at any time, may create confusion if two users are trying to pick changes that need multiple (non-sequential) commits each.</div><div><br></div><div>An alternative would be to build a branch off the release branch (ex. "release-x.y.z-$username") and pick the commits on that branch, run the pre-commit tests, and then merge to the release branch if it's all green.</div><div><br></div><div>Because the merge is atomic, and the tests passed on the alternative branch, the probability of the release branch breaking is lower.</div><div><br></div><div>Of course, interaction between the users' branches can still break, and well, further tests that are not present in the pre-commit tests, can also.</div><div><br></div><div>But with atomic merges of cherry-picks in a linear sequence will also make it easier to bisect in case anything goes wrong with the release candidate.</div><div><br></div><div>If only a subset of users can merge, then they'd do one at a time and this problem wouldn't be a big issue and we'd avoid a complicated infrastructure setup.</div><div><br></div><div>Does that make sense?</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>