Update sig-virtualization label to sig-compute

[aburdenthehand]

As I understand it 'sig-virtualization' is an outdated term for the group that is now called 'sig-compute'.

Suggestion was to change the label to recognise this ahead of the release notes changes:
kubevirt/kubevirt#8752 (comment)

Happy to add rather than replace if that makes more sense.

[brianmcarey]

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brianmcarey

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:

• OWNERS [brianmcarey]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubevirt-bot]

@aburdenthehand: Updated the label-config configmap in namespace kubevirt-prow at cluster default using the following files:

• key labels.yaml using file github/ci/prow-deploy/kustom/base/configs/current/labels/labels.yaml

In response to this:

As I understand it 'sig-virtualization' is an outdated term for the group that is now called 'sig-compute'.

Suggestion was to change the label to recognise this ahead of the release notes changes:
kubevirt/kubevirt#8752 (comment)

Happy to add rather than replace if that makes more sense.

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.

[iholder101]

Hey @aburdenthehand!
For some reason I still see this label in kubevirt/kubevirt#13252. FYI @dhiller.

[iholder101]

Seems like the bot is the one to blame!

[dhiller]

Seems like the bot is the one to blame!

@iholder101 there's a slight hiccup here - this issue was talking about the sig-virtualization label, which has been renamed here, where the label sig/virtualization still exists and seems to be usable - even though I agree with you to disagree leading to that we should not use sig/virtualization and favor the sig/compute label rather.

I've configured dosu to not apply the sig/virtualization label any more.

@dosubot can you remove the sig/virtualization labels from the pull requests again please?

[dhiller]

@iholder101 @acardace @xpivarc what is the use of sig/virtualization actually? I believe a real SIG is not behind this? Should we rename this one into sig/compute?

FYI @aburdenthehand

[iholder101]

@iholder101 @acardace @xpivarc what is the use of sig/virtualization actually? I believe a real SIG is not behind this? Should we rename this one into sig/compute?

FYI @aburdenthehand

Yes, I believe that's what we should do.

this issue was talking about the sig-virtualization label, which has been renamed here, where the label sig/virtualization still exists and seems to be usable

@dhiller for my education, can you show me where it exists? I don't see this label in labels.yaml nor in our docs, or anywhere else in project-infra tbh. Is it possible that dosu have added a custom label to PRs that used to exist in the past?

[dhiller]

@iholder101 @acardace @xpivarc what is the use of sig/virtualization actually? I believe a real SIG is not behind this? Should we rename this one into sig/compute?
FYI @aburdenthehand

Yes, I believe that's what we should do.

this issue was talking about the sig-virtualization label, which has been renamed here, where the label sig/virtualization still exists and seems to be usable

@dhiller for my education, can you show me where it exists? I don't see this label in labels.yaml nor in our docs, or anywhere else in project-infra tbh. Is it possible that dosu have added a custom label to PRs that used to exist in the past?

This seems to be a label that has been created manually - according to this query it was used frequently rather in the beginning of the project - mainly on kubevirt/kubevirt, although defined globally. It's usage slowly faded after that, only to be picked up by the bot recently.

I'd suggest adding the label sig/virtualization as another previously configuration to the label config sig/compute in section default, similar to what was done in this PR, so that label_sync will transfer it towards the sig/compute label.

@aburdenthehand @iholder101 WDYT?

[aburdenthehand]

@dhiller Wow, prow can do anything :)
So if I understand correctly, this PR renamed the label from sig/virt to sig/compute but because sig/virt was manually created it had some kind of old-world magic that allowed it to continue to be used? Despite this, we can still prevail by giving it to prow as a 'previously' which will then overwrite any future use of sig/virt with sig/compute?
If so, then I think this is a grand solution.

[iholder101]

I'd suggest adding the label sig/virtualization as another previously configuration to the label config sig/compute in section default, similar to what was done in this PR, so that label_sync will transfer it towards the sig/compute label.

@aburdenthehand @iholder101 WDYT?

+1

[dhiller]

On that note @iholder suggested cleaning up a bunch of sig/ labels where no SIG actually exists - by converting them into topic/ and/or area/ labels. I am not exactly sure what to choose where though.

[dhiller]

On that note @iholder suggested cleaning up a bunch of sig/ labels where no SIG actually exists - by converting them into topic/ and/or area/ labels. I am not exactly sure what to choose where though.

A quick look at the kubernetes labels seems to indicate that area/ should be preferred.