-
Notifications
You must be signed in to change notification settings - Fork 34
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
Remove the concept of extended
fields from our standard and experimental channels
#275
Comments
/assign @tssurya |
We should also consider whether the "channel" terminology makes sense. (It seems to not really be working well for Gateway anyway?) We just have "experimental features", right? |
(maybe after the next release) |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
Describe the issue:
We have 2 channels:
We have spoken in past sig-network-policy-api meetings and at kubecon that community is OK to get rid of these extended/core concept totally and just have the two channels -> All implementations that are implementing experimental must implement all the fields there and same goes for core.
The text was updated successfully, but these errors were encountered: