 Hello, hello, everyone. My name is Steven Augustus and I am one of your co-chairs for KubeCon, CloudNativeCon, and a virtual 2020. When I'm not reviewing your lovely talk submissions or putting together a program for what I truly believe is one of the best conferences in the world, I am a senior open-source engineer at VMware. Now, it's in the title, but let's go a little deeper on the open-source bits. My day-to-day is spending time in a open-source project that is near and dear to my heart, and you may have heard of it. It's called Kubernetes. So today I wanted to take some time to talk to you a little bit about the Kubernetes project, and more specifically the release cycle for the Kubernetes project. Now, in the community, I serve as a co-chair for SIG release, as well as one of the senior release managers. And what that means is, honestly, I have the opportunity to interface with a bunch of lovely people to manage a group of rock stars, really. So I wanted to give you a little bit of their view into the release cycle and some of the discussions that we've had across 2020. Now, something interesting happened in 2020, and I'm not sure that it has happened too frequently, if at all, in the project. And that's, we slowed down. We slowed down the release cadence during the 119 release, and we did it deliberately. We did it to give an opportunity for people to really live through the 2020 of it all. And in making that decision, it was not about technology. It's very much so about the people. And I think it's going to ring true as you view the talks across the week that the contributors, maintainers of the Kubernetes project very deeply care about the people who work on the project, the people who consume what we produce every day. Now, one of the interesting questions that was asked as we slowed down the release cadence, the slowdown of the release cadence resulted in what will be only three releases for the for the 2020 calendar year. And the question was, is this permanent? Is that something that's going to continue to happen? Right now, we have a set of folks that that are differing opinions. And I was interested in getting some feedback here, and kind of coalescing all of that into one place. Now, I decided to do something incredibly scientific. And I started a Twitter poll to ask, would you prefer three releases or four for the year? And I got some great responses. I got some really, really great responses, some well thought out ones, some funny ones, as well as offering options like releasing, releasing twice a year, releasing once a year, talking about LTS, releasing on a nightly basis, releasing on a weekly basis, right? So lots of different options to consider. And layered onto those options is what is best for our community? What is best for the people who have to produce Kubernetes? What is best for the people who are downstream contributor contributors to downstream projects? What are the what are the trade offs for end user communities that need to consume Kubernetes? What are the trade offs for vendors cloud cloud providers that are interested in consuming Kubernetes or publish distributions of Kubernetes? Now, I'm going to kind of rapid fire some of the feedback that was given. But firstly, I'll say that there was overwhelming support for three releases as opposed to four for the year. Now, one of the things that I consider as one of the co-chairs of SIG release is the overhead to actually crank the wheel that is Kubernetes, right? That is releasing a minor release of Kubernetes. And part of that is communication, a huge part of that is communication. Usually affectionately call the incoming release team lead the chief cat herder of the group. The release team is a group of somewhere between at any one cycle 25 and 40 people. Now, all of those people are one, we have to recruit those people. Two, all of those people are responsible for delivering feedback from the various SIGs, sub projects, component areas in the project back into SIG release. So that we can get an accurate picture of what's happening for right now the quarter and maybe later something different in terms of cadence. So one of the big things I consider is the overhead to actually spin up a team every cycle, right? That takes at least two weeks if we're if we're doing it quickly and a little more if we're considering holidays, feedback, reaching out to people doing interviews, so on and so forth. So that's one component of it. Now another component is the release engineering tooling, right? So some of the release engineering tooling that we use today has been in place from close to the inception of the project, right? So considerations around how we build functionality into new sets of tools and how we start to spin down the old, right? The goal being that the new tools are more sustainable, more likely to have to attract contributors to our group, so on and so forth, right? So also considering data, so SIG cluster lifecycle recently had a survey where the data does support that people would be interested in fewer releases. Now why is that? I think kind of with the 2020 theme, but also every other year, people are struggling to keep up. Now as a former, a former field engineer and solutions architect at cloud native leaders like CoreOS and Red Hat, I've had the opportunity to see up close what users have to deal with as they consider moving to Kubernetes or upgrading Kubernetes and the kind of work that's involved there from a company perspective, as well as the work that needs to not happen in order for that to happen. Moving to new infrastructure means that you spend less time on building for stability. It means that you spend less time building and deploying features, right? So that's something to consider from the end user perspective as well. Now for users, at least one of those release cycles that we have for the year, their focus is pointing somewhere else, right? And it's, as I mentioned, whether it's delivering features, delivering stability for their internal platforms, applications, and again, something that we need to consider. Now, something that I love that happened towards the end of the 119 release cycle is that we had an extended code freeze and we had an extended hold on thawing the code, essentially making Kubernetes, the Kubernetes, Kubernetes repo ready to accept merges again. So we have various tooling that allows us to gate merges on milestones, on whether or not something is approved, on whether the tests are failing or not. And I saw the opportunity both from the SIG release side, from the SIG testing side, from a slew of SIG chair component sub-project areas in improving the way that we test the infrastructure that we test upon. And that was a net positive for the project. So being able to build stability into more of the processes that we care about day to day, that we have to kind of live through day to day is important as well. Now, some people brought up the fear of accumulating risk and technical debt in the project. And to be frank with you, we've already done it. We've already done it. So I think this is a good opportunity for us to step back, look at open issues, look at things that are in previous milestones, look at things that are targeted as priority important long-term. And think about how to plan out those projects, think about how to deliver enhancements in a more sustainable way. So SIG responsibilities, things like the API policies, the feature graduation changes, making it possible for more people to consume Kubernetes releases, whether they be pre-releases, minors, RCS, the patch releases that come out monthly. All of that is kind of composed in this story, as well as driving down the rush to review during code freeze, testing very specific things more often, and figuring out what all of the downstream implications are for the things that we do day to day. So really in closing, I would ask you to be vocal about what you want as we consider changes to the release process. Have the conversation with us in Slack on the mailing lists across the SIGs. If you want to reach out via DM and chat about this, feel free, feel free to come to us because we want to make a decision and we want to make a decision considering everyone who's involved, whether it be a contributor, a maintainer, downstream consumer, end users, cloud providers. So come and play. Thank you for your time, everyone. Have a good day.