►
From YouTube: Kubernetes Release Engineering - 2022-06-07
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everyone
today
is
7th
of
june
2022.
I
guess-
and
this
is
the
release
engineer
meeting
and
I'm
your
host
for
today,
and
I
hope
I
can
remember
all
these
steps
and
everything
otherwise
that
all
gonna
help
me
as
well
and
welcome
everybody
and
I'm
gonna
post
in
the
chat.
The
link
for
the
meeting
agenda.
A
A
B
I'm
very
new
to
kubernetes
meeting
and
seek
engineering
so
trying
to
explore
more
on
these
things
and
happy
to
see
your
people.
C
Yeah
hi,
I'm
pandey
raja
here,
I'm
also
from
india.
So
I
I
used
to
contribute
before
kubernetes
and
the
cncf.
C
D
Yeah
hi
there.
This
is
my
first
meeting,
I'm
mohammad.
I
met
some
of
you
gone
earlier
last
month,
but
yeah
I've
already
started
doing
some
work
and
one
of
the
things
we've
been
working
on
is
the
agenda
so
talk
about
it
later.
E
Well,
regarding
the
release
manager
for
125,
there's
still
not
the
release
range
manager
for
175,
we
are
still
and
discussions
to
see
who
has
the
time
and
availability
to
take
on
the
job,
and
we
are
also
trying
to
figure
out
how
the
actual
team
would
look
like
will
look
like.
So
we
are
hoping
we
can
bring
some
of
the
new
people
that
have
expressed
becoming
release
manager,
circuits
and
maybe
have
some
of
them
shadow,
the
125
branch
manager,
but
we
are
still
conforming.
The
team.
A
Okay,
I'm
gonna
give
you
one
quick
update
like
the
past
few
days,
some
jobs
like,
for
example,
the
ci
build
that
builds
the
and
push
the
virtual
markers
was
failing,
and
that
was
doing
for
like
an
issue
regarding
the
signatures
that
we
are
using.
Besides,
we
are
using
ephemeral
keys.
A
The
six
star
full
show
was
deployed
a
new
version
in
production,
and
that
was
had
a
breaking
change
for
versions
below
cosine
versions,
below
1.8.0
we're
not
going
to
work,
and
in
that
was
our
case.
The
k
promo
and
the
ci
job
like
the
crow
one
ci
build,
was
using
cosine
1.7.2
dependency
and
that
brokes
our
jobs.
A
F
So
what
so
one
awesome
to
hear?
Thank
you
for
working
on
all
of
the
updates.
I
saw
some
of
the
the
prs
flying
around
the.
I
guess.
The
question
I
have
is
around
compatibility
expectations.
F
A
For
prevention,
for
the
future
is
like,
I,
I
would
say,
was
more
like
an
issue
on
our
side,
maybe
we'd
like.
Maybe
we
need
to
follow
the
the
full
show
and
record
and
all
that
they
want
the
thing
star
releases
and
watch
for
the
the
breaking
changes
and
also
like
up
to
date
like
having
everything
up
to
date
as
soon
as
possible.
A
That's
the
the
amazing
stuff.
I
I
also
work
on
the
sick
story
and
I
didn't
see
like
for
the
upcoming
full
show
and
recorded
this
there's.
No
breaking
changes.
That's
gonna
affect
us,
but
for
the
future
we
need
to
keep
our
eye
on
the
the
the
ex
the
full
post.
Your
release
as
well.
F
So
I
I
think,
because
we
have
some
overlap
and
folks
who
are
contributors
to
both
yourself.
I
would
push
back
on
that
statement
a
little
bit
and
say
that
for
a
v1
and
change
if
we
are
or
if
there
is
an
expectation,
I
know
that
that
is
an
open
question.
If
there's
an
expectation
of
semver
compliant
versions,
then
I
would
not
expect
the
breaking
change
and,
if
they're-
and
if
that
did
happen,
then
I
would
that
I
would
ask
one
is:
is
what
we're
depending
on
adhering
to
semver,
is?
F
If
not,
is
there
a
reason
why
not
so
on
and
so
forth,
right
having
that
discussion
is
worthwhile.
I
think
I
think
if
it
is
a
dependency
where
the
expectation
is
that
there
there
will
be
some
for
compliance,
then
we
should
have
that
conversation
between
teams.
E
I
can
add
a
little
bit
more
to
that.
So
there
are
two
factors
here.
The
first
one
is
we
built
the
library
to
sign
our
artifacts
and
that
library
is
built
at
a
point
that
is
really
close
to
the
cli
in
cosine,
and
the
breaking
of
cosine
into
independent
libraries
has
not
been
going
as
fast
as
anyone
would
have
liked.
E
There
are
some
plans
to
start
working
on
moving
some
of
the
functionality
inside
of
the
cosine
binary,
its
own
libraries
and
repo
and
ship,
some
of
that
functionality
to
the
six
or
six
store
ripple,
and
we
should,
in
the
end
end
up
using
that.
That's
the
first
one,
so
we
built
our
library
precisely
to
shield
ourselves
from
some
of
the
changes
in
the
code
that
have
been
happening
so
fast.
But
this
was
more
of
a
change
in
the
the
app
yeah
in
the
api
strategy.
E
I
think-
and
that's
the
first
one
and
the
second
one
is
so
six
star
has
not
yet
reached
ga,
and
since
it
has
not,
it's
not
officially
generally
available.
So
we
can
still
expect
some
breaking
changes
to
happen
and
we,
the
expectation,
is
that
sixer
will
become
ga
around.
E
I
think
one
month
or
so
and
after
that,
so
I
I've
seen
some
of
the
work
involved
in
that
and
and
while
people
are
trying
to
avoid
breaking
changes
like
this,
we
still
are
open
to
to
suffering
some
some
some
breaking
change
from
now
and
then,
but
after
hca.
We
should
not
see
that
anymore.
A
F
Okay,
that
that's
good
to
know.
I
think
that
the.
F
F
So
again,
going
back
to
the
expectations
of
that,
but
but
again
I
get
it
so
just
as
long
as
we
are,
I
I
guess,
keeping
a
steady
eye
on
on
the
ga
and
and
if
it's
only
going
to
be
within
a
month,
then
I'm
less
concerned
but
but
yeah.
It
is
something
that
we
should.
We
should
keep
a
steady
eye
on.
A
Yeah
now
just
to
reinforce
here
like
we
are
running
the
other
dependencies
like
up
to
date
for
everything
like
and
this
morning.
We
also
release
the
release
sdk
that
have
the
codes
that
we
use
in
the
k,
promo
and
then
also
in
the
release
repository
as
well,
and
those
are
like
up
to
date.
F
So
so,
yes,
I
mean
keeping
keeping
them
up
to
date
is
fine.
The
the
problem,
and
I
mean
we
have.
We
have
mechanisms
like
dependables
running
on
most
of
our
repos
as
well.
The
problem
is
with
you
know,
with
depend
abod
if
it's
doing
an
automatic
bump
or
something
like
that
you
can
be
like
okay.
Well,
yes,
I
like
this
squash
and
merge.
I
don't
like
this,
ignore
this
minor
version
ignore
this
major
version
right,
if
we're
pulling
in,
if
we're
pulling
in.
F
What's
what
are
effectively
major
version
changes
in
the
minor
versions,
we
don't
have
the
we.
We
don't
have
the
mechanism
to
be
able
to
to
say
that
when
reviewing
prs
like
getting
the
libraries
or
getting
the
libraries
up
to
date
is
not
so
much
a
problem,
it's
the
expectation
that
you
have
when
you
keep
those
libraries
up
to
date
right
now.
We
don't.
We
don't
have
an
expectation
of
compatibility
right.
G
Yeah
I
was,
I
was
just
curious.
It
was
mentioned
that
it
was
failing
a
lot
of
ci
bills
and
I'm
not
sure,
is
cosine
signing
everything
like
on
all
ci
bills,
or
should
it
only,
for
example,
fail
when
it's
fading
on
releases
instead
of
yeah
oldest
gi
jobs.
So.
F
Yeah
so
so
to
explain
the
part
that
I
understood,
because
I
didn't
dive
into
the
debugging
too
much
on
the
the
cosign
side,
but
to
explain
the
part
that
I
understand
is
the
so
we
have
a
suite
of
built
jobs
right
for
for
kubernetes
kubernetes
right,
so
those
are
build
jobs
that
are
running
across
each
of
the
supported
release
branches,
so
so
dev
or
or
the
master
branch,
as
well
as
everything
that
you
know
the
within
the
three
or
four
sku
that
we
that
we
support
right.
F
So
each
of
those
branches
build
roughly
roughly
every
few
hours.
There
is
a
build
so
for
the
for
the
development
branch
there
is
both
a
full
build
and
a
fast
build
which
the
fast
build
only
produces
amd64
artifacts
right.
The
artifacts
that
come
out
of
these
jobs
include
the
fun
fun,
tarballs
and
bits
container
images
and
the
version
markers
right.
So
the
version
markers
are
only
written
when
we
have
proven
that
we
are
able
to
get
all
the
previous
artifacts
right.
F
F
It
will
recognize
that
the
build
has
happened
already
and
and
exit
the
build
early
right.
So
what
happens
when
the?
So
this
is
happening
in
the
signing
or
signing
verifying
portion
of
the
the
container
image
build
what's
happening
there
is
that
we
don't
get
a
clean
build,
so
we
never
roll
the
version
marker
forward.
So
if
there
are
changes
that
are
expected
in
newer
versions
of
mainline
right,
those
changes
aren't
reflected,
or
rather
the
the
artifacts
don't
exist.
The
the
version
marker
doesn't
exist.
The
artifacts
don't
exist
from
that
version.
F
Marker
from
that
sha.
That's
that's
at
the
head
of
the
master
branch,
which
means
any
job
that
depends
on
the
version
markers
to
derive
that
information
are
any
jobs
that
may
depend
on
the
version
marker
to
derive
that
information
or
the
content
on
the
main
line
to
be
ahead
of
where
whatever
the
latest
build
was,
will
not
work.
A
G
That's
a
lot
of
clock,
but
I'll
I'll
reread
it
and
and
listen
to
it
again
to
fully
understand.
What's
I
understand
the
version
markers,
but
I've
not
fully
understand
myself
yet
how
how
that
is
used
in
different
parts,
but
that's
just
because
I'm
new
to
the
project
but.
F
We
have
written
rewritten
a
an
explainer
for
this
actually,
so
I
would
take
a
read
of
this
and
see
if
that
tracks
and
if
it
doesn't,
let
us
know
we'll
clean
that
up,
but
essentially
any
any
job
can
depend
on
these
version
markers
across
anything,
that's
running
in
kubernetes
or
elsewhere
right,
so
those
jobs
will
often
have
like
a
like.
F
You
know,
within
the
first
few
steps,
they'll
have
a
fetch
right
and
the
fetch
will
will,
you
know,
will
curl
or
some
sort
of
deriving
of
the
version
marker
and
version
and
attempt
to
use
that
to
either
pull
a
container
image
or
pull
down
some
code
content
or
something
like
that
and
then
start
its
own
job
right.
So
what
you'll
see.
F
It's
gonna
fail
at
the
fetch
right
or
or
it
will
not
fail
at
the
fetch
it'll
pass
at
the
fetch,
because
it's
pulling
an
old
version
of
the
build
and
the
change
that
you
expected
to
see
is
not
there.
So
your
tests
will
continue
fail.
G
F
A
Okay:
let's
go
to
the
open
discussions
level
about
the
testgrid.json
exporter.
I
Yeah
hello,
so
you
might
have
seen
I
think,
a
couple
of
weeks
ago,
a
new
repository
merged.
I
So
the
tesco
json
exporter-
this
is
right
now
a
tool
in
development.
So
it's
not
not
deployed.
I
There's
also
a
pull
request:
updating
the
readme,
but
it's
kind
of
still
in
progress
to
clarify
about
the
goals
and
so
on.
But
essentially
this
will
be
used
or
it
should
be
used
for
the
release
team,
but
maybe
also
for
release
engineering
to
get
basically
a
one-page
overview
about
the
relevant
test
grid
boards
so
that
we
have
a
grafana
dashboard.
That
shows
just.
H
I
You
open
up
the
issues
I
created.
I
think
five
issues
some
of
them
are
just
to
align
with
kubernetes
in
general,
so,
for
example,
use
like
the
community-owned
infrastructure
to
post
the
container
images
and
stuff
like
that,
but
also,
for
example,
the
grafana,
dashboard
and
yeah.
I
just
want
to,
I
don't
know,
share
the
five
issues.
If
you
have
like
any
input
would
be
awesome
to
leave
any
comments.
I
One
of
one
of
the
tasks,
maybe
or
one
of
the
interesting
like
topics
would
be
to
define
use
cases
when
to
use
this
tool
and
when
to
use,
for
example,
cp,
maybe
which
we
use
right
now
in
as
a
pilot
project
and
when
to
use
just
a
regular
dashboard.
Because
I
think
just.
J
H
I
I
J
F
So
yeah
a
general
note.
For
again
this
might
be
a
sig
release,
meeting
type
note
versus
the
release
engineering
meeting.
But
a
general
note
is
that
if
we
have
agreed
to
to
ingest
the
project
via
donation,
I
feel
that
that
is
also
an
in.
You
know:
signaling
our
intent
to
utilize
the
project
and,
and
with
that
said,
for
the
areas
that
the
project
affects
we
should.
We
should
be
reaching
out
to
them
directly
and
kind
of
encouraging
the
usage.
F
It
gives
an
opportunity
to
one
kind
of
strengthen
the
the
bond
between
the
the
folks
who
are
donating
the
tool-
and
maybe
you
know
in
certain
examples
and
and
somewhat
in
this
example,
rolling
off
of
the
release
team
to
are
rolling
into
a
new
role
in
the
release
team,
to
kind
of
make
sure
that
there's
a
handoff
between
these
two
things
and
then
you
know
and
then
finally,
it
gives
an
opportunity
to
kind
of
build
up
that
contributor
or
that
set
of
contributors
portfolio
of
contributions.
Right.
K
I
think
a
dolph
will
just
gave
the
update
earlier
that.
A
Thanks
joseph
next
one,
can
I
get
some
help
in
getting
over
the
line
ahmed?
Can
you
explain
this
one.
D
Yeah,
so
that's
a
fix
for
getting
own
aliases
automatically
synced
across
repositories
by
pulling
the
aliases
from
pre-builders,
it's
a
little
bit
different
to
how
we
create
their
own
aliases
today.
So
it
requires
some
changes,
one
of
them
being
that
instead
of
people
crafting
aliases
manually,
they're
gonna
correspond
to
get
a
theme
exists
so
yeah.
If
you
scroll
down
a
little
bit,
not
pr
there's
a
nice
reading
to
explain.
What's
going
on.
F
So
I
remember
this
conversation
kind
of
like
floating
by
my
inbox.
The
there
are
comments
that
need
to
be
resolved
and
I
think
the
the
primary
ones
are
that
you
should.
So,
if
you,
if
you
think
about
the
whoever
is
thank
you
so
if
you
think
about
the
the
usage
of
like
the
readme
generator,
the
sigs
generator
or
the
groups
generator
for
a
community,
for
example,
right
in
that
template
is
also
there's
a
there.
F
There's
a
begin
and
end
custom
content
section
in
that
template,
so
that
there
is
a
portion
of
the
template
that
can
be
generated
and
there's
a
portion
of
the
template
that
you
can.
You
can
do
manually
right,
okay
and
and
for
for
cigs,
where
it
doesn't
fit
where
the
template
doesn't
fit,
what
they
do
perfectly
we're.
Actually
one
of
them
where
we
may
include
custom
content
because,
like
the
release,
team
works
a
little
differently
than
any
of
the
other
structures
in
kubernetes.
F
The
the
same
could
be
said
for
for
this.
I
think
I
think
to
summarize
some
of
the
comments
it
was.
We
don't
want
to
auto
generate
aliases.
F
There
are
situations
where-
and
I
say
we
as
in
we,
as
in
the
kubernetes
community
on
mass-
does
not
want
to
generate
auto-generate
aliases,
because
different
strokes
for
different
folks
kind
of
thing
right.
The
the
aliases
are
going
to
look
different
depending
on
what
repos
you
go
to.
F
To
give
you
an
example
for
release
engineering
in
for
release
engineering
we
may
give
release
manager
associates
a
certain
level
of
access
on
specific
repos,
but
we
may
not
give
them
approval
access
on
other
repos,
because
they're
potentially
you
know
so
like
test
infra,
for
example,
test
infra
includes
files
that
are
potentially
destructive,
they're
the
the
signing
verifying
build
push
kind
of
things
for
production
that
we
may
not
want
to
give
people
approval
rights
to
right.
F
So
in
that
situation,
in
that
situation
with
similarly
named
aliases,
you
kind
of
get
you
fall
into
a
state
that
you
don't
actually
want
right.
So
you
should
provide
people
the
option
to
generate
their
aliases
but
not
enforce
it.
F
I
can
say
for
sig
release
in
particular,
there
are
places
where
I
would
love
for
the
aliases
to
stay
up
to
date,
all
the
time
and
it
and
it's
one
of
those
things
that
like.
If
you
look
at
the,
if
you
don't
mind
carlos,
if
you
can
open
up
the
the
sig
release,
repo.
F
F
Right
so
this
is
this
is
a
really
good
example
of
like
we
have
at
least
five
places
that
you
have
to
add
a
release
manager
to
and
update
aliases
and
yada
yada
yada,
where
it
would
be
good
to
like,
say:
hey
they're,
onboarding
cool,
run
this
tool
and
that
will
sync
the
team
right
or
that'll
issue
the
prs
to
sync,
the
team
kind
of
thing
right
that
that
being
able
to
have
that
would
be
great
to
keep
the
teams
up
to
date
over
over
time,
especially
if
people
are
onboarding
off-boarding
and
there
are
different
people
handling
the
case
each
time.
F
D
Okay,
so
yeah
so
auto
generating
owners
is
not
even
in
scope,
because
I
don't
think
that
should
be
automatically
made.
Humans
should
be
making
that
change
with
own
aliases.
I
think
the
getup
teams
should
be
available
in
every
repo
with
space
at
the
end,
for
people
to
add
whatever
custom
content
they
want.
F
F
Just
tracking
the
breadcrumbs
yeah,
I
think.
D
Yeah,
initially,
repositories
will
have
to
be
manually
onboarded
for
auto
generation,
so
start
small.
Let's
see
how
useful
it
is
if
it
turns
out
to
be
a
success,
it's
worthwhile
going
through
the
hassle
of
making
sure
things
are
in
good
of
teams.
F
F
For
for
us,
we
also
for
us
we're
like
reasonably
good
about
our
github
teams.
We
have
they're
pretty
well
segmented,
we
don't
we
don't
necessarily
reference,
all
of
them
for
reviews
and
things,
but
the
the
teams
are
pretty
well
segmented.
So
this
is
something
that
so
just
in
terms
of
scope
and
and
why
bob
left
some
of
those
comments.
F
This
is
the
need,
because
we
have
kind
of
these
disparate
repos
across
multiple
orgs
is
definitely
there
for
sig
release
the
suggestion
that
it
might
do
enforcement
or
should
do
enforcement
or
synchronization
in
some
way
shape
or
form
is
under
the
purview
of
of
the
github
management
subproject
within
sig
contributor
experience.
F
Okay,
so
that's
that's
kind
of
why
he
was
highlighting
it,
so
I
will
say
for
cigarettes.
I
definitely
want
this,
but
I
can't
speak
for
the
entire
community.
Well,.
D
F
That
is
not
strictly
true.
Okay,
so
are
you
saying
that
the
tool
has
to
live
there
or
what
content
specifically?
Are
you
referring
to.
D
Yes,
so
the
tools
live
there
and
they
read
the
config
folder.
So
let's
say
somebody
turned
up
today
right
what.
D
F
F
The
teams
are
right
yeah,
so
the
tool
doesn't
need
to
live
there
and
that's
like
that,
will
also
help
you
push
it
across
the
line.
So
I'm
looking
at
some
of
these
things.
F
F
There's
there's
there's
bash
that
could
probably
be
go
as.
F
Yeah
the
so
I
would
say,
don't
do
the
generation
so
like
what
we
tend
to
do
is
you
know
like
sing
so
for,
for
example,
like
the
sig
release,
owner's,
alias
or
the
k,
you
know
the
k,
sig
release
or
the
are
the
k,
release,
aliases
or
roughly
the
source
of
truth
for
the
rest
of
the
sig
release,
repos
right.
Okay,
you
can
try
using
sig
release
as
the
source
of
truth
for
your
tests
and
do
the
generation
there.
F
I'm
fine
to
have
the
generation
happen
on
the
sig
release
level,
the
you're
getting
some
some
pushback,
because
the
the
pr
also
includes
generation
for
everything
within
kubernetes.
D
F
So
yeah,
if,
if
you
can
d
scope
to
just
sig
release,
then
we
can
I'm
I'm
happy
to
have
like
hobby.
You
know
or
like
it's
kind
of
like
to
pre-flight
it
here
and
and
firm
it
up.
D
Okay,
interesting
thoughts,
I'll
go
and
take
another
look
cool.
A
Cool
thanks
moving
on
starting
the
road
for
salsa
level.
Three,
let's
go
for
you.
E
Yeah,
just
one
really
quick,
so
in
our
in
the
cell
cycle
landscape.
Well
I'll
link
it
in
a
little
bit.
We
have
targeted,
we
have
targeted
compliant
with
salsa
level
2
by
the
time
we
release
kubernetes
124
and
we
didn't
get
all
the
way
there,
but
we
did
most
of
the
work
that
we
required
to
get
things
ready
to
to
do
it.
E
For
those
of
you
who
are
not
familiar
with
the
efforts
outside
like
a
security
framework
too,
to
ensure
we
are
releasing
things
in
a
more
secure
manner
and
it
specifies
certain
security
levels
which
we
have
tried
to
tie
to
certain
kubernetes
releases,
so
123
with
the
salsa
level,
one
which
I
get
that's
at
a
level
two
for
124
and
for
125.
E
Alongside
the
technical
and
programming
tasks
we
had
to
do
to
reach
salsa
level
one,
we
had
to
do
a
lot
of
consensus,
building
and
working
with
the
community
and
writing
the
cups
and
all
of
that,
all
of
them
work
alongside
the
producing
the
necessary
at
the
stations
and
the
next
one
for
124
is
the
non-programming
work
was
mostly
around
setting
up
and
speeding
up
the
necessary
infrastructure
to
be
able
to
sign
and
generate
the
required
tokens
for
the
identities
we
needed
to
to
use
for
signing,
and
that
leaves
the
road
to
salsa
3
for
125,
and
I
think
we
can
make
it.
E
E
F
F
Yes,
I
I
think
that
we
should
encourage
the
contributions
here.
I
think
that
this
kind
of
dovetails,
too,
with
figuring
out
our
stance
on
inclusion
for
release
manager,
associates,
I
think
some
of
the
I'm.
I
don't
want
this
to
be
taken
as
gatekeepey
or
anything
or
hopefully
it
doesn't
come
off
that
way,
but
I
think
that
the
some
of
the
best
people
positioned
to
do
this
work
are
release
managers
because
they
have
context
of
so
many
parts
of
the
system
that
these
pieces
need
to
be
integrated
into.
F
So
I
think
that,
as
part
of
this
work,
we
need
to
better
define
as
a
team,
the
process
for
inclusion
to
release
manager
associates
as
well
as
moving
through
that
contribution
ladder
and
as
well
as
off-boarding
and
like
what
what
inactivity
looks
like
and
what
off-boarding
should
look
like
as
a
result.
E
Yeah,
I
agree
absolutely
and
some
especially
some
of
the
some
parts
require
access
in
order
merely
to
test
them,
so
that
that
is
one,
but
we
also
have
other
things
that
do
not
require
that
access.
So
I'm
planning
to
split
the
work
into
a
smaller
pieces
as
I
can
so
then
anybody
interested
in
control.
F
F
And
I
will
again
stress
the
the
need
to
kind
of
build
out
this
team.
I
think
that
you
know
a
lot
of
the
the
folks
who
have
the
requisite
access
also
are
wearing.
You
know.
Adolfo
is
a
as
a
great
example.
Adelpho
carl
really
like
anyone
who
is
simultaneously
a
release,
manager
and
a
sig
lead.
That's
not
good,
because
because
it
means
we're
also
staring
at
other
things
right
so
again,
stressing
the
need
to
kind
of
build
this
ladder
out
and
onboard
new
contributors
to
the
release
manager.
F
Associates
thing
I
mean
you
know
we
we
have.
The
the
reason
for
the
release
manager
associates
program
is
to
provide
the
is
to
provide
a
level
of
access
into
logs
and
the
team
as
folks
build
confidence
in
learning
processes
and
tooling,
before
they're
granted
access
to
basically
delete
prod.
So
not
everyone,
not
everyone
has
access
to
delete
prod
per
se
right
now,
but
the
senior
release
managers
do
so.
The
the
I
I
think
the
name
of
the
game
is
is
trust
right.
F
The
largest
go
project
on
the
internet
right
and
there
is
a
level
of
there's
a
level
of
expect,
so
we
need
to
be.
We
need
to
scale
out
the
team,
because
I
mean
I
think
in
general,
just
in
open
source
life
and
in
just
state
of
the
world.
People
are
tired.
People
are
doing
too
much,
but
we
also
have
to
make
sure
we're
scaling
out
the
team
carefully.
So
that
is
that,
should
100
be
one
of
our
primary
focuses
for
125.
H
I
have
to
say
that,
as
a
humble
only
release
manager
that
doesn't
have
another
role,
I
have
felt
the
burn
of
of
that
you
know
of
like
the
other
release
managers.
H
Having
other
more,
I
would
call
them
senior
roles
where
their
hands
are
full,
so
like
in
in
the
for
the
past
two
release
cycles
where
where
they
have
been
focusing
a
lot
on
the
salsa
compliance
thing,
which
is
amazing,
like
the
monkey
jobs,
let's
call
them
like
that.
I
I
have
been
feeling
the
burn
and
and
it's
great,
but
we
definitely
need
more
people.
A
F
Okay,
I
would
so
I
I
wonder
if
I
could
propose
a
job
for
frank
which
would
be
to
help
with
recruiting
and
help
with
the
latter.
H
H
No,
I
think
it's
kosher.
I
I
think
that
that
is
usually
like
a
role
for
like
women.
You
know
and
I
would
be
happy,
but
I
think
the
stereotype
would
be
yourself
full
feeling.
F
So
allow
me
to
rephrase
as
a
as
a
as
an
experienced
release
manager.
You
know.
F
H
Bring
people
but
it
I
also
think
like
if
more
people
and
more
women
come
and-
and
I
I'm
saying
this
not
just
from
my
perspective
but
because
there
have
been
many
conversations
around
it
with
other
women
in
the
release.
H
Larger
released
family
that
yeah,
the
the
the
more
responsibilities
are
for
for
other
people
and
and
we
end
up
doing
the
things
that
we
don't
yeah-
that
other
people
don't
don't
want
to
do
so
that
that
is
it,
but
other
than
that.
I'm
happy
and
I
am
extroverted
enough
to
just
be
like
hey
people
come,
but
but
that
also
has
to
be
sustainable.
F
Sorry
so
recruiting
was
maybe
the
the
like.
I
I
hear
I
hear
the
feedback,
and
if
that
is
something
that
is
habit-
and
you
have
been,
you
provide
feedback
really
openly
so
like
if
there
are
things
that
you're
seeing
that
are
not
patterns
that
we
want
to
be
representative
of
sig
release,
please
continue
to
bring
them
to
the
sigma
sig
leads
recruiting
is
maybe
the
wrong
word.
F
Baking,
I
think,
baking
sustainability
into
more
of
more
of
the
process
right.
If,
if
we
can't,
I
mean
you
know
one
one
great
example,
and-
and
I
am
maybe
not
excited
about
using
this
example
because
it
reinforces
the
reinforces
one
of
the
problems-
is
that
the
the
documentation
for
release
management?
For
example?
There
have
been
open
issues
on
the
documentation
for
release
management
for
a
while,
and
that's
the
kind
of
thing
that
so
like
I
I
find
personally.
F
F
F
So
I
think
one
of
the
problems
that
we
we
have
is
when
there
is
a
lack
of
visibility
into
the
into
the
process
for
eligibility
in
the
first
place
and
then
to
waiting
through
documents
that
are
kind
of
labyrinthian
and
maybe
not
as
up
to
date
as
they
could
be
is
another
problem.
So
I
think
helping
with
sustainability
and
recruiting
is
the
part
of
it
is,
is
improving
our
documentation
and
that's
that's
that's.
F
Places
yeah,
I
think
we
shorted
out
in
multiple
places,
like
you
know,
the
promotion
tooling,
for
example
the
contribution
docs
I
I
did
a
sweep
of
and
updated
some
documentation
and
sig
release
recently,
but
I
think
the
I
think
the
day-to-day
playbook
for
release
engineering
is
lacking.
F
So
what
ends
up
happening
is
the
folks
who
already
have
context
on
how
to
do
the
job
instead
of
explaining
it.
While
the
house
is
on
fire,
there's
a
cv
to
attend
to
there's
a
build
job,
that's
broken.
We
just
do
the
thing
and
we
reinforce
the
sustainability
problem.
H
Yeah
totally,
you
know
that
that
is
what
I
meant
with
when
I
said
that
I
felt
the
burn
because
it's
like
I,
I
have
been
doing
the
the
operational
things
and
that's
great.
I
have
no
complaint
about
that,
but
then
the
things
that
need
to
be
fixed,
like
usually
yeah,
we're
understaffed.
That's
that's
the
reality,
because
no
one
is
not
doing
anything
like
people
who
are
doing
all
this.
H
Also
compliance
thing
are
to
their
tonsils
with
with
work,
so
we
have
been
relegating
other
monkey
work
because
we
don't
have
the
time
so
yeah,
that's
great.
F
Okay,
someone
updated
the
base
images
and
they
pushed
one
pr,
but
they
didn't
promote
the
you
know
they
didn't
promote
the
the
images
after
they
were
built
and
then
you
have
to
come
back
and
and
update
the
images
again
so
that
the
set
of
dependents
get
updated
and
then
did
you
promote
those
and
then,
after
you
promoted
all
that
stuff.
Okay,
that's
great,
but
then
did
you
take
those
references
and
update
them
in
kubernetes.
F
Kubernetes
is
the
you
know
like,
like:
do
people
understand
that
flow
right
and
you
and
you
usually
don't
unless
you
have
the
context
of
being
in
the
team,
so
I
see,
I
see
that
jason
in
the
chat
has
has
offered
to
be
a
volunteer
to
help
you
out
veronica.
So
folks,
who
are
interested
will
also
mention
this
on
the
well
when
it's
on
the
recording
two,
it's
in
the
notes,
we'll
mention
it
on
the
mailing
list
too.
But
overall,
we
need
to.
F
We
need
to
spend
some
time
on
sustainability,
and
it's
so
important
that,
like
one,
this
is
being
discussed
on
a
larger
kubernetes
community
level,
but
also
on
the
on
the
cncf
and
governing
board
level
about
sustainability
of
projects.
This
is
so
important
that
I
would
prefer
to
slip
deadlines
to
get
it
done.
F
Then,
like
that's
how
important
it
is,
so
we
we
need
to
work
out
a
plan
for
125
that
is
not
just
strictly
operational,
but
also
also
has
to
well
strictly
tactical
rather
and
has
more
to
do
with
the
strategy
and
sustainability
of
the
sig
as
well.
F
E
Yeah
well
just
my
quick
two
cents
on
this,
so
I
agree
and
I
acknowledge
the
need
to
to
update
the
processes
and
everything,
but
I
I
think
that
we
should
find
another
process
because
I
mean,
while
release
managers
can
actually
you
know,
provide
the
necessary
background
and
information
and
knowledge
to
be
plastered
and
transformed
into
process
and
definitions
of
them,
and
we
have
like
very
few
people
right
now
that
can
actually
perform
so
veronica,
for
example.
E
I
don't
want
to
volunteer
her
just
yet,
but
she
may
end
up
being
one
of
the
persons
that
maybe
can
do
it
for
branch
managing
175.
So
I
would
rather
explore
another
process
where
we
can.
We,
as
a
release
managers
group,
can
advise
some
other
contributors
to
move
this
along,
but
it's
a
longer
conversation
than
maybe
for
the
next
one
yeah.
I.
F
It
I
mean
we
also
have
this
unfortunate
and
I
I
know
we're
I'm
rambling
and
we're
running
out
of
time.
We
also
have
this
an
unfortunate
disease.
I
guess
I
guess
in
open
source,
where
we're
very
willing
to
help
at
our.
You
know,
at
our
own
detriment.
Sometimes,
so
I
want
to
be
cognizant
of
that.
I'm
also
looking
at
the
roster.
F
We
have
four
release
managers,
we're
four
release.
Managers
currently,
who
are
who
are
also
sig
leads.
We
have
one
that
is,
I
believe,
away
for
school
right
now,
veronica,
who
has
been
doing
it
a
bunch
now
brewing.
Who
has
done
it
previously
as
well?
It
might
be,
it
might
be.
The
veronica
navaroon
tag
team
again
as
we
work
to
as
we
work
to
onboard
release
manager
associates.
F
F
I
think
we
don't
have
a
defined
process
around
how
we
recruit
and
and
onboard
release
manager
associates,
and
we
should
we
need
to
so
far.
It
has
been.
Have
you
served
on
the
release
team
as
a
in
in
some
lead
capacity
in
some
role
lead
capacity
right?
So
if
you
have
hit
role
lead
on
any
one
of
our
release
teams,
you
know
within,
I
guess
within
reason
within,
I
guess
the
supported
bounds.
Then
you
are
eligible
to
be
a
release
manager.
F
If
that
is
something
that
you're
interested
in,
we
don't,
I
think
at
you
know
in
there
was.
There
was
a
time
where
we
were
just
getting
people
up
to
the
level
of
release
you
know
of
of
release
manager,
so
we
built
out
a
team
of
people
who
have
full
access
and
then
and
then
unfortunately,
prioritized
the
the
kind
of
the
the
contribution
ladder
portion
of
it
for
the
release
manager
associates.
F
So
I
think,
for
the
release
manager
associates
we've
seen
that
there
has
been
interest
and
and
sometimes
availability,
and
some
work
has
done.
That
has
been
done
and
some
people
shoot
through
the
ranks
based
on
the
work.
Some
people
do
not
necessarily
have
the
time
to
dedicate
to
it
without
being
actively
mentored.
So
we
need
to
figure
out
how
to
to
to
bridge
that,
and
I
think
maybe
it
starts
with
bringing
in
a
group
and
discussing
it.