Changes to Pull Request Subscription System

Are there instructions for how to subscribe to a label? I did some quick googling but didn’t come up with anything.

Does this means I’ll stop receiving notifications on all groups I have subscribed? How can I see the mapping between the new tags and the old groups?

I can’t see any issue if I don’t know how to migrate to the new system, is there documentation on how to do that?

Shouldn’t we want until most people have made sure their workflows won’t be affected by this? Why the rush?

@rengolin You don’t have to do anything different. We are reusing the same teams as we had for CODEOWNERS.

I think we should move quickly, because it’s still early and we don’t want more people setting up their workflows around using the CODEOWNERS file. Based on this discussion, there are no advantages to keeping our current system, so I think we should move to something better ASAP.

1 Like

You reviewed my patch that documented it just two days ago! :wink:
LLVM Developer Policy — LLVM 18.0.0git documentation

=> there is no builtin support, we continue to use “GitHub teams”, nothing changes.
The only difference is that the teams aren’t added as “reviewers” of the PR, but instead a comment is added and the teams are @pr-subscribers-<team> notified.

That talked about joining teams, and that teams were associated with paths; not that teams were associated with labels?

I strongly support that we remove pr-subscribers-* from .github/CODEOWNERS and do it quickly, to prevent confusion and prevent users from relying on this work flow.
I think people can understand that things are a bit in flux as we started to use pull requests.

People who want new teams can update .github/new-prs-labeler.yml instead and check the existing labels and* teams.

FWIW I have some notes how patch subscription works Reflections on LLVM's switch to GitHub pull requests | MaskRay

To enable component-based subscription, the llvm organization on GitHub has created multiple pr-subscribers-* teams, which users can freely join them. ( Note: A maintainer is supposed to accept every join request. Unfortunately, GitHub only displays the “pending request” information on the* page and not on any other page. It’s not reasonable to expect a maintainer to routinely check the* pages for pending join requests. So if they miss the email notification that says would like to join "LLVM", the request may remain pending indefinitely. )

Then we use label-based subscription. A GitHub action is set up to label every pull request, and these labels are used to notify pr-subscribers-* teams. For example, a pull request affecting clang/lib/Driver/XX will receive the labels clang and clang:driver, and the pr-subscribers-clang and pr-subscribers-clang:driver teams will be notified.


Ah, labels are just used as an implementation detail here: this is why the paths are stored in the file new-prs-labeler.yml.
A label is added, and then the GitHub action is handling it to @ the right team, so: join the team to subscribe to the label!
(this is what we were doing for issues until GitHub allowed to subscribe to issues based on labels)

1 Like

PR to remove the CODEOWNERS file: Remove CODEOWNERS file and copy missing paths into new-prs-labeler.yml by tstellar · Pull Request #66145 · llvm/llvm-project · GitHub

Do we plan to add it back with actually code owners?

If we continue receiving the same notifications, it’s fine.

But it’s still unclear to me how I wold “subscribe” to other/new labels.

You still join the teams. Talking about labels here is just an implementation issue as @mehdi_amini said above. If you are in the right teams nothing will change.


I think the libc++ developers want to do this, so likely yes.