llvm dev - Dec 2021 - RFC: New Automated Release Workflow (using Issues and Pull Requests)

On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> * On an existing issue or a newly created issue, a user who wants to
> backport
> one or more commits to the release branch adds a comment:
>
> /cherry-pick <commit_sha> <..>
>
Hi Tom,

Would this be *any* user or users with certain permissions in the repo
(like code owners, release managers)?

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.

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.

Because the merge is atomic, and the tests passed on the alternative
branch, the probability of the release branch breaking is lower.

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.

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.

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.

Does that make sense?

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211223/a3c99b57/attachment.html>

On 12/23/21 09:53, Renato Golin wrote:
> On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>     * On an existing issue or a newly created issue, a user who wants to
backport
>     one or more commits to the release branch adds a comment:
> 
>     /cherry-pick <commit_sha> <..>
> 
> 
> Hi Tom,
> 
> Would this be *any* user or users with certain permissions in the repo
(like code owners, release managers)?
> 
Any user can do this.
> 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.
> 
> 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.
> 
This is actually how it works.  The cherry-picked commits get
pushed to a branch called issue<issue#> and the pull request is created
off of that branch.

-Tom
> Because the merge is atomic, and the tests passed on the alternative
branch, the probability of the release branch breaking is lower.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Does that make sense?
> 
> cheers,
> --renato