|
| 1 | +# Glossary |
| 2 | + |
| 3 | +- [API Review](#api-review) |
| 4 | +- [Code Freeze](#code-freeze) |
| 5 | +- [Exceptions](#exceptions) |
| 6 | +- [Enhancements Freeze](#enhancements-freeze) |
| 7 | +- [Kubernetes Enhancements Proposal (KEP)](#kubernetes-enhancement-proposal-kep) |
| 8 | +- [Production Readiness Review (PRR)](#production-readiness-review-prr) |
| 9 | + |
| 10 | +### API Review |
| 11 | +The API review process is intended to maintain logical and functional integrity of the |
| 12 | + API over time, the consistency of user experience and the ability of previously |
| 13 | + written tools to function with new APIs. |
| 14 | + |
| 15 | +If an enhancement is considered to be changing the Kubernetes core API in any way, |
| 16 | + a mandatory API review is required. An Enhancement owner should proactively request an |
| 17 | + API review for an enhancements PR by adding a `/label api-review` comment. |
| 18 | + The status of an API review can be found in the |
| 19 | + [API review backlog](https://github.com/orgs/kubernetes/projects/13). |
| 20 | + |
| 21 | +More details can be found in [Kubernetes API Review Process](https://github.com/kubernetes/community/blob/master/sig-architecture/api-review-process.md). |
| 22 | + |
| 23 | +### Code Freeze |
| 24 | +All enhancements going into the release must be code-complete by the code freeze deadline. |
| 25 | + Any unmerged pull requests in k/k repo for the upcoming release milestone will be removed |
| 26 | + by the Release Team and will require an approved exception to have the milestone added back |
| 27 | + by the Release Team. |
| 28 | + |
| 29 | +More details can be found in [Code Freeze](https://github.com/kubernetes/sig-release/blob/master/releases/release_phases.md#code-freeze). |
| 30 | + |
| 31 | +### Exceptions |
| 32 | +When an enhancement fails to meet the release deadline, Enhancement owner must file an |
| 33 | + [exception request](https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md#requesting-an-exception) |
| 34 | + addressed to SIG sponsoring the enhancement, the Release Team, and SIG Release to gain approval. |
| 35 | + The Release Team will be responsible for approving or rejecting exceptions and the decision |
| 36 | + will be based on discussion with the sponsoring SIG's chairs/leads and any other participating |
| 37 | + SIG's chairs/leads. |
| 38 | + |
| 39 | +More details can be found in [Exceptions to Milestone Enhancement Complete dates](https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md). |
| 40 | + |
| 41 | +### Enhancements Freeze |
| 42 | +All enhancements going into the release must meet the [required criteria](https://github.com/kubernetes/sig-release/blob/master/releases/release_phases.md#enhancements-freeze) by the enhancements freeze deadline. |
| 43 | + |
| 44 | +Any enhancements that do not meet all of the criteria will be removed from tracking for the upcoming release. |
| 45 | + Any unmerged pull requests in k/enhancements repo for the upcoming release milestone will be removed |
| 46 | + by the Release Team and will require an approved exception to have the milestone added back and the enhancement |
| 47 | + tracked again by the Release Team. |
| 48 | + |
| 49 | +More details can be found in [Enhancements Freeze](https://github.com/kubernetes/sig-release/blob/master/releases/release_phases.md#enhancements-freeze). |
| 50 | + |
| 51 | +### Kubernetes Enhancement Proposal (KEP) |
| 52 | +A Kubernetes Enhancement Proposal is a way to propose, communicate and coordinate on new efforts |
| 53 | + for the Kubernetes project. |
| 54 | + |
| 55 | +A KEP should be created after socializing an idea with the sponsoring and participating SIGs. |
| 56 | + To create a KEP, the [KEP template](https://github.com/kubernetes/enhancements/blob/master/keps/NNNN-kep-template/README.md) |
| 57 | + should be used and follow the process outlined in the template. |
| 58 | + |
| 59 | +Use the [definition of what is an Enhancement](https://github.com/kubernetes/enhancements#is-my-thing-an-enhancement) |
| 60 | + to determine if a KEP is required. |
| 61 | + |
| 62 | +More details can be found in [Kubernetes Enhancement Proposals](https://github.com/kubernetes/enhancements/blob/master/keps/README.md#kubernetes-enhancement-proposals-keps) |
| 63 | + and [Enhancements](https://github.com/kubernetes/enhancements/blob/master/README.md). |
| 64 | + |
| 65 | +### Production Readiness Review (PRR) |
| 66 | +Production Readiness Reviews are intended to ensure that features merging into Kubernetes |
| 67 | + are observable, scalable and supportable, can be safely operated in production environments, |
| 68 | + and can be disabled or rolled back in the event they cause increased failures in production. |
| 69 | + |
| 70 | +PRR approval is a requirement for the enhancement to be part of the upcoming release and all |
| 71 | + enhancements owners must [submit a KEP for production readiness approval](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md#submitting-a-kep-for-production-readiness-approval) |
| 72 | + before the Enhancements Freeze deadline. |
| 73 | + |
| 74 | +To request a Production Readiness Review, assign a PRR approver from the `prod-readiness-approvers` |
| 75 | + list in the [OWNERS_ALIASES](https://github.com/kubernetes/enhancements/blob/662e4553eee3939442c88e6cdaef4c776b564b22/OWNERS_ALIASES#L193) |
| 76 | + file and reach out to the production readiness approvers in slack channel #prod-readiness. |
| 77 | + |
| 78 | +More details can be found in [Production Readiness Review Process](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md#production-readiness-review-process) |
| 79 | + and [PRR KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1194-prod-readiness). |
0 commit comments