►
From YouTube: Kubernetes Release Team Bi-Weekly Meeting for 20221214
Description
Kubernetes Release Team Bi-Weekly Meeting for 20221214
A
Everyone
welcome
to
part
three
of
the
kubernetes
126
retro.
My
name
is
Jeremy
and
I'm
going
to
be
the
facilitator
today.
Hopefully
we
can
get
through
everything.
That's
left
on
our
documents.
Today
we
have
a
few
things
in
the
parking
lot
section
and
a
few
things
left
in
our
what
we'll
do
differently
section
so
we'll
go
through
those
and
then
try
to
make
as
much
progress
as
possible.
I
think
James
is
going
to
be
our
Note
Taker
again
today.
A
Thank
you,
James
anybody
else
that
wants
to
contribute
to
the
docs
feel
free
I'll
drop.
The
link
into
the
chat
this
meeting
before
we
get
started
is
covered
by
the
cncf
code
of
conduct.
So
please
be
mindful
of
the
things
you
say:
it'll
also
be
recorded,
it
is
being
recorded.
It
will
be
available
on
YouTube.
So
if
you
just
have
keep
that
in
mind
as
we
get
going
so
with
that,
we
will
start
back
up
into
what
we
will
do
differently,
and
this
is
another
Sig
docs
related
topic.
A
I,
don't
know
if
Ray
will
be
here
or
not
from
from
the
Sig
box
perspective.
But
if
anybody
has
any
extra
context
on
this
item,
it
is
proposal
to
create
a
Sig
docs
lead,
co-chair
handbook
for
the
release.
This
handbook,
potentially
residing
in
K
website
would
contain
bifurcation
of
the
responsibilities
between
the
release,
team,
docs,
comms
and
Sig
docs,
just
to
clarify
who
should
be
doing
what
and
then
information
that's
really
similar
to
the
release
team
docs
roll
handbook,
but
with
specific
triage
and
information
from
the
Dax
peer
view.
C
B
This
time
it
was
little
it
took
quite
some
time
to
get
the
docs
ready,
so
I
think
some
documentation
or
handbook
for
the
on
all
sides
is
pretty
much.
I
can
step
forward
to
make
this
process
more
like
cleaner
and
and
straightforward.
What
we
need
to
do
so
I
think
that's
a
good
idea.
B
So
it
was
partially
due
to
the
documentation.
It
was
not
100
clear
what
we
need
to
do,
or
it
was
not
I
mean
there
were
like
a
couple
of
like
possibilities,
how
you
could
understand
the
documentation
or
the
handbook,
and
then
there
was
also
the
problem
that
we
got.
The
release
on
Friday
and
some
of
the
doc's
leads
were
obviously
already
on
the
weekend
and
there
was
a
problem
of
getting
then
clarification
on
on
the
handbook.
B
B
I
don't
know
like
how
the
previous
Cycles
were
because
I
think
this
this
hand
broke
I,
think
Rey
updated
a
couple
of
releases
ago,
so
I
didn't
heard
anything
bad
last
time.
Maybe
I
don't
know
it
would
be
interesting
to
to
follow
up
on
that.
B
Also,
maybe
it
would
be
good
to
add
this
to
the
lead
handbook
to
check
in
with
the
release
lead
a
couple
of
days
before
the
deadline
to
see
if
everything
is
in
order,
because
there's
like
some
tasks
for
the
release,
docs
lead
to
do
like
two
or
three
days
before
the
release
cut
and
I
mean
some
of
those
tasks
have
been
done.
Did
we
come?
We
completed
some
of
those
tasks,
but
not
all
of
them,
so
it
was
a
little
messed
up.
So
maybe
also
some
documentation
on
the
release.
D
A
Do
you
think
that
you
can
take
an
action
item
to
update
the
release,
lead
Docs.
A
That
sounds
good
to
me.
Does
anybody
have
any
different
thoughts?
Any
other
suggestions
around
this
one
before
we
move
on.
A
All
right
next
one
up
is
Frederico,
comes.
A
I'm,
sorry,
it's
I'll
read
it
and
then,
while
you're
opening
it
should
we
make
the
feature
blog
series
more
visible.
C
Yeah,
it's
just
an
open
idea
to
get
the
others
filling
I
I,
currently,
I
feel
that
the
feature
Block
series
is
is
great
because
it
adds
feature
blocks
to
this
to
the
to
the
release,
but
it
doesn't
really
have
this
like
unit
view
outside
of
it.
So
it's
a
series
of
blogs
that
happen
after
the
release
and
looking
at
it
from
this
way.
If
you
have
more
blogs
that
are
published
right
after
the
last
one,
it's
essentially
the
same.
D
E
Really
great
to
do
it,
how
we
do
it
is
something
I
think
we
should
bring
it
up
with
sick
dogs,
people,
because
there
are
multiple
ways
to
do
it.
I
have
not
seen
many
blogs
being
updated
after
they
are
published
and
like
with
such.
E
Specifically
I.
F
E
As
a
matter
of
fact,
that
Google
has
something
called
a
series
or
it
it
has
different
kind
of
taxonomies,
but
I'm
not
sure
if
the
kubernetes
website
currently
supports
it
yeah,
but
if
they
do
and
we
can
introduce
a
taxonomy
called
series
that
would
really
yeah
solve
this
purpose.
But
again,
this
discussion
I
feel,
like
mostly.
D
B
Yep,
plus
one
on
on
what
now
Bruins
said,
I
I,
don't
think
like
updating
a
blog
post
at
the
end
is
very
good
because
it's
maybe
it
would
make
more
sense
to
just
publish
in
an
entire
new
blog
post
and
so
the
idea
of
updating
blog
posts
with
like
adding,
also
content
to
it.
I
don't
know
if
I,
if
that's
that's
the
way
to
go,
let's
bring
this
to
sick
talk
sounds
to
me
like
a
good
good
step.
G
I
think
one
I
would
definitely
want
to
have
the
conversation
with
the
incoming
Communications
lead
as
well
to
get
their
thoughts
on
it
and
two
putting
my
my
products
manager
hat
on
I.
If
we
could
get
traffic
data
from
the
website
into
like
how
many
clicks
the
core
blog
post
receives.
After
all
of
the
feature,
blogs
have
been
published
versus
before
and
then
also
take
a
look
at
like
how
many
clicks
the
feature
blogs
themselves
typically
receive
after
the
release.
G
It
could
give
us
a
good
idea
whether
it
would
be
worth
it
to
add
the
links
after
the
fact.
If
enough
people
are
actually
revisiting
the
core
feature
block
or
the
core
release
blog
after
that
date
to
make
that
worth
it,
yeah,
I,
I,
don't
I,
yeah
I
would
wonder
about
pulling
that
data
from
from
like
the
netlify
admins
or
whoever
owns
that
yeah.
That's
my
thoughts.
H
A
A
All
right
next
up,
we
have
a
pair
of
items
from
Grace.
Don't
think
Grace
is
here
the
first
one.
What
is
the
process
for
sub
team
leads
with
shadows?
Who
are
unresponsive?
A
Where
can
we
document
this
foreign
I?
Don't
think
we
have
documented
this.
I
Yeah,
you
can
both
speak
on
this
one,
because
this
was
a
conversation
that
happened
with
us,
but
they're
like
there's.
This
unspoken,
like
kind
of
knowledge
that
gets
passed
down
from
lead
to
lead,
but
not
until
an
issue
actually
arises
that
if
you
have
entirely
unresponsive
Shadows
that
you
you
can
remove
them,
but
it
one
that
information
isn't
communicated
until
a
problem
arises
to
a
point
where
a
sub-team
lead
complains
about
it
to
the
release,
lead
and
two.
I
It's
not
documented
anywhere
I,
don't
know
how
to
remove
an
unresponsive
Shadow
or
what
constitutes
an
unresponsive.
Shadow
and
I
think
that
this
is
something
that
should
be
documented
and
addressed
before
it
becomes
a
problem
and,
furthermore,
like
Shadows
should
be
made
aware,
and
it
should
be
documented
in
a
place
where
Shadows
can
see
it
that
if
they
get
too
busy
in
the
middle
of
a
release
cycle
that
they
do
have
the
option
and
the
ability
to
prioritize
themselves
and
step
back
right.
I
So
I
guess
what
what
actually
is
the
process
there
can
can
a
shadow
be
replaced
yes
and
and
where?
Where
should
we
document
that?
Because
it
should
be
documented?
This
is
not
the
type
of
thing
that
should
be
passed
down
like
as
some
kind
of
like
Secret
passing
of
the
torch
thing
between
leads.
You
know.
A
So
I
think
there's
probably
opportunity
to
put
this
in
a
few
places.
One
the
Emeritus
advisor
I
think
can
come
into
play
here.
I
think
it's
part
of
their
job
is
to
this.
This
is
me
putting
on
my
my
previous
release,
lead
and
and.
A
Really
sweet
and
EA
kind
of
role,
I
think
that
it's
we
have
done
this
in
the
past
before
this
release.
Just
for
clarity,
I
think
that
we
should
document
it
if
it's
not
documented
anywhere.
A
A
E
Yeah
I
feel
like
we
should
document
it,
and
I
mean
it
for
long
time.
It
has
been
like
unspoken
role
of
the
EA
to
like
advice
whenever
such
situations
occur,
and
traditionally
the
solution
that
we
have
taken
is
like
the
lead,
Shadows
go
ahead
and
like
assume
the
rows
that
they're
comfortable
with-
and
that
has
happened
in
my
release
in
the
past,
where
sharers
are
unresponsive
in
the
middle
of
the
cycle,
and
we
had
to
like
go
ahead
and
do
the
work
ourselves
about
what
should
exactly
be
the.
E
Think
we
get
noodle
on
the
same
change
PR
whenever
we
make
that
PR.
D
E
Now,
on,
how
we
remediate
missing
Shadows
is
something
we
can
discuss
separately.
A
We
should
probably
open
the
tracking
issue
for
this
to
to
capture
it
and
make
sure
we
identify
the
places
where
we
want
to
do
this
so
Leo
or
cat.
Do
you
want
to
take
an
action
to
start
a
an
issue
in
Sig
release
so
that
we
can
have
this
as
a
top
level
kind
of
tracking
thing,
and
then
we
can
identify
where
we
want
to
put
this
into
the
handbooks
and
and
maybe
in
the
issue
kind
of
iterate
on
what
the.
I
A
Okay,
thank
you
cap
for
taking
the
action
to
do
that.
One
yep
and
then
what's
the
next
one
from
Grace
when's
a
good
time
to
wipe
the
enhancements
label
doing
any
signals
from
anyone.
So
originally
it
said
board
and
I
think
the
board
was
changed
to
labels.
There.
F
Was
yeah?
There
was
a
discussion
in
slack
a
while
ago
about
do
we
want
to
create
a
new
board
or
wipe
the
existing
board
like
just
archive
everything
on
the
board
and
create
a
new
board
or
add
everything
back
to
the
same
board,
and
we
decided
to
create
a
new
board
to
preserve
that
history.
So
then
I
think
the
question
was:
when
do
we
remove,
especially
that
lead,
opted
and
label
to
make
sure
leads
re-upped
in.
A
Yeah,
that
probably
needs
to
happen.
Oh
Frederico.
C
I,
don't
know
it's
very
just
just
to
add
that
this
is
an
important
point,
because
the
board
currently
is
actually
Linked
In
the
release
article.
So
if
you
were
to
reuse
it
we
would
I
would
have
to
go
and
and
change,
and
this
this
was
something
that
was
not
totally
discussed
before,
but
this
is
an
important
one.
I
was
assuming
at
the
time
that
we
would
we're
creating
new
boards
for
new
releases,
and
if
this
isn't,
if,
if
this
is
true,
then
another
one.
A
I
think
in
the
past
we,
when
we
use
this
sheet,
we
always
created
a
new
one
partially
for
historical
purposes.
So
you
could
go
back
and
see
what
had
happened
and
if
we
I
think
keeping
and
reusing
the
same,
one
will
lose
I.
Think
that
was
comments
that
were
from
the
slack
card
number
one.
You
have
your
hand
up.
E
Yeah
I
just
wanted
to
I.
Did
it
on
the
fact
that
we
kind
of
had
decided
to
not
wipe
the
board
ever
primarily
because
of
archival
reasons,
and
if
we
wipe
the
board,
then
we
would
break
some
contract
that
we
decided
long
back
with
everyone
who
consumes
features
of
kubernetes
because
they
come
back
to
boards
like
this
and
look
at
like
what
was
shipped
in
a
particular
release
cycle.
E
So
I
think
that
board
would
basically
change
that
context.
On
the
on
wiping
the
labels
I
feel
like
we
should
follow
the
same
ideology
that
we
have
been
doing
till
date.
As
in
when
do
we
set
our
ideas
to
track
no
start
of
the
cycle
yeah?
When
do
we
remove
the
leads
operating
level
exactly
at
the
same
time,
when
we,
when
the
next
announcements,
it
starts
working
on
the
release
cycle
and
starts
like
populating
the
board
with
initial
metadata
I.
Think
it's
that
moment
when
all
of
this
should
be
wiped
away.
F
Yeah
and
I
have
I
was
waiting
for
the
the
pr
and
to
test
infra
to
lift
the
code
freeze
and
then
I
have
been
removing
some
of
the
labels
already
because
it
does
say
in
the
week
zero
of
the
handbook
I've
been
treating
it
the
same
way
as
the
tracks.
Yes,
no
remove
them
at
the
beginning
or
like
the
week's
work.
E
F
The
issues
stay
on
the
board,
but
one
of
the
columns
on
the
board
is
all
of
the
labels
that
were
applied
to
the
pr
and
those
two
get
reflected
across,
like
all
like
all
of
the
boards
that
the
labels
are
in
and
I've
been
making
sure
to
not
touch
the
milestones
for
labels
that
have
already
been
completed,
and
things
like
that
as
says
in
the
handbook.
F
But
we
do
have
the
history
of
in
the
board
what
phase
or
what
stage
the
enhancement
was
targeting
in
that
release
and
if
it
was
dropped
or
not
in
separate
columns
in
each
one
of
the
release
boards.
So
I
think
we
can
use
that
as
the
source
of
Truth
for
the
historical
boards.
Instead
of
looking
at
what
labels
are
on
them,
because
the
labels
are
more
of
a
point
in
time.
F
E
E
F
E
B
Yes,
I
was
just
wondering
why
we
have
this
I
mean
it's
not
like
a
reason
why
we
have
this
on
the
Retro,
because
what
is
not
so
from
this
discussion,
I
get.
We
don't
change
anything
right,
so
we
stick
kind
of
to
what
we
also
did
in
the
past.
Is
there
like
something
we
improve,
because
I
think
this
is
under
the
what
we
should
do
differently
section
right,
yeah.
A
I
think
maybe
the
originally
this
was
when
do
we
wipe
the
board,
which
we're
not
going
to
do
so.
I
like
that
I
think
the
only
question
now
and
James:
you
have
your
hand
up,
so
you
can
go
in
just
a
second
I
think.
The
only
question
is:
is
the
current
guidance
clear
enough
in
the
handbook
Mark
seems
like
you
were
just
following
that
and.
F
H
I'm,
muted
myself
to
meet
myself
I
was
gonna
say
if,
if
this
information
about
what
went
into
each
release
is
really
important,
which
I
agree
with
it
is,
do
we
want
to
try
like
publishing
that,
as
some
form
of
artifact
out
of
the
end
of
a
release
that
isn't
a
spreadsheet,
because,
like
right
right
now,
for
example,
the
124
release
spreadsheet
is
in
my
my
jet
stack
company,
Google
Drive,
and
if
that
ever
went
away,
that
would
break
history
for
everything
forever
and
I'm
sure
that
all
of
the
old
spreadsheets
in
a
very
similar
situation
as
well.
B
I
remember:
Sasha
opens
an
issue
about
collecting
metrics
about
the
releases,
so
I
think
there's
already
like
something
not
in
the
works,
but
something
that
we
want
to
do
so.
I
guess
this
would
be
basically
adding
adding
to
that.
E
James,
the
answer
to
your
question
is
the
Caps
website
and
the
artifacts
that
we
push
every
day.
So
when
the
author
updates
the
Cappy
ml
that
gets
stored
in
history
and
we
have
a
clear
provenance
of
the
data
and
that
gets
stored,
that
gets
generated
into
the
Caps
website
every
night.
So
we
kind
of
have
that
archive
already.
F
I
was
gonna,
say
the
same
thing
that
which
States
and
what,
when
graduated
as
long
as
they
get
updated,
is
in
the
Cup
start,
yaml.
E
A
It's
pretty
neat
okay,
so
that
wraps
up
everything
that
we
had
in
the
what
we'll
do
better.
So
we've
got
some
stuff
in
the
parking
lot
section.
A
So
we'll
pick
up
from
there
from
the
until
mid
cycle,
retro
walk
Frederico,
you
have
the
first
one.
This
is
surely
obviously
like
this
but
50
of
feature
blogs.
Opt-In
come
the
last
day.
Substantial
part
of
the
work
is
foreshadowing
I.
A
F
I,
don't
remember
why
I
added
that
one
I
think
this
was
just
part
of
this
is
one
of
the
what
my
my
thoughts
were.
One
of
the
kind
of
more
manual
processes
of
the
enhancements
team
is,
after
code,
freeze
and
or
after
enhancement,
freeze
and
code
freeze
going
through
and
checking
to
make
sure
that
all
of
that
criteria
is
met
and
then
removing
like
commenting
on
each
issue
and
saying
you
know
like
switching
it
from
track.
F
Would
anybody
be
interested
or
have
any
objections
to
somebody
going
developing
a
CLI
to
like
check
that
and
potentially
do
changes?
I
see,
navaroon
laughing.
E
A
B
B
I
mean
you
have
like
a
very
strict
deadline
so
like
have
like
the
idea
was
just
to
have
like
some
some
tooling
to
remove
all
like
all
the
labels
and
and
Milestones
but
yeah.
This
was
just
basically
maybe
like
some
tool
that
could
help
this
process,
because
otherwise
it
takes
like
10
minutes,
maybe
longer
or
maybe
half
an
hour
or
or
something
like
this.
Maybe
you
missed
something,
and
this
like
very
important.
This
is
like
a
very
important
deadline,
so
some
shooting
might
be
useful.
E
E
F
E
Has
come
up
many
times
over
the
years
and
Jeremy
and
I
headed
out
on
an
adventure
to
solve
this
exactly
two
years
back
with
a
solution
called
receipts
which
essentially
was
not
that
scalable.
E
But
if
you
want
to
find
a
solution
to
it,
I
am
happy
to
collaborate
and
try
to
find
something
which
is
which
works
out
right
now,
with
the
current
state
of
how
we
do
enhancements.
So
the
idea
is
great
that
motivated
us
to
work
on
receipts,
but
maybe
we
can
think
of
an
alternate
solution
and
not
receipts
so
I'm
cool
with
like
collaborating
on
this,
so
feel
free
to
bring
in
name.
G
Back
like
when
I
was
enhancements,
lead
and
it's
just
a
little
CLI
I
wrote
that
just
pulls
data
from
GitHub
and
provides
a
different
interface
to
cap
spot
like
if
you
wanted
something
that's
not
received.
So
you
can
build
on
that
or
just
look
at
the
code
and
I.
Don't
know
it's
just
a
thing
that
I
did
a
while
back.
E
There
was
something
written
by
Harsha
was
I
think
in
the
bakria's
team.
This
time
back
during
1.19,
which
tries
to
like
he
wrote
a
tool
which
tries
to
automate
like
a
lot
of
manual
processes
we
used
to
do
earlier.
Maybe
we
can
take
like
Inspirations
from
there
as
well.
I
can
share
a
link
shortly.
A
All
right
next
one
is
from
Grace
code
freeze
project
board
tracking.
D
B
A
very,
very
short
one,
so
we
created
like
shortly
after
countries
a
new
view.
This
is
like
basically
something
that
we
that
we
improved
on
on
like
during
during
the
cycle,
so
created
a
new
view
for
code
freeze
just
to
track
the
status
because
we
received
a
lot
of
like
exception
requests,
and
it
was
a
little
difficult
to
track
all
of
them
and
this
view
was
kind
of
Handy,
I.
Guess.
A
F
F
B
A
Okay,
the
next
one
was
the
improve
the
release
process
to
better
incorporate
large
PRS.
There's
a
lot
of
stuff
written
here
Leo.
If
you
want
to
walk
us
through
it.
B
This
is
basically
an
action
item
from
an
exception
request
we
received-
and
we
discussed
this
extra
exception
request
for
quite
some
time
and
at
the
end
it
did
not
make
the
deadline
because
it
was
too
big
and
not
reviewed
and
so
on,
and
there
was
like
some
discussion
around
how
we
can
improve
to
better
incorporate
large
PRS
into
the
releases,
because
this
one
in
particular
missed
the
deadline
like
a
couple
of
times
and
the
author
tries
to
get
it
in
for
like
a
year
or
longer,
and
the
question
was
basically
how
the
release
team
could
maybe
improve
the
release
cycle
or
like
some
processes,
or
something
like
this
to
make
sure
that
these
large
beers
get
in
the
release.
B
So
this
is
certainly
not
like
a
topic
just
for
the
release
team,
maybe
at
the
end
I,
don't
know
if
there's
like
some
tasks
for
us
to
do.
Maybe
this
is
like
purely
for
the
reviewers
and
and
the
other
sick
leads
but
yeah.
So
there
was
also
a
thread
from
Tim
over
the
mailing
group.
B
He
shared
like
some
some
processes,
how
he
triages
those
PRS
and
like
some
best
practices
from
from
his
side.
B
This
definitely
contributes
to
the
like
overall
achievement
or
idea
of
incorporate
those
PRS
and
there's
one
proposal
from
Tim
that
we
discussed
in
the
sick
release
meeting
about,
for
example,
having
like
another
deadline
for
xlprs,
so
xlpr
should
get
in
two
weeks,
maybe
before
the
others,
so
that
this
entire
like
stretches
out
or
something
like
this.
B
But
we
discussed
this
in
the
sick
release
meeting
and
everybody
was
kind
of
on
the
minus
one
on
adding
another
deadline
and
there's
also
another
idea
from
Tim
about
assembling
a
review
team,
not
sure
if
this
is
I
mean
this
might
can,
or
this
could
potentially
live
in
the
release,
team
or
somewhere
else
yeah.
Maybe
there's
some
other
ideas
as
well.
A
F
Yeah
I
was
going
to
say
this
issue
was
discussed
at
a
few
of
the
chairs
and
TLS
meetings
too.
There's
more
than
one
PR,
but
I
know
that
the
that
have
been
in
this
case
where
they
slip
and
some
of
the
thoughts
were
like
how
first
somebody
was
like
Hey.
F
What
if
we
do
feature
branches
again
and
then
everybody
was
against
the
feature
branches,
because
it's
a
lot
more
overhead
and
then
people
still
want
to
re-review
the
code
just
because
there's
so
many
different,
like
re-um,
like
changes
that
that
happen
with
this
too
and
then
I
think
like
one
of
the
at
least
in
the
chairs
and
teals
meetings
that,
like
we
really
spent
a
lot
of
time
discussing
it's
like
well.
F
What
about
breaking
PRS
up
into
smaller
PR's
and
one
of
the
issues
that
a
lot
of
people
said
is
that
that
tends
to
lead
to
half
implemented
features
getting
into
the
code
base.
And
one
of
the
the
big
concerns
is
that
once
API
changes,
especially
to
stable
apis,
make
it
into
a
make
it
into
the
code
base
and
then
go
out
with
a
release
they're
essentially
in
there
forever.
F
So
it
for
these
larger
PRS
that
do
tend
to
touch
stable
apis,
there's
a
lot
of
caution
around
making
sure
that
the
implementation
is
correct
when
they
go
in,
because
there's
not
that
flexibility
to
iterate
on
you
know,
Alpha
and
beta
apis,
and
then
so.
I
think
that
this,
like
these
PRS
that
tend
to
drag
out
and
don't
get
broken
up,
are
a
smaller
subset
of
like
Excel
or
XXL
PRS
to.
But
we
really
didn't
have
a
good
way
of
doing
this,
and
these
two
tend
to
just
get
punted
and
punted
and
punted.
E
Thanks
Mark,
actually
for
giving
the
context
from
the
Chase
and
Deals
meeting
I
was
also
wondering
like
I
was
thinking
like
if
this
is
actually
a
Securities
problem,
and
it
I
thought
like
it's
more
to
be
like
a
cheers
and
TLS
plus
contributor
experience
kind
of
problem
that
we
should
solve
what
I.
What
I
kind
of
understand
from
this
problem
is
like?
How
do
we
reduce
friction
of
like
reviewing.
E
And
you
have
to
solve
that
problem,
somehow
one
more
thing
that
I
was
so
when
the
idea
of
like
adding
another
Milestone
came
into
picture.
I
was
thinking
like
what
stops
people
from
reviewing
the
code.
Even
when
we
are
in
code
freeze
or
exactly
we
are
not
in.
We
are
not
in
the
release
cycle.
For
example,
code
freeze
happened
a
month
back.
E
Code,
it's
just
that
they
can't
get
the
code
merged
until
Court
thought
happens
a
a
month
from
code
freeze.
So
this
is
a
kind
of
cultural
change.
I
probably
want
to
see,
but
then
again
this
is
not
the
right
Forum
to
discuss
that.
E
Probably
the
share
centennials
meeting
plus
contrary
by
X-
and
maybe
if,
since
this
also
kind
of,
is
like
non-technical
governance
of
the
project
and
that's
like
steering
starter
so
I'm,
not
sure
like
who
is
the
correct
group
but
doesn't
seem
like
sick
really
is
a
release
team
to
be
the
best
audience
for
this.
A
I
agree
and
I
think
this
has
happened
as
long
as
we've
had
releases
like
the
sidecar
cap
comes
to
mind
right,
like
we
in
120
I,
think
number
20.,
maybe
it's
119.
there
was.
A
This
has
been
like
the
fourth
or
fifth
time
that
this
PR
had
like
the
cap
had
been
merged
like
the
cap
had
been
merged
and
it
was
approved,
and
somebody
had
been
working
on
the
pr
and
it
was
a
big
PR
and
it
touched
a
lot
of
things
and
it
just
kept
going
from
release
to
release
because
it
never
met
the
deadline
for
code
freeze
and
the
person
would
have
to
rebase
it
and
the
person
would
have
to
rebase
it,
and
that
is
not
a
Sig
release
problem.
That's
not
a
release
team
problem.
A
In
the
end,
it
turned
out
that
this
shouldn't
have
approved
the
cap,
but
nobody
felt
like
saying
no.
They
were
trying
to
be
accommodating
and
making
sure
like
a
person
was
feeling
like
their
their
work
was
being
appreciated,
but
then,
when
it
came
to
reviewing
the
pr-
because
it
was
so
big-
and
it
touched
so
many
things
and
people
had
reservations
about
it-
it
just
never
made
it
over
the
line.
So
it's
a
combination
of
of
like
like
not
ruin,
set.
It's
a
contributor
experience
problem,
it's
a
governance,
kind
of
problem.
A
It's
people
we've
moved
to
this
and
that
one
was
bad
too,
because
we
would
always
ping
like
at
that
point
in
time
we
always
ping
the
author
of
the
cap
and
the
author
of
the
pr
to
say
is
this
going
to
make
it
is
this
going
to
make
it?
Is
this
going
to
make
it
now
that
we
have
Sig's
opting
things
in?
They
should
take
more
ownership
of
things,
especially
for
these
big
PR's,
or
these
things
are
going
to
be
big
and
say:
yeah
we're
going
to
dedicate
time
to
do
this.
A
Maybe
we're
going
to
dedicate
time
to
do
it
during
code
freeze
for
the
next
cycle,
and
this
one
in
particular
like
it
didn't
get
reviewed
by
the
time,
but,
like
we
I,
think
in
that
thread,
we
said
like
you,
can
get
this
ready
to
land
at
the
beginning
of
the
next
cycle
and
get
ready
ready
to
go
for
this.
So
I.
Don't
think
that
there
is
work
to
do
here.
It's
like
putting
my
sign
release
that
up
I.
Don't
think
we
should
change
deadlines.
We
shouldn't
add
things.
This
isn't
a
Sig
release
problem.
A
This
isn't
a
releasing
problem.
This
is
just
a
general
kubernetes.
Change
is
hard.
There
are
not
enough
people
to
review
big
things,
so
those
folks
should
should
take
ownership
of
things
and
and
opt
in
correctly
or
be
a
little
more
restrictive
on
we're
not
going
to
do
35
things
this
time,
we're
going
to
do
10
things
this
time
to
have
better
review,
bandwidths,
okay,
Mark.
You
have
your
hand
out
again,
I.
F
Was
going
to
say
a
lot
of
what
you
just
said,
I
think
it's
a
it's
a
review
bandwidth
and
then
a
contributor
experience
issue
like
I
think
a
lot
of
times.
There
are
people
who
have
lots
of
reviews
like
the
API
reviewers,
like
that
and
and
people
who
are
reviewing
these
large
PRS
they're,
constantly
like
trying
to
balance
like
there's
one
big
PR
and
in
this
case
I
think
everybody
wanted
this
PR
to
go,
and
this
was
in
place.
Pod
vertical
Auto.
D
F
Do
I,
like
I,
have
a
limited
amount
of
time,
do
I
focus
on
this
one
PR
or
do
I
focus
on
getting
20
other
small
PR's
in
like
enhancements
in
and
I
think
that
maybe
one
thing
is
that
these
reviews
need
to
happen
by
both
the
Sig
and
the
API
review
team
and
I.
Think
I've
seen
a
change
in
signode,
especially
around
like
acknowledging
like
we
have.
F
We
have
bandwidth
to
do
one
big
PR
and
then
maybe
a
couple
like
other
small
PR's,
but
the
API
reviewers
like
when
when
Tim
was
on
this
I,
don't
know
if
they
have
the
same
way
of
balancing
that
and
the
pr
team
too,
across
all
the
different
sigs
kepts
that
are
coming
in
quite
as
easily
but
yeah
I.
Don't
think
it's
a
necessarily
a
Sega
release
problem
either.
A
All
right
any
other
discussion
on
this
one
before
we
move
on,
we've
got
15
minutes
left
or
still.
A
All
right
next,
one
up
Frederico
deprecations
GitHub
tag
for
PRS
to
improve
filtering
for
comms.
A
Okay,
Leo,
the
release,
notes
team
uses
some
tracking
issues
in
each
cycle
to
follow
up
on
the
work
in
general.
I
think
this
is
good
for
tracking
tasks
and
transparently
just
shouldn't
work.
Oh,
we
do
the
same
for
docs
enhancements
and
cops.
B
Pretty
much
what
I
already
wrote
wrote
there,
so
the
I
think
release
notes
has
a
couple
of
issues.
They
created
each
each
release
to
follow
up
all
these
tasks
and
I
think
this
is
kind
of
nice
also
for
transparency
and
just
to
follow
up.
Who
is
doing
what
and
to
distribute
work
and
everything,
and
also
you
can
attach
those
issues
to
the
board.
So,
overall,
the
bot
can
be
become
a
little
bit
more
useful.
B
So
at
the
moment
we
don't
track
a
lot
of
things
because
we
don't
have
any
issues,
but
essentially
we
have
a
lot
of
issues,
but
we
don't
like
create
issues
for
it.
We
we
just
basically
do
it,
so
perhaps
this
would
be
like
an
interesting
pilot
for
next
release,
maybe
to
create
like
a
couple
of
more
issues
just
to
test
it
out.
If
it
helps
would
be
my
idea,
one
yeah
suggestion,
maybe.
E
I,
like
the
idea,
this
is
exactly
what
we
do
in
release
engineering
and
it's
good
to
have
like
tracking
issues
for
certain
big
management
students.
B
A
I
think
that's
a
a
great
idea.
Do
you
want
to
does
Xander
your
gender
still
here
Xander?
How
do
you
feel
about
it.
G
I
yeah
I
need
to
open
we'll
reopen
the
pr,
not
the
pr,
the
the
issue
for
getting
everybody
access.
That's
like
mentioned
in
the
current
handbook
and
initially
I
was
gonna.
Wait
until
Leo's
PR
emerged,
but
I
can
just
adapt
the
issue
to
include.
What's
there,
I
I,
like
the
idea
of
having
a
a
tracking
issue
like
that
I
think
it
works
really
well
for
the
releases
and
it
can
be
adapted
quite
well
to.
B
D
B
Right
I,
I,
think
already
kind
of
know.
The
answer
or
I
mean
we're
already
in
in
sync,
with
the
goaling
team
and
I,
don't
know
if
it's
possible
to
anticipate,
for
example,
security,
patches
or
some
other
things
even
better
and
as
far
as
I
know,
we
already
kind
of
schedule
the
release
in
that
way
that
we
don't
like
push
the
new
changes
out
on
the
same
day
or
in
the
same
week
as
as
calling
packages
are
getting
updated
as
far
as
I
know.
So
probably,
we
cannot
improve
that.
B
A
We
have
a
good
idea
about
when
regular
patch
releases
forgo
are
going
to
happen.
That's
fairly
regular,
the
security
things
we
we're
not
gonna
get
better.
They
tell
us,
there's
a
there's,
a
distribution
list
that
they
notify
that
patches
are
gonna
happen,
but
just
like
the
kubernetes
embargoed
cves
like
we,
don't
those
don't
go
out
ahead
of
time.
Super
super
early,
so
I
think
cases
like
this
we're
gonna
have
to
be
reactive
and
and
go
with
the
the
flow
as
much
as
we
can
right.
B
A
And
then
this
last
one
is
done
already.
We
have
put
in
place
the
ability
to
pause
and
stop
the
fast
forward
job.
So
thanks
Jordan
for
for
finding
this
and
and
everybody
for
fixing
it.
A
All
right,
it
brings
us
to
the
end
of
our
agenda.
Today
we
have
a
bunch
of
action
items
we've
identified
throughout
the
document,
so
we
can
go
ahead
and
I'll
go
through
and
try
to
pull
some
of
these
out
and
add
them
to
the
action
items
list
at
the
bottom
James.
If
you
want
to
help
me
with
that,
that
would
be
awesome
too.
I.
F
I
didn't
realize
until
after
the
meeting
last
time
so
before
we
had
talked
about
potentially
like
making
sure
that
the
Sig
chairs
knew
that
that
they
should
be
responsible
for
shepherding
the
enhancements
in
and
I
did
find
in
the
community.
Let
me
find
which
page
it
is
I'll
link
to
it
in
a
little
bit,
but
it
did
say
that
it
said.
F
Sig
chairs
should
be
responsible
for
maintaining
the
like
statement
of
enhancements
through
the
release,
but
they
may
delegate
it
to
other
people
on
the
team
and
then
that
brought
back
a
memory.
I
thought
a
while
ago,
Laurie
Apple
tried
to
introduce
a
role
of
an
enhancements
liaison
and
then
I
couldn't
find
any
more
I.
I
had
forgotten
about
that
I.
Don't
I
wasn't
really
super
involved
with
the
release
team
at
that
time.
Does
anybody
know
what
happened
with
that
pilot?
F
G
Kind
of
just
fizzled:
okay,
saves
the
best
description.
I
think
the
intent
was
good,
but
It
ultimately
required
participation
from
everyone
involved
and
I
think
people
just
kind
of
fell
back
into
the
process
that
they
were
used
to.
So
it
it
fizzled.
H
I
think
part
of
a
problem
as
well
is
that
people
that
did
it
were
ended
up
sort
of
responsible
for
stuff,
but
with
no
power
to
do
anything
because
they
were
ultimately
just
passing
messages
between
Sig
leads
and
the
release
team,
while
having
no
Authority
is
the
wrong
word.
No,
no
like
thing
to
do
themselves,
so
it
just
wasn't
very
appealing
for
people
I,
don't
think
so.
It
didn't
end
up
going
anywhere,
but
I
agree.
The
idea
was
was
was
well
placed.
F
F
A
All
right
with
that,
unless
anybody
has
anything
else,
we'll
call
it
a
day.
Five
minutes
early,
thank
everybody
for
attending
the
this
retro
and
all
the
feedback,
the
Retro
yesterday
and
all
the
great
feedback
and
the
first
retro
mid-cycle
looking
forward
to
127
and
good
luck
to
everybody.
I
hope
everybody
has
a
good
time
off
if
you're,
taking
any
time
off
in
December,
January
anytime,
before
the
end
of
127.