Update roadmap for 2024 and beyond

Updating the roadmap based on the recent refinement sessions. Signed-off-by: Sascha Grunert <[email protected]>
kubernetes · Dec 11, 2023 · 193a3cd · 193a3cd
1 parent 4fd4096
commit 193a3cd
Showing 1 changed file with 96 additions and 63 deletions.
diff --git a/roadmap.md b/roadmap.md
@@ -1,27 +1,21 @@
 # Roadmap and Vision
 
-## SIG Release Roadmap for 2022 and beyond
+## SIG Release Roadmap for 2024 and beyond
 
-This document contains the SIG Release Roadmap for 2022 and beyond. More
+This document contains the SIG Release Roadmap for 2024 and beyond. More
 detailed information can be found on the corresponding project boards.
 
 ### Primary Focus
 
-Establish a **consumable**, **introspectable**, and **secure** supply chain for
-Kubernetes. As a supply chain we understand the defining, building and
-publishing of Kubernetes related artifacts.
-
-1. **Consumable**: Improving the usability of artifacts by making their
-   consumption easier. This includes being process independent of vendor,
-   employer and individuals.
-1. **Introspectable**: It is clear for users at which point and how Kubernetes
-   artifacts are being built. This includes the documentation of all
-   deliverables as well as clarifying what we do not support. All official
-   release artifacts will be built by a hermetic process that is impervious to
-   human interference.
-1. **Secure**: The artifacts we produce are verified for their integrity. This
-   applies to their functionality (we know what we deliver) as well as their
-   software security (we know when CVEs occur).
+Provide a more **robust**, **fast** and **flexible** release pipeline for
+Kubernetes.
+
+1. **Robust**: The process of creating release metadata should be consistent
+   across consecutive runs as well as resilient to infrastructure failures.
+1. **Fast**: The creation time of Kubernetes releases should be minimized.
+1. **Flexible**: Future enhancements to the process will be taken into
+   consideration from the beginning on, for example when thinking about
+   extending the release metadata.
 
 ### Deliverables
 
@@ -31,71 +25,59 @@ state.
 
 ### Work in progress (WIP)
 
-1. **SLSA compliance in the Kubernetes Release Process (Secure)**
+1. **Make artifact validation more robust**
 
-   Outcome: Ensure that our release process is [SLSA](https://slsa.dev)
-   compliant. We also intend to participate actively in the development of the
-   framework.
+   Outcome: Provide a fast and error-resistant workflow for artifact promotion
+   compliant with SLSA.
 
-   Enhancement: https://github.com/kubernetes/enhancements/issues/3027
+   Enhancement: was https://github.com/kubernetes/enhancements/issues/3027
 
-   Project board: https://github.com/orgs/kubernetes/projects/138
+   Project board: https://github.com/orgs/kubernetes/projects/171
 
-1. **Moving deb/rpm package builds to community infrastructure (Consumable)**
+1. **Making deb and rpm package builds more robust**
 
-   Outcome: Automated builds of signed `deb` and `rpm` Kubernetes packages
-   within community infrastructure.
+   Outcome: Provide a fast and error-resistant workflow for building and
+   publishing packages to the community-owned infrastructure.
 
    Enhancement: https://github.com/kubernetes/enhancements/issues/1731
 
    Project board: https://github.com/orgs/kubernetes/projects/137
 
-1. **Signing of release artifacts (Secure)**
-
-   Outcome: Being able to ship signed release artifacts, which includes
-   container images in the first iteration as well as all artifacts following
-   on.
-
-   Enhancement: https://github.com/kubernetes/enhancements/issues/3031
+1. **Enable other Kubernetes subprojects to use our packages infrastructure**
 
-1. **Migrate away from GCS bucket: gs://kubernetes-release**
+   Outcome: Building a CLI, library and documentation for Kubernetes related
+   projects to use the existing packaging infrastructure.
 
-   Outcome: Ensure we migrate away from gs://kubernetes-release, use a community-owned Object Storage bucket for binaries releases, serve the binaries published through a CDN service.
+   Enhancement: _none_
 
-### To be done (TODO)
+   Project board: https://github.com/orgs/kubernetes/projects/137
 
-1. **Enhance Kubernetes binary artifact management (Consumable)**
+1. **Migrate away from GCS bucket: gs://kubernetes-release**
 
-   https://github.com/kubernetes/sig-release/issues/1372
+   Outcome: Ensure we migrate away from gs://kubernetes-release, use a
+   community-owned Object Storage bucket for binaries releases, serve the
+   binaries published through a CDN service.
 
    Enhancement: _none_
 
-   Outcome: Being able to promote files as artifacts and using this mechanism
-   for Kubernetes releases.
-
-1. **Define and collect metrics about Kubernetes releases (Introspectable)**
-
-   https://github.com/kubernetes/sig-release/issues/1527
+### To be done (TODO)
 
-   Enhancement: _none_
+1. **Modernize and Extend Release Metadata**
 
-   Outcome: Being able to measure and interpret a set of defined metrics about
-   Kubernetes releases to associate actions with those.
+   Outcome: Providing release metadata compliant to the latest industry
+   standards.
 
-1. **Establish Cluster API as first-class signal for upstream releases
-   (Consumable)**
+   Enhancement: _none_ (was https://github.com/kubernetes/enhancements/issues/3027)
 
-   Enhancement: _none_
+   Project board: https://github.com/orgs/kubernetes/projects/138
 
-   Outcome: Cluster API provides a CI signal for blocking release test jobs.
+1. **Make Kubernetes releases more flexible**
 
-1. **Enhance and simplify Kubernetes version markers (Consumable)**
+   Outcome: Provide more possibilities for Kubernetes releases to be created in
+   custom infrastructure environments.
 
    Enhancement: _none_
 
-   Outcome: Clear documentation about available version markers as well as their
-   simplified automation.
-
 ### Known Risks
 
 1. **We rely on different SIGs for our work**
@@ -110,25 +92,39 @@ state.
    means that there is a risk of delaying because of investing more time in
    pre-research.
 
-1. SLSA framework is in earlier stages and changes to it can/may affect some of
-   the direction of roadmap items.
-
 ### Requests to Other Teams
 
+1. **SIG K8s Infra**
+
+   For general infrastructure support we rely on.
+
 1. **SIG Architecture**
 
    For the formalization of the released platforms and input about the overall
    supply chain.
 
-1. **SIG Cluster Lifecycle**
+1. **SIG Security**
 
-   To get input for making Cluster API a first-class signal for upstream releases.
+   For content which should be part of the release metadata.
 
-1. **SIG K8s Infra**
+### Done Deliverables
 
-   For general infrastructure support we rely on.
+1. **Moving deb/rpm package builds to community infrastructure (Consumable)**
 
-### Done Deliverables
+   Outcome: Automated builds of signed `deb` and `rpm` Kubernetes packages
+   within community infrastructure.
+
+   Enhancement: https://github.com/kubernetes/enhancements/issues/1731
+
+   Project board: https://github.com/orgs/kubernetes/projects/137
+
+1. **Signing of release artifacts (Secure)**
+
+   Outcome: Being able to ship signed release artifacts, which includes
+   container images in the first iteration as well as all artifacts following
+   on.
+
+   Enhancement: https://github.com/kubernetes/enhancements/issues/3031
 
 1. **Formalize supported release platforms (Introspectable)**
 
@@ -174,3 +170,40 @@ state.
 
    Outcome: A documented and simple process for handling CVE information within
    Kubernetes releases.
+
+### Stale
+
+This section covers items from the past 2022 roadmap which have not been
+started or became stale.
+
+1. **Enhance Kubernetes binary artifact management (Consumable)**
+
+   https://github.com/kubernetes/sig-release/issues/1372
+
+   Enhancement: _none_
+
+   Outcome: Being able to promote files as artifacts and using this mechanism
+   for Kubernetes releases.
+
+1. **Define and collect metrics about Kubernetes releases (Introspectable)**
+
+   https://github.com/kubernetes/sig-release/issues/1527
+
+   Enhancement: _none_
+
+   Outcome: Being able to measure and interpret a set of defined metrics about
+   Kubernetes releases to associate actions with those.
+
+1. **Establish Cluster API as first-class signal for upstream releases
+   (Consumable)**
+
+   Enhancement: _none_
+
+   Outcome: Cluster API provides a CI signal for blocking release test jobs.
+
+1. **Enhance and simplify Kubernetes version markers (Consumable)**
+
+   Enhancement: _none_
+
+   Outcome: Clear documentation about available version markers as well as their
+   simplified automation.