Kubernetes 1.24 is the first scheduled release of 2022. Running from Monday 10th January through our expected release date of Tuesday 19th April, it will represent months of work from all across the community to deliver new features to Kubernetes users. From quality-of-life improvements, to major new features, to the removal of major deprecations.
Kubernetes is integral to our work at Jetstack. Our products are built on it, and as a Senior Solutions Engineer I work with Kubernetes day-to-day with our clients. We also spend time working on open source. Including our own projects, projects that Jetstack has donated to the Cloud Native Computing Foundation such as cert-manager, and community projects such as Kubernetes itself.
My name is James Laverack, and I’m the Release Lead for the Kubernetes 1.24 release team. I’ve been a member of every release team since Kubernetes 1.18 in early 2020, and I’ve been in a wide range of roles in that time. I’ve often been asked what exactly the release team does, and what my role in it is.
Every release has a team of people that run the “mechanics” of the release. Everything from performing branch cuts and running release CI jobs, generating and editing release notes, monitoring CI dashboards, monitoring test failures and regressions, freezing and thawing the main branch, tracking enhancements, coordinating documentation updates, writing the release blog, and more. Over 30 people make up each release team, with a mix of experienced and brand-new contributors.
My job as Release Lead is to organise, aid, and assist those that need to make decisions rather than doing so myself. I don’t decide what makes it into the release, but I enable those that do. I don’t make the rules for what is required of an enhancement, but I help the release team members who enforce and evaluate those rules. I also take on a huge number of administrative tasks: running meetings, getting the correct permissions for members, and fielding questions from community members. Later in the release, I’ll select the release theme and logo too.
I’m assisted by a number of Release Lead Shadows — four in the 1.24 release team. These are experienced contributors who have worked on previous release teams and help share the load of everything that needs to be done and are an invaluable source of advice and information about parts of the process I may be less familiar with.
The bulk of the team is organised into six sub-teams: Enhancements (who track all new features), CI Signal (who monitor CI throughout the release), Bug Triage (who manage bug reports as they come in), Docs (who manage documentation updates), Release Notes (who generate and edit the release notes), and Communications (who handle all external comms about the release). Each role has a lead, an experienced contributor in that area, and a number of shadows. The role shadows can be experienced themselves or are brand-new contributors.
One of the release team’s major functions, alongside our primary function of delivering a release, is to onboard and mentor new contributors. Every release we take on 10—15 people who may have never contributed to Kubernetes, or open source at all, and mentor them to becoming fully-fledged members of our community — many former release team members work in all aspects of the community. I myself joined Kubernetes, and open-source as a whole, via the release team shadow program in the 1.18 release team.
We have a role on the team explicitly to organise mentoring, our Emeritus Adviser. They are ultimately responsible for helping the role leads select their shadows, and be a point of contact and support for all shadows throughout the release. Finally, we’re joined by a Branch Manager from the Release Engineering subproject of SIG Release (the “special interest group” that the release team itself is a part of), who manages the mechanics of git management and running release CI jobs.
This is just the briefest overview of what our team is and does, and of course our in-depth documentation is available with all the details. If you’re interested in getting involved, the next Kubernetes release team will likely be looking for applicants in April or May this year, keep an eye on the developer mailing list for details closer to the time. In the meantime check out our excellent getting started documentation for more on getting involved in our community.
We don’t know yet what will be included in Kubernetes 1.24 when it is released, but the community is hard at work building the groundwork, and the release team is starting up to support them in delivering another great release of Kubernetes.