<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 20, 2021 at 9:18 PM Tom Stellard <<a href="mailto:tstellar@redhat.com">tstellar@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 12/20/21 18:21, Mehdi AMINI wrote:<br>
> <br>
> <br>
> On Mon, Dec 20, 2021 at 3:24 PM Tom Stellard <<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>>> wrote:<br>
> <br>
> On 12/20/21 09:16, Tom Stellard wrote:<br>
> > On 12/18/21 15:04, David Blaikie wrote:<br>
> >><br>
> >><br>
> >> On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard <<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a> <mailto:<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>>>> wrote:<br>
> >><br>
> >> On 12/17/21 16:47, David Blaikie wrote:<br>
> >> > 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)<br>
> >> ><br>
> >><br>
> >> The impact is really going to depend on the person and what notification preferences they<br>
> >> have/want. If you are already watching the repo with the default settings, then you probably<br>
> >> won't notice much of a difference given the current volume of notifications.<br>
> >><br>
> >><br>
> >> I think I'm on the default settings - which does currently mean a notification for every issue update, which is a lot. Given that <a href="mailto:llvm-bugs@email.llvm.org" target="_blank">llvm-bugs@email.llvm.org</a> <mailto:<a href="mailto:llvm-bugs@email.llvm.org" target="_blank">llvm-bugs@email.llvm.org</a>> <mailto:<a href="mailto:llvm-bugs@email.llvm.org" target="_blank">llvm-bugs@email.llvm.org</a> <mailto:<a href="mailto:llvm-bugs@email.llvm.org" target="_blank">llvm-bugs@email.llvm.org</a>>> 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".<br>
> >><br>
> >> 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?<br>
> >><br>
> >> 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?)<br>
> >><br>
> ><br>
> > I think the number of net new comments on issues will be very minimal or none at all. The<br>
> > automated comments that are created by this process are replacing comments that I'm already making<br>
> > manually.<br>
> ><br>
> > So 2+ for pull requests is probably a good estimate. I still need to figure out how many notifications<br>
> > get generated for Actions with the default settings.<br>
> ><br>
> <br>
> I did some research on the notifications and here is what I came up with:<br>
> <br>
> From what I can tell, notifications for actions are only sent to the<br>
> user that initiated the event that led to the actions, so there would<br>
> be no global notifications sent for the actions used by this workflow.<br>
> <br>
> There have been 131 bugs marked as release blockers in the llvm-13 cycle,<br>
> this includes the 13.0.0 and 13.0.1 release. In the best case scenario,<br>
> this proposal would generate 2 additional notifications per issue<br>
> (1 for creating a pull request and 1 for merging it), and 0 net new<br>
> issue comments (the automated comments just replace manual comments).<br>
> <br>
> If you assume that no manual comments would be replaced by the automation,<br>
> then in the typical use case there would be a maximum of 4 notifications<br>
> generated from issues (/cherry-pick comment, cherry-pick failed comment,<br>
> /branch comment, /pull-request comment). In addition to the 2 pull<br>
> request notifications.<br>
> <br>
> Based on this, my estimate is that this proposal will produce between<br>
> (2 * 131) = 262 and (6 * 131) = 786 net new notifications every 6 months.<br>
> Or between 1.46 and 4.367 net new notifications per day.<br>
> <br>
> For comparison, on Fri Dec 17, I received 115 email notifications from<br>
> the llvm/llvm-project repo.<br>
> <br>
> The pull request emails should be easy for people to filter out of their<br>
> inboxes with a rule. Pull request emails would have llvm/llvm-project in<br>
> the To: field and have '(PR #123456)' at the end of the Subject: field<br>
> (where 123456 is pull request number).<br>
> <br>
> <br>
> 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.<br>
> <br>
<br>
Matching on '(PR #' might be enough if people wanted to try it.<br></blockquote><div><br></div><div>Gmail ignores punctuation unfortunately, this is partly why the current situation with issue notification is also quite messy and hard to manage on the client side.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> 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.<br>
> <br>
<br>
Yeah, this is one of the downsides of using pull-requests in the monorepo.<br>
<br>
> You didn't really elaborate about why not use a repo dedicated for managing your actions and everything else? Seems like a conservative choice that would provide isolation while still having the feature you desired, wouldn't it?<br>
> <br>
<br>
One advantage of using the monorepo for the pull-requests is that it simplifies<br>
the workflow. With pull-requests in a secondary repo, there would have to be an<br>
additional step to sync from the secondary repo into the monorepo after the<br>
pull-request was merged. You would also need to setup a sync from the monorepo<br>
to the secondary repo in case something was pushed directly to the monorepo.<br>
<br>
Using the monorepo for pull requests also makes it easier to enable self-hosted<br>
action runners, because you would only need to set them up for one repo and<br>
wouldn't have to figure out how to coordinate their usage between two.<br>
And if we were able to get GitHub to give us access to some of their more powerful<br>
runners, it might be more difficult to enable them for both repos.<br></blockquote><div><br></div><div>I would hope that we can get access to this for the entire organization and just for one repo.</div><div><br></div><div>-- </div><div>Mehdi</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
- Tom<br>
<br>
> <br>
> <br>
> For people who filter out the pull request notifications, they would have between<br>
> 0 and 2.9 net new notifications per day.<br>
> <br>
> - Tom<br>
> <br>
> <br>
> > --Tom<br>
> ><br>
> >> If people want to give their notification preferences, I can try to look at how<br>
> >> this change will impact specific configurations.<br>
> >><br>
> >><br>
> >> @Mehdi AMINI <mailto:<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a> <mailto:<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>>> - are there particular scenarios you have in mind that'd be good to work through?<br>
> >><br>
> >><br>
> >> -Tom<br>
> >><br>
> >><br>
> >> > On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>>> wrote:<br>
> >> ><br>
> >> > Hi,<br>
> >> ><br>
> >> > Here is a proposal for a new automated workflow for managing parts of the release<br>
> >> > process. I've been experimenting with this over the past few releases and<br>
> >> > now that we have migrated to GitHub issues, it would be possible for us to<br>
> >> > implement this in the main repo.<br>
> >> ><br>
> >> > The workflow is pretty straight forward, but it does use pull requests. My<br>
> >> > idea is to enable pull requests for only this automated workflow and not<br>
> >> > for general development (i.e. We would still use Phabricator for code review).<br>
> >> > Let me know what you think about this:<br>
> >> ><br>
> >> ><br>
> >> > # Workflow<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>
> >> > * This starts a GitHub Action job that attempts to cherry-pick the commit(s)<br>
> >> > to the current release branch.<br>
> >> ><br>
> >> > * If the commit(s) can be cherry-picked cleanly, then the GitHub Action:<br>
> >> > * Pushes the result of the cherry-pick to a branch in the<br>
> >> > llvmbot/llvm-project repo called issue<n>, where n is the number of the<br>
> >> > GitHub Issue that launched the Action.<br>
> >> ><br>
> >> > * Adds this comment on the issue: /branch llvmbot/llvm-project/issue<n><br>
> >> ><br>
> >> > * Creates a pull request from llvmbot/llvm-project/issue<n> to<br>
> >> > llvm/llvm-project/release/XX.x<br>
> >> ><br>
> >> > * Adds a comment on the issue: /pull-request #<n><br>
> >> > where n is the number of the pull request.<br>
> >> ><br>
> >> > * If the commit(s) can't be cherry-picked cleanly, then the GitHub Action job adds<br>
> >> > the release:cherry-pick-failed label to the issue and adds a comment:<br>
> >> > "Failed to cherry-pick <commit_sha> <..>" along with a link to the failing<br>
> >> > Action.<br>
> >> ><br>
> >> > * If a user has manually cherry-picked the fixes, resolved the conflicts, and<br>
> >> > pushed the result to a branch on github, they can automatically create a pull<br>
> >> > request by adding this comment to an issue: /branch <user>/<repo>/<branch><br>
> >> ><br>
> >> > * Once a pull request has been created, this launches more GitHub Actions<br>
> >> > to run pre-commit tests.<br>
> >> ><br>
> >> > * Once the tests complete successfully and the changes have been approved<br>
> >> > by the release manager, the pull request can me merged into the release branch.<br>
> >> ><br>
> >> > * After the pull request is merged, a GitHub Action automatically closes the<br>
> >> > associated issue.<br>
> >> ><br>
> >> > Some Examples:<br>
> >> ><br>
> >> > Cherry-pick success: <a href="https://github.com/tstellar/llvm-project/issues/729" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729</a> <<a href="https://github.com/tstellar/llvm-project/issues/729" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729</a>> <<a href="https://github.com/tstellar/llvm-project/issues/729" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729</a> <<a href="https://github.com/tstellar/llvm-project/issues/729" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729</a>>><br>
> >> > Cherry-pick <<a href="https://github.com/tstellar/llvm-project/issues/729Cherry-pick" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729Cherry-pick</a> <<a href="https://github.com/tstellar/llvm-project/issues/729Cherry-pick" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729Cherry-pick</a>> <<a href="https://github.com/tstellar/llvm-project/issues/729Cherry-pick" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729Cherry-pick</a> <<a href="https://github.com/tstellar/llvm-project/issues/729Cherry-pick" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/729Cherry-pick</a>>>> failure: <a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a> <<a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a>> <<a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a> <<a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a>>> <<a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a> <<a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a>> <<a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a> <<a href="https://github.com/tstellar/llvm-project/issues/730" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/730</a>>>><br>
> >> > Manual Branch comment: <a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a> <<a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a>> <<a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a> <<a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a>>> <<a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a> <<a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a>> <<a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a> <<a href="https://github.com/tstellar/llvm-project/issues/710" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/issues/710</a>>>><br>
> >> ><br>
> >> ><br>
> >> > # Motivation<br>
> >> ><br>
> >> > Why do this? The goal is to make the release process more efficient and transparent.<br>
> >> > With this new workflow, users can get automatic and immediate feedback when a commit<br>
> >> > they want backported doesn't apply cleanly or introduces some test failures. With<br>
> >> > the current process, these kinds of issues are communicated by the release manager,<br>
> >> > and it can be days or even weeks before a problem is discovered and communicated back<br>
> >> > to the users.<br>
> >> ><br>
> >> > Another advantage of this workflow is it introduces pre-commit CI to the release branch,<br>
> >> > which is important for the stability of the branch and the releases, but also gives<br>
> >> > the project an opportunity to experiment with new CI workflows in a way that<br>
> >> > does not disrupt development on the main branch.<br>
> >> ><br>
> >> > # Implementation<br>
> >> ><br>
> >> > If this proposal is accepted, I would plan to implement this for the LLVM 14 release cycle based<br>
> >> > on the following proof of concept that I have been testing for the last few releases:<br>
> >> ><br>
> >> > <a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a>>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow.yml</a>>>><br>
> >> > <a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a>>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-workflow-create-pr.yml</a>>>><br>
> >> > <a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a>>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a>> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a> <<a href="https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml" rel="noreferrer" target="_blank">https://github.com/tstellar/llvm-project/blob/release-automation/.github/workflows/release-merge-pr.yml</a>>>><br>
> >> ><br>
> >> > Thanks,<br>
> >> > Tom<br>
> >> ><br>
> >> > _______________________________________________<br>
> >> > LLVM Developers mailing list<br>
> >> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>><br>
> >> > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>>> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>>>><br>
> >> ><br>
> >><br>
> ><br>
> <br>
<br>
</blockquote></div></div>