After finalizing the rewrite of the release process from bash into golang, the release engineering team has been focusing its efforts on two main areas:
- Improving the release automation on two fronts:
- Adding new features, tests and checks to the release process which were missing from the original anago (binary verification, CVE disclosure, building from custom branches and repositories).
- Consolidating the codebases of new repositories which SIG Release brought under its responsibility. The range of new repositories we are consolidating go from critical projects (like the image promoter) to less important repositories (like downloadkubernetes.com)
- Hardening the Kubernetes Supply Chain via key efforts:
- SBOM Generation
- SLSA 3 compliance
- Artifact signing
The most important change currently under development not tracked in a KEP is the new automated branch forward. Tests are currently underway and we aim to have automated forward of the release branch during code freeze by the 1.25 cycle. A recent announcement sent to the dev mailing list has more details about the plan.
- Alpha
- KEP-2853 - Kubernetes repository branch rename - $milestone.stable
- KEP-3027 - SLSA Level 3 Compliance in the Kubernetes Release Process - $milestone.stable
- KEP-3031: Signing release artifacts - $milestone.beta
- $kep-number - $title - $milestone.beta
-
What areas and/or subprojects does your group need the most help with? Any areas with 2 or fewer OWNERs? (link to more details)
All of the following areas are reviewed by the Release Engineering subproject, but we could always use more help here:
-
What metrics/community health stats does your group care about and/or measure?
Some data tracking efforts that SIG Release performs include monitoring release team applications, release manager activities and code commits to ensure timely release cuts in our repos.
-
Does your CONTRIBUTING.md help new contributors engage with your group specifically by pointing to activities or programs that provide useful context or allow easy participation?
- The
CONTRIBUTING.md
was recently revamped and includes a Getting Started section with links to mentoring opportunities.
- The
-
If your group has special training, requirements for reviewers/approvers, or processes beyond the general contributor guide, does your CONTRIBUTING.md document those to help existing contributors grow throughout the contributor ladder?
-
Does the group have contributors from multiple companies/affiliations?
- Yes, over the past two years, we've had contributors from the following companies (non-exhaustive, gathered from here):
- Red Hat
- Cisco
- Chainguard
- Mattermost
- Apple
- SUSE
- VMware
- Upbound
- Jetstack
- Kubermatic
- IBM
- HashiCorp
- SAP
- HSBC
- Huawei
- Intel
- Autodesk
- Yes, over the past two years, we've had contributors from the following companies (non-exhaustive, gathered from here):
-
Are there ways end users/companies can contribute that they currently are not? If one of those ways is more full time support, what would they work on and why?
- We've been considering offering internships to help us round the rough edges in some repositories such as the Kuebrnetes SBOM Tool.
Accurate of 2022-02-14. Stats are primarily pulled from kubernetes/release, the primary repository for Release Engineering tooling/work, which serves as a reasonable representation of reviewers/approvers across SIG Release repositories.
- Primary Slack channel member count: 2458
- Primary mailing list member count: 501
- Primary meeting attendee count (estimated, if needed): 20
- Primary meeting participant count (estimated, if needed): 10
- Unique reviewers for SIG-owned packages (from kubernetes/release): 24
- Unique approvers for SIG-owned packages (from kubernetes/release): 7
Include any other ways you measure group membership
Retired in 2021:
Continuing:
New in 2021:
Retired in 2021:
WG K8s Infra was converted into SIG K8s Infra in 2021.
Continuing:
Operational tasks in sig-governance.md:
-
README.md reviewed for accuracy and updated if needed
-
CONTRIBUTING.md reviewed for accuracy and updated if needed (or created if missing and your contributor steps and experience are different or more in-depth than the documentation listed in the general contributor guide and devel folder.)
-
Subprojects list and linked OWNERS files in sigs.yaml reviewed for accuracy and updated if needed
-
SIG leaders (chairs, tech leads, and subproject owners) in sigs.yaml are accurate and active, and updated if needed
-
Meeting notes and recordings for 2021 are linked from README.md and updated/uploaded if needed
-
Did you have community-wide updates in 2021 (e.g. community meetings, kubecon, or kubernetes-dev@ emails)? Links to email, slides, or recordings:
- [Hardening the Kubernetes Software Supply Chain Through Better Transparency](https://www.youtube.com/watch?v=W6hUXv66rRc) KubeCon + CloudNativeCon NA 2021