►
From YouTube: Kubernetes SIG Release for 20230113
Description
Kubernetes SIG Release for 20230113
A
All
right,
everyone
Welcome
to
our
first
sick
release,
meeting
for
2023
and
I,
wish
you
all
happy
New
Year
and
would
like
to
remind
you
that
this
meeting
at
your
studio,
cngf
code
of
conduct,
which
basically
boils
down
to
be
excellent
to
each
other
Marco
added
the
sick
release,
meeting
agenda
and
the
chat
and
I
also
shared
with
you
with
you
in
the
screen.
So
please
add
yourself
to
the
list
of
attendees,
and
we
also
require
one
note
taker
for
today.
Do
we
have
anyone
on
the
call
who
would
like
to
take
notes,
foreign.
A
A
B
Yeah
sure
I
left
some
notes
in
the
agenda,
but
so
let's
get
started
for
OBS.
Sadly,
we
don't
have
major
updates,
as
of
now
I
still
need
to
sit
down
and
come
up
with
a
cap
update
and
I
plan
to
do
it
next
week,
since
I
got
busy
with
work
and
every
holidays
and
stuff
like
that,
so
I
didn't
have
time
before,
but
I
hope
that
sometimes
next
week,
I
will
be
able
to
provide
the
pr,
and
then
we
can
continue
our
discussion
there.
Besides,
that,
we
had
core
updates
and
we
update.
B
We
have
a
PR
for
updating
Master
to
go
for
the
20
thanks
to
Carlos.
For
this
we
also
did
the
update
of
go
on
release
branches
for
124
and
then
23
to
go
1.19.
This
is
something
that
I'd
like
to
discuss
a
little
bit
more
in
depth,
because
I
think
this
is
important
and
I
added
an
agenda
point
for
this
in
the
open
discussion,
so
that
we
can
go
through
this.
B
Besides
that,
I'd
like
to
do
an
update
and
reminder
for
January
patch
releases
for
126,
125,
124
and
123.,
the
those
Specialists
are
scheduled
for
January
18,
which
is
the
next
week,
and
with
that
being
we
have
the
traffic
deadline.
This
Friday
on
January
13th,
one
more
thing
is
to
mention,
is
that
what
23
is
officially
in
the
maintenance
mode,
but
I
think
we
should
cut
at
least
one
more
patch
release
to
ship
the
go
updates
that
we
did
recently
besides,
that
yeah
I
think
this
covers
most
of
this
stuff.
B
A
A
B
Yeah,
exactly
the
cap
that
we
have
right
now
is
talking
about
in
general.
What
are
we
expecting
from
the
new
infrastructure?
How
is
it
going
to
work,
and
what
is
the
plan
is
that
I
would
like
to
expand
it
with
the
solution?
The
the
concrete
solution
that
we
chose.
This
is
OBS,
how
it
exactly
Works,
what
are
the
positive
and
negative
sides
and
how
we
how
it
should
all
like
look
like
in
terms
of
automation
like
who
is
going
to
evoke
the
process?
B
A
D
B
Yep
they're
sure
thank
you
for
that.
We
will
keep
insight
about.
What's
the
plan
I
plan
to
come
up
with
something
at
least
some
working
progress
PR
for
cap,
and
then
we
can
probably
iterate
based
on
that
to
see
what
we
can
edit,
what
we
can
remove
and
stuff
like
that,
but
yeah,
it's
just
been
a
bit
busy
last
week.
So
in
that
we
didn't
Advantage
plan,
but
I
hope
it
should
get
better.
As
of
this
next
week,.
E
But
if
someone
wants
to
help,
please
let
me
know:
I
I
know
I,
don't
remember
right
now,
who
said
this
a
long
time
ago,
but
that
if
there
was
a
spreadsheet
to
track
the
Cherry
picks,
it
will
be
easier
for
them.
I'm
happy
to
to
start
a
spreadsheet.
If
that
works
for
you
and
you'll
want
to
help.
But
I
learned
that
just
ping
me
other
and
otherwise
I
won't
do
it.
But
if
you
wanted
I'll,
do
it?
A
F
G
It's
all
right,
I
mean
that's
the
gist
of
it.
I
was
gonna,
say
to
give
a
little
bit
more
detail
on
that.
The
shadow
survey
closed
last
week,
Tuesday
third,
the
enhancements
of
team
has
finished
their
selection
and
started
reaching
out.
Everyone
else
has
have
you
ever
the
other.
Five
sub
teams
has
almost
finished
selection.
So
thank
you
to
all
the
Rollies
for
doing
that.
I'm.
G
G
G
I
missed
two
of
those
files,
completely
my
fault,
but
that
caused
some
delay.
Interestingly,
from
talking
to
nabaroon,
this
happened
last
cycle
as
well,
something
very
similar,
so
I
think
there
needs
to
be
some
verbiage
in
the
EA
GA
handbook
to
help
advise
on
on
not
having
that
happen
and
how
why
it
happens.
It's
a
slack
issue,
basically
so
yeah.
So
look
at
that
and
then
once
Shadows
are
selected
I'll
work
on
generating
ensuring
non-identifiable
statistics
you
from
the
people.
G
I
H
Yeah,
why
not
for
kadev,
just
for
just
for
funsies,
just
to
be
super
transparent,
I,
say
that,
because
people
kind
of
always
have
this
question
about
what
we're
doing
and
how
we're
doing
it.
And
when
surveys
are
opening
closing
up
down
left
right,
yada,
yada
I
would
just
send
I
would
just
blast
it
wide.
Honestly.
G
I
G
A
B
Yes,
I
am
in
advance,
sorry
for
the
number
of
topics,
but
we
had
quite
a
few
happenings
over
the
since
the
last
meeting
and
the
first
one
I
wanted
to
a
little
bit
talk
about
policy
for
go,
updates
on
release
branches,
so
I
mentioned
it
in
the
update
earlier,
but
just
to
repeat
for
folks
who
just
joined
it.
We
had
two
PRS
that
updated
go
for
release
branches
for
123
and
124
to
go
1.19
because
other
go
releases
are
not
supported.
B
B
Since
now,
when
this
happened-
and
this
one
is
a
little
bit,
I
worried
a
little
bit
because
what
effect
this
might
have
to
the
community
and
to
users
of
go
libraries,
because
now
you
might
end
up
needing
to
update
to
go.19.
If
you
are
using
about
23
and
124,
and
this
is
something
that
is
a
little
bit
new
I.
B
Don't
I,
don't
know
if
we
provide
any
backrest
compatibility
regarding
Go
version,
but
I
wanted
to
at
least
announce
it
and
to
send
a
note
to
kdev
to
say:
okay,
we
updated
Google
1.19,
please
make
sure
if
you're
using
our
kubernetes
dependency,
make
sure
that
you
will
need
to
update
about
that
Titan
as
well,
but
yeah.
Besides
that,
once
we
said
the
announcement
I
don't
see
a
big
problem
with
that,
but
I
just
wanted
to
write
the
bonus
with
it
because
it
happens
over
the
holiday
seasons
actually,
two
or
three
days
before
the
Christmas.
H
So
I
would
I
would
I
think
you
know.
I
saw
some
of
those
things
flying
around
and
one
I
think.
Let's
discuss
the
reasoning
because,
yes,
we
haven't
done
that
and
and
I
was
under
the
impression
that
we
had
gotten
to
the
point
where
we
were
in
a
reasonable
skew
for
the
release
branches,
so
I'm
not
sure
if
there
was
an
extension
or
something
that
made
this
unpossible
impossible
to
to
to
maintain
for
kind
of
the
lagging
branches.
B
E
B
Year
so
we
will
have
a
problem
that
we
wouldn't
be
able
to
deliver
security
updates
and
stuff,
like
that
it
was
the
biggest
driver
behind
this
change.
As
far
as
you
know,
so
that
we
can
ensure
the
communities
and
release
branches
are
built
with
Google
verses
that
are
not
vulnerable
to
some
of
the
security
stuff.
That
is
being
announced
that
he
has
been
announced
recently
as
well.
H
Yeah
I
think
I
still
have
mixed
feelings
on
this,
and,
and
it-
and
it's
part
of
you
know
part
of
it-
is
that
having
a
Go
version,
be
out
of
you
know,
be
out
of
support
is
is
actually
a
forcing
function
for
people
to
upgrade
versions
of
kubernetes
right.
We
we
cannot
infinitely
support
the
support
release
branches
if
there
so
was
this
like
this
timing
with
our
lagging
branch
and
the
and
go
117
support.
B
B
B
Yeah,
but
at
this
point
we
merge
those
br's.
This
is
what
I'm
not
sure
like.
Should
we
just
accept
it
as
it
is?
Should
we
eventually
consider
reverting
it?
I,
don't
know
for
124.
I
am
just
looking
at
the
calendar
and
it
is
going
in
maintenance
mode
end
of
May
as
far
as
I
see
here,
so
we
would
have
at
least
how
much
is
it
three
or
four
months
between
it
reached
end
of
between
interest
maintenance
mode
and
go
up
on
1.8
in
end
of
life?
H
B
Yeah
I
am
I
personally
fix
this
with
these
already
like
we
shouldn't
go
back
because
I
don't
know
if
it
is
going
to
have
some
negative
effects
like
his
publishing,
but
with
stuff
like
that.
It
is
maybe
more
risky
to
just
divert
this
if,
as
of
right
now,
but
I
think
we
should
announce
this,
and
we
should
probably
bring
this
up,
maybe
even
if
form
a
sub
cap
or
something
like
that,
so
that
we
have
a
formal
documented
way
that
we
decided
to
do
this.
H
H
J
E
I
think
that
in
general,
sorry,
we
have
been
doing
things
that
go
slightly
against
our
not
against,
but
breaking
the
boundaries
of
our
policies,
which
I
think
it's
normal
and
if
different
things
happen,
like
several
things
happen
it.
It's,
maybe
Worth
to
revisit
those
policies
like,
for
example,
this
one
or
the
one,
how
we
treated
122
and
so
on
right.
So
because
the
the
policies
are
clearly
not
serving
for
edge
cases
that
that
is
my
opinion
and.
E
Thoughts
came
to
my
head
now.
I
know
why?
Because
that
that
way,
if
we
have
clear
policies,
I'm
not
saying
that
we
should
amend
them
or
not,
but
like
just
having
Clarity
on
what
we
have,
we
are
very
distributed
and
we
are
very
of
of
offline
and
I
think
so
sometimes
someone
needs
to
make
a
decision
when
the
rest
of
us
are
not
around
right
or
whatever.
E
So
having
clear
guidelines
on
how
to
make
decisions
is
easier
for
for
everyone
to
not
depend
on
a
specific
person
to
make
a
final
call,
so
that
that
is
my.
My
rational
in
general,
not
just
specifically
about
the
gold
policies
here
had
I
been
in
that
situation.
I
would
have
known
what
to
do
because
our
policy
stated
one
thing
yeah,
but
it
was
also
necessary
so
that
that
is
my
point
of
view.
H
H
Thank
you
for
working
on
it
and
and
pushing
the
ball
forward,
but
in
in
future
we
should
make
sure
that
we
I
I
would
I
would
sooner
block
for
discussion,
because
things
are
always
harder
to
revert
than
they
are
to
just
do,
and
the
I
think
we've
gotten
the
process
down
to
it
is
not.
It
is
not
magic
and
it
is
not
easy,
but
once
it's
you
know
like
it,
it
we've
gotten
it
roughly.
To
the
point
of
of
you
know,
there
are
some.
H
You
know
search
and
replaces
that
you
can
do
that,
will
roughly
get
some
of
this
done
and
then
outside
of
emotions
and
and
actually
using
the
promoted
images
like
it's.
It's
done
it's
not
as
difficult
as
it
was
in
the
past
to
quickly
answer
our
node
so
quickly.
Answer
your
your
question
about
in
the
chat.
H
So
no
RC
go
Wang
for
release
branches,
absolutely
not
no
RC's
on
no
RCs
for
forgoing
on
our
release
branches,
and
that's
part
of
the
reason
that
we
push
forward
on
trying
to
so
I
believe
Carlos
already
started
working
on
the
120
RC,
one
updates
for
for
the
the
for
the
development
branch
and-
and
you
know-
and
we
can
already
see-
we've
got.
You
know
our
120
RC
2
out
as
of
the
last
few
days.
H
J
B
In
general,
there
are,
there
were
some
CVS
over
the
past
few
months
that
we
included
in
Google
updates
and
in
library
updates
as
well
like
xnet
Library,
which
wasn't,
which
we
may
not
be
able
to
up
its
own
123
because
it
was
using.
It
was
70.,
but
yeah
I
mean
I
have
to
agree
with
Stephen
and
Veronica
about
this,
because
we
should
yeah.
You
should
actually
have
lot
on
it.
I
jumped
a
little
bit
too
quick
on
the
Chain,
because
we
folks
wanted
to
get
it
merged
before
holidays.
B
To
get
the
CI
signal
before
break,
to
make
sure
that
everything
is
working
and
that
we
don't
do
it
too
soon
before
the
patch
releases,
but
yeah,
maybe
we
should
have
just
I,
should
have
just
blocked
on
it
and
waited
for
everyone
to
get
back.
This
is
definitely
something
that
I
messed
up,
but
yeah
I
think
that
we
should
definitely
update
any
policy
to
decide
if
you
have
to
continue
going
with
these
further
or
then
to
stop
doing
this
in
the
future.
B
Like
one
thing,
that
I
would
just
add,
if
that's
okay,
one
of
the
reasons
why
we
didn't
do
that
before
was
that
go
was
introducing
some
breaking
changes
to
call
them
like
that
in
the
language
itself,
and
that
didn't
make
it
possible
to
update
goal.
But
since
recently
like
4.19
about
18
and
quite
clean
what
the
20
they
made
it.
B
They
reduced
that
number
of
changes
and
made
it
possible
to
disable
some
of
those
changes
like
Fidos
go
debug
environmental
variables
and
stuff
like
that,
which
were
implemented
on
release
branches,
to
make
sure
that
we
have
the
same
behavior
as
before,
so
that
we
don't
change
anything
regarding
that.
But.
B
H
H
Why
of
it
and
discuss
if
we
need
to
change
policy
based
on
that,
the
for
for
making
changes
on
the
release
branches-
yes,
I
agree
that
it
is
easier
than
it
used
to
be,
but
as
the
as
one
of
the
people
who's
usually
working
on
the
the
beta
RC
roles
into
the
development
branch,
there's
a
bunch
of
stuff
that
breaks
and
and
lynchers
are
also
one
of
them
right.
So
if
we're
bumping,
you
know
if
we're
bumping,
you
know
if
we're
bumping
major
Go
versions
on
release
branches.
H
We
also
have
to
consider
that
and
the
amount
of
work
that
it's
going
to
take
to
bring
in
changes
that
bring
in
changes
that
we
may
not
be
calculating,
especially
if
it
is
related
to
Feature
work.
So
it
is,
is
generally
something
that
we
we
absolutely
do
not
want
to
do
unless
there
is
a
really
really
good
reason.
So,
like
a
good
reason
for
me
would
be
like
would
be
a
a
massive
security
vulnerability.
H
That's
discovered
a
you
know,
just
a
super
super
mega
regression,
I,
don't
know
where,
on
the
scale
of
of
regression
super
mega
goes
but
I
like
just
a
a
crushing
regression
which,
which
happened.
I
think
you
know
two
three
releases
ago
where,
where
it
was
I,
think
it
was
more
advisable
to
we
were
kind
of
touch
and
go
based
on
the
Go
version
and
and
the
release
because
of
the
because
of
impact
to
to
stability,
to
scalability,
I
I
think
in
particular
for
one
of
the
Go
versions.
H
124
could
have
been,
it
could
have
been
it's
at
least
a
year
ago,
but
but
stuff
like
that
stuff
that
is
going
to
to
materially
impact
people's
operation
of
kubernetes,
whether
it
be
through
security,
scalability
Etc.
But
yes,
we
should.
We
should
document
this
stuff,
but
it
is
a
I
think
we
are
because
of
where
we're
seated
in
just
we
are.
We
are
the
group
that
releases
kubernetes.
Ultimately,
we
we're
the
ones
who
packages
it.
H
We
tend
to
be
in
this
this
role
in
service
to
a
lot
of
other
groups
right,
and
that
often
causes
us
to
be
a
little
bit
more
relaxed
on
our
policies
in
service
of
those
groups
right.
So
what
I
would
ask
is,
when
you
get
a
request,
regardless
of
who
it's
coming
from
question,
whether
or
not
that
is
that
is
with
our
or
against
our
policy
and
why
we
would
actually
want
to
do
it
before
executing.
J
In
the
end,
one
thing
I
wanted
to
add
is
that
we
also
need
to
consider
that
by
bumping
the
minor
version,
we
could
fundamentally
be
altering
the
way
kubernetes
behaves.
There
are
sometimes
like
things
like
performance
improvements
which,
on
massively
massive
scale,
they
tend
to
have
an
impact,
and
then,
if
you
consider
the
the
overlap
of
when
our
branches
go
out
of
support
and
the
Go
versions
go
out
of
support,
maybe
it's
we
need.
J
Probably
maybe
the
police
is
right
and
not
doing
it
and
I'm
trying
to
avoid
changing
it.
Of
course,
like
students
said,
if
there's
something
like
really
really
critical
well,
we
need
to
to
go
there,
but
there
are
some
things
that
we
can
possibly
anticipate.
Like
I
mean
yeah,
it
may
fundamentally
it's
we
I
mean
it.
It
will
not
break
the
code
base
and
compile
that
I'm,
not
sure
if
it's
really
our
job
to
be
to
anticipate
like
in
a
really
quick
snap
position.
J
B
I
would
I
would
just
like
to
ask
for
more
concern
that
he
has
been
raised
right
now
by
Adolfo
and
Joseph
Richard.
It
is
that
we
that
PR
data
data
goal
actually
made
sure
that
there
are
no
unexpected
changes.
Like
you
said,
there
are
some
performance
improvements
that
are
costing
more
resources,
but
those
changes
are
disabled
by
using
those
I,
don't
know
kinda,
environment
variables
and
stuff
like
that,
so
those
are
not
going
to
affect
users
like
even
maybe
a
little
bit.
You
know
Globe
like
1.18.
B
B
I
would
like
to
recapate
so
I
think
that
we
should
probably
go
as
it
is
for
now.
We
should
prepare
an
announcement.
We
show
the
calligraphy
in
details
like
what
happened
and
that
it
is
not
supposed
to
have
any
negative
impacts
on
users,
since
we
paid
some
attention
to
that
and
based
on
that,
I
will
also
try
to
go
ahead
and
collect
the
feedback
on
that.
To
talk
about
folks
who
are
achieving
this
and
to
try
to
come
up
with
some
PR
on
issue
to
it.
H
Yeah
and
I
I
would
you
know
so
so
going
back
to
the
kind
of
going
through
the
backlog
to
understand
why
the
changes
happen.
The
reason
I
stress
that
is
is
the
second
we
send
and
also
being
metered
with
whatever
we
we
send
out
as
an
announcement,
the
second
lease
on
the
announcement.
Second,
we
lock
in
yet
another
policy,
especially
if
it
is
if
it
is
more
relaxed.
H
We
start
beholding
ourselves
to
to
that,
so
expect
requests
for.
You
know
for
updates
on
on
on
previous
branches
as
a
result
of
that
or
expect
people
to
point
to
our
policy
as
a
result
of
that,
let's
be
be
sure
that
anything
that
we
send
out
we're
guarding
against
that,
because,
while
we
are
assessing
that
there
may
be
minimal
performance
impacts
across
release
branches,
there
could
be
catastrophic
ones
right.
C
B
C
C
B
B
Yeah
now
that
we
discuss
this
in-depth
with
gold
stuff
and
so
on,
I
was
wondering:
do
we
have
a
policy
for
sending
staff
to
care
now,
so
I
was
wondering
concretely
in
this
case,
for
example.
Is
it
worth
to
also
send
it
to
K
announce
because
it
is
affecting
kubernetes
user
in
general
like
to
make
sure
or
do
we
want
to
send
to
kdev?
H
H
Branch
manually
tag
something
rerun
things
and
and
like
throw
out
an
entire
release
like
that
announcement
is
going
out
to
is
going
out
to
K
announced
to
let
people
know
that
that,
like
don't
use
this
tag
at
all,
as
well
as
as
well
as
like
a
link
to
here's,
why
it
happened
and
then
here's
what
we're
doing
to
fix
it.
I
try
to
I
try
to
lean
towards
over
Communication
in
those
instances
in
general.
H
I
think
the
answer
is,
we
don't
have
an
answer,
and-
and
this
is
another
like
good
like
let's
do
a
policy
thing-
I
think
you
know
a
baseline
would
be.
You
know
if
it's
something
that
is
local
to
Sig
release,
then
definitely
Sig
release
if
it's
something
that
you're
seeding
feedback
from
Sig
release
leads
or
release
managers
to,
say,
realist
leads
or
release
managers
groups
as
appropriate,
and
if
it's
something
that
is
is
going
to
affect
the
community,
then
definitely
kdev.
H
C
B
Yeah
I
would
just
I
think
the
register
changes
is
maybe
more
important,
but
about
this
PR
please
just
take
a
look.
It
is
a
super
simple
one.
It
is
about
dropping
the
kubernetes
source
code
from
Big
publishable
GitHub
releases,
so
just
to
make
sure
that
we
plan
that
the
numbers
to
drop
in
this
in
January
January
is
here
so
I
want
to
make
sure
that
three
movies
hold
on.
It
is
okay,
so
yeah
just
take
a
look
at
that
and
provide
your
feedback.
B
C
B
The
next
topic
will
be
the
register
changes
thing
we
have
been
asked
about
it
and
Ben
pointed
out
in
CK
test
infra
that
we
are
again
spending
a
lot
of
money
on
gcp,
so
yeah.
There
had
been
some
discussion
in
this
group
that
we
should
stop
publishing
tags
and
stuff
like
that,
but
we
never
really
came
with
anything
concretely.
So
I
wanted
to
make
sure
that
we
come
up
with
some
communication.
Let's
see
if
anybody
can
help
with
that.
B
K
Hi
happy
New
Year,
just
to
basically
complete
Mark
or
say
so
dude.
The
main
idea
is
to
ensure
for
127
we
stop
push
controller
image
to
kiss.gci.io,
so
I
saw
the
slack
conversation.
This
is
they're
like
some
technical
Decay.
We
need
to
figure
out,
but
ideally
we
should
make
a
communication
for
to
the
six
and
the
overall
community
that,
basically,
once
while
127
is
out,
we
only
privilege
to
to
preciously
the
case.
Hotel.
K
Oh
and
because
the
patch
really
is
in
December
change
the
Regency
endpoint,
we
can
extend
that
to
also
other
release
branches.
So
basically,
that's
the
idea.
We
need
to
figure
out
this
Milestone
and
that's
why
my
might
say
we
should
basically
make
a
really
quick
and
early
announcements
to
basically
say:
oh,
if
you
are,
if
you
consume
a
project
for
the
communities
project,
we
should
be
used
in
your
register.
Endpoint.