-
Notifications
You must be signed in to change notification settings - Fork 38.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
component-base: avoid accumulating default labels #105541
Conversation
The intention in kubernetes@ecb3813 was to use the component-base/OWNERS labels only as fallback when the OWNERS files in the sub-directories don't set labels. This should never have been necessary because all of those sub-directories have reasonable labels configured. But in practice, the labels were also added to PRs that only touched files in sub-directory because OWNERS files are inherited, which created noise in various sigs that shouldn't have been tagged for those PRs.
Also update OWNERS in subdirs based on best-guess picks of appropriate OWNERS. We can update as necessary in future iterations but this'll help reduce initial noise for SIG-Arch.
/remove-sig api-machinery |
/lgtm |
/triage accepted |
/assign @derekwaynecarr |
Context in #105414 (comment). We wanted to use these labels as a fallback but that doesn't seem to be the behavior. Since subdirs are already labeled, I'm okay deleting these to reduce noise. |
/lgtm |
Looks like @derekwaynecarr is busy or missed this one. @dims : can you approve? /assign @dims |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dims, pohly The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
The intention in
ecb3813
was to use the component-base/OWNERS labels only as fallback when the OWNERS
files in the sub-directories don't set labels. This should never have been
necessary because all of those sub-directories have reasonable labels
configured.
But in practice, the labels were also added to PRs that only touched files in
sub-directory because OWNERS files are inherited, which created noise in
various sigs that shouldn't have been tagged for those PRs.
Does this PR introduce a user-facing change?