[prev in list] [next in list] [prev in thread] [next in thread]
List: llvm-dev
Subject: Re: [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)
From: Renato Golin via llvm-dev <llvm-dev () lists ! llvm ! org>
Date: 2021-12-24 11:49:30
Message-ID: CAPH-gfcT-rrKra+ER0gEW_zPpyUaiM=mY35n-iGX3sgL3Wxo4Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Ah, awesome, thanks!
On Fri, 24 Dec 2021, 03:11 Tom Stellard, <tstellar@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@lists.llvm.org <mailto:llvm-dev@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
>
>
[Attachment #5 (text/html)]
<div dir="auto">Ah, awesome, thanks! </div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Fri, 24 Dec 2021, 03:11 Tom Stellard, <<a \
href="mailto:tstellar@redhat.com">tstellar@redhat.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/23/21 09:53, Renato Golin \
wrote:<br> > On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev <<a \
href="mailto:llvm-dev@lists.llvm.org" target="_blank" \
rel="noreferrer">llvm-dev@lists.llvm.org</a> <mailto:<a \
href="mailto:llvm-dev@lists.llvm.org" target="_blank" \
rel="noreferrer">llvm-dev@lists.llvm.org</a>>> wrote:<br> > <br>
> * 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>
> <br>
> <br>
> Hi Tom,<br>
> <br>
> Would this be *any* user or users with certain permissions in the repo (like \
code owners, release managers)?<br> > <br>
<br>
Any user can do this.<br>
<br>
> 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.<br> > <br>
> 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.<br> \
> <br> <br>
This is actually how it works. The cherry-picked commits get<br>
pushed to a branch called issue<issue#> and the pull request is created<br>
off of that branch.<br>
<br>
-Tom<br>
<br>
> Because the merge is atomic, and the tests passed on the alternative branch, the \
probability of the release branch breaking is lower.<br> > <br>
> 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.<br> > \
<br> > 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.<br> > \
<br> > 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.<br> > <br>
> Does that make sense?<br>
> <br>
> cheers,<br>
> --renato<br>
<br>
</blockquote></div>
[Attachment #6 (text/plain)]
_______________________________________________
LLVM Developers mailing list
llvm-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic