Merge pull request #10583 from vincepri/simple-backport-policy

📖 Simplify our backport policy

CONTRIBUTING.md

@@ -87,38 +87,13 @@ The test module, clusterctl, and experiments do not provide any backward compati
 
 #### Backporting a patch
 
-We generally do not accept PRs directly against release branches, while we might accept backports of fixes/changes already
-merged into the main branch.
-
-Any backport MUST not be breaking for either API or behavioral changes. 
-
-We generally allow backports of following changes to all supported branches:
-- Critical bugs fixes, security issue fixes, or fixes for bugs without easy workarounds.
-- Dependency bumps for CVE (usually limited to CVE resolution; backports of non-CVE related version bumps are considered exceptions to be evaluated case by case)
-- Cert-manager version bumps (to avoid having releases with cert-manager versions that are out of support, when possible)
-- Changes required to support new Kubernetes versions, when possible. See [supported Kubernetes versions](https://cluster-api.sigs.k8s.io/reference/versions.html#supported-kubernetes-versions) for more details.
-- Changes to use the latest Go patch version to build controller images.
-- Changes to bump the Go minor version used to build controller images, if the Go minor version of a supported branch goes out of support (e.g. to pick up bug and CVE fixes). 
-  This has no impact on folks importing Cluster API as we won't modify the version in `go.mod` and the version in the `Makefile` does not affect them.
-
-We generally allow backports of following changes only to the latest supported branch:
-- Improvements to existing docs (the latest supported branch hosts the current version of the book)
-- Improvements to CI signal
-- Improvements to the test framework
-
-While we recommend to target following type of changes to the next minor release, CAPI maintainers will also consider
-exceptions for backport of following changes only to the latest supported branch:
-- Enhancements or additions to experimental Cluster API features, with the goal of allowing faster adoption and iteration;
-  Please note that stability of the branch will always be top priority while evaluating those PRs, and thus approval
-  requires /lgtm from at least two maintainers that, on top of checking that the backport is not introducing any breaking
-  change for either API or behavior, will evaluate if the impact of those backport is limited and well-scoped e.g. 
-  by checking that those changes should not touch non-experimental code paths like utils and/or by applying other 
-  considerations depending on the specific PR.
-
-Like any other activity in the project, backporting a fix/change is a community-driven effort and requires that someone volunteers to own the task. 
-In most cases, the cherry-pick bot can (and should) be used to automate opening a cherry-pick PR.
-
-We generally do not accept backports to Cluster API release branches that are [out of support](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#support-and-guarantees).
+Pull Requests against the main branch can be backported using `/cherry-pick` prow command.
+Any backport MUST NOT be breaking for API or behavioral changes.
+
+We usually backport critical bugs or security fixes, changes to support new Kubernetes minor versions (see [supported Kubernetes versions](https://cluster-api.sigs.k8s.io/reference/versions.html#supported-kubernetes-versions)), documentation and test signal improvements. Everything else is considered case by case.
+
+[Out of support](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#support-and-guarantees) release branches are usually frozen,
+although maintainers may allow backports in specific situations like CVEs, security, and other critical bug fixes.
 
 ### APIs
 
@@ -245,7 +220,7 @@ When submitting the PR remember to label it with the 📖 (:book:) icon.
 
 ## Releases
 
-Cluster API release process is described in [this document](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-cycle.md). 
+Cluster API release process is described in [this document](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-cycle.md).
 
 ## Proposal process (CAEP)
 
@@ -287,15 +262,15 @@ Please note that:
   - Priority can change over time, and everyone is welcome to provide constructive feedback about updating an issue's priority.
   - Applying a priority label is not a commitment to execute within a certain time frame, because implementation
     depends on contributors volunteering time to do the work and on reviewers/approvers bandwidth.
-  
+
 - Closing inactive issues which are stuck in the "triage" phases is a crucial task for maintaining an
   actionable backlog. Accordingly, the following automation applies to issues in the "triage" or the "refinement" phase:
-  - After 90 days of inactivity, issues will be marked with the `lifecycle/stale` label 
-  - After 30 days of inactivity from when `lifecycle/stale` was applied, issues will be marked with the `lifecycle/rotten` label 
+  - After 90 days of inactivity, issues will be marked with the `lifecycle/stale` label
+  - After 30 days of inactivity from when `lifecycle/stale` was applied, issues will be marked with the `lifecycle/rotten` label
   - After 30 days of inactivity from when `lifecycle/rotten` was applied, issues will be closed.
     With this regard, it is important to notice that closed issues are and will always be a highly valuable part of the
     knowledge base about the Cluster API project, and they will never go away.
-  - Note: 
+  - Note:
     - The automation above does not apply to issues triaged as `priority/critical-urgent`, `priority/important-soon` or `priority/important-longterm`
     - Maintainers could apply the `lifecycle/frozen` label if they want to exclude an issue from the automation above
     - Issues excluded from the automation above will be re-triaged periodically
@@ -306,7 +281,7 @@ Please note that:
   - Lack of consensus or the issue is not relevant for other contributors
   - Lack of contributors; in this case, finding ways to help and free up maintainers/other contributors time from other tasks
     can really help to unblock your issues.
-  
+
 - Issues in the "actionable" state are not subject to the stale/rotten/closed process; however, it is required to re-assess
   them periodically given that the project change quickly. Accordingly, the following automation applies to issues
   in the "actionable" phase:
@@ -317,7 +292,7 @@ Please note that:
 - If you really care about an issue stuck in the "actionable" phase, you can try to figure out what is holding back
   the issue implementation (usually lack of contributors), engage with the community, find ways to help and free up
   maintainers/other contributors time from other tasks, or `/assign` the issue and send a PR.
- 
+
 ## Triaging E2E test failures
 
 When you submit a change to the Cluster API repository as set of validation jobs is automatically executed by
@@ -372,14 +347,14 @@ process.
 
 Open [issues](https://github.com/kubernetes-sigs/cluster-api/issues/new/choose) to report bugs, or discuss minor feature implementation.
 
-Each new issue will be automatically labeled as `needs-triage`; after being triaged by the maintainers the label 
+Each new issue will be automatically labeled as `needs-triage`; after being triaged by the maintainers the label
 will be removed and replaced by one of the following:
 
 - `triage/accepted`: Indicates an issue or PR is ready to be actively worked on.
-- `triage/duplicate`: Indicates an issue is a duplicate of another open issue. 
-- `triage/needs-information`: Indicates an issue needs more information in order to work on it. 
-- `triage/not-reproducible`: Indicates an issue can not be reproduced as described. 
-- `triage/unresolved`: Indicates an issue that can not or will not be resolved. 
+- `triage/duplicate`: Indicates an issue is a duplicate of another open issue.
+- `triage/needs-information`: Indicates an issue needs more information in order to work on it.
+- `triage/not-reproducible`: Indicates an issue can not be reproduced as described.
+- `triage/unresolved`: Indicates an issue that can not or will not be resolved.
 
 For big feature, API and contract amendments, we follow the CAEP process as outlined below.
 
@@ -466,8 +441,8 @@ Optional fields have the following properties:
 * Fields SHOULD be pointers if there is a good reason for it, for example:
   * the nil and the zero values (by Go standards) have semantic differences.
     * Note: This doesn't apply to map or slice types as they are assignable to `nil`.
-  * the field is of a struct type, contains only fields with `omitempty` and you want 
-    to prevent that it shows up as an empty object after marshalling (e.g. `kubectl get`) 
+  * the field is of a struct type, contains only fields with `omitempty` and you want
+    to prevent that it shows up as an empty object after marshalling (e.g. `kubectl get`)
 
 #### Example