review comments and do some cleanup

Author: rikatz

keps/sig-cli/2551-return-code-normalization/README.md

@@ -1,5 +1,5 @@
 # KEP-2551: kubectl exit code standardization
-
+π
 <!-- toc -->
 - [Release Signoff Checklist](#release-signoff-checklist)
 - [Summary](#summary)
@@ -95,6 +95,7 @@ to this specific problem.
 ### Non-Goals
 
 * Define a different return for each internal kubectl step or each APIServer condition/return
+* Define a return code pattern for kubectl plugins or other external calls (we will recommend, but this is not a goal)
 
 ## Proposal
 
@@ -106,7 +107,7 @@ to this specific problem.
   * Exit codes generated by kubectl itself should be distinct, so as not to be confused with codes from external/subcommands
 * Implement a common way so commands can delegate the exit code normalization to a different function
 
-### User Stories (Optional)
+### User Stories 
 
 #### Story 1
 Joice, the SRE of a big company is automating the deployment of the infrastructure with a lot of kubectl commands.
@@ -370,35 +371,17 @@ This section must be completed when targeting alpha to a release.
 
 ###### How can this feature be enabled / disabled in a live cluster?
 
-<!--
-Pick one of these and delete the rest.
--->
-
-- [ ] Feature gate (also fill in values in `kep.yaml`)
-  - Feature gate name:
-  - Components depending on the feature gate:
-- [ ] Other
-  - Describe the mechanism:
-  - Will enabling / disabling the feature require downtime of the control
-    plane?
-  - Will enabling / disabling the feature require downtime or reprovisioning
-    of a node? (Do not assume `Dynamic Kubelet Config` feature is enabled).
 
+- [X] Feature gate (also fill in values in `kep.yaml`)
+  - Feature gate name: ENV VAR `KUBECTL_ERROR_CODES`
+  
 ###### Does enabling the feature change any default behavior?
 
-<!--
-Any change of default behavior may be surprising to users or break existing
-automations, so be extremely careful here.
--->
+Yes, kubectl exit codes numbers will change after the FG is enabled
 
 ###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?
 
-<!--
-Describe the consequences on existing workloads (e.g., if this is a runtime
-feature, can it break the existing applications?).
-
-NOTE: Also set `disable-supported` to `true` or `false` in `kep.yaml`.
--->
+Yes, just remove the Env Var.
 
 ###### What happens if we reenable the feature if it was previously rolled back?
 

keps/sig-cli/2551-return-code-normalization/kep.yaml

@@ -7,39 +7,23 @@ owning-sig: sig-cli
 status: provisional
 creation-date: 2021-03-16
 reviewers:
-  - TBD
+  - "@soltysh"
+  - "@sftim"
+  - "@rikatz"
+  - "@deejross"
 approvers:
-  - TBD
-prr-approvers:
-  - TBD
-see-also:
-  - "/keps/sig-aaa/1234-we-heard-you-like-keps"
-  - "/keps/sig-bbb/2345-everyone-gets-a-kep"
-replaces:
-  - "/keps/sig-ccc/3456-replaced-kep"
+  - "@soltysh"
+
 
 # The target maturity stage in the current dev cycle for this KEP.
 stage: alpha
 
 # The most recent milestone for which work toward delivery of this KEP has been
 # done. This can be the current (upcoming) milestone, if it is being actively
 # worked on.
-latest-milestone: "v1.22"
+latest-milestone: "v1.24"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone:
-  alpha: "v1.22"
-  beta: "v1.23"
-  stable: "v1.24"
-
-# The following PRR answers are required at alpha release
-# List the feature gate name and the components for which it must be enabled
-feature-gates:
-  - name: MyFeature
-    components:
-      - kubectl
-disable-supported: true
+  alpha: "v1.24"
 
-# The following PRR answers are required at beta release
-metrics:
-  - my_feature_metric