►
From YouTube: Kubernetes SIG Release Bi-Weekly Meeting for 20211130
Description
Kubernetes SIG Release Bi-Weekly Meeting for 20211130
A
Now
welcome
everyone
to
our
sick
release.
Meeting
I
would
like
to
remind
you
to
please
adhere
to
the
kubernetes
code
of
conduct,
which
basically
means
that
be
excellent
to
each
other
and
be
mindful
what
you
say
yeah.
So,
let's
start
with
our
sick
release
meeting
and
let's
start
with
welcoming
new
attendees,
and
do
we
have
anyone
on
the
call
who
would
like
to
introduce
themselves.
A
B
I
guess
I
can
do
it.
We
there
haven't
been
many
changes
recently.
The
last
big
one
was
that
all
of
the
spvdx
and
licensing
goggles
plato
to
its
own
to
its
own
repository.
So
now
the
bill
of
material
soul
is
now
a
separate
project
of
its
own.
We
already
run
the
first
release,
pulling
the
libraries
from
that
repository,
so
things
are
mostly
going
well
and
besides
that,
I
think
things
have
been
quiet
on
the
on
the
release
engineering
code
base,
as
we
are
nearing
release
dates.
B
A
A
So
the
next
topic
is
the
roadmap
and
vision
update.
So
I
provided
a
short
summary
about
what
is
going
on
from
a
status
perspective,
how
we
can
align
our
roadmap
and
vision
with
some
enhancements
in
kubernetes,
and
we
have
two
open
caps
right
now.
So
we
have
this
also
compliance
cap
and
a
release,
artifact
signing
cap
and
both
kind
of
align
with
each
other,
and
our
overall
goal
would
be
to
merge
both
caps
because
they
are
kind
of
small
and
before
christmas.
A
So
I
really
would
like
to
encourage
you
to
give
them
a
review.
Maybe
add
some
suggestions
or
just
put
your
lttm
there,
because
we
kind
of
need
to
support
from
the
whole
stick
to
that
that
it's
clear
that
everyone
is
on
the
same
page
and
then
we
can
continue
implementing
the
technical
details
behind
both
caps.
A
So
I
think
our
next
goal
would
be
to
zoo,
after
merging
those
caps
to
start
with
integrating
designing
of
release
artifacts
and
therefore
it's
not
completely
clear.
If,
but
how
we,
how
we
do
that,
but
in
general
we
can
kind
of
experiment
and
find
out.
For
example,
we
start
with
container
image
signing
and
things
like
that
and
yeah.
B
Not
really
so
the
salsa
one
got
a
some
comments
from
tim,
which
I'm
going
to
take
a
look
and
address
today,
probably,
but
so
yes,
everyone
is
encouraged
to
take
a
look
and
and
provide
comments,
insights
or
just
a
thumbs
up
as
we.
We
want
to
really
kick
this.
I
think
we're
lagging
a
little
bit
far
behind
on
starting
the
the
signing
of
the
artifact
thing.
This
has
been
on
discussions
from
years
even
from
the
fact
that
the
initial
technology
suggests
that
are
not
even
longer
in
use.
A
D
I
do
well,
I
was
very
familiar
sorry
for
myself,
so
I
was
very
familiar
with
the
salsa
compliance
framework
and
etc,
but
after
cubecon
I
started
disengaging
a
little
bit,
because
I
understood
that
there
were
a
few
efforts
from
different.
I
would
call
them
parties
or
actors
involved
in
this
yeah
just
in
this
effort
that
were
not
necessarily
technical
but
like
to
my
understanding.
D
There
were
a
few
people
interested
in
the
same
goal,
so
I
didn't
know
yeah.
I
don't
know
where
we
are
at
at
this
point
like
is
it?
Does
the
main
effort
live
on
sick
release
or
yeah
who's?
The
current
leader
of
all
of
this
in
general?
I
know
that
on
our
side
at
also,
you
have
done
a
lot
of
work
and
I
am
very
familiar
with
the
code
that
you
have
written
like
on
the
technical
side.
I
I
don't
have
any
questions
just
like
where,
where
does
this
live?.
B
Yeah
so
after
some
discussions
going
back
and
forth
with
with
both
online
offline
and
by
making
some
trials
in
code,
we
we
are
suggesting,
as
a
c,
to
use
cosine
and
to
implement
the
salsa
framework.
There
are
other
there
are
other
efforts
around
it
and
that's
why
we
open
the
gap.
So
if
anyone
has
any
suggestions
or
could
envision
a
different
path
to
to
accomplish
this
goal,
they
can
go
into
the
gap
and
suggest
them.
B
I've
we've
been
pretty
much
a
lot
of
folks
here
in
the
call.
We
have
had
some
sort
of
discussion
about
what
we
see
and
I
think
we
have
been
in
some
consensus
that
we
see
the
most
momentum
behind
cosine
and
salsa
and
they're.
Both
efforts
hosted
on
the
year
under
the
open
ssf,
which
is
like
the
sister
of
the
cncf
sister
foundation
of
the
cncf.
So
that's
why
we
chose
those
and
but
yeah,
it's
they're
open
for
anyone
to
comment
and
suggest,
especially
we.
B
So
there
are
two
two
two
important
facts
to
note
here.
This
is
a
decision
to
choose
which
technologies
we're
following
so
which
technology
sets
and
the
framework
we're
adopting
and
because
these
are
users
are
facing,
and
then
we
we
will
own,
as
I
say,
all,
of
the
implementation
of
whatever
path
we
choose
to
follow.
A
Yeah
yeah,
so
I
just
want
to
underline
that
we
want
to
keep
the
discussion
surface
as
low
as
possible
and
yeah.
I
think
we
thought
about
who
else
could
own
it,
but
we
kind
of
agreed
on
that
mainly
only
sick
release
is
the
owner
of
this
overall
effort.
So
we
don't
see
any
other
sex
really
involved
in
it.
Maybe
testing
when
it
comes
about
technical
details,
but
not
about
which
technology
to
choose
or
how
signing
what
to
assign,
for
example,.
B
D
A
Yeah
yeah
exactly
and
as
a
follow-up,
I
see
what
we
already
can
do
if
we
see
that
we
can
agree
on
those.
Both
caps
is
to
carve
out
some
follow-up
stories
or
issues
because
for
the
signing
effort,
for
example,
we
could
start
on
some
topics
in
parallel
yeah.
We
don't
have
to
block
each
other,
so
we
don't
have
to
work
on
it
sequentially,
because
we
can
sign
binary
artifacts
in
kind
of
independently
from
container
images.
E
B
Okay,
yeah,
I
can
maybe
start
giving
a
little
bit
of
background
on
those,
so
there
was
during
the
119
release.
I
think
decision
was
made
to
before
19
in
including
I
think,
whenever
the
release
branch
was
cut,
the
but
the
process
to
make
the
branches
even
was
that
one
of
the
release
managers
will
go
in
and
then
fast
forward,
the
the
branches
so
that
they
match
and
they
have
all
changes
and
they
they
go
in
parallel
right
during
119.
B
So
during
119
the
children
was
made
to
stop
doing
the
fast
forwards
and
then,
instead
of
that,
require
pr
authors
to
file
a
cherry
peak
besides
their
their
their
feature,
pull
requests
so
today
and
you're
expected
to
go,
and
whenever
you
want
to
to
submit
a
pr
you,
you
submit
your
pr
and
in
side
by
side
you,
you
should
submit
a
cherry
piece.
Cherry
pick
request
to
the
feature
to
the
release
branch.
In
this
case
to
123.
B
it
seems
that
not
the
the
the
decision
was
not
really
well
communicated
and
during
1
20
at
least
when
I
was
a
branch
manager
for
121
and
122..
There
were
people
who
still
didn't
know
this
process
existed.
We
sent
a
a
notice
to
kdev
to
remind
people
that
we
were
not
fast
forwarded
on
the
branches
and
we
expected
them
to
follow
the
cherry
picks,
but
even
right
now
we
have
seen
some
some
confusion
around
that.
B
D
Yeah
so,
as
I've
also
said
we
have
been
discussing
this,
I
was
not.
I
I
saw
that
there
were
conversations
about
121
and
122
being
unaware
of
of
the
change,
and
so
right
now
for
me
I
don't
know
about
navarro,
but
for
me
I
am
getting
familiar
with
adolfo's
work
on
when
he
was
branch
manager
to
see
how
we
can
proceed,
and
I
also
know
that
this
topic
was
set
for
bigger
discussion.
D
D
C
Yeah,
so
I
I
I
know
from
the
pr
author's
perspective
that
it's
just
easier
for
for
us
to
do
fast
forward.
I
mean,
like
you
know
they
don't
have
to
do
another
chat.
I
didn't
have
to
do
another
pull
request
to
the
release
branch
but
like,
but
with
the
issues
when
we
did
that,
and
we
had
issues
with
that.
So
it
is,
I
think,
as
I
think,
if
it's
maintained
the
the
quality
of
of
the
merge
pull
requests
to
it.
C
Might
it
would
be
better
to
maintain
the
with
the
cherry
picks,
so
we
don't
have
issues
with
milestones
and
and
other
issues
that
might
come
with
fast
forwards.
We
could
do
a
lot
more
communication
with
that,
so
we
could
do
it
at
the
start
of
the
release.
We
could
do
it
in
the
middle
of
things.
We
could
do
it
at
every
phase
of
communication
with
the
release
or
once
we
get
impressions
to
to
to
the
branch
cut.
C
C
D
Yeah,
I
I
think
I
agree
with
you
ray
that
just
for
the
sake
of
I
mean
we
only
have
a
few
days
left
yeah
for
this,
so
in
my
personal
opinion,
not
even
as
a
branch
manager
but
but
technically
speaking
like
I
would
pick
a
fast-forwarding
and
then
discuss
it
and
make
sure
to
build
things
properly
for
124,
but
obviously
happy
to
follow
the
consensus.
If
there's,
I
don't
know
nabarun
what
are
your
thoughts
around
this.
F
A
So
this
overall
code
freeze
period
should
be
as
small
as
possible
and
we
are
now
down
to
two
weeks
and
we
create
the
release
candidate
with
or
the
branch
with,
the
release
candidate,
which
is
also
something
kind
of
new
since
this
year,
and
the
benefit
is
that
we
have
a
very
short
period
where
the
master
branch
is
frozen
and
the
issue
with
that.
So
in
theory,
it's
totally
fine
because
the
process
would
align
with
the
patch
release
process.
A
So
if
you
want
to
merge
your
merge
something
into
the
master
branch
to
match
something
into
the
meso
branch,
the
milestone
has
to
be
applied
right
now,
but
if
it
merges-
and
you
want
to
ensure
that
it's
also
part
of
any
release-
you
have
to
cherry
pick
into
a
release.
Branch-
and
this
is
the
same
process
for
all
of
those
release.
A
Branches
and
reintroducing
fast
forward
would
have
to
be
in
the
drawback
that
we
would
still
have
some
documentation
effort
around
the
process,
so
it
would
make
the
process
more
complicated
on
the
branch
manager
side.
But
on
the
other
side-
and
I
think
and
that's
the
the
main
issue-
we
cannot
guarantee
that
everything
is
merged
when
we
create
a
release
branch
because
brow
kind
of
tests,
those
pr's
in
batches
and
then
merges
if
prowl
things
all
tests
have
been
passed,
and
this
doesn't
necessarily
align
with
the
release
branch
creation.
A
So
we
don't
don't
align
on
that.
So
we
create
a
release
branch
and
it's
possible
that
afterwards,
some
pr's
got
merged
and-
and
it's
also
possible
that
some
prs
got
applied
to
the
milestone.
But
this
is
a
different
process,
so
yeah.
What
we
can
do
now
is
just
as
nebron
already
mentioned,
watch
the
master
branch
mergers
and
maybe
encourage
those
authors
of
those
brs
to
cherry
pick
or
we'll
share
a
pick
on
our
side.
A
So
this
should
be
fine,
because
we
only
have
a
few
days
left
before
the
releases
will
be
cut
and
and
for
the
future.
I'm
not
completely
sure
everything
we
change
will
introduce
more
effort
on
one
side,
but
I
also
see
the
point
that
the
from
a
contributor's
perspective,
it's
not
ideal
at
all.
Right
now,.
A
C
A
Wrong
words
yeah,
but
that's
fine,
but
that's
totally
fine.
The
idea
would
be
to
not
block
the
master
at
all,
so
we
always
can
merge
into
the
master
branch
and
then
pr
all
of
those
fpr
also
see
that
okay,
we
created
the
next
release
branch.
Then
they
would
have
to
cherry
pick
in
the
same
way
we
do
for
patches,
but
does
this
work?
I'm
not
completely
sure
if
I
have
the
full
context
on
this?
B
B
I
think
that
during
what
24,
we
should
really
establish
a
roadmap
to
see
and
handle
this
well,
because
it's
still
not
it's
still
kind
of
mushy
and
in
limbo,
and
it's
not
even
in
the
branch,
one
of
your
handbook
that
frenchman
is
supposed
to
do
this.
So
after
we're
done
and
ray
added
the
discussion
to
the
retrospective
and
then
after
that,
we
can
hopefully
synthesize
everything
and
drop
the
new
policy
and
not
design
new
new
tools,
if
needed.
D
Since
stephen
suggested
or
sort
of
yeah,
let's
say
that
he
suggested
the
fast
forwarding,
but
that
obviously
discussions
had
to
be
had
do
we
have
anything
like
specifically
against
cherry
picking,
because
what
navern
said
makes
a
lot
of
sense,
especially
since
there
are
very
few
pr's
right
now.
But
I
don't
know
if
there
are
any
any
reasons.
Why
not
to
follow
cherry
picking.
H
Yeah,
sorry,
I
just
like
it,
so
maybe
I
missed
some
context,
but
when
we
discuss
it
between
jordan
back
last
week
or
when
was
it,
the
reasoning
was
that
it
is
a
manual
step.
It
is
something
that
can
be
forgotten,
for
example,
by
the
release,
leads
or
whatsoever,
and
it
can
happen
that
yeah
we
just
don't
do
it.
Sophie,
doesn't
land
in
the
release
that's
coming
up,
and
if
it
is
more
standardized
process
done
by
release
managers,
then
we
increase
the.
We
actually
decrease
the
chance
that
it
might
be
forgotten.
H
A
Yeah,
one
drawback
is
probably
the
manual
effort
on
our
side,
so
reviewing
cherry
picks
takes
more
time
than
doing
executing
a
fast
forward.
But
and
we
have
a
huge
list
of
milestone
maintainers
and
I
think
we
had
some
prs
in
the
past
who
got
applied
to
a
milestone
and
then
slipped
into
the
release,
which
were
probably
both.
Often
cherry
pick
and
a
further
discussion.
So
I
mean
we
already
have
the
cherry
pick
process
in
place
and
yeah.
So.
D
D
A
A
A
H
H
Did
it
pull
the
comments
and
so
on,
and
we
found
out
that
the
reasoning
for
that
is
that
the
master
branch
of
some
stage
repositories
like
cube,
ctl
client,
go,
and
I
think
those
are
only
two
of
ones
affected-
are
missing.
One
cognitive
for
economy
that
got
merged
on
community
slash
kubernetes
in
master,
there
is
no
such
commit
in
those
stage.
H
Repositories
turns
out
that
comet
got
merged
around
when
we
cut
beta0
release
the
one
that
we
are
missing
tag
for
and
so
far
it
appears
that
the
publishing
bot
doesn't
really
know
how
to
handle
the
tree
that
we
build
when
we
push
the
release,
because
if
you
remember
correctly,
a
few
months
ago
in
june,
we
changed
the
process,
we
don't
rebase
the
master
batch
anymore,
we
use
merging.
So
when
we
push
the
changelog
commit
for
the
release.
If
something
happens
in
between,
for
example,
someone
pushes
a
comment.
H
H
So
we
need
definitely
to
take
a
look
at
this
before
we
cut
the
next
release.
I
think
that
we
will
probably
save
for
1.23,
because
we
will
not
have
any
comment
in
between,
but
I
still
think
we
should
spend
some
time
looking
into
this.
To
try
to
see
is
this
problem
on
our
side
and
can
we
fix
anything
about
it?.
H
A
So
I'm
kind
of
wondering
where
the
race
is
because
we
fetch
from
the
remote
and
then
we
merge
the
master
into
the
release
brand
or
into
the
release
branch
or
into
the
master,
and
then
we
push
it
without
force
pushing
so
usually
there
shouldn't
be
any
commits
missing.
So
I
still
don't
understand
completely
where
this,
where
this
overall
race
happens,
because
this
whole
process,
as
you
described,
the
issue
with
merging,
should
be
fine
in
theory.
So
I
don't
see
any
any
big
gap
with
that.
A
So,
but
I
I
see
that
there
may
be
some
some
racy
behavior
between
what
is
going
on
on
the
remote
master
branch
and
what
we
then
merge.
But
in
theory
we
can't
push
if
there
is
any
remote
change
right.
So
it
wouldn't
work
at
all
no
yeah,
but
did
we
had
any
issue
with
the
with
the
release
that
did
we
had
to
retry
it
on
on
release
or
something
like
this.
B
H
So
I
don't
know
why
better
I
mean
we
were
wondering
why
that
wasn't
the
case
before
and
we
concluded
that
it
was
probably
that
we
were
just
lucky
enough
that
it
didn't
happen
but
looks
like
that
day.
We
probably
had
many
comments
and
triggers
some
weird
behavior
of
this
logic.
So
it's
probably
up
to
that.
I
mean
we
can
defeat,
investigate
it,
a
little
bit
more
so
yeah.
F
What
what
I
got
from
the
conversation
is
when
publishing
bot
runs.
It
tries
to
find
the
commit
from
which
the
branches
were
fought,
and
in
this
particular
case
it
found
a
commit
from
where
two
different
kind
of
branches
are
fought.
So
if
you
can
see
marcos
pr
so
how
we
are
doing
the
merging
the
master
into
the
tracking
branch
and
then
merging
it
back
we're
kind
of
not
using
the
parent
master
as
the
parent.
F
So,
ideally
even
stefan
suggested
like
maybe
what
we
can
do
is
when
we
push
our
changes
instead
of
like
pushing
them
directly
to
master.
What
we
can
do
is
raise
a
pr
so
that
it
goes
through
the
usual
workflow,
so
that
frow,
when
it
merges
the
pr
into
master
it
gets
the
correct
parent
commit
publishing
bot
works
on
that
parent
commit
for
its
correctness.
F
F
B
A
Yeah,
as
you
already
mentioned,
it
may
be
possible
that
the
publishing
but
doesn't
see
all
commits
because
it
doesn't
follow
the
path
we
are
kind
of
merging.
So
it
follows
the
wrong
the
wrong
parent
commit
and
then
doesn't
see
this
commit
and
then
throws
an
error
and
yeah
yeah.
I
mean
the
idea
with
the
pr
is
probably
really
really
good.
Maybe
we
can.
We
can
really
do
this
because
we
are
able
to
create
prs
and
not
during
our
release
process
and
therefore
we
would
have
a
chance
to
review
what
was
what
was
going
on.
A
H
Now
I
think
the
hugest
problem
in
this
case
is
the
master
branch
where
we
push
the
change
locks.
So
I
guess
we
would
probably
not
have
that
much
of
a
problem
with
the
release
branches,
because
at
the
most
we
would
have
one
merge
commit,
and
I
guess
publishing
bots
would
probably
handle
that
properly.
I'm
not
sure
we
will
have
to
check
that,
but
master
is
problematic
because
we
do
multiple
mergers
over
the
time
because,
for
example,
on
that
day
we
pushed
four
releases
which
had
three
patch
releases
and
one
better
zero
release.
H
A
Okay,
then,
I
would
suggest
we
follow
up
on
the
discussion
on
the
issue
you
opened
and
then
we
will
see.
I
mean
there
were
some
plans
that
the
publishing
board
moves
into
the
zac
release
ownership
right.
Maybe
this
is
a
good
chance
to
understand
the
wall,
workflow
and
yeah
that
we
have
more
influence
on
how
it
goes
and
can
keep
track
of
it
a
bit
better
in
the
future.