Nearly by the day two years ago, I joined my first Kubernetes release as part of the SIG Release - Kubernetes Release Team. K8s v1.17 - "the chillest release" was driven by Guinevere "Guin" Saenger, with a massive bag of positivity. I had the luck to start in the communications team ran by Mr. Rawkode aka David McKay/Flanagan.
I ended up within the release team after I started some minor contributions on the Kubernetes docs. Somehow it didn't felt like doing enough. Kubernetes was, at this point, already the central part of my professional career, and I needed to give something back to the community. So what to do when you are not strong on writing Go code? Getting lost for weeks in reading through all the SIGs, I found this small team that bundles together all of the community efforts and goes with all the contributors the last mile before releasing a new major K8s version.
From chill to bumpy roads
K8s v1.18 was the total opposite of v1.17. Therefore, Jorge Alarcon, the release lead for this cycle, gave the release a well-suited name, "A Bit Quarky". Still part of the communications team, I could learn a lot from Karen Chu to organize a little more bumpy release. BTW Karen designed The Illustrated Children's Guide to Kubernetes. The comms team is responsible for coordinating with the CNCF the press communication, organizing a short webinar with the release lead to update the community on the enhancements but most recognized, the release blog and feature blogs, highlighting some of the enhancements.
If I had known at this time that v1.18 was just the warmup for v1.19 - "Accentuate The Paw-sitive", I would visit before a guerrilla communications boot camp. Kubernetes v1.19 was my turn to step up as the comms lead. With Taylor Dolezal in the driver seat and many other great people in the single streams, we were ready to take this release. Blindfolded, my team and I started preparing the release communication, planned the communication dates and searching for feature blogs. Did I mention that we are talking about 2020? v1.19 was on its way right in the beginning of a global pandemic. We had to change the release schedule several times, and the overall contribution got swirled in an ocean of uncertainty. In addition, the change of the release cadence from 3 to 4 months, due to the discussion of the long-term support (LTS) of Kubernetes, was uncoordinatedly communicated. The release took 21 weeks, where 13-14 was expected. However, I learned that a community is always stronger than a single force like a pandemic, doesn't matter how disruptive this force is.
And I think that's also what "Accentuate The Paw-sitive" wants to underline!
The v1.20 release aka "The Raddest Release" (raddest: adjective, Slang. excellent; wonderful; cool), I joined the Bug Triage team as a shadow, while Jeremy Rickard steered the team through the new normal of a global pandemic crisis. Interestingly enough, the community recovered very fast from the turbulent start of the year and contributed a high number of enhancements, 42 in total (v1.19 made it to 34, v1.18 - 38, v1.17 - 22, I mean, what's going on?).
As I didn't feel like a Bug Triage guy, I switched to the CI Signal team for v1.21 and Joyce Kung showed us with an incredible high passion how to hunt and proactively solve flakes in the Kubernetes testing machinery. In total, I believe this release was boosted so much, and Nabarun Pal sovereignly steered it.
The whole community comes back more vital than ever, and therefore the release deserves so much the name "Power to the community". Still following the 3 months release cycle, blazing 51 enhancements were included in the release.
More comms in CI Signal
I have learned from the 1.19 release that stronger communication is always worth it, so when I stepped up to take over the CI Signal team for v1.22 I focused on this. Many releases ago, there was a CI Signal reporting tool in use (created by Alen Varkockova & Jim Angel) but somehow got forgotten. We buried it out of the dust, made some minor adjustments so that the tool didn't hit any GitHub limits, and reintroduced it to publish a weekly report on the CI signals. Also, it seems to be redundant to what we have on the dashboards; continuously pushing it to the k/dev email list and sig release slack, catches the contributors' interest from time to time. This was good support to solve faster flaking and failing tests. In addition, we set up a one-on-one responsibility with the release branch managers for each release cut during the cycle. With that, the communication was focused on an early indication of whether a release cut could be done or there were blockers on the road.
With 53 enhancements, Kubernetes v1.22 "Reaching new peaks", we reached a new peak :) As Savitha Raghunathan, the release lead of v1.22 said, COVID somehow gave the community an extra boost.
The finishing line
Now, after over two years in the Kubernetes release team, I end up in the release lead team, shadowing Rey Lejano for v1.23 together with Joseph, James and Menna. We currently expect the release of an early Christmas present at the beginning of December 2021, most likely with another record in the number of enhancements.
What will be the next steps? Well, I don't know, maybe another round with the release team or taking over more work from the release engineering team I have joined earlier the year, but never found "my" topic to work on yet.
Whatever it will be, I'm looking forward keep contributing with so many talented people and moving on this great open-source product. I believe the community approach is the way to go for any tools, software, systems, however, you want to call it. It is like this creativity method where you have to build on the ideas of others or create new ideas. This way, you open up continuously the solution space, reshape it, sort some stuff out and then find new ideas. Looking into the Kubernetes universe, I think this is the big bang that drives the whole ecosystem and keeps inventing (and reinventing) things.
How to get started with contributing to SIG Release?
Besides the roles mentioned before there are some more within the release team. Each of them has a handbook explaining in detail the expectations and tasks.
If you found something that you like, the next step is to inform yourself when the next release will be and when the shadow selection will start. Keep an eye on the Kubernetes #sig-release Slack channel and assign yourself to the k/dev group to not miss out on the following selection.
To shadow means to take part within a release team and learn the common tasks from the lead.
But there are so many other SIGs that need your help, there is a whole GitHub organisation and I'm pretty sure you will find something for your taste!
And if you are not sure, please feel free to reach out to me at the Kubernetes Slack; you will find me with my nickname @mkorbi or on twitter.