Laura Santamaria: Welcome to Cloud
Native Compass, a podcast to help

you navigate the vast landscape
of the cloud native ecosystem.

David Flanagan: We're your hosts.

I'm David Flanagan, a technology
magpie that can't stop

playing with new shiny things.

Laura Santamaria: I'm Laura
Santamaria, 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 SIGrelease in the Kubernetes project.

David Flanagan: Kubernetes is the second
biggest open source project in the world,

which means the only people being paid to
contribute to Kubernetes are the lawyers.

Laura Santamaria: 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.

David Flanagan: 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.

Laura Santamaria: David and
I are excited to have Kat on.

Kat is here.

Yay!

Hi, Kat.

You sound so excited.

Kat Cosgrove: I'm not well
known for my enthusiasm.

No.

Laura Santamaria: No, I know it's okay.

David Flanagan: Yeah, you're fitting
well with the Scottish audience

and the Scottish culture, because
you're dry as fuck, and I love

Kat Cosgrove: you.

Thank you.

Laura Santamaria: well, so for
those of you who don't know us, the

three of us used to work together.

And so this is going to 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 going to stick
to it, but we're going to find out.

So

Kat Cosgrove: We'll try

Laura Santamaria: yeah, why not?

David, do you have like a first question?

Otherwise.

We're just going to dive in, I don't know.

David Flanagan: Oh, yeah, we'll kick it
off with a nice low hanging fruit, easy

to answer, lubricate the conversation.

I've never used that before, ever,
and now that I've said it out loud,

Kat Cosgrove: lubricate.

Yeah, I think we regret that one.

Yeah.

File that away for Don't do it again.

Jesus.

David Flanagan: I was actually wanting to
make like a whiskey and bourbon intro I

couldn't quite connect the dots in my head

Laura Santamaria: So, so

David Flanagan: conversation

Laura Santamaria: our guests who
are joining us in the middle of

this conversation, we already
have been talking for about 40

minutes, including about bourbon.

So there was an attempt, David,
that was a entertaining attempt

at drawing us back to bourbon.

but maybe we should talk tech first,
then we can talk about bourbon

David Flanagan: All right

Kat Cosgrove: I don't love computers.

Laura Santamaria: Yeah.

What, it?

Who taught sand to think?

Who thought that was a good idea?

Kat Cosgrove: I thought
teaching sand I think was fine.

Letting the talking sand
communicate with other talking

sand, that's where we fucked up.

Laura Santamaria: Okay.

Kat Cosgrove: that's where
we veered off course, I

think

Laura Santamaria: sense.

Makes sense.

Kat Cosgrove: kubernetes.

Laura Santamaria: the

conversation.

David Flanagan: lubricating it up Let's
go No I'm not going to make that joke So

let's Kat you led the release our previous
release I think we're now back to releases

there was called I don't even know how
to pronounce it Uwubernetes Is that

Kat Cosgrove: Uwubernetties.

Yes.

I was the release lead for Uwubernetes.

David Flanagan: But you're
also continuing your work right

Kat Cosgrove: I am, I own the
release team subprojects now.

now I am the release leads.

It's, boss and mom and personal
assistant and, housekeeper.

Laura Santamaria: There you go.

There you go.

Kat Cosgrove: Yeah.

Laura Santamaria: So you want

to

Kat Cosgrove: is which

David Flanagan: so let's come at this
from both angles Let's understand what's

involved in leading a release naming all
the fun bits as well as the hardships

And then maybe we could 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

Kat Cosgrove: Sure.

So we do three releases a year.

each cycle is about four months long.

there's a week at ish and a
half of gap between each release

where we're not doing anything.

Which is, nice, but, 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 advisor.

The emeritus advisor'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 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's 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,

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 KEP 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.

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.

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.

Laura Santamaria: So you obviously then
get a lot of 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

Kat Cosgrove: I don't think new people

Laura Santamaria: coming through?

Kat Cosgrove: 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.

what drives people to go through
the release team as an entry

point is, it's very structured.

That's for sure a contributing factor.

Like 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 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
cause 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.

Laura Santamaria: course.

Of course.

Yeah, I

David Flanagan: get that And I was a
shadow for the 1 12 13 and 14 release

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

Kat Cosgrove: Oh, we get hundreds.

We get hundreds of applicants.

David Flanagan: 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 official

right And we were all volunteers but I
was the host of the Kubernetes office

hours and join and release is actually
a good way to do it keep up to date with

what is 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 it was a bit like the
Wild West like even to the point where

the enhancements team you just say Oh
what are we going to do in this release

And they're like Oh we don't know yet Oh
let's maybe pull in these ones And it's

very ad hoc and it's very we'll just see
what we can get done And it felt I don't

want to say wrangling cats but it did feel

Kat Cosgrove: it is.

it's so it's definitely more structured
now than it was when you were on the team.

And we also have far fewer sub teams now.

Now we only have four.

we used to have bug signal or
a bug triage and CI signal.

and there was a testing.

Subteam as well.

So we've deleted some subteams and
things are definitely much more

structured, but the herding cats
aspect, 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?

so many of those contributors
are just doing it for free.

David Flanagan: yeah that's the thing Like
everyone working on the Kubernetes the

only people paid for Kubernetes is the
CNCF staff So let's not touch that with

a particle However watching 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
Google Red Hat a couple of 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 is a feature going to make
it and they're replying as they can and

I get that That's just the nature of
open source as you said people don't

Laura Santamaria: it's the nature of

any

volunteering organization,
to be honest with you.

Like if you're a conference, like
no, no one's really paid to do that.

If 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, I don't know.

It is kind of an
interesting conundrum there.

David Flanagan: Yeah

If you want right Okay So when again
I'll come back to one more question

related to my time on it Cause that's
where most of my experience is And we

can talk about modern more of the modern
day stuff But the CI signal was a 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 the CI just falling over And you'd

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 and relevant is that still the case

Kat Cosgrove: 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 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 like a 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 like almost nothing to do
so little to do there's still something

there's still enough that we couldn't
just like can the whole roll but we just

rolled it in to 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 master blocking

test fails, yeah, it's still frantic.

But how frantic that is depends on the
SIG that owns that test that fails.

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 work over weekends.

So we will not.

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 a, an

RC, a release candidate cut.

cause why?

the release date is aspirational and
we're not gonna make our team miserable

to hit it cause nobody's paying us.

Laura Santamaria: 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 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 in open source

Kat Cosgrove: not that I
can, not that I can think of.

as well, 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 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.

Laura Santamaria: Yeah.

The only thing I can of that is even
remotely, I don't know if guaranteed is

the right word is the Ubuntu releases.

Cause they always do it in April
and October, but even then.

It's a whole month to hit, not a, like

Kat Cosgrove: not a single

Laura Santamaria: day.

Yeah.

Kat Cosgrove: right?

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, go line,

Laura Santamaria: Really?

Kat Cosgrove: yeah, the go project
does not tell us when there's

going to be an update coming.

We don't get any kind of advance warning.

the only time we get advance warning is
if it is due to, a CBE that affects us.

We will know in advance, but
we can't tell you that because

we all sign NDAs for that.

So like we, we can't
actually say anything.

but yeah, if Go updates.

and they update too close to the release
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, like three or
four Kubernetes releases in my time.

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.

We can, we can work around it.

It's no skin off my back to
delay a release for a week.

Laura Santamaria: Yeah.

Nobody's waiting for it that
hard or they shouldn't be.

If they maybe you should
go touch some grass.

Kat Cosgrove: 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

David Flanagan: why is there a
press embargo date when everything

is so open and transparent what is

Kat Cosgrove: No idea.

Wish I knew, but I think it's dumb.

So cause, 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, the logo

will get added to that PR like the day
before release, two days before release.

so it's not public, but if you
know how to look at GitHub, like

you can see it, you can see it.

I don't really get it like embargoing
interviews with the release lead.

fine, I don't really care.

But embargoing, just writings about
the release, which is all based

on information that is like very
publicly visible on GitHub seems

a little bit ridiculous to me.

I don't know.

I, it's smells like a formality
that's there to make the whole thing

seem more important than it actually

is

David Flanagan: think it's some weird
decision from someone who's worked in

Kat Cosgrove: So

David Flanagan: Press marketing and it's
yeah because I wouldn't name the company

but there's well known observability
company that always published or what's

new in Kubernetes the day before the
embargo was supposed to lift and obviously

the information is public Like it's like

they can

they can't force them to stop

Kat Cosgrove: Yeah.

What are you going to do?

What?

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 was, okay.

It irritates me in one
situation, 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

Laura Santamaria: Who
worked their butt four

Kat Cosgrove: who worked their butt
off for four months for probably

more like two or three years because
you've got to lead multiple sub

teams to end up as a release leads.

it's a lot of work and, it's unpaid work.

And 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.

Cause what enhancements made it has
been public for shit, four, six weeks

at that point because of code freeze.

So be my guest.

I don't care.

It's not.

I mean fight with the CNCF on it, but
for me, that's not not against the rules.

it's in public.

It's on

Laura Santamaria: Yeah.

It's easy 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,

Kat Cosgrove: 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 go look in
the Kubernetes website repo.

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.

Laura Santamaria: I mean, or.

You could join a SIG
and be There's that too.

like could be part of

Kat Cosgrove: You can go, yeah,
you could go snooping or you could

come do some free work for me.

Laura Santamaria: Free work.

Sounds good.

Free work.

Sounds good,

David

David Flanagan: just read the PRs a
lot less effort and then I can pump

them through AI and have to write my
own blogs and then a job done Right

Kat Cosgrove: Oh yeah.

Laura Santamaria: Well, but
I'm worth saying, David, you

could go do some free work.

Hint, hint, hint, hint.

Kat Cosgrove: Oh yeah.

Come do some free work for me.

We did have a drive by AI PR issue a

Laura Santamaria: Oh, I did.

David Flanagan: Does not surprise

Laura Santamaria: mean,
every open source project has

David Flanagan: Especially
during Hacktoberfest right

I'm assuming it was right

Laura Santamaria: geez.

Kat Cosgrove: we do not participate
in Hacktoberfest, for the same

reasons that lots of people don't
participate in Hacktoberfest anymore.

and it was not a Hacktoberfest thing.

It was some like 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 like free drive by PRs.

And say, Oh, this one's on the house.

If we can just say, you use us.

And, so two problems with that one,
absolutely fucking not without talking

to us first, no, two, the PR was bad.

it's entirely automated.

It doesn't actually think or
learn or understand the 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 projects
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 ahold

of

David Flanagan: I think the question
when to do this is not as your

product useful and could we get
value from it that could be a yes

but is that the right way to do it No

Kat Cosgrove: like is to be yes.

Yeah, that's 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 work, but you can't just rock

up with an unasked for PR and say,
Hey, can we use you for marketing?

Laura Santamaria: So I, I will say I
know someone and I am not naming names.

I know somebody who for a little while.

Was doing auto pep eight on Python stuff.

This was a long time ago.

They were doing auto pep eight on
Python code in random open source

projects and just submitting PRs.

They would just run auto pep eight,
you know, pull it down or run auto

pep eight, submit the PR next project.

And it was, I think at the time,
I don't how many they did, but it

definitely was 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 autopip.

It was just autopipping.

I don't know.

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 how many decisions,
all of that is overwhelming.

So if you're going to 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

David Flanagan: is the biggest

Kat Cosgrove: rude.

David Flanagan: 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 million line PR with

this feature that no one has ever even
talked about and you're just you're going

to accept this because I've all this work
and it's no like there's maintenance that

comes in the back of that people have to

then

it's so frustrating

Laura Santamaria: yeah.

Also what development team ever
would let you do that in general?

Kat Cosgrove: okay, no,

Laura Santamaria: There are, there are

Kat Cosgrove: if

you were getting.

Laura Santamaria: but like the, the good

Kat Cosgrove: you're at a tiny startup
and you're like a piece of shit 10x

engineer like the lone wolf That like
all of your co workers fucking hate you,

but you've been there since the dawn of
time and you're you know that xkcd comic

with the like one tiny project You're
that guy at this 15 person startup.

And so yeah, even though you're
awful and toxic and shitty they

feel like they can't get rid of you.

They'll tolerate that guy
opening a 15 000 line drive by PR

Laura Santamaria: Yeah,

Kat Cosgrove: that refactors the whole
goddamn thing without talking to anybody.

Laura Santamaria: 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

David Flanagan: and a team
is the important bit here

right I just because I look my

pull

requests the Rockwood Academy
monorepo and I am a dick

Laura Santamaria: Well,
David, I mean, like, that's

David Flanagan: Christmas

break I rewrote every microservice with a
slightly different tool but that's because

I was having fun at my project there's
no contributions external contributions

Laura Santamaria: there

Kat Cosgrove: Yeah.

Your own stuff.

It's fine.

Like your own

David Flanagan: I was just making
sure I didn't qualify the That was it

Laura Santamaria: are

David Flanagan: can

continue now

Laura Santamaria: Like I, I literally
on some of my commit messages, it's

just more, more, cause I don't know what

Kat Cosgrove: Oh yeah.

Laura Santamaria: Like
I'm just, I'm screwing

Kat Cosgrove: I don't even, you put words.

I just type like a, there may not

even be a

commit message.

Like

David Flanagan: progress and as the and
I'm like I'll edit it later I edit it

Kat Cosgrove: Why not?

I'm pushing the main the whole time.

Laura Santamaria: I use commitizen,
to kind of force myself to have

a commit message, but you know,
cause that's installed globally.

So it asks me everywhere, even
including in my like personal repos,

Kat Cosgrove: You're much kinder
to your future self than I am.

Laura Santamaria: Not as
much as you would think.

You should see some of the comments I

David Flanagan: the lesson here
is do as we say, not as do.

Laura Santamaria: Like Right.

Okay.

There we go.

There's the lesson.

That's perfect.

There we go.

David Flanagan: All right so let's
get us back on track just a moment

Laura Santamaria: We were, we had a track

David Flanagan: we pretend sometimes but
Kat has said we'd love more people to

come and help out with SIG release So
let's assume that want people to listen

to this enjoy it find it funny and then
but hopefully help the project You're

both active members of SIGS to the best
of my knowledge I was previously one

but what I'm going to do is say 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

going to be fame It's definitely not
money It's not glory why do you do this

Laura Santamaria: all
Kat, you or me first?

Kat Cosgrove: Oh, go ahead.

Laura Santamaria: you want me to go first?

Okay.

I, I will admit that right now,
just due to, chaos in my 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 going to get to use.

I do it for that.

And granted, I, I probably have a
little bit of a, I guess I hate for

myself considering how many projects
I do this with, for everybody

Kat Cosgrove: take a vacation.

Laura Santamaria: What?

Kat Cosgrove: Please take a vacation.

Please take

Laura Santamaria: Eventually.

I, I help run, I don't remember
how many I help run now.

And meetups and, and lots of other things
along with open source and, and now I'm

also starting a job with more open source.

So it's kind of like, it's just I am

Long story short, that's why

I

David Flanagan: you're busy

Laura Santamaria: What?

Oh yeah, sorry.

There's that too.

I don't know anymore, like, it's
just Where can I be of help?

Where can I be of service?

And that's where I end up.

And unfortunately,

Kat Cosgrove: When was the
last time you were bored?

Laura Santamaria: Me?

Bored?

Kat Cosgrove: Yeah,

Laura Santamaria: I don't
know what that word means.

Kat Cosgrove: I think you
need to experience boredom.

Laura Santamaria: 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.

Anyway, Kat, you probably have a le I
don't know if you have a less altruistic

version of this because I think some
people think I'm insane, but you

Kat Cosgrove: you know what?

I, I got involved by accident.

a long time ago, 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 and
people were freaking out online

and it was six in the morning and I
was like, people are wrong online,

Laura Santamaria: Oh no.

Kat Cosgrove: because people
were not thinking 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.

initially I got involved because
people were wrong on the internet and I

didn't like seeing people being wrong.

Laura Santamaria: comic right there

Kat Cosgrove: it is 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 of removing
a Docker shem 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 nonstop, both like 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 gonna fix it.

Laura Santamaria: Would you

Kat Cosgrove: Yeah, I
like solving problems.

Laura Santamaria: would you say that this
itches the, like a, like an ADHD itch?

Because there's always

Kat Cosgrove: Oh yeah,

Laura Santamaria: and you,

Kat Cosgrove: there's always something.

yeah, there's absolutely
always something going on.

I'm ignoring nine Slack
messages right now.

All from the Kubernetes Slack.

Laura Santamaria: Don't, don't distracted!

Don't get distracted!

Kat Cosgrove: 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.

Laura Santamaria: we go, there's, there's
the ad. There's the, the plug here at

the end

David Flanagan: we've
never published a short

Kat Cosgrove: we are trying

to

David Flanagan: to episode but
that right There's going to

Laura Santamaria: it.

That's it right

Kat Cosgrove: Go for it.

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 chaotic.

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.

Laura Santamaria: There you

Kat Cosgrove: So just because
somebody was one of the original

three committers to Kubernetes and
they've been at Google for 25 years,

you still got to tell that guy, no,

Laura Santamaria: You also

Kat Cosgrove: just tell him, no.

Laura Santamaria: they're wrong, right?

Kat Cosgrove: Yeah.

Tell him he's wrong.

Tell him no.

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.

David Flanagan: Awesome Great
answers Thank you both Two very

different answers both great
answers Laura wants the world better

Kat Cosgrove: neither of
them psychologically healthy.

David Flanagan: people and cat's
doing it more with a sword and go but

Laura Santamaria: Well, I mean,
I think that actually sums

the both of us up fairly well.

David Flanagan: yeah

Kat Cosgrove: it does.

Laura Santamaria: it does, it does

Kat Cosgrove: Yeah.

That's why we work well

Laura Santamaria: Yeah,

David Flanagan: no both doing great
work Yeah that's fantastic And I love

that I started just from people don't
understand the Docker gem deprecation yeah

Kat Cosgrove: Yeah, just mad as
hell tweeting at six in the morning.

Laura Santamaria: with no coffee.

that's the line that I'm not sure.

I believe Kat is the, is that you were

Kat Cosgrove: Oh no.

Laura Santamaria: with no

Kat Cosgrove: all of my worst tweets have
happened first thing in the morning, like

while I'm waiting for my coffee to brew.

All of the worst ones.

Laura Santamaria: Okay, that's fair.

All right.

I can believe that one.

I think it's more, the ten tweet thread is
the one I'm not so sure about, but okay.

Kat Cosgrove: Oh yeah, no.

I was banging that out while I
was waiting for my French press.

Laura Santamaria: There you go.

There you go.

Yeah.

Yeah

David Flanagan: All right I have on
emore question and then we'll see

what happens after that But Kubernetes
what was the last release 132 133 33

Kat Cosgrove: 33.

David Flanagan: obviously Kubernetes has
been a thing now for the best part of 10

years Yeah 10 years Almost 11 is there
ever going to be a 2.0 or is backwards

compatibility It's something that release
team tries to enforce or encourage

I

Laura Santamaria: it's like, I
wish you didn't ask that question.

I could see it.

Kat Cosgrove: 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.

David Flanagan: mean there is a

Kat Cosgrove: don't
know if there ever will

David Flanagan: sorry No

Kat Cosgrove: 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 enhancement sub-project would have.

A say there, I think.

but I don't know.

I think it's more fun to just stay as a 1.

0 forever.

David Flanagan: no there's this
list of things I would love to

see that were they weren't okay
at the time And I'm like we need

Kat Cosgrove: Oh, I know.

David Flanagan: but can't because
we're so far My favorite example who

knows what the default DNS policy
is in a Kubernetes cluster right

Kat Cosgrove: I do not

David Flanagan: it's cluster first
However there is a DNS policy called

default And I'm like can we please
not 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 That's it Things like this

Kat Cosgrove: But, yeah.

David Flanagan: we should draw a line
and say we have a golden opportunity

Laura Santamaria: we found your

David Flanagan: yeah I
should join a release

Kat Cosgrove: yeah.

Here's the thing, David.

Baby, baby.

Baby, it's an open source project.

PR is welcome.

Open that PR like you want it.

You want to see the change?

Open the PR,

David Flanagan: because would say
let's just deprecate the policy create

a new one with

a name and then make it 1 35 And that's
a that's an okay solution too but

Kat Cosgrove: Yeah.

And then you're, do it open a cap, file
an issue and then fight with friends

David Flanagan: I'm gonna do and then
I'm gonna have that ready for cube

con and drum up rally and protest
to get this thing changed but yeah

Kat Cosgrove: Okay.

Laura Santamaria: and

David Flanagan: do you have any
other questions Laura that you

would like throw towards Kat

Laura Santamaria: No, I'm just
enjoying having the two of you on

the same call with me right now.

That's

David Flanagan: All right I'm
going to be selfish and ask

a closing

not tech related at all
just because I would love

to your

answers because I need a new book I need a
new movie and I need a new album to listen

to so catch recommendations catch super
hits I don't know what we'll call it but

give me a book a movie and an album please

Kat Cosgrove: book.

I would say, have you read Jeff
VanderMeer's Southern Reach?

Do you

like

hard sci fi?

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 want to go see Nosferatu
because you don't like horror movies

and you can't take your children
to see a scary black and white art

house horror flick, I think that
Kiss Bang is criminally underrated.

And you should, if 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

David Flanagan: Awesome And are
they like industrial EDME Are they

industrial metal What which genre of
industrial do they fit in Good metal

Kat Cosgrove: more like industrial
metal they do a lot of collabs with

like they've done collabs with bad
omens and poppy as well So if you

like either of them, you'll 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

David Flanagan: 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

Kat Cosgrove: nice

David Flanagan: All right thank
you so much for your time today Kat

Kat Cosgrove: Thank you.

Laura Santamaria: Woohoo!

Thanks for joining us.

David Flanagan: If you want to keep up
with us, consider us subscribing to the

podcast on your favorite podcasting app,
or even go to cloud native compass fm.

Laura Santamaria: And if you want
us to talk with someone specific or

cover a specific topic, reach out
to us on any social media platform

David Flanagan: and tell next
time when exploring the cloud

native landscape on three

Laura Santamaria: on three.

David Flanagan: 1, 2, 3.

Don't forget your compass.

Don't forget

Laura Santamaria: your compass.