►
From YouTube: Kubernetes SIG Release Bi-Weekly Meeting for 20221115
Description
Kubernetes SIG Release Bi-Weekly Meeting for 20221115
A
Foreign,
hello,
everyone
and
good
morning
good
evening,
whatever
you
may
be,
welcome
to
the
November,
15
2022.
see,
release
meeting
and,
as
always,
super
excited
to
see
everyone
the.
As
a
reminder
this.
This
is
a
meeting
governed
by
the
kubernetes
code
of
conduct
and
it
will
be
recorded
to
the
Internet.
So
please
be
mindful
of
everything
that
you
to
and
say
on
the
during
this
meeting.
A
We
have
someone
somewhat
the
black
agenda
for
today.
So
let's
kick
it
off
with
the
so
project
only
as
well,
if
there's
anybody
who
is
new
and
would
like
to
say
hi,
and
if
you
want
to
tell
us
what
your
interest
is
here
with
the
release
and
release
engineering
or
the
release
team,
please
feel
free
to
do
so.
B
A
C
C
We
had
to
delay
them
for
one
day
then
originally
plan
it
because
of
issues
with
the
speed
of
promotion
process
and
I
would
like
to
give
that
shout
out
to
Sasha
for
fixing
all
the
stuff,
because,
a
day
later
we
did
a
better
zero
I
think
and
with
all
the
fixes
that
we
got
merged.
Since
then,
the
promotion
process
is
much
faster
and
like
for
One
release,
it
is
taking
like
50
minutes
for
pre-submit
30
minutes
for
deposit
submit,
which
is
much
better
than
two
hours
that
we
had
when
cutting
those
Specialists.
C
C
So
we
are
going
to
do
it
on
a
safer
side
than
do
it,
while
we
clearly
had
done
originally
Planet,
also
when
it
comes
to
that
we
are
still
discussing
if
you
want
to
do
one
more
132
release,
and
it
will
be
only
for
the
register
change
that
we
had
planned
before.
This
is
something
that
we
are
still
waiting
for
the
feedback.
There
is
a
PR
open
to
update
the
calendar.
We
did.
I
can
eventually
link
to
it
later.
C
But
if
you
have
anything
to
provide
the
garlic
that
it
will
be
welcome-
and
let
me
see
what
else
here
we
had
so
we
should
be
tests,
so
it
does
create,
but
I
think
most
of
them
very
slow
before
and
while
we
cut
the
release,
maybe
there
is
something
that
is
going
on:
Master,
informing
but
I.
Think
I
would
leave
that
to
release
team
to
give
a
better
update
than
I
could
do
and
I
could
also
say
for
OBS.
C
A
Yeah,
thank
you.
Yeah
I
would
just
only
like
to
add
that
that
Sasha
fixing
the
time
with
the
promoter
unlocks
a
ton
of
things
for
other
people.
So
we
can.
We
have
that
fixed
as
as
our
previous
priority,
so
we
can
now
continue
working
on
some
of
the
other
efforts
that
we
were
doing
to
the
release
process
and
also
on
the
side
of
kids,
kids
infra.
It
will
allow
them
to
and
continue
the
shedding
of
the
load
to
some
of
the
other
Cloud
providers
that
they're
doing
so
again.
A
Thank
you,
Sasha.
It
was
a
really
great
thing
to
do,
and
also
the
other
one
is
there
is
Carlos
has
in
Flight
APR
to
sign
the
artifacts
it's
pretty
far
ahead
by
now,
and
so
I
expect
he's
not
here,
I
think,
but
to
give
us
an
update,
but
that
should
be
landing
soon,
I'm,
not
sure
if
we
still
have
to
to
talk
depending
on
where
it
lands
on
when
it
lands.
We
still
have
to
think
when
we
first
when
we
will
first
run
that,
but
it's.
B
C
I
would
like
to
add
two
more
things:
okay,
so
it's
just
too
hard
to
keep
up
with
everything,
but
there
are
two
proposal
changes
a
little
bit
to:
let's
call
it
a
release
process
Jeremy
sent
an
email
to
kubernetes
Dev
that
we
are
planning
to
stop
doing
rc0
for
official
releases.
So
this
is
something
that,
if
you
can
please
take
a
look
and
provide
the
feedback
on
that
and
also
I
said.
C
A
D
So
for
the
first
one
I
would
suggest
I
I,
better
set
things,
look
to
be
going
well
based
on
Sasha's,
test
PR,
but
I
would
maybe
strongly
suggest
holding
those
changes
until
the
next
batch
of
patch
releases.
Just
like.
Let's
get
out
of
the
Year
clean
before
for
enacting
that,
because
I
I
think
the
the
changes
that
we've
made
to
the
release
process
relating
to
versioning
in
the
past-
and
this
was
free
Krell
but
I
I
think
also
the
the
the
straw
that
broke
anagos
back
so
to
speak.
D
In
deciding
you
know,
in
deciding
that
you
know
the
the
we
should
weird
things
happened
with
versioning.
It
was
related
to
an
upgrade
of
bash
in
our
in
our
images
for
for
release
engineering,
because
of
the
way
that
patch
5
handled
associative
arrays
and
that
wrecked
the
release
process
for
for
multiple
weeks,
not
saying
that
that
will
happen
again.
D
D
A
D
Safe
too
yeah,
it's
so
so
in
the
past
it
was
done
to
essentially-
and
you
know,
to
to
Ben's
points
and
and
Jordan's
points
on
the
on
the
emails
it
in
the
past.
It
was
done
to
essentially
say
that
the
content
in
the
release,
Branch
moving
forward,
is
content
for
the
next
version
that
that
was
pretty
much
it.
D
So
if
we
don't
promote
the
images
we'll
run
into
a
failure
on
the
verifications,
but
we
can
say
that
we
just
don't
want
to
do-
we
just
don't
want
to
do
any
artifacts
for
them.
Well,
if
the
tag
is
sufficient,
I
think
that's
fine,
but
changing
the
expectation
to
the
new
content
being
within
the
old
release.
Version
I
think
is
is
incorrect,
so
we
should
so
one.
We
should
discuss
that
some
more
two
I
think
prior
to
sending
notes.
D
We
should
do
some
more
discussion
within
Sig
release
before
sending
that
to
kadev,
because
I'm
not
sure
I'm,
not
sure.
If
we're
going
to
see
more
questions
for
our
friction
before
we've
had
a
chance
to
discuss
I,
do
we
have
a
do?
We
have
a
discussion,
discussion,
GitHub
discussion,
thing
open
for
it
perhaps.
A
E
F
I
can
give
an
update.
So,
as
Mark
already
mentioned,
we
have
quite
I.
Think
three
or
four
failings
on
mass
and
forming
I
stick
with
the
Cs
signal
team
earlier
today.
So
they
are,
they
are
on
it
I
think.
Besides
one
it's
clear
what
the
root
source
of
the
problem
is,
one
is
currently
they're
investigating
the
responsible
stick,
but
I
will
keep
them
closer
eye
on
on
the
CI
signal
reporting,
but
I.
Think
for
rc0
is
the
light
green.
So
that's
good.
F
Today
we
also
have
in
the
sick
testing
meeting
a
short
presentation
or,
like
a
short
I,
don't
know
summary
about
CS
signal
about
test
grid,
how
to
observe
Flakes
and
everything.
So
we
observed
that
in
the
past
it
was
a
little
bit
challenging
to
basically
transport
the
knowledge
from
one
team
to
the
next
one.
F
So
for
CI
signal
we
probably
need
to
improve
further
the
onboarding.
We
already
have
a
couple
of
recordings
and
the
long
handbook
and
everything,
but
it
looks
like
there's
still
some
some
work
needed
to
better
transport,
the
knowledge
to
the
shadows
and
so
on.
So
the
recording
or
the
recording
of
the
six
testing
meeting
today
will
also
be
then
part
of
the
onboarding
for
new
CS
signal.
F
So
this
is
the
new
item
which
I
added
to
the
Retro,
which
could
lead
to
maybe
some
small
adjustments
in
the
release
process,
so
Tim,
for
example,
had
the
idea
that
maybe
there's
a
new
deadline
for
large
PRS
or
large
caps.
So
there's.
Basically,
we
just
stretch
out
the
review
timeline,
so
the
reviewers
of
the
PRS
and
the
sick
leads
and
everything
they
are
not
required
to
review
everything
inside
of
like
a
very
short
time
of
period.
F
D
D
D
If
we
I
I
feel
I
feel
like
every
time
we
do
a
retro
if,
if
we
I
mentioned
something
along
the
lines,
if,
if
we
push
the
deadlines
like
the
deadlines
are
already
not
respected
in
many
ways,
if
we
push
the
deadlines
and
we
change
deadlines
where
it's
a
soft
deadline,
it's
a
it's
a
freeze.
It's
an
almost
freeze,
we're
gonna,
continue
to
run
into
these
these
issues.
D
My
understanding
of
the
what
got
kicked
was
was
that
it
has
been
kicked
for
multiple
Cycles
yeah
like
like,
and
and
not
just
like,
two
or
three,
but
but
more
than
that.
So
that
is
I'm,
not
sure
that
that
is
our
problem
to
take
on
I.
Think
that
that's
that's
a
question
that
needs
to
be
asked
to
the
Sig
of
why.
Why
is
review
not
happening
ahead
of
time?
If
we
know
that
this
is
a
if
this
is
an
issue.
F
Yeah
so
for
this
particular
case
there
was
a
couple
of
reasons
why
we
also
like
shortened
the
approval
of
time
we
had
to
move
it
up
again,
but
there
were
reviews
missing
from
sick
note
and
the
author
of
the
pull
request
basically
commented
was
a
great
exercise
of
rebasing.
So
maybe
this
was
one
of
the
challenges
that
this
the
coach
where
he
made
some
adjustments,
was
kind
of
heavily
being
worked
on
also
on
other
caps
and
this
kind
of
messed
up,
the
the
reviews
again
and
so
on.
F
But
Tim
also
mentioned
that
this
is
likely
or
maybe
not
a
problem
of
the
release
process,
so
not
on
our
side,
maybe
a
problem
on
the
side
of
the
reviews
so
that
they
have
to
maybe
I,
don't
know,
Define
different
schedules
or
something
else.
So
maybe
it's
not
the
release
team.
That
needs
to
take
like
the
big
action
here.
Yeah.
D
So
I
think
it
is
worthwhile,
for
the
sake
of
our
retro,
to
determine
that
at
least
using
this
as
a
test
case
to
say
like
this
is
truly
not
part
of
our
process
and
use
that
as
an
escalation
point.
So
let's
make
sure
that
we,
we
are
capturing
I'm
sure
it's
already
captured,
but
let's
make
sure
we
are
capturing
it
for
the
Retro.
A
A
A
So
we
are
we're
having
working
for
the
past
couple
of
months
or
maybe
more
to
try
to
find
a
way
to
share
the
serving
load
from
the
community
infra
in
Google
Cloud
to
to
modify
how
we
are
serving
artifacts
to
make
sure
that
we
can
leverage
other
infrastructure
donated
by
some
other
Cloud
providers,
and
this
has
been
work
that
has
been
ongoing
for
I
mean
the
the
Gap
itself.
I
think
it's
been
open
for
maybe
two
years
so
I
think
well,
maybe
maybe
not
that,
but
for
a
long
time.
A
But
now
things
have
become
a
little
bit
more
pressing
and
we
want
to
ensure.
So
if
you
maybe
miss
the
announcements
that
have
been
flying
around
in
slack
and
all,
and
also
by
commenting
by
some
people
on
Twitter
I
mean
this,
is
this
announcement
has
been
happening
in
secret
infra.
It's
like
no,
not
in
secretes,
so
we
were
short
in
the
budget
to
serve
the
artifacts.
That
is
the
container
images
that
people
pulled
to
live
to
spin
up
their
clusters.
A
We
were
short
in
the
budget
to
to
serve
that
this
year
by
several
hundred
thousand
dollars,
and
the
situation
for
this
year
is
now
resolved
by
another
donation
of
money
to
pay
for
the
remaining
of
the
bill.
But
now
we
need
to
think
about
next
year,
and
so
what
we
have
been
working
on
together
with
Secrets
infra,
is
how
to
shift
the
load
of
the
images
we
release
so
that
they
can
be
served
by
other
Cloud
providers
and
the
first
one
is
already
taking
some
load.
A
But
we
need
to
accelerate
that
serving
process,
because
we
need
to
make
sure
that
next
year,
at
least
I
think
it's
at
least
half
of
the
the
image
servings
are
coming
from
there
and
for
more
details
on
the
actual
numbers.
I
would
refer
that
to
the
C
kids
infra
meeting,
but
one
thing
we
need
to
do
is
we
need
to
back
Port,
so
the
registry
name
from
where
we
serve
the
images
is
changing
from
the
former
gates.gcr.io
to
registry,
dot,
Gates,
dot,
IO
and
but
that's
a
little.
A
That's
a
little
change
has
some
breaking
implications
for
people
running
under
certain
circumstances,
namely
people
who
are
running
in
networks
that
have
high
security
via
firewall
connections
to
the
outside,
or
maybe
air
gap
environments.
So
we
need
to
and
plus
a
few
others
which
we
need
to
warn
people
about.
A
So
I
will
attempt
to
do
a
second
one
and
maybe
opening
up
for
review
of
more
focused
stakeholders
instead
of
just
a
free-for-all,
so
that
we
can
discuss
it
in
a
more
controlled
manner.
I'm,
not
controlling
the
sense
that
it's
not
open,
but
in
the
sense
that
it
all
basically
not
opening
editing
for
everybody,
because
it
went
down
into
chaos,
so
I
will
share
it
soon.
As
soon
as
we
can
I
mean
we
have
the
other.
The
other
blog
post.
I
can
share
this.
A
A
D
I
I,
I,
think
talking
through
some
of
the
Alternatives,
which
include
no
longer
publishing
artifacts
for
previous
releases
because
of
the
costs
associated
is
a
worthwhile
thing
to
do
just
for
the
the
sake
of
clarity.
We
are
doing
this
as
a
service
for
for
for
previous
releases.
We
could
just
as
easily
not
do
it.
C
I
have
a
chance
to
look
at
the
original
post.
I
would
just
say
that
I
think
it
is
well
done,
but
I
would
like
that
we
some
can
better
emphasize
on
what
you
see
of
this
and
maybe
what's
going
to
happen
if
forgot
migrate,
and
also
what
is
one
very
important
thing
that
I
think
that
was
not
highlighted
enough,
that
we
really
need
some
call
for
action
or
something
like
that
for
Fox,
maintaining
things
like
charts,
other
projects,
I,
don't
know
stuff
that
is
using
character
hdcr.
C
I
o
that
they
need
to
migrate
as
soon
as
possible.
This,
for
example,
we
close
stuff
I,
don't
know
like
CCM
CSI
drivers,
I,
don't
know
many
of
the
health
charts
that
users
deploy
and
I
think
this
is
something
that
is
also
important
to
cover
like.
We
really
need
to
tell
to
folks
making
such
components
to
Downstream
consumers
like
big
vendors
and
so
on,
like
you
really
have
to
switch
as
soon
as
possible,
even
if
it
is
not
really
nice
experience,
but
this
is
something
that's
like
all
right
device.
Yeah,
we
don't
know.
A
D
Let's
stay
on
an
older
patch
of
an
older
release,
you
know
that
you
can
choose
when
you
want
to
upgrade
I
mean
for
sure
for
for
things
in
for
things
in
maintenance,
you're
kind
of
you
should
be
considering
moving
to
the
next
release.
The
next
minor
release
for
things
in
you
know
for
things
that
are
still
within
the
the
patch
support
cycle
you
you
do
have
some
time
to
stay
on
a
previous
patch.
If,
if
that
is
going
to
be
a
disruptive
change
for
you,.
A
Okay,
yeah
there's
a
question
from
Angelos
in
the
chat
regarding
if
registry
either
case
study
is
a
stable
as
the
older
one
and
yes,
it
is
so.
The
the
only
difference
between
the
two
is
that
when
you
are
hitting
the
the
so
one
domain
is
part
of
a
Google
service
and
then
one
is
the
community
domain,
but
I
mean
technically
they've.
They
work
differently,
but
it's
been
under
testing
for
a
while,
now
and
I
think
all
glitches
have
been
figure
it
out.
A
So,
as
as
the
communications
effort
moves
along
I'll
try
to
share
more
in
the
in
our
channel,
the
other
one
I
couldn't
communicate
as
much
because
I
was
traveling
while
doing
this,
but
in
the
next
one
I
promise
to
be
more
more
communicative
about
it
all
right.
The
next
one
is
from
Leo.
We
still
have
time
yet
and
I'm
tracking
image
updates.
Yes,.
F
So
this
was
brought
up
by
by
dims
in
a
threat
and
I
was
I.
Think
it's
worth
bringing
this
to
this
meeting.
So
if
we
have
like
new,
contain
Images
new
images
in
general,
this
is
usually
done
in
two
steps
to
PRS
and
it
happened
yesterday
that
we
for
or
yesterday
we
noticed
that
the
pr
to
update
the
reference
to
the
new
image
was
forgotten,
and
perhaps
there's
like
a
good
idea
to
lock
this
or
to
improve
that.
F
A
Yeah
yeah
I
I
saw
the
comments
live
by
and
I
actually
I
had
a
discussion
with
Carlos
about
one
month
ago
that
we
were
seeing
sometimes
folks
do
that
like
updating,
bumping
images
but
not
completing
the
process
of
actually
rolling
them
out.
So
maybe
we
should
like
ride
down
on
our
I.
Don't
know
if
there's
a
how
the
documentation
on
image
forms
what
it
looks
like
or.
D
Yeah,
it's
I
mean
like
it
it's
here
and
there
I
think
the
documentation
for
like
goaling
images
is
just
pretty
much
ensconced
in
the
issue.
Template
for
golang
image
updates
the
the
issue.
Template
also
does
note
that
the
issue
should
be
filled
out
and
completed
by
a
release,
manager
and
part
of
the
reason
for
that
is
because
of
this,
because
that
last
mile
of
the
of
the
update
gets
dropped.
D
D
It
has
been
a
while
since
I've
touched
the
code
but
like
I
should
or
does
have
the
capability
to
essentially
look
ahead
in
terms
of
updates
and
check
if
something
should
be
updated.
What
we
could
do
is
add
a
update,
the
parameters
of
the
existing
pre-submits
for
Zeitgeist
to
block
on
to
block.
If
there
is
an
image
update
for
certain
Registries,
but
we'd
have
to
dig
into
how
we're
using
it
today
in
kubernetes,
kubernetes.
A
D
A
A
E
Yeah
I
have
a
couple
of
really
quick
ones,
so
Marco
and
I
were
discussing
release
manager,
Associates
reviewing
cherry
pick
PRS
and
right
now
to
apply
the
label.
You
have
to
be
in
the
release
managers
group
to
do
it
manually,
so
we
discussed
that.
Maybe
it
would
be
cool
if
there
was
a
pro
plug-in
that
could
better
look
at
the
release,
managers
and
the
release
manager
Associates
list
and
then
do
some
validation.
E
So
I
opened
an
issue
to
track
that
and
I
started
working
on
PR
yesterday
to
start
implementing
a
new
plugin
it'll
be
called
cherry,
pick
approved
to
go
alongside
of
our
cherry
pick,
unapproved
plugin.
If
you
have
any
suggestions
on
how
that
might
look,
feel
free
to
drop
them
into
the
issue.
Sasha
drop
some
some
comments
in
there
about
things
we
might
want
to
do
later
on
too
so
feel
free
to
take
a
look
at
that
one.
E
If
you
have
any
feedback
or
comments,
I
think
that'll
be
it'll,
be
cool
once
we
have
this
and
then
the
other
one
I
just
wanted
to
mention
a
couple
of
changes
that
I
did
to
K
release
that
just
got
merged.
One
I
modified
the
build
the
docker
file
and
the
makefile
for
building
go
Runner.
So
now
you
can
override
the
destroyless
image
and
point
it
to
another
registry.
If
you
want
to
so,
it's
not
hard
coded
to
GCR
and
then
I
also
allowed
you
to
override
the
Builder
image.
E
E
Remove
that
just
to
clean
things
up
a
little
bit
and
then,
as
I
was
looking
at,
that
we
had
a
discussion
in
siguri's
or
in
release
management
I'll
go
back
and
find
the
thread
and
Link
it
here,
but
there's
a
question
whether
we
need
to
do
a
step
in
the
build
for
cube
cross
at
all
or
if
it
needs
to
change
right
now.
If
the
target
architecture
for
build
for
the
cube
cross,
it's
being
built,
is
AMD
64.
it
tries
to
cross.
E
It
tries
to
pre-compile
the
standard
library
for
everything
that
we're
going
to
build
and
that
selects
you
know
like
the
s390x
and
the
windows
386
and
everything,
and
it
only
does
that
for
AMD
64.
so
like
if
you're
building
it
and
you're
going
to
run
it
on
like
a
new
Macbook
or
something
that's
arm64
and
you're,
targeting
arm64,
it's
not
going
to
do
that.
E
So
I'm
doing
some
analysis
right
now,
just
to
see
if
we
want
to
continue
doing
that
inside
of
the
qpross
image,
if
we
get
rid
of
it,
it'll
shrink
the
image
down
a
little
bit
and
just
make
it
a
little
bit
easier
to
maintain
it's
going
forward.
So
I
don't
know
if
I
I
opened
an
issue
for
that
or
not
I.
Think
I
did
I'll
link
it
here
too.
E
A
D
D
Exactly
yeah,
yeah
and
I
mentioned
Milestones,
specifically,
because
Milestone
also
includes
that
ability
to
to
restrict
based
on
GitHub
teams
right,
so
we
can,
we
can
do
it
for
the
the
get
the
the
release
managers,
team
I
think
I
am
overdue
to
get
back
to
the
discussion
around
onboarding
for
release,
manager,
Associates
and
and
kind
of
moving
through
that
ladder.
Overall,
one
of
the
things
that
we
want
release
manager
Associates
to
be
able
to
do
is
do
that.
D
Cherry
pick
review
the
I
think
the
the
question
that
will
always
come
up
as
kind
of
like
is
this
ready
for?
Is
this
ready
for
approval
and
is?
Is
a
release
manager
associate
necessarily
the
right
person
to
determine
that
so
I
I
think?
That's
I
think
that
at
least
in
the
interim
we
should
see
hopefully
see
an
uptick
in
police
manager
Associates
doing
review.
Even
if
it's
you
know,
for
the
sake
of
of
having
a
pre-review
for
release,
managers
to
eventually
approve
before
being
able
to
kind
of
Grant.
D
D
Chair
I
think
Jeremy
has
been
doing
a
phenomenal
job
kind
of
on
the
on
the
release
team
on
the
release
team
sub
project,
but
really
kind
of
looking
across
to
say
handling
some
of
the
the
fun
politics
that
we
have
to
do
deal
with
on
occasion
across
all
cigs
and
really
just
doing
a
phenomenal
job
overall.
I
think
that
the
the
opportunity
is
there
if
he's
interested
in
it
and
I
heard
that
he
is
so
that
is,
that
is
the
first
change
that
we'll
be
proposing.
D
The
second
is
again
again
one
of
our
fellow
teammates.
That
kind
of
goes
above
and
beyond.
On
the
on
the
technical
side,
both
in
in
kind
of
encouraging
encouraging
new
contributors
within
the
Sig,
as
well
as
making
sure
that
the
wheels
don't
kind
of
fall
off
of
the
race
car
or
the
rocket
ship
or
whatever
metaphor
that
we
want
to
use
so
we'd
like
to
propose
that
Veronica
join
us
as
a
Sig
release.
Technical
lead,
yep.
D
So
again,
thank
you.
Thank
you
to
both
Jeremy
and
Veronica
for
your
hard
work
really
across
years,
I.
Think
working
in
Sig
release
the
the
time
starts
to
lead
together,
but
we've
been
we've
been
kind
of
working
on
it
for
a
while
and
seriously
the
the
folks
that
come
to
come
and
stay
and
provide
that
kind
of
connective
tissue
for
people
who
are
people
in
processes.
Kind
of
that
that
we
depend
on
like
thank
you
seriously.