[ACTION REQUIRED] Migration of kind/design to kind/feature in k/k

Skip to first unread message

Madhav Jivrajani

Sep 20, 2021, 2:15:10 AMSep 20
to kuberne...@googlegroups.com

Hey kdev,

TL;DR - The kind/design label will now be an opt-in label for all existing and newly created repositories. Please reply to this email if you are a maintainer of a repository that currently actively uses kind/design or would like to start using kind/design. Please read further for more details on this. The lazy consensus period ends on 27th September.

Due to the adoption of KEPs as a replacement to design proposals in kubernetes/kubernetes, the kind/design label will be migrated to the kind/feature label [1][2]. Please read the consequences of the same and what it means for you if you are a maintainer of a repository that actively uses the kind/design label.

After implementing this migration [2], kind/design will be an opt-in label. This means that any existing repository which actively uses kind/design or a newly created repository that wishes to actively use kind/design will have to send in a PR to k/test-infra/label_sync [3] adding the respective repository's entry (if it did not already exist) followed by specifying an entry for the kind/design label.

When discussed on the original issue for this migration [1], the maintainers of the following repositories came forth saying that they actively use kind/design:

- k/kubeadm

- k-sigs/controller-runtime

- k-sigs/cluster-api

which is why you will see these three repositories as "opted-in" for kind/design use in the migration PR [2].

If any other repository also uses or would like to use kind/design please reply to this email saying so by 27th September 2021, post which kind/design will be deleted:

- kind/design on all issues and PRs of said repository will be deleted.

- kind/design will be deleted from the list of labels of the said repository.

Please note that it is being done this way to try and keep our source of intent [3] and our source of truth (the state of the labels on the repository), as identical as possible.

This will be the case for all repositories that did not opt-in via this email. Please note that you can still opt-in at a later point by sending in a PR to [3] as mentioned above.

[1] https://github.com/kubernetes/community/issues/5641

[2] https://github.com/kubernetes/test-infra/pull/23011

[3] git.k8s.io/test-infra/label_sync/labels.yaml



Reply all
Reply to author
0 new messages