Mirrors/flux2
1
0
Fork 0
mirror of synced 2026-02-06 19:05:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add RFC process

Browse Source 
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
This commit is contained in:
Stefan Prodan
2021-11-30 15:01:57 +02:00
parent c5b2c6709a
commit 99a0c47277
1 changed files with 25 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
rfcs/README.md
View File

@@ -19,6 +19,31 @@ Examples of substantial changes:
- Impactful UX changes (new required inputs to the bootstrap process)
- Drop capabilities (sunset an existing integration with an external service due to security concerns)
## RFC Process
- Before submitting an RFC please discuss the proposal with the Flux community.
Start a discussion on GitHub and ask for feedback at the weekly dev meeting.
You must find a maintainer willing to sponsor the RFC.
- Submit an RFC by opening a pull request using RFC-0000 as template.
- The sponsor will assign the PR to themselves, will label the PR with `area/RFC` and
will request other maintainers to begin the review process.
- Integrate feedback by adding commits without overriding the history.
- At least two maintainers have to approve the proposal before it can be merged.
Approvers must be satisfied that an
[appropriate level of consensus](https://github.com/fluxcd/community/blob/main/GOVERNANCE.md#decision-guidelines)
has been reached.
- Before the merge, an RFC number is assigned by the sponsor and the PR branch must be rebased with main.
- Once merged, the proposal may be implemented in Flux.
The progress could be tracked using the RFC number (used as prefix for issues and PRs).
- After the proposal implementation is available in a release candidate or final release,
the RFC should be updated with the Flux version added to the "Implementation History" section.
- During the implementation phase, the RFC could be discarded due to security or performance concerns.
In this case, the RFC "Implementation History" should state the rejection motives.
Ultimately the decision on the feasibility of a particular implementation,
resides with the maintainers that reviewed the code changes.
- A new RFC could be summited with the scope of replacing an RFC rejected during implementation.
The new RFC must come with a solution for the rejection motives of the previous RFC.
## RFC Template
```text