Update roadmap for 2025 and beyond #2739
Conversation
k8s-ci-robot
added
kind/documentation
k8s-ci-robot
added
needs-priority
approved
|
/hold For review. |
k8s-ci-robot
added
the
do-not-merge/hold
k8s-ci-robot
added
the
lgtm
saschagrunert
force-pushed
the
roadmap-2025
branch
from
5396c94 to
ea1d47c
Compare
k8s-ci-robot
removed
the
lgtm
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
saschagrunert
force-pushed
the
roadmap-2025
branch
from
ea1d47c to
d7ba7e3
Compare
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cpanato, saschagrunert, xmudrii The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
|
||
| Project board: https://github.com/orgs/kubernetes/projects/171 | ||
|
|
||
| 1. **Enable other Kubernetes subprojects to use our packages infrastructure** |
There was a problem hiding this comment.
SIG K8s Infra is generally asking subprojects to leverage github releases over e.g. dl.k8s.io to prevent digging the hole deeper on acquiring CDN bandwidth etc. (we have a sufficient allocation from fastly for that use case + some room for growth built in) The packages currently use AWS credits which could be a problem.
For the container images, we are in a unique position that the usage patterns are different and we've flattened the curve by colocating them with the bulk of pulls in the cloud so the situation is a bit different. (that, and we can safely shard content-addressed traffic across multiple backends without the same security concerns as curl-ed files)
That's not strictly incompatible with making the tooling more re-usable, but IMHO something to keep in mind ... wherever possible we're asking subprojects consider if they need to put us on the hook for serving users.
There was a problem hiding this comment.
I guess that's totally fine. Everything under "Other Priorities" would need a rework before we can start working on those items. We renamed that category from "Stale" to maintain a more optimistic viewpoint.
|
|
||
| For general infrastructure support we rely on. | ||
| Outcome: Clear documentation about available version markers as well as their | ||
| simplified automation. |
There was a problem hiding this comment.
Just curious: Is there existing discussion about simplifying?
For documentation, I think we actually have that now? Though it could be more visible,
There was a problem hiding this comment.
Yes, simplifying was one of the main goals here. Unfortunately has not been a priority for a long time. Do you think that SIG K8S Infra could/would work on this in the foreseeable future?
|
Setting a lazy consensus until March 7. |
|
|
||
| 1. **Enable other Kubernetes subprojects to use our packages infrastructure** | ||
| 1. **Improve SIG Release contributor ladder & sustainability** | ||
| Outcome: Up-to-date documentation and project boards for new and long term contributors. |
There was a problem hiding this comment.
I think its worth calling out exactly where you need documentation updated, since new contributors could be willing to sign up to help with that as a mechanism for learning about the roles and responsibilities of the different subprojects (e.g. Release Managers, Release Team, etc).
There was a problem hiding this comment.
@kubernetes/release-managers @xmudrii do you have further thoughts on that?
What type of PR is this:
/kind documentation
What this PR does / why we need it:
Update the roadmap based on our current priorities.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
PTAL @kubernetes/sig-release