Deploy preview for kubernetes-io-master-staging ready!

Built with commit 19132e4

https://deploy-preview-10294--kubernetes-io-master-staging.netlify.com

/assign @bradtopol
/sig architecture

/hold

cc @bgrant0607 @jdumars

thanks @dims and @anlunas :)

the preview and the definitions SGTM as per the google docs edits.

Alpha: 0 releases

with regard to alpha gates, something else i've remembered that kubeadm is currently doing is the following.
it deprecates a certain alpha gate not immediately but rather waits for 1 release.
this was due to the fact that the particular gate had a user base even if being alpha and kubeadm didn't want to phases it out without notification.

but we can consider this as an edge case.

WRT the above, a possible addition to the document can be that maintainers might decide to extend the deprecation period, if see fit.

Seems pretty close to what I expected

@neolit123 , Since enforcement was a topic during the discussion, I thought we should write a guideline that is/sounds less flexible, at the same time pointing out the fact that not all feature-gates (or their maintainers) respect this guideline. do you think we need a new sentence to add flexibility?
If not, I believe the Alpha case is covered by both rules: Rule #8a for the lower bound - Alpha must function for no less than 0 releases after their announced deprecation ~ equal to or more than 0 releases.
Rule #8b: for the upper bound - Alpha must function at most until the old behavior has been removed ~ no need for it anymore as there is nothing to toggle.
I believe we could make the "rules" part more readable but at the cost of breaking the syntax of the rest of the de document.
In any case I am open, let me know what you think.

@anlunas thinking about it a bit more i think this extra case that i pointed out it already covered. the lower and upper bounds provide sufficient detail for both developers and contributors.
thanks for the clarification!

/assign @thockin

Tim, please approve this for sig-arch ( @jdumars and @bgrant0607 tagged you as approver on sig-arch slack ) :)

-- Dims

Seems like this is a lot better than not being there and feedback has been incorporated.

/lgtm

Thanks for persevering :)

@anlunas please incorporate the last bits from @liggitt above and we can take it to the arch meeting for final approval

/assign @thockin
and thank you for persevering :)

A related question was raised on kubernetes/kubernetes#68230 (comment) that isn't covered by the policy:

From @liggitt:

allowing people to specify command-line options we then do the opposite of doesn't seem like a good idea for feature gates... presumably they had a reason for explicitly disabling the feature... our options in this situation are:

• continue allowing the feature to be disabled (which we don't want to do)
• do the opposite of what they commanded (which I think is a bad idea)
• refuse to start

Should we extend the policy to cover this case?

From @liggitt:

allowing people to specify command-line options we then do the opposite of doesn't seem like a good idea for feature gates... presumably they had a reason for explicitly disabling the feature... our options in this situation are:

• continue allowing the feature to be disabled (which we don't want to do)
• do the opposite of what they commanded (which I think is a bad idea)
• refuse to start

Should we extend the policy to cover this case?

This line was intended to address it:

When an invocation tries to disable a no-op GA gate, the call will fail in order to
avoid unsupported scenarios that might run silently.

Oh, got it, I missed that. Thanks!

/hold cancel
/lgtm

@kubernetes/sig-docs-en-owners @kubernetes/sig-docs-en-reviews Can one of you please /approve this?

@dims Reviewing now 👀

/approve
/hold

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: thockin, zacharysarah

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/lgtm

/hold cancel