[lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

[Renato Golin via lldb-dev]

Ah, awesome, thanks!

On Fri, 24 Dec 2021, 03:11 Tom Stellard, <tstellar at redhat.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20211224/81b0546e/attachment.html>