-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
Tracking Issue: Normalize Kind Labels #2032
Comments
/sig contributor-experience |
kind/bug and kind/failing-test seem to commonly overlap since tests fail due to bugs somewhere, why would failing-test not be a priority label still? |
"bug" tells me that there is a bug in the kubernetes code base somewhere. "failing-test" can be for a bug, but it can also be a test-infra issue, or an external dependency issue unrelated to a bug in the code base. |
This label is also used across the org though? Bugs can also be from code not primarily attributed to a repo (vendor?) or interactions with external tools. failing-test seems like a subset of bug with somewhat murky distinction. Switching this label away from priority will leave a lot of existing issues / PRs with a now-unused label. I'm not convinced this is helpful FWIW. |
I don't understand this. Could you explain? |
The existing label is pretty heavily used, so switching it will artificially split up issues / PRs into the old label and the new. |
So? That's true of any label change. If that's a winning argument, then we can never change any labels ever. The answer to this is to have a bot reassign for currently open issues and PRs. @spiffxp's issue on this explains the problems with priority/failing-test:
|
Here's a good example of why priority/failing-test is a failure as a label: kubernetes/kubernetes#61645 (comment) In that issue, it's not even used, and the way we track that it's a failing test is by "[test fail]" in the issue title. When folks start resorting to adding ad-hoc tagging to long text fields, labelling isn't working. |
It definitely is true of any label change, and I do think most label changes cause unnecessary churn and confusion FWIW, so I'd prefer strong justification for changing any labels. This is a label we search for and catalog as humans, the bots don't and probably shouldn't care about this label. The justification from @spiffxp SGTM, but I do want to mention that we still have somewhat awkward overlap with kind/bug and kind/failing-test. What do I label a PR fixing a bug for a failing test? Seems like we will wind up wanting to have two kind label on many PRs/issues instead of two priority labels which doesn't seem like a vast improvement. 🤷♂️
I don't see anything particularly convincing here that renaming this will solve the issue of "people don't use appropriate labels", FWIW. This issue could have just as well been labeled |
To clarify I want to see this change overall and love seeing less labels(!) -- I'm not asking to block anything, I'm just raising some concern that those two kind labels will likely continue to be poorly conflated and imho probably raise the likelihood that test failures are only labeled as bugs. |
@BenTheElder the label sync tool migrates the label. So renaming it doesn't impact current issues/PRs that use the old label. |
@BenTheElder it's not "people don't use appropriate labels", it's "people can't use appropriate labels, because the 'appropriate' labels don't make any sense". The problem is less that "failing-test ought to be a kind" than "failing-test shouldn't be a priority". That is, having it as a priority causes several different problems, and doesn't make any sense. And if it's not going to be a priority, having it be a kind is what makes the most sense, especially given the workflow considerations mentioned above. |
Also, priority labels are supposed to be exclusive (and this issue is the only reason we don't enforce that), whereas kind labels are "try to use only one". So it is materially better to have two kinds than two priorities, especially when it comes to reporting and triage. The alternative would be to make failing-test its own, independent, label. |
This might actually make sense. From my point of view a "low priority failing test" doesn't really make sense. What good are tests if we're content to let them fail? |
No, but I can see having a failing test be priority/important-soon or priority/important-longterm instead of priority/critical-urgent, depending on the test. For example, new tests for alpha features just aren't critical-urgent when they fail; part of the feature getting to beta is having good tests, but we don't expect the developers to fix the tests on a 48hours-or-less basis. |
I would rather see N I hear the I'm explicitly against non-prefixed labels in general, because they break the (IMO intuitive/discoverable) pattern where the It's been a good bit since I've looked at devstats, so I'll survey and see if that helps prove any particular point |
Label migration does impact issue / PR update time, but I don't think label renaming does. AFAIK we don't have anything automatically creating issues with |
Reading over this discussion, I don't think we have any further objections to moving |
I've got opinions on the rest, preferring to add as few as possible, but I want to go get some more data about what labels are out there and how they're used first. It looks like the proposed list keeps us within https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two so broadly lgtm. For now, a comment on:
This isn't new, it's been present in kubernetes/kubernetes, but nowhere else. I was wary of this being noisy, but looking at its use -author:k8s-merge-robot it seems pretty well understood as distinct from kind/bug and distinct from priority/failing-test. So yeah I think I'm in favor of making this org-wide. |
@spiffxp yeah, my criteria for all of the remaining kind/ labels was "can I imagine wanting to run a report on issues/PRs of this type". |
Incidentally, I consider this good to go, it's just waiting for conventions to be over so I can carry it out. |
OK, this is all done, ref: #1579 and kubernetes/test-infra#8129 As for the rest, many of the labels you reference as unused (in kubernetes/community) are used in kubernetes/kubernetes. Looking at both, I would suggest (in order of ease):
I'll tackle the first two today. Not sure if/when I'll get to the rest |
Notified kubernetes-dev@ of manual removal of https://groups.google.com/forum/#!topic/kubernetes-dev/CGpiuWpp5uE |
new-api and api-change should actually go to sig-arch. Yes, they actively use the labels. |
API kind labels added to lists above per @cblecker's comment, which I agree with based on 1.11 activity. Basically, api-change and new-api have specific meanings, and both pass the test of "is this something that I'd want to run a report on". I'd prefer that they both be consolidated into one kind/api-change label,but I'm also not willing to argue with SIG-arch or SIG-api about it. |
Once the PR I just linked here merges, that leaves us with:
|
This is no longer user kubernetes/test-infra#9007. Opened #2032 to merge the label into kind/documentation
I'm now leaning more toward making this an org-wide label. Adding it puts us at 9
WDYT? |
I don't buy the logic on keeping kind/friction, because:
|
It's been used 28 times across the org. Of those, it was used distinctly 16 times. The numbers are low enough that I'm sold. I'll propose merging kind/friction into kind/cleanup to k-dev@ |
/close I think efforts to further prune one-off
|
@spiffxp: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
All the things in the original issue are done. Great work! |
There are several issues open regarding Kind labels. This is a tracking issue to track all of them across the project so that people can visualize what the end result will be.
Issues:
Some general points:
I am vague on how we should be applying this set of rules to K/K vs. organization-wide. My primary concern is limiting the pool of kind labels in k/k to a relative handful of clearly needed labels.
New list of canonical Kind labels
Deprecated Kind labels:
Also officially deprecating these kind labels, which exist but have not been used since 1.9 or earlier:
List of Changes To Make
Renames:
New Labels:
Existing Labels to be added to labels.md:
Finally, announce deprecation of all the deprecated labels above, and mark them as such in the label dictionary.
cc @spiffxp
The text was updated successfully, but these errors were encountered: