kubernetes-sigs/kustomize
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-05-17 18:25:26 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Introduce in-repo proposal process

Browse Source
This commit is contained in:
Katrina Verey
2021-08-19 17:00:20 -07:00
parent 023a580f00
commit 3e7246690f
2 changed files with 207 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

159
proposals/00-00-template.md Normal file
View File

@@ -0,0 +1,159 @@
<!--
**Note:** When your proposal is complete, all of these comment blocks should be removed.
To get started with this template:
- [ ] **Make a copy of this file.**
Name it `YY-MM-short-descriptive-title.md` (where `YY-MM` is the current year and month).
- [ ] **Fill out this file as best you can.**
At minimum, you should fill in the "Summary" and "Motivation" sections.
- [ ] **Create a PR.**
Ping `@kubernetes-sigs/kustomize-admins` and `@kubernetes-sigs/kustomize-maintainers`.
-->
# Your short, descriptive title
**Authors**:
**Reviewers**:
**Status**: implementable
<!--
In general, all proposals made should be merged for the record, whether or not they are accepted. Use the status field to record the results of the latest review:
- implementable: The default for this repo. If the proposal is merged, you can start working on it.
- deferred: The proposal may be accepted in the future, but it has been shelved for the time being. A new PR must be opened to update the proposal and gain reviewer consensus before work can begin.
- withdrawn: The author changed their mind and no longer wants to pursue the proposal. A new PR must be opened to update the proposal and gain reviewer consensus before work can begin.
- rejected: This proposal should not be implemented.
- replaced: If you submit a new proposal that supersedes an older one, update the older one's status to "replaced by <link>".
-->
## Summary
<!--
This section is incredibly important for producing high-quality, user-focused
documentation such as release notes or a development roadmap.
A good summary is probably at least a paragraph in length.
-->
## Motivation
<!--
This section is for explicitly listing the motivation, goals, and non-goals of
this proposal. Describe why the change is important and the benefits to users. If this
proposal is an expansion of an existing GitHub issue, link to it here.
-->
### Goals
<!--
List the specific goals of the proposal. What is it trying to achieve? How will we
know that this has succeeded?
-->
1. A goal
1. Another goal
### Non-Goals
<!--
What is out of scope for this proposal? Listing non-goals helps to focus discussion
and make progress.
-->
1. A non-goal
1. Another non-goal
## Proposal
Proof of concept PR (optional):
<!--
This is where we get down to the specifics of what the proposal actually is. What is the plan for implementing this feature? Does this proposal require new kinds, fields or flags? What do they look like?
-->
### User Stories
<!--
Describe what people will be able to do if this KEP is implemented. If different user personas
will use the feature differently, consider writing separate stories for each.
Include as much detail as possible so that people can understand the "how" of the system.
The goal here is to make this feel real for users without getting bogged down.
-->
#### Story 1
Scenario summary: As a [end user, extension developer, ...], I want to [...]
<!--
A walkthrough of what it will look like for a user to take advantage of the new feature.
Include the the steps the user will take and samples of the commands they'll run
and config they'll use.
-->
#### Story 2
Scenario summary: As a [end user, extension developer, ...], I want to [...]
<!--
A walkthrough of what it will look like for a user to take advantage of the new feature.
Include the the steps the user will take and samples of the commands they'll run
and config they'll use.
-->
### Risks and Mitigations
<!--
What are the risks of this proposal, and how do we mitigate? Think broadly.
For example, consider both security and how this will impact the larger
Kubernetes ecosystem.
-->
### Dependencies
<!--
Kustomize tightly controls its Go dependencies in order to remain approved for
integration into kubectl. It cannot depend directly on kubectl or apimachinery code.
Identify any new Go dependencies this proposal will require Kustomize to pull in.
If any of them are large, is there another option?
-->
### Scalability
<!--
Is this feature expected to have a performance impact?
Explain to what extent and under what conditions.
-->
## Drawbacks
<!--
Why should this proposal _not_ be implemented?
-->
## Alternatives
<!--
What other approaches did you consider, and why did you rule them out? Be concise,
but do include enough information to express the idea and why it was not acceptable.
-->
## Rollout Plan
<!--
Depending on the scope of the features and the risks enabling it implies,
you may need to use a formal graduation process. If you don't think this is
necessary, explain why here, and delete the alpha/beta/GA headings below.
-->
### Alpha
<!--
New Kinds should be introduced with an alpha group version.
New major features should often be gated by an alpha flag at first.
New transformers can be introduced for use in the generators/validators/transformers fields
before they get their own top-level field in Kustomization.
-->
- Will the feature be gated by an "alpha" flag? Which one?
- Will the feature be available in `kubectl kustomize` during alpha? Why or why not?
### Beta
<!--
If the alpha was not available in `kubectl kustomize`, you need a beta phase where it is.
Full parity with `kubectl kustomize` is required at this stage.
-->
### GA
<!--
You should generally wait at least two `kubectl` release cycles before promotion to GA,
to ensure that the broader user base has time to try the feature and provide feedback.
For example, if your feature first appears in kubectl 1.23, promote it in 1.25 or later.
-->

48
proposals/README.md Normal file
View File

@@ -0,0 +1,48 @@
# Kustomize Enhancement Proposal Processes
So you want to propose an enhancement to Kustomize—awesome! Choose the option below that best fits the scope of your idea. Before you get started, it's a good idea to review the list of [eschewed features](https://kubectl.docs.kubernetes.io/faq/kustomize/eschewedfeatures).
[SIG CLI]: https://github.com/kubernetes/community/tree/master/sig-cli
[Enhancements repo]: https://github.com/kubernetes/enhancements
### Option 1: Github issue
Small, straightforward enhancements can be proposed in regular GitHub issues. As a rule of thumb, the enhancement should be resolvable in a single PR that is at most size L.
**Example features**:
- a new Kustomization field that does something very straightforward, like annotating resources
- a new option for an existing built-in transformer
**Instructions**: [Open an issue](https://github.com/kubernetes-sigs/kustomize/issues/new?labels=kind%2Ffeature&template=feature_request.md)
### Option 2: Mini (In-Repo) Enhancement Proposal
If your feature may be controversial or has a lot of details to explain, you should write it up as a mini enhancement proposal on this repo. This process is still relatively lightweight, but allows for more in-depth discussion of multiple details. Because it is submitted as a PR, reviewers can comment on individual lines of the proposal, facilitating discussion. The PR will be merged whether the feature is accepted or rejected, creating a record of the decisions.
Since the proposal template is a subset of what's required for the full KEP process, this can also be a good option if you're unsure whether your proposal is of general interest to [SIG-CLI]. You can use it to get preliminary feedback from the Kustomize team before bringing a full-fledged KEP to the SIG.
**Example features**:
- a new built-in transformer with several configurable options
- a feature that will bring in a significant new dependency
- a feature that introduces a new class of behavior, such as manipulating data within an opaque resource field
- a new build process that does not affect `kubectl kustomize`
**Instructions**:
1. Make a copy of [00-00-template.md](00-00-template.md) and rename it with the current date (e.g. 21-08) and a succinct title.
1. Fill out the template.
1. Submit it for review as a PR.
1. (Optional) Present your proposal at a biweekly [SIG-CLI] meeting. This can be a good way to get more traction for your proposal. Your presentation should be a quick summary to help folks understand whether the proposal is relevant to them.
### Option 3: Kubernetes Enhancement Proposal (KEP)
If your feature changes behaviour in a way that has significance for `kubectl kustomize`, particularly in terms of security, you will need to follow the full KEP process and get buy-in from [SIG-CLI] leadership in addition to Kustomize maintainers. Note that you can still submit a mini (in-repo) enhancement proposal as a first step to get preliminary feedback, including on whether a full KEP is required.
**Example features**:
- a feature with significant privacy or security implications to work out
- a feature that is not purely localized to the Kustomize binary on the end user's machine (e.g. downloads something remote, executes something external)
**Instructions**:
1. Follow the process on the [Enhancements repo]. Be sure to put your KEP in the directory for SIG-CLI.
1. (Strongly recommended) Send a link to your KEP to the [SIG-CLI] mailing list.
1. (Strongly recommended) Present your KEP at a biweekly [SIG-CLI] meeting. Your presentation should be a quick summary to help folks understand whether the KEP is relevant to them.
1. After your KEP is accepted, remember to update its metadata as your feature proceeds through the release process.