Re: [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,  wrote:

> On 12/23/21 09:53, Renato Golin wrote:
> > On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev <
> llvm-...@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  <..>
> >
> >
> > 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 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
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tom Stellard via lldb-dev]

On 12/23/21 09:53, Renato Golin wrote:

On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev mailto:llvm-...@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  <..>


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 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


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Renato Golin via lldb-dev]

On Fri, 17 Dec 2021 at 21:15, Tom Stellard via llvm-dev <
llvm-...@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  <..>
>

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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tom Stellard via lldb-dev]

On 12/20/21 18:21, Mehdi AMINI wrote:



On Mon, Dec 20, 2021 at 3:24 PM Tom Stellard mailto:tstel...@redhat.com>> wrote:

On 12/20/21 09:16, Tom Stellard wrote:
 > On 12/18/21 15:04, David Blaikie wrote:
 >>
 >>
 >> On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard mailto:tstel...@redhat.com> >> 
wrote:
 >>
 >>     On 12/17/21 16:47, David Blaikie wrote:
 >>  > Sounds pretty good to me - wouldn't mind knowing more about/a 
good summary of the effects of this on project/repo/etc notifications that Mehdi's 
mentioning. (be good to have a write up of the expected impact/options to then discuss - 
from the thread so far I understand some general/high level concerns, but it's not clear 
to me exactly how it plays out)
 >>  >
 >>
 >>     The impact is really going to depend on the person and what 
notification preferences they
 >>     have/want.  If you are already watching the repo with the default 
settings, then you probably
 >>     won't notice much of a difference given the current volume of 
notifications.
 >>
 >>
 >> I think I'm on the default settings - which does currently mean a notification for every issue update, which is a 
lot. Given that llvm-b...@email.llvm.org  > has been re-enabled, sending mail only on issue creation, I & others might opt 
back in to that behavior by disabling the baseline "notify on everything" to "notify only on issues I'm 
mentioned in".
 >>
 >> I guess currently the only email that github is generating is one email 
per issue update. We don't have any pull requests, so there aren't any emails for 
that, yeah?
 >>
 >> So this new strategy might add a few more back-and-forth on each cherrypick 
issue (for those using llvm-bugs & disabling general issue notifications, this will 
not be relevant to them - there won't be more issues created, just more comments on 
existing issues). But there will be some more emails generated related to the pull 
requests themselves, I guess? So each cherrypick goes from 2 emails to llvm-bugs (the 
issue creation and closure) to, how many? 4 (2 for llvm-bugs and I guess at least 2 for 
the pull request - one to make the request and one to close it - maybe a couple more 
status ones along the way?)
 >>
 >
 > I think the number of net new comments on issues will be very minimal or 
none at all.  The
 > automated comments that are created by this process are replacing 
comments that I'm already making
 > manually.
 >
 > So 2+ for pull requests is probably a good estimate.  I still need to 
figure out how many notifications
 > get generated for Actions with the default settings.
 >

I did some research on the notifications and here is what I came up with:

  From what I can tell, notifications for actions are only sent to the
user that initiated the event that led to the actions, so there would
be no global notifications sent for the actions used by this workflow.

There have been 131 bugs marked as release blockers in the llvm-13 cycle,
this includes the 13.0.0 and 13.0.1 release.  In the best case scenario,
this proposal would generate 2 additional notifications per issue
(1 for creating a pull request and 1 for merging it), and 0 net new
issue comments (the automated comments just replace manual comments).

If you assume that no manual comments would be replaced by the automation,
then in the typical use case there would be a maximum of  4 notifications
generated from issues (/cherry-pick comment, cherry-pick failed comment,
/branch comment, /pull-request comment). In addition to the 2 pull
request notifications.

Based on this, my estimate is that this proposal will produce between
(2 * 131) = 262 and (6 * 131) = 786 net new notifications every 6 months.
Or between 1.46 and 4.367 net new notifications per day.

For comparison, on Fri Dec 17, I received 115 email notifications from
the llvm/llvm-project repo.

The pull request emails should be easy for people to filter out of their
inboxes with a rule.  Pull request emails would have llvm/llvm-project in
the To: field and have '(PR #123456)' at the end of the Subject: field
(where 123456 is pull request number).


Actually it isn't enough: there isn't a way to filter on regexes in gmail for 
example. Until GitHub allows the use of some different alias / target / 
cc-email or similar mechanisms, it'll be hard to filter GitHub emails 
accurately / reliably.



Matching on '(PR #' might be enough if people wanted to try it.


There are also the confusing aspects of starting to use pull-requests in the 
monorepo, but only for some branches, which seem undesirable to me.



Yeah, this is one of the downsides of using pull-requests in the 

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

[Philip Reames via lldb-dev]

On 12/20/21 3:24 PM, Tom Stellard via llvm-dev wrote:

On 12/20/21 09:16, Tom Stellard wrote:

On 12/18/21 15:04, David Blaikie wrote:



On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard > wrote:


    On 12/17/21 16:47, David Blaikie wrote:
 > Sounds pretty good to me - wouldn't mind knowing more about/a 
good summary of the effects of this on project/repo/etc 
notifications that Mehdi's mentioning. (be good to have a write up 
of the expected impact/options to then discuss - from the thread so 
far I understand some general/high level concerns, but it's not 
clear to me exactly how it plays out)

 >

    The impact is really going to depend on the person and what 
notification preferences they
    have/want.  If you are already watching the repo with the 
default settings, then you probably
    won't notice much of a difference given the current volume of 
notifications.



I think I'm on the default settings - which does currently mean a 
notification for every issue update, which is a lot. Given that 
llvm-b...@email.llvm.org  has been 
re-enabled, sending mail only on issue creation, I & others might 
opt back in to that behavior by disabling the baseline "notify on 
everything" to "notify only on issues I'm mentioned in".


I guess currently the only email that github is generating is one 
email per issue update. We don't have any pull requests, so there 
aren't any emails for that, yeah?


So this new strategy might add a few more back-and-forth on each 
cherrypick issue (for those using llvm-bugs & disabling general 
issue notifications, this will not be relevant to them - there won't 
be more issues created, just more comments on existing issues). But 
there will be some more emails generated related to the pull 
requests themselves, I guess? So each cherrypick goes from 2 emails 
to llvm-bugs (the issue creation and closure) to, how many? 4 (2 for 
llvm-bugs and I guess at least 2 for the pull request - one to make 
the request and one to close it - maybe a couple more status ones 
along the way?)




I think the number of net new comments on issues will be very minimal 
or none at all.  The
automated comments that are created by this process are replacing 
comments that I'm already making

manually.

So 2+ for pull requests is probably a good estimate.  I still need to 
figure out how many notifications

get generated for Actions with the default settings.



I did some research on the notifications and here is what I came up with:

From what I can tell, notifications for actions are only sent to the
user that initiated the event that led to the actions, so there would
be no global notifications sent for the actions used by this workflow.

There have been 131 bugs marked as release blockers in the llvm-13 cycle,
this includes the 13.0.0 and 13.0.1 release.  In the best case scenario,
this proposal would generate 2 additional notifications per issue
(1 for creating a pull request and 1 for merging it), and 0 net new
issue comments (the automated comments just replace manual comments).

If you assume that no manual comments would be replaced by the 
automation,

then in the typical use case there would be a maximum of  4 notifications
generated from issues (/cherry-pick comment, cherry-pick failed comment,
/branch comment, /pull-request comment). In addition to the 2 pull
request notifications.

Based on this, my estimate is that this proposal will produce between
(2 * 131) = 262 and (6 * 131) = 786 net new notifications every 6 months.
Or between 1.46 and 4.367 net new notifications per day.

For comparison, on Fri Dec 17, I received 115 email notifications from
the llvm/llvm-project repo.

The pull request emails should be easy for people to filter out of their
inboxes with a rule.  Pull request emails would have llvm/llvm-project in
the To: field and have '(PR #123456)' at the end of the Subject: field
(where 123456 is pull request number).

For people who filter out the pull request notifications, they would 
have between

0 and 2.9 net new notifications per day.


This seems both fairly minimal, and well justified to me.

Philip



- Tom



--Tom

    If people want to give their notification preferences, I can try 
to look at how

    this change will impact specific configurations.


@Mehdi AMINI  - are there particular 
scenarios you have in mind that'd be good to work through?



    -Tom


 > On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via llvm-dev 
mailto:llvm-...@lists.llvm.org> 
>> 
wrote:

 >
 >     Hi,
 >
 >     Here is a proposal for a new automated workflow for 
managing parts of the release
 >     process.  I've been experimenting with this over the past 
few releases and
 >     now that we have migrated to GitHub issues, it would be 
possible for us to

 >     implement this in the main 

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

[Tom Stellard via lldb-dev]

On 12/20/21 09:16, Tom Stellard wrote:

On 12/18/21 15:04, David Blaikie wrote:



On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard mailto:tstel...@redhat.com>> wrote:

    On 12/17/21 16:47, David Blaikie wrote:
 > Sounds pretty good to me - wouldn't mind knowing more about/a good 
summary of the effects of this on project/repo/etc notifications that Mehdi's 
mentioning. (be good to have a write up of the expected impact/options to then 
discuss - from the thread so far I understand some general/high level concerns, 
but it's not clear to me exactly how it plays out)
 >

    The impact is really going to depend on the person and what notification 
preferences they
    have/want.  If you are already watching the repo with the default settings, 
then you probably
    won't notice much of a difference given the current volume of notifications.


I think I'm on the default settings - which does currently mean a notification for every issue update, which 
is a lot. Given that llvm-b...@email.llvm.org  has been re-enabled, 
sending mail only on issue creation, I & others might opt back in to that behavior by disabling the 
baseline "notify on everything" to "notify only on issues I'm mentioned in".

I guess currently the only email that github is generating is one email per 
issue update. We don't have any pull requests, so there aren't any emails for 
that, yeah?

So this new strategy might add a few more back-and-forth on each cherrypick issue 
(for those using llvm-bugs & disabling general issue notifications, this will 
not be relevant to them - there won't be more issues created, just more comments on 
existing issues). But there will be some more emails generated related to the pull 
requests themselves, I guess? So each cherrypick goes from 2 emails to llvm-bugs 
(the issue creation and closure) to, how many? 4 (2 for llvm-bugs and I guess at 
least 2 for the pull request - one to make the request and one to close it - maybe 
a couple more status ones along the way?)



I think the number of net new comments on issues will be very minimal or none 
at all.  The
automated comments that are created by this process are replacing comments that 
I'm already making
manually.

So 2+ for pull requests is probably a good estimate.  I still need to figure 
out how many notifications
get generated for Actions with the default settings.



I did some research on the notifications and here is what I came up with:

From what I can tell, notifications for actions are only sent to the
user that initiated the event that led to the actions, so there would
be no global notifications sent for the actions used by this workflow.

There have been 131 bugs marked as release blockers in the llvm-13 cycle,
this includes the 13.0.0 and 13.0.1 release.  In the best case scenario,
this proposal would generate 2 additional notifications per issue
(1 for creating a pull request and 1 for merging it), and 0 net new
issue comments (the automated comments just replace manual comments).

If you assume that no manual comments would be replaced by the automation,
then in the typical use case there would be a maximum of  4 notifications
generated from issues (/cherry-pick comment, cherry-pick failed comment,
/branch comment, /pull-request comment). In addition to the 2 pull
request notifications.

Based on this, my estimate is that this proposal will produce between
(2 * 131) = 262 and (6 * 131) = 786 net new notifications every 6 months.
Or between 1.46 and 4.367 net new notifications per day.

For comparison, on Fri Dec 17, I received 115 email notifications from
the llvm/llvm-project repo.

The pull request emails should be easy for people to filter out of their
inboxes with a rule.  Pull request emails would have llvm/llvm-project in
the To: field and have '(PR #123456)' at the end of the Subject: field
(where 123456 is pull request number).

For people who filter out the pull request notifications, they would have 
between
0 and 2.9 net new notifications per day.

- Tom



--Tom


    If people want to give their notification preferences, I can try to look at 
how
    this change will impact specific configurations.


@Mehdi AMINI  - are there particular scenarios you 
have in mind that'd be good to work through?


    -Tom


 > On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org> >> wrote:
 >
 >     Hi,
 >
 >     Here is a proposal for a new automated workflow for managing parts 
of the release
 >     process.  I've been experimenting with this over the past few 
releases and
 >     now that we have migrated to GitHub issues, it would be possible for 
us to
 >     implement this in the main repo.
 >
 >     The workflow is pretty straight forward, but it does use pull 
requests.  My
 >     idea is to enable pull requests for 

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

[Tom Stellard via lldb-dev]

On 12/18/21 15:04, David Blaikie wrote:



On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard mailto:tstel...@redhat.com>> wrote:

On 12/17/21 16:47, David Blaikie wrote:
 > Sounds pretty good to me - wouldn't mind knowing more about/a good 
summary of the effects of this on project/repo/etc notifications that Mehdi's 
mentioning. (be good to have a write up of the expected impact/options to then 
discuss - from the thread so far I understand some general/high level concerns, 
but it's not clear to me exactly how it plays out)
 >

The impact is really going to depend on the person and what notification 
preferences they
have/want.  If you are already watching the repo with the default settings, 
then you probably
won't notice much of a difference given the current volume of notifications.


I think I'm on the default settings - which does currently mean a notification for every issue update, which 
is a lot. Given that llvm-b...@email.llvm.org  has been re-enabled, 
sending mail only on issue creation, I & others might opt back in to that behavior by disabling the 
baseline "notify on everything" to "notify only on issues I'm mentioned in".

I guess currently the only email that github is generating is one email per 
issue update. We don't have any pull requests, so there aren't any emails for 
that, yeah?

So this new strategy might add a few more back-and-forth on each cherrypick issue 
(for those using llvm-bugs & disabling general issue notifications, this will 
not be relevant to them - there won't be more issues created, just more comments on 
existing issues). But there will be some more emails generated related to the pull 
requests themselves, I guess? So each cherrypick goes from 2 emails to llvm-bugs 
(the issue creation and closure) to, how many? 4 (2 for llvm-bugs and I guess at 
least 2 for the pull request - one to make the request and one to close it - maybe 
a couple more status ones along the way?)



I think the number of net new comments on issues will be very minimal or none 
at all.  The
automated comments that are created by this process are replacing comments that 
I'm already making
manually.

So 2+ for pull requests is probably a good estimate.  I still need to figure 
out how many notifications
get generated for Actions with the default settings.

--Tom
  


If people want to give their notification preferences, I can try to look at 
how
this change will impact specific configurations.


@Mehdi AMINI  - are there particular scenarios you 
have in mind that'd be good to work through?


-Tom


 > On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org> >> wrote:
 >
 >     Hi,
 >
 >     Here is a proposal for a new automated workflow for managing parts 
of the release
 >     process.  I've been experimenting with this over the past few 
releases and
 >     now that we have migrated to GitHub issues, it would be possible for 
us to
 >     implement this in the main repo.
 >
 >     The workflow is pretty straight forward, but it does use pull 
requests.  My
 >     idea is to enable pull requests for only this automated workflow and 
not
 >     for general development (i.e. We would still use Phabricator for 
code review).
 >     Let me know what you think about this:
 >
 >
 >     # Workflow
 >
 >     * 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  <..>
 >
 >     * This starts a GitHub Action job that attempts to cherry-pick the 
commit(s)
 >     to the current release branch.
 >
 >     * If the commit(s) can be cherry-picked cleanly, then the GitHub 
Action:
 >           * Pushes the result of the cherry-pick to a branch in the
 >             llvmbot/llvm-project repo called issue, where n is the 
number of the
 >             GitHub Issue that launched the Action.
 >
 >           * Adds this comment on the issue: /branch 
llvmbot/llvm-project/issue
 >
 >           * Creates a pull request from llvmbot/llvm-project/issue to
 >             llvm/llvm-project/release/XX.x
 >
 >           * Adds a comment on the issue: /pull-request #
 >             where n is the number of the pull request.
 >
 >     * If the commit(s) can't be cherry-picked cleanly, then the GitHub 
Action job adds
 >     the release:cherry-pick-failed label to the issue and adds a comment:
 >     "Failed to cherry-pick  <..>" along with a link to the 
failing
 >     Action.
 >
 >     * If a user has manually cherry-picked the fixes, resolved the 
conflicts, and
 >     pushed the result to a branch on github, they can automatically 
create 

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

[David Blaikie via lldb-dev]

On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard  wrote:

> On 12/17/21 16:47, David Blaikie wrote:
> > Sounds pretty good to me - wouldn't mind knowing more about/a good
> summary of the effects of this on project/repo/etc notifications that
> Mehdi's mentioning. (be good to have a write up of the expected
> impact/options to then discuss - from the thread so far I understand some
> general/high level concerns, but it's not clear to me exactly how it plays
> out)
> >
>
> The impact is really going to depend on the person and what notification
> preferences they
> have/want.  If you are already watching the repo with the default
> settings, then you probably
> won't notice much of a difference given the current volume of
> notifications.
>

I think I'm on the default settings - which does currently mean a
notification for every issue update, which is a lot. Given that
llvm-b...@email.llvm.org has been re-enabled, sending mail only on issue
creation, I & others might opt back in to that behavior by disabling the
baseline "notify on everything" to "notify only on issues I'm mentioned in".

I guess currently the only email that github is generating is one email per
issue update. We don't have any pull requests, so there aren't any emails
for that, yeah?

So this new strategy might add a few more back-and-forth on each
cherrypick issue (for those using llvm-bugs & disabling general issue
notifications, this will not be relevant to them - there won't be more
issues created, just more comments on existing issues). But there will be
some more emails generated related to the pull requests themselves, I
guess? So each cherrypick goes from 2 emails to llvm-bugs (the issue
creation and closure) to, how many? 4 (2 for llvm-bugs and I guess at least
2 for the pull request - one to make the request and one to close it -
maybe a couple more status ones along the way?)


> If people want to give their notification preferences, I can try to look
> at how
> this change will impact specific configurations.
>

@Mehdi AMINI  - are there particular scenarios you
have in mind that'd be good to work through?


>
> -Tom
>
>
> > On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org > wrote:
> >
> > Hi,
> >
> > Here is a proposal for a new automated workflow for managing parts
> of the release
> > process.  I've been experimenting with this over the past few
> releases and
> > now that we have migrated to GitHub issues, it would be possible for
> us to
> > implement this in the main repo.
> >
> > The workflow is pretty straight forward, but it does use pull
> requests.  My
> > idea is to enable pull requests for only this automated workflow and
> not
> > for general development (i.e. We would still use Phabricator for
> code review).
> > Let me know what you think about this:
> >
> >
> > # Workflow
> >
> > * 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  <..>
> >
> > * This starts a GitHub Action job that attempts to cherry-pick the
> commit(s)
> > to the current release branch.
> >
> > * If the commit(s) can be cherry-picked cleanly, then the GitHub
> Action:
> >   * Pushes the result of the cherry-pick to a branch in the
> > llvmbot/llvm-project repo called issue, where n is the
> number of the
> > GitHub Issue that launched the Action.
> >
> >   * Adds this comment on the issue: /branch
> llvmbot/llvm-project/issue
> >
> >   * Creates a pull request from llvmbot/llvm-project/issue to
> > llvm/llvm-project/release/XX.x
> >
> >   * Adds a comment on the issue: /pull-request #
> > where n is the number of the pull request.
> >
> > * If the commit(s) can't be cherry-picked cleanly, then the GitHub
> Action job adds
> > the release:cherry-pick-failed label to the issue and adds a comment:
> > "Failed to cherry-pick  <..>" along with a link to the
> failing
> > Action.
> >
> > * If a user has manually cherry-picked the fixes, resolved the
> conflicts, and
> > pushed the result to a branch on github, they can automatically
> create a pull
> > request by adding this comment to an issue: /branch
> //
> >
> > * Once a pull request has been created, this launches more GitHub
> Actions
> > to run pre-commit tests.
> >
> > * Once the tests complete successfully and the changes have been
> approved
> > by the release manager, the pull request can me merged into the
> release branch.
> >
> > * After the pull request is merged, a GitHub Action automatically
> closes the
> > associated issue.
> >
> > Some Examples:
> >
> > Cherry-pick success:
> https://github.com/tstellar/llvm-project/issues/729
> > Cherry-pick <
> 

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

[Tom Stellard via lldb-dev]

On 12/17/21 16:47, David Blaikie wrote:

Sounds pretty good to me - wouldn't mind knowing more about/a good summary of 
the effects of this on project/repo/etc notifications that Mehdi's mentioning. 
(be good to have a write up of the expected impact/options to then discuss - 
from the thread so far I understand some general/high level concerns, but it's 
not clear to me exactly how it plays out)



The impact is really going to depend on the person and what notification 
preferences they
have/want.  If you are already watching the repo with the default settings, 
then you probably
won't notice much of a difference given the current volume of notifications.

If people want to give their notification preferences, I can try to look at how
this change will impact specific configurations.

-Tom



On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via llvm-dev mailto:llvm-...@lists.llvm.org>> wrote:

Hi,

Here is a proposal for a new automated workflow for managing parts of the 
release
process.  I've been experimenting with this over the past few releases and
now that we have migrated to GitHub issues, it would be possible for us to
implement this in the main repo.

The workflow is pretty straight forward, but it does use pull requests.  My
idea is to enable pull requests for only this automated workflow and not
for general development (i.e. We would still use Phabricator for code 
review).
Let me know what you think about this:


# Workflow

* 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  <..>

* This starts a GitHub Action job that attempts to cherry-pick the commit(s)
to the current release branch.

* If the commit(s) can be cherry-picked cleanly, then the GitHub Action:
      * Pushes the result of the cherry-pick to a branch in the
        llvmbot/llvm-project repo called issue, where n is the number of 
the
        GitHub Issue that launched the Action.

      * Adds this comment on the issue: /branch 
llvmbot/llvm-project/issue

      * Creates a pull request from llvmbot/llvm-project/issue to
        llvm/llvm-project/release/XX.x

      * Adds a comment on the issue: /pull-request #
        where n is the number of the pull request.

* If the commit(s) can't be cherry-picked cleanly, then the GitHub Action 
job adds
the release:cherry-pick-failed label to the issue and adds a comment:
"Failed to cherry-pick  <..>" along with a link to the failing
Action.

* If a user has manually cherry-picked the fixes, resolved the conflicts, 
and
pushed the result to a branch on github, they can automatically create a 
pull
request by adding this comment to an issue: /branch //

* Once a pull request has been created, this launches more GitHub Actions
to run pre-commit tests.

* Once the tests complete successfully and the changes have been approved
by the release manager, the pull request can me merged into the release 
branch.

* After the pull request is merged, a GitHub Action automatically closes the
associated issue.

Some Examples:

Cherry-pick success: https://github.com/tstellar/llvm-project/issues/729
Cherry-pick  
failure: https://github.com/tstellar/llvm-project/issues/730 

Manual Branch comment: https://github.com/tstellar/llvm-project/issues/710 



# Motivation

Why do this?  The goal is to make the release process more efficient and 
transparent.
With this new workflow, users can get automatic and immediate feedback when 
a commit
they want backported doesn't apply cleanly or introduces some test 
failures.  With
the current process, these kinds of issues are communicated by the release 
manager,
and it can be days or even weeks before a problem is discovered and 
communicated back
to the users.

Another advantage of this workflow is it introduces pre-commit CI to the 
release branch,
which is important for the stability of the branch and the releases, but 
also gives
the project an opportunity to experiment with new CI workflows in a way that
does not disrupt development on the main branch.

# Implementation

If this proposal is accepted, I would plan to implement this for the LLVM 
14 release cycle based
on the following proof of concept that I have been testing for the last few 
releases:


https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml
 

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

[David Blaikie via lldb-dev]

Sounds pretty good to me - wouldn't mind knowing more about/a good summary
of the effects of this on project/repo/etc notifications that Mehdi's
mentioning. (be good to have a write up of the expected impact/options to
then discuss - from the thread so far I understand some general/high level
concerns, but it's not clear to me exactly how it plays out)

On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hi,
>
> Here is a proposal for a new automated workflow for managing parts of the
> release
> process.  I've been experimenting with this over the past few releases and
> now that we have migrated to GitHub issues, it would be possible for us to
> implement this in the main repo.
>
> The workflow is pretty straight forward, but it does use pull requests.  My
> idea is to enable pull requests for only this automated workflow and not
> for general development (i.e. We would still use Phabricator for code
> review).
> Let me know what you think about this:
>
>
> # Workflow
>
> * 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  <..>
>
> * This starts a GitHub Action job that attempts to cherry-pick the
> commit(s)
> to the current release branch.
>
> * If the commit(s) can be cherry-picked cleanly, then the GitHub Action:
>  * Pushes the result of the cherry-pick to a branch in the
>llvmbot/llvm-project repo called issue, where n is the number of
> the
>GitHub Issue that launched the Action.
>
>  * Adds this comment on the issue: /branch
> llvmbot/llvm-project/issue
>
>  * Creates a pull request from llvmbot/llvm-project/issue to
>llvm/llvm-project/release/XX.x
>
>  * Adds a comment on the issue: /pull-request #
>where n is the number of the pull request.
>
> * If the commit(s) can't be cherry-picked cleanly, then the GitHub Action
> job adds
> the release:cherry-pick-failed label to the issue and adds a comment:
> "Failed to cherry-pick  <..>" along with a link to the failing
> Action.
>
> * If a user has manually cherry-picked the fixes, resolved the conflicts,
> and
> pushed the result to a branch on github, they can automatically create a
> pull
> request by adding this comment to an issue: /branch //
>
> * Once a pull request has been created, this launches more GitHub Actions
> to run pre-commit tests.
>
> * Once the tests complete successfully and the changes have been approved
> by the release manager, the pull request can me merged into the release
> branch.
>
> * After the pull request is merged, a GitHub Action automatically closes
> the
> associated issue.
>
> Some Examples:
>
> Cherry-pick success: https://github.com/tstellar/llvm-project/issues/729
> Cherry-pick
>  failure:
> https://github.com/tstellar/llvm-project/issues/730
> Manual Branch comment: https://github.com/tstellar/llvm-project/issues/710
>
>
> # Motivation
>
> Why do this?  The goal is to make the release process more efficient and
> transparent.
> With this new workflow, users can get automatic and immediate feedback
> when a commit
> they want backported doesn't apply cleanly or introduces some test
> failures.  With
> the current process, these kinds of issues are communicated by the release
> manager,
> and it can be days or even weeks before a problem is discovered and
> communicated back
> to the users.
>
> Another advantage of this workflow is it introduces pre-commit CI to the
> release branch,
> which is important for the stability of the branch and the releases, but
> also gives
> the project an opportunity to experiment with new CI workflows in a way
> that
> does not disrupt development on the main branch.
>
> # Implementation
>
> If this proposal is accepted, I would plan to implement this for the LLVM
> 14 release cycle based
> on the following proof of concept that I have been testing for the last
> few releases:
>
>
> https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml
>
> https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml
>
> https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml
>
> Thanks,
> Tom
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev