-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Clean up the existing area labels and adding new useful ones #8263
Comments
/triage accepted Thanks for opening this @joekr! To add context we currently have the following labels. I've grouped them based on my own categorization. The existing list is at https://github.com/kubernetes-sigs/cluster-api/labels?q=area Code area
Features
Cross-cutting development areas
Providers
My opinion:
|
For context, the labels on this repo are set from the list at: https://github.com/kubernetes/test-infra/blob/7471678e74188b7bdd29ba378a13df5a4a47dbb8/label_sync/labels.yaml#L1676 So we can add and remove labels by making the changes at that repo. |
Awesome! I can make those changes based on your opinion above and as others provide feedback we can update that repo. |
@joekr Let's leave it a few days at least for other people to have their say 🙂 - I think one thing we don't want is to be making big changes to often, so it would be good to get something like consensus. |
i don't think this is needed. iirc an admin can just add the labels to the capi repo and the '/area foo' command can trigger for any existing 'area/foo' |
Yup, this should work. While the label sync tool in test-infra is syncing labels it doesn't remove all additional labels that exist in the repo. (had a case recently where I had to delete a label and it wasn't defined in test-infra). But I personally would prefer if our labels are defined via test-infra vs. an admin configuring them manually. |
Generally agree, does this already cover ~ everything? (IPAM?)
+1
Does core also make sense for the core provider? Might make sense to use area/provider/ to make clear that thoes are provider labels.
Agree, let's remove them
+1 in general. I think barely used might be fine if the label seems to make sense, but I think there are some that we never use and would never use How do we feel about creating a Google doc with the labels we want with Killians categorization? This way folks can chime in and we can converge towards a "final" (for now) list. Also seems easier to discuss something like this in a Google doc (more interactive). |
if the goal is to use this for generating release notes, my main concern is that as of today we are not really applying labels to PRs, and we have to strike a healthy balance between asking for info from all the contributors and keeping the barrier for contributing to CAPI as low as possible. WRT to the list of areas, I have only two asks:
|
Yes, this is the motivation. Once available we will add it to the release notes tool asap.
Today when generating the release notes there are sometimes prefixes and for the rest Joe and I use previous release notes / educated guesses what the prefix should be. So not always accurate and somewhat time consuming work that has to be done at the last moment before a release. I agree both with not pushing this on new contributors and that automation is the best end solution. However as an interim solution could we have it as not required and ask the pr approvers to ensure it's set? They have the domain knowledge required to accurately set it and there is more time before the actual release. Then moving on work towards automating this away more and more. I suggest starting with a gdoc as @sbueringer suggested above and once we have the key areas agreed upon, start labeling. |
I've created a PR to add the label |
Automatic area assignment worked perfectly #8344. |
Sorry it has taking me a bit. Here is a link to a google doc with the all the labels from Killian's comment https://docs.google.com/document/d/1PWUZsoO-4Un4FHszEeMDCF_007ic6uA0WRj-crMhB3A/edit?usp=sharing |
There is now also a pr for the release notes tool which uses the area label: #8343. This modified version was used with the upcoming releases this week (1.2, 1.3, 1.4) and it "seems to work:copyright:" when the area label is present. I think if we can get the most important / easiest areas agreed upon early then it will help a lot for future release notes. |
I've added a few suggestions to the doc. IMO we should define these labels in terms of their intended usage instead of linking it to codebase etc. I think the area labels should be used (in order of implementation and importance)
We should automatically label all PRs with I think we should merge the label changes soon and make this an incremental process informed by the release team - especially the comms team which will rely on this for generating the notes. |
Below is a list of - area/machine
- area/machinehealthcheck
- area/util
- area/machinedeployment
- area/machineset
- area/machinepool
- area/clustercachetracker
- area/clusterresourceset
- area/ipam
- area/runtime-sdk
- area/topology
- area/api
- area/networking
- area/security
- area/upgrades
- area/dependency
- area/release
- area/logging
- area/metrics
- area/ci
- area/devtools As @killianmuldoon mentioned, I agree that it is highly unlikely that the areas will directly correlated with |
I would like to avoid having to manage that many OWNERS files if somehow possible. I wonder if we should have another round of discussion about further restructuring our repository before we start introducing OWNERS files everywhere. Some ideas:
|
I agree with @killianmuldoon and @sbueringer
|
This work should be complete now - we can add and remove more labels iteratively as we learn what works and see how the codebase evolves. |
/close |
@killianmuldoon: 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. |
As a part of the PR template change (#8260) we are asking folks to add
/area
label(s). This is an iterative approach to improve change tracking. When PRs are labeled by area the release note generation can be more automated (issue where area labels were first discussed #8051). In order to achieve this we should clean up our existing labels https://github.com/kubernetes-sigs/cluster-api/labels?q=area and add new labels. These labels should better align with the current prefixes add to the release notes.For example:
https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.3.0 has
clusterctl: Add move --to-directory and --from-directory flags
. The user who created that PR would have used/area clusterctl
which currently does exist.Some new addition suggestions:
e2e-testing
ortest/e2e
The text was updated successfully, but these errors were encountered: