0:00 Introduction

0:00 Welcome to Cloud Native Compass, a podcast to help you navigate the vast landscape of the cloud native ecosystem. We're your hosts. I'm David Flanagan, a technology magpie that can't stop playing with new shiny things. I'm Laura Santa Maria, a forever learner who is constantly breaking production. David is supposed to be working on something open source at this point, at least according to our current guest, Kat Cosgrove, one of the sub project leads for SIG release in the Kubernetes project. Kubernetes is the second biggest open source project in the world, which means the only people being paid to

0:08 Meet the Hosts and Guest

0:34 contribute to Kubernetes are the lawyers. In this episode, we didn't even bring up Rust, but we did get to talk with Kat about the release process and what being a maintainer is like, including burnout and handling drive by PRs. Enjoy this episode. And for a bit of fun, one project has caused numerous delays to the Kubernetes release. Can you guess what it is? Enjoy. David and I are excited to have Kat on. Kat is here. Yay. Hello. Hi, Kat. Yay. You sound so excited. I'm not well known for my enthusiasm. No. No. I know. It's okay. Yeah. You're well

1:10 with the Scottish audience and the Scottish culture because you're dry as fuck, and I love it. Thank you. Thank you. Well, so for for those of you who don't know us, the three of us used to work together, and so this is gonna be a highly entertaining podcast, I think, more than anything else. But we are trying to talk about the Kubernetes release cycle on this, and who knows if we're gonna stick to it? But we're gonna find out. So We'll try. Yeah. Why not? David, do you have, like, a first question? Otherwise, we're just gonna dive in. I don't know.

1:24 Kubernetes Release Process Overview

1:40 Oh, yeah. We'll kick it off with a nice low hanging fruit, easy to answer. Lubricate the the conversation. I've never used that before ever. And then I said it out loud. Lubricate. Yeah. Yeah. Yeah. I think we regret that one. Yeah. File that away, so don't do it again. Jesus. I was actually wanting to make, like, a whiskey and bourbon intro, and I could quite connect the dots in my head about looking at the conversation. So our guests who are joining us in the middle of this conversation, we already have been talking for about forty minutes, including about

2:11 bourbon. So there was an attempt, David. That was a entertaining attempt at drawing us back to bourbon. But maybe we should talk about tech first. Then we can talk about bourbon again. Alright. I don't love computers. Yeah. What is the who who taught sand to think? Who thought that was a good idea? I thought teaching sand to think was fine. Letting the talking sand communicate with other talking sand, that's where we fucked up. That's where we veered off course, I think. Yeah. Sounds makes sense. Okay. I'm trying to lubricate the conversation. Lubricating up. Right? Let's go.

2:48 No. I'm not gonna make that joke. So let's cat you led the release, our previous release. I think we're now back to releases there. It was called, I don't even know how to pronounce it, Kubernetes. Is that right? I was the release lead for Oh, Kubernetes. But you're also continuing your work, right? I am. I own the release team sub project now. Now I am the release lead's boss and mom and personal assistant and housekeeper. There you go. There you go. Yeah. You went to All right. So let's cover this through both angles. Let's understand

3:22 Challenges in Kubernetes Release Management

3:25 what's involved in leading a release, naming all the fun bits as well as the hardships. And then maybe we can talk broader about just how much effort goes into each release, the people involved, and how people can inevitably contribute and help out. Because, obviously, this is a fast moving project. Kubernetes has not stopped in many years. And I'd love to get into that in more detail. Sure. So we do three releases a year. Each cycle is about four months long. There's a week ish and a half of gap between each release where we're not doing anything, which is nice. But

3:58 yeah, we don't really slow down at any point during the year, which is unfortunate for us, but fortunate for people who rely on Kubernetes. If you want new updates frequently. And the release team is not as large as it used to be, but it is still quite large. The team itself is made up of the sub project owners, which is myself and Grace, then a release lead and an emeritus adviser. The emeritus adviser's job is just kind of emotional support for the lead because it is like it's stressful. It's highly public. You are the face of the release. You have to

4:08 Team Structure and Roles

4:32 talk to the press. You have to deal with the CNCF sometimes. You get random DMs from people you don't know and have never spoken to, but they have a lot of power and that can be overwhelming for some people. And beneath the release lead, they have their own shadows. They have between four and six release lead shadows who are people who have experience leading a sub team within the release team and may lead a release in the future. There are also several sub teams. There is a docs sub team responsible for making sure that any KEP with

5:03 user facing changes has documentation. That is a hard requirement. We don't allow KEPs with user facing changes into the release unless they have documentation. There's a communications team that's responsible for managing things like feature blogs, making sure the release webinar happens, managing the press embargo, handling the release lead schedule for interviews with the press, that kind of stuff. Then an enhancements team that catalogs and makes sure that each CAP has all of its requirements met by certain deadlines, like code freeze and test freeze. And release signal, which is bug hunting, basically, making sure that our CI looks good before any cut.

5:45 And if it is bad for whatever reason, if there's a test failing, they chase down the SIG that owns it and make sure that bug gets fixed. Each of those teams has between four and six shadows and a lead as well. So ultimately, the release lead is managing something like 25 to 30 people for four months. It is a lot of work. It can be very overwhelming. Any role on the release team is mostly just project management, but some of them do require like some degree of technical expertise. You have to know how to use Git

6:17 on basically any team, but you don't have to be an expert in Kubernetes or an expert in open source. It's a pretty common entry point for new people contributing to Kubernetes for the first time. I don't think it is a good way to contribute to Kubernetes for the first time if that's really overwhelming. But people do it all the time and survive. I just don't think it's the easiest or best way to get started in the project. But it is it's a it's an overwhelming place to be. It's a burnout factory too. So you obviously then get a lot of

6:29 Open Source Contributions and Burnout

6:47 floaters coming in and out, a lot of new contributors, people you have to kind of guide ish. Do you think a lot of it has more to do with just how structured and how short of a time commitment it is that you get so many new people coming through? I don't think the short time commitment is a consideration because for a lot of these people, by the time they're halfway through the release cycle, they think four months is a long time and they disappear. Yeah. What drives people to go through the release team as an entry

7:17 point is it's very structured. That's for sure a contributing factor. It's very clear how to get involved and what getting involved gets you, which is org membership. Anybody on the release team has to be a Kubernetes org member. So if you are not an org member and you are selected for the release team, we just give you org membership with no previous contributions. I think the bigger contributing factor to people choosing the release team is how public and how flashy it is, and they think it looks good on a resume. And I think that's something that the project doesn't think about

7:49 enough. We are the second largest open source project in the world. We are the largest Golang based open source project in the world. And we need to accept that, that we are no longer a little tiny baby. We are in fact like an absolutely enormous force within open source and people want that on their resume. So they go through the release team because it is an easy way to get a very public aspect of the Kubernetes project on your LinkedIn profile. Don't love that because people do misuse it. Of course. Of course. Yeah. I get that, David. And I was a

8:25 shadow for the one twelve, 13, and 14 release. You wanna come Well, actually, the reason I stopped contributing is because I kept signing up for other different groups. I only ever did release columns, but I couldn't get accepted into any other group because I think there was a phase where there were so many people applying. It was really Oh, we get hundreds. We get hundreds of applicants. So I just stopped applying, but I would definitely love to come back. I didn't do it to get it on my resume. I was the official host of the Cooper official. Right? And we

8:51 were all volunteers, but I was the host of the Kubernetes office hours and joining the release team is actually a good way to keep up to date with what was happening. But I think one of the things that shocked me the most is, like, the release team is super structured, but the people working on issues and contributing code, was a bit like the Wild West. Like, to the point where the feature enhancements team, we just say, oh, what are going to do in the best release? And they're like, oh, we don't know yet. Let's maybe pull

9:16 in these ones. And it's very ad hoc and it's very we'll just see what we can get done. It felt like I don't want to say wrangling cats, but it does feel like wrangling cats. It is. It's definitely more structured now than it was when you were on the team. We also have far fewer sub teams now. Now we only have four. We used to have bug signal or bug triage and CI signal, and there was a testing sub team as well. So we've deleted some sub teams and things are definitely much more structured, but the herding cats aspect,

9:44 absolutely still a problem. It's still an enormous problem. Some SIGs are harder to herd than others, but it is very much still an issue. And that's just the nature of open source. Right? Many of those contributors are just doing it for free. Yeah. That's the thing. Like everyone working on the Kubernetes program, normally people paid for Kubernetes. It's the CNCF staff. So let's not touch that with a particle. However Yeah. Working working on Kubernetes are volunteers. They have day jobs. Some of them are fortunate enough to be paid to be working on Kubernetes, which is great for the people that work at

10:15 Google, Red Hat, a couple other big ones. Right? But most people are just yeah, I'll try and get this done. I'll do it at the weekend. I'll do it when I get home. You're asking for questions on documentation updates and as a feature gonna make it, and they're replying as they can. And I get that. That's just the nature of open source, as you said. Like, don't. It's the nature of any I don't know. Volunteering organization, to be honest with you. Like, if you're running a conference, like, no no one's really paid to do that if

10:42 you're doing it as a community conference, and it's when somebody gets time. And so you have to flex around that quite a bit. So I don't think it's I don't think it's unique to open source. The only thing unique about open source, I'd say, is how, specialized it can get when you start really getting down to it. So Mhmm. I don't know. It is kind of an interesting conundrum there. Yeah. Right. Okay. So when again, I'll come back to one more question related to my time on it because that's where most of my experience is,

11:06 Managing CI and Bug Triage

11:11 and we can talk about modern more of the modern day stuff. But CI Signal was the team that I had the most sympathy empathy. I'm not sure which for. They felt like they were I felt like they were constantly firefighting with everybody pushing up new bugs, new features, all these things, and CI just falling over. And you actually take a step back to understand just what is happening, how many commits per day there are, how many CI runs, how many GitHub actions that is. It's such a huge, daunting task to keep all of that green

11:41 and relevant. Is that still the case? Yeah. It's gotten better. As we've gotten better at writing tests, not everything is blocking now, which is an improvement. But one of the things that made bug triage and CI signal easier, easy enough that we could eliminate them as separate teams and merge them, was actually just a change in the way we manage those teams. We used to handle all of that through a Google spreadsheet, which was a big, shitty, miserable nightmare. The whole release was managed in a single Google Sheet. Anything from enhancements tracking to CI signal to bug triage was all just like

12:21 a bunch of messy automation dumping into a Google Sheet. And six or seven releases ago, maybe six releases ago, we canned that and switched over to using GitHub projects board and some significantly smarter automation for our test grid, which is what the CI signal team was looking at. And now Bug Triage has almost nothing to do, so little to do. There's still something. There's still enough that we couldn't just can the whole roll, but we just rolled it into CI signal and now it's much easier for everybody to deal with. So it's less frantic, but every time there's a bug or a

13:02 master blocking test fails, yeah, it's still frantic. But how frantic that is depends on the SIG that owns that test that failed. Some SIGs are larger and more well staffed and more responsive than others. And again, it's open source, so everybody has a day job. Everybody has kids and family and pets to take care of. And an important thing that I think not just the public, but a lot of people even within the project don't realize is that by charter SIG release will choose to delay a release before we choose to make the release team

13:36 work over weekends. We will yeah, we it is. We will not run our team ragged just to squash a bug and make a release cut. We will just delay it. We've done it in the past. We'll do it again. I personally have been very quick to say no, delay an RC, a release candidate cut, because why? The release date is aspirational, and we're not gonna make our team miserable to hit it because nobody's paying us. Yeah. I have to remember like, I guess I'm kind of showing that maybe I don't remember everything about open source. What open source project

14:16 does have set releases like this? Really, like, this like, something this big. Even, like, the Linux kernel doesn't say, like, we're guaranteeing a release on this day. No one really does that. Not an open source. Not that I can think of. They don't guarantee it. Some projects will give you their target release dates for every release for the year. Whereas we only give you a target date at the beginning of the release cycle. We're discussing the timeline for the next Kubernetes release right now. So within the next week or two, you'll know when the next Kubernetes releases target

14:55 date is. Some projects will give you their target dates for a whole year, but I don't think anybody guarantees that. I don't think even not it's not even that common with closed source, like paid nobody would guarantee a release date. That's ridiculous. That's a liability. Yeah. The only thing I can think of that is even remotely I don't know if guaranteed is the right word is the Ubuntu releases because they always do it in April and October. But even then, it's a whole month to hit, not a Yeah. Not a single day. Day. Yeah. Right?

15:28 Release Delays and External Dependencies

15:28 Yeah. And we can't we would never be able to do that anyway because honestly, the most common cause of a Kubernetes release being delayed is Golang. Really? Yep, the Go project does not tell us when there's going to be an update coming. We don't get any kind of advanced warning. The only time we get advanced warning is if it is due to a CBE that affects us. Will know in advance, but we can't tell you that because we all sign NDAs for that. So, we can't actually say anything. But yeah, if Go updates and they update too close to the release

16:03 date so that we can't have we really want at least three days for a new Go version to soak before we call it good and release. If they cut it too close, we have no choice but to delay. I've seen that delay three or four Kubernetes releases in my Pretty common cause. And we have no control over that. We have no way to predict it because we don't get any kind of advanced warning from the Go team, Which is fine. They don't have to give it to us. Can like, we can work around it. It's no skin

16:30 off my back to delay a release for a week. Yeah. Nobody's waiting for it that hard or they shouldn't be. If they are, maybe you should go touch some grass. Yeah. Touch grass. The media, because they get it means that we push their embargo date back and that's like a little bit irritating. But yeah, it's not the end of the world. Like, you're not going to die because you had to wait another release. Why is there a press embargo date when everything is so open and transparent? What is No idea. Wish I knew one. I think it's dumb.

16:51 Press Embargoes and Publicity

17:02 So, because So we try to keep it secret, right, with the release blog. The release blog will be staged in a PR two weeks before an actual release date. And then the little blurb that the release lead writes and the logo will get added to that PR like the day before release, two days before release. So it's not public, if you know how to look at GitHub, like you can see it, you can see it. I don't really get it. Embargoing interviews with the release lead, fine. I don't really care. But embargoing just writings about the release,

17:42 which is all based on information that is very publicly visible on GitHub, seems a little bit ridiculous to me. I don't know. It smells like a formality that's there to make the whole thing seem more important than it actually is. Yeah. I think it's some weird decision from someone who's worked in So press market and and it's yeah. It's because I wouldn't name the company, but there's a well known observability company that always published or watched new Kubernetes the day before the embargo was supposed to lift. And obviously, the information is public. Like, it's not like they can

18:14 they can't force them to stop it. Yeah. What are you gonna do? Yeah. There's nothing you can do. Like, you are welcome to do that. I don't love it. It's a little bit irritating. It's okay. It irritates me in one situation and one situation only. When people go and rip quotes out of the unpublished release blog and publish it, that hurts my feelings a little because it's stealing the thunder from the release lead who- Yeah. Worked their butt off for- Who worked their butt off for four months, for probably more like two or three years

18:47 you've got to lead multiple sub teams to end up as a release lead. It's a lot of work and it's unpaid work. The only reward that the release lead gets is publishing that release blog with their cute little couple paragraphs about the release theme and naming it something fun. So I don't like it when people rip that out of the unpublished blog. That's rude. But just talking about what enhancements made it go ahead, because what enhancements made it has been public for shit, four, six weeks at that point because of code freeze. So be my guest.

19:28 I don't care. It's not, I mean, fight with the CNCF on it. But for me, that's not against the rules in It's to find if you know. I guess there is a little bit of that if you know where to look. And I mean, everyone always talks about how complex and convoluted the Kubernetes GitHub can be for somebody who isn't familiar with how everything is structured. So I guess there's a little bit of that, maybe. But for listeners who want to get a sneak peek of what's going to be in the release before the actual release date, the trick is you

20:03 go look in the Kubernetes website repo. Yep. And the release blog will be there in PRs a couple weeks before the release, as well as any unpublished feature blogs. And if you want to know which enhancements made it, you go to the Kubernetes enhancements repo and go look there. I mean, or you could join a and be there's that too. I mean, like, could just be part of it. Yeah. You could go snooping or you could come do some free work for me. Free work sounds good. Free work sounds good. David. I've I've just read the PRs. There's a lot

20:35 less effort. And then I can pump them through AI and have to write my own blogs and then the job done. Right? Oh, yeah. Easy. But I'm worth saying, David, you could go do some free work. Hint. Hint. Hint. Hint. Oh, yeah. Come do some free work for me. We did have a drive by AI PR issue a little while Oh, did. I you does not surprise me. I mean, open source project has been Especially during Hacktoberfest. Right? I'm assuming it was right. Oh, geez. I know. We do not participate in Hacktoberfest for the same reasons that lots of people

20:46 AI in Open Source Documentation

21:02 don't participate in Hacktoberfest anymore. And it was not a Hacktoberfest thing. It was some paid product that uses AI to improve the docs for open source projects for style guide compliance and all that. But it is a paid product and they do these free drive by PRs and say, Oh, this one's on the house if we can just say you use us. And so we have two problems with that. One, absolutely fucking. Not without talking to us first. No. Two, the PR was bad. That's entirely automated. It doesn't actually think or learn or understand the

21:41 structure of the Kubernetes docs website. So it was making changes to a bunch of generated files and some things that like admittedly our bad are how we like to write things, but not at the time weren't included in our style guide. So if you own an AI based project about docs for open source projects, please do not drive by PRs. Just talk to us for God's sake. We're so easy to get a hold of. Just talk to The question when they do this is not is your product useful and could we get value from it? And that

22:13 The Challenges of Open Source Contributions

22:18 could be a yes, but is that the right way to do it? No. It could easily be yes. Yeah. That's the problem. Yeah. Like, I would love to see, like, some toil reduced in open source projects. Right? Like, style guide compliance is an obnoxious thing to review for. It's very ticky tack, and it's hard to train new people to do that because it's this laundry list of like really specific tiny things that they have to comply with. And they're going to screw up a lot at first until they have the style guide memorized. And it would be great to reduce that

22:52 work. But you can't just rock up with an unasked for PR and say, hey, can we use you for marketing? So I will say I know someone, and I am not naming names. I know somebody who, for a little while, was doing AutoPep eight on Python stuff. This was a long time ago. They were doing AutoPep eight on Python code in random open source projects and just submitting PRs. They would just run AutoPep eight, you know, pull it down, run AutoPep eight, submit the PR. Next project. And it was I think at the time, I don't remember

23:06 The Auto PEP 8 Incident

23:30 how many they did, but it definitely was a, like, what are you doing? Why are you creating more work for a maintainer? You're not even asking. You're not, like, looking at what they have. This was long before black and any of those those projects that would lint for you and do the auto pip. It was just auto pip eight. I don't know. I I keep thinking about just how many how many decisions an open source maintainer has to make in the day. How many, like, reviews they have to do and all that, but just the pure idea of

23:49 The Overwhelming Decisions of Maintainers

23:59 how many decisions. All of that is overwhelming. So if you're gonna come in with a random auto generated PR and ask them to make another decision rather than talking to them first. It is it is the epitome of Which is the biggest problem with open source. Whether it's automated or not is that people feel, I use your project as open source. I can come along with a 500,000,000 line PR with this feature that no one has ever even talked about. And you're just expecting, oh, you're gonna accept this because I've done all this work. And

24:01 The Etiquette of Open Source PRs

24:29 there's no like, there's maintenance that comes on the back of that. People have to then Also Ugh. It's so frustrating. Yeah. Also, what development team ever would let you do that in general? No, There are others that do this, but the good ones- If at a tiny startup and you're a piece of shit 10x engineer, the lone wolf that all of your coworkers fucking hate you, but you've been there since the dawn of time. You're You know that ex KCD comic with the one tiny You're that guy at this 15 person You're brilliant. So, even though you're awful and toxic

25:04 and shitty, they feel like they can't get rid of you. They'll they'll tolerate that guy opening a 15,000 line drive by PR. Yeah. That refactors the whole goddamn thing without talking to anybody. I don't know. I just I always look at some of these and I go like, where did you learn to do development in a team? Like I think and a team is the important thing here. Right? And I just because I look at my Rawkode Academy Mono Repo, and I am a dick. David, I mean like that's- Over the Christmas break, I rewrote every microservice with a slightly

25:37 different tool, but that's because I was having fun at my project. There's no contributions, external contributions. Yeah. Your own stuff, it's fine. Yeah. Like, your own stuff. I'm just making sure I didn't qualify for the fish part of the stuff. We can continue that. Like, I I literally on some of my commit messages, it's just more more. Because I don't know what else. Right? Like, I'm just I'm just screwing it right now then. You you put words. I just type, like, There you know, because that's installed globally, so it asks me everywhere, even including in my, like,

26:19 personal repos. You're much kinder to your future self than I Not as much as you would think. You should see some of the comments I'm looking here is do as we see. Sometimes we think. Right. Okay. There we go. Yeah. There's the lesson. That's perfect. There we go. Alright. So let's get us back on the track for just a moment. We were we had a track. We pretend sometimes. But Kat has said we'd love more people to come and help out with sick release. So let's assume that we want people to listen to this, enjoy it, find it funny,

26:39 Personal Experiences in Open Source

26:48 and then but hopefully, help the project. You're both active members of six to the best of my knowledge. I was previously one, but what I'm gonna do is say right now. Why do you both do it? What is the reward, the gooey feeling? What if you could say to someone, do this because. Right? It's not gonna be fame. It's definitely not money. It's not glory. Why do you do this? Alright. Kat, you or me first. No, go ahead. Do you want me to go first? Okay. Yes. I will admit that right now, just due to chaos in my

27:19 life, I haven't been very active. I do it because I like helping people. That's just it's a thing. I like teaching people. I like helping people. I don't like sitting on my hands and watching someone else do something for me. I want to do it myself, and I want to help somebody get somewhere. So I do it for the I helped somebody else out today. I answered somebody's question. I built something that someone else is gonna get to use. I do it for that. And granted, I I probably have a little bit of a I guess, a hate for myself

27:54 considering how many projects I do this with, for everybody who knows. A vacation. What? Please take a vacation. Eventually. I I help run don't remember how many conferences I help run now. And meetups and and lots of other things along with open source. And and now I'm also starting a a job with a more open source. So it's kind of like, it's just who I am. Long story short, that's why I do busy. What? Oh, I'm podcasting. Sorry. It's up to I I don't know anymore. Like, it's just where can I be of his help? Where can I be of service?

28:27 And that that's where I end up. And, unfortunately, I last time you were bored. Me? Bored? Yeah. I don't know what that word means. I think you need to experience boredom. Well, but then I have a book. I have a crocheting project. Like, I will unplug. That's different. I still am helping. Does that count? Okay. Okay. Anyway, Kat, you probably have a I don't know if you have a less altruistic version of this because I think some people are thinking I'm insane. But you know. You know what? I got involved by accident a long time ago,

28:56 The Accidental Involvement in Kubernetes

29:01 before I was actually involved in the Kubernetes project. We announced a deprecation for an aspect of the project that had been there since the dawn of time. We announced the deprecation of the Docker shim, which was a little software shim that allowed you to use the entire Docker stack as your container runtime. If you're relatively new to Kubernetes and that sounds ridiculous to you, good. It should sound ridiculous. That should never have been a thing. But we announced the deprecation for this and it was really poorly received. People were freaking out. Twitter was big at the time

29:37 and people were freaking out online and it was six in the morning. And I was like, people are wrong online. Oh no. Because people were not freaking out about the right thing. They were misunderstanding what the Docker shim is. They were misunderstanding what Docker is in relation to a container runtime. And they were misunderstanding how this would actually impact both cluster administrators and like regular developers that may work inside of containers, but don't actually touch Kubernetes. A lot of people thought we were deprecating Docker as if an open source project has the power to shut down a private business.

30:12 Initially, I got involved because people were wrong on the internet, and I didn't like seeing people being wrong. TV comic right there. It is. So, like, people were wrong online, and I was like, I'm not standing for this at six in the morning before I've had any coffee. So I thumbed out a tweet, like 10 tweets long, and it went wildly viral, for tech Twitter at least. And I got dragged into SIG Contributor Experience, a SIG that I no longer touch, really, to write some blog articles explaining what was actually going on, the actual implications

30:45 of removing the Dockershim and why people were misunderstanding and freaking out online. From there, SIG Release liked the way I handled that from a communications perspective and asked me to come shadow on the comms subteam for version 1.22. And then I just never left because it turns out that being on the release team is a constant barrage of somebody is wrong on the internet or I see this glaring problem that everybody else is just stepping around. I know how to fix that. I will go fix that. So there's just it is an onslaught. It is

31:24 nonstop, both trying to solve technical issues and interpersonal issues. And it just does not get boring at all, ever. So I just never left. I just kept doing that until they gave me a fancy maintainer title. And then I went and did the same thing in Sigdocs, which is why I'm a tech lead over there. And now we're working on unfucking the way we generate our reference API docs for the same reason. It is a problem and nobody else has bothered to fix it for years. So I'm going to fix it. You say that Yeah. I like solving problems.

31:58 Would you say that this itches the like an ADHD itch? Because there's always something going on and you, like There's always something on. Switch a ton. Yeah. There's there's absolutely always something going on. But I'm ignoring nine Slack messages right now, all from the Kubernetes Slack. Ping. Don't don't get distracted. Don't get distracted. Who are asking me for something, all of them will get it. But, yeah, it's just if you like chaos and you thrive in chaotic environments, Sig Release may be for you. There we go. There's there's the ad. There's the the plug at here at the end. We've never

32:17 The Chaos of SIG Release

32:34 published a show as a prelude to an episode, but that right there is going out. That's it. That's it right there. Go for it. Yeah. It's it's not always chaotic. We're trying to make it less chaotic. We're actively making changes to to be less chaotic, but it is very you're you're all over the place at all times by its nature. Another important thing for newcomers in SIG release is if you are on the release team, you need to be real comfortable not being afraid of people that you might consider to be Kubernetes celebrities. There you go. So just because somebody was

33:07 one of the original three committers to Kubernetes and they've been at Google for twenty five years, you still got to tell that guy no. Y'all just him no. Tell they're wrong. Right? Yeah. Tell him he's wrong. Tell him And if he pushes back, then you can come crying to your release leader. You can come crying to me and we'll take care of it. But you do got to not be afraid of people like that. Awesome. Great answers. Thank you both. And two very different answers. Both great answers. Laura wants to make the world a better

33:35 place. Of them psychologically healthy. Lots of people. And Kat's doing it more with a sword and go Well, I mean, I think that actually sums the both of us up fairly well. Yeah. Actually. It does. It does. It does. Yeah. That's why we work well together. Yeah. Exactly. No. You're both doing great work. That's And I love that it started just from people don't understand the talker sham deprecation. So Yeah. Just mad as hell tweeting at six in the morning. With no coffee. That's the line that I'm not sure I believe, Kat, is the is the you

34:06 were tweeting. Yeah. With no All of my worst tweets have happened first thing in the morning. Okay. That's while I'm waiting for my coffee to brew. Yeah. All of the worst ones. Okay. That's fair. Alright. I could believe that one. I think it's more the 10 tweet thread is the one I'm not so sure about. But okay. Oh, yeah. No. I was banging that out while I was waiting for my French press. There you go. There you go. Yeah. Yeah. Alright. I have one more question. Okay. And then we'll see what happens after that. But Kubernetes,

34:31 Kubernetes 2.0 and Backwards Compatibility

34:34 what was the the last release? January, '1 '30 '3? '30 '3. Obviously, Kubernetes has been a thing though for the best part of anything. Can't ten years? Yeah, ten years. Almost eleven. Is there ever going be a two point zero or is backwards It's something the release team tries to enforce or encourage. It's like, I wish you didn't ask that question. I could see it. So here's the thing. That's not my call. Yeah. It's, it is not my call and it never will be. Like, I don't get to say when we finally bump the major version. I mean,

35:13 there is a list. Don't know if there ever will be. Sorry. We don't enforce things like backwards compatibility. Like we, we don't enforce anything really with respect to the technical implementation of an enhancement. It is absolutely not within our purview. Who does have control over that technically is SIG architecture? The enhancements subproject would have a say there, I think. But I don't know. I think it's more fun to just stay as a one point zero forever. There's just a list of things I would love to see that were They worked okay at the time and we

35:51 need to change this, we can't because we're so far. My favorite example. Who knows what the default DNS policy is in the Kubernetes cluster? Right? I do not. It's cluster first. However, there is a DNS policy called default. And I'm like, can we please help fix this? And the default one made sense at the time. It means use the default DNS resolution of the host. Like, fine. Sure. It should be host first or whatever. But this thing things like test. You should just draw a line and say, we have a golden opportunity. We found your bar. I've actually joined

36:20 a release team. Here's the thing. Going over. Maybe got your bar. Baby, it's an open source project. PR is welcome. Open that PR. Like, you want to see the change? Open the PR. Right. But that's someone would say, let's just deprecate the default policy, create a new one with a name, and then make it 135. And that's a that's an okay solution too. Yeah. And then you're do it. Open a cap, file an issue, and then fight with friends and get them caught But I'm gonna have that ready for KubeCon and drum up a rally and protest to get this thing

36:51 changed. But yeah. Okay. And and Do you have any other questions, Laura, that you would like to throw towards Kat? No. I'm just enjoying having the two of you on the same call with me right now. That's all. Yeah. Alright. I'm gonna be selfish and ask a cool an not tech related at all just because I would love to know your answers. Okay? And because I I need a new book. I need a new movie, and I need a new album to listen to. So catch recommendations. That's super hits. I don't know what we'll call it, but get me a a book,

37:07 Book, Movie, and Album Recommendations

37:19 a movie, and an album, please. Book. I would say have you read Jeff Vandermeer's Southern Reach? Do you like hard sci Excellent. You should read, Jeff Vandermeer's Southern Reach. It was originally a trilogy. However, he just released a fourth book a little while ago. I just finished it. It's exceptional. Yeah. Go read Jeff Vandermeer's Southern Reach. Movie. I have seen Nosferatu twice. I'm gonna say go see Nosferatu. If you don't wanna go see Nosferatu because you don't like horror movies and you can't take your children to see a scary black and white arthouse horror flick,

37:55 I think that Kiss Bang is criminally underrated. It's not a horror movie. It's a thriller kind of drama starring Robert Downey Jr. Before he played Iron Man. It's very good. It's funny. You should go watch that album. I don't know. Do you like industrial? Okay. Are you familiar with the band Health? You are now. Go listen to Health. Any of their records, but their most recent one is great. They're very And are they like industrial EDME? Are they industrial metal? What genre of industrial do they fit in? Metal. Industrial do they fit in? Metal. Okay. More like industrial metal.

38:31 They do a lot of collabs with like, they've done collabs with Bad Omens and Poppy as So if you like either of them, you will also like Health, but Health is significantly more industrial and Bad Omens is significantly more metal. I don't know. I've seen him like four times. Cool. That'll keep me busy for the next few weeks with my travel. So again, selfish question, but I'm glad I asked now. Nice. Alright. Thank you so much for your time today, Kat. Thank you. Woo hoo. Thanks for joining us. If you wanna keep up with us, consider subscribing to

38:51 Conclusion and Farewell

39:00 the podcast on your favorite podcasting app or even go to cloudnativecompass.fm. And if you want us to talk with someone specific or cover a specific topic, reach out to us on any social media platform. Until next time when exploring the cloud native landscape on 3. On 3. 1, 2, 3. Don't forget your compass. Forget your compass.