►
From YouTube: Kubernetes Weekly SIG Release Meeting for 20200407
Description
Kubernetes Weekly SIG Release Meeting for 20200407
A
A
So
today,
I
wanted
to
talk
about
kubernetes
119
right.
We
are
joined
here
today
by
Taylor
Taylor,
who
is
our
incoming
kubernetes
119
release
team
lead
so
Taylor,
Tim
and
I
have
been
chatting
a
little
bit
about
some
of
the
stuff
that
we're
going
to
be
working
on
for
119
and
I
figured
that
will
do
this.
Oh
I'll
just
share.
You
know
what
I'll
share
my
to-do
list.
How
about
that,
and
and
we
can,
we
can
go
through
it
that
way,
all
right.
So
can
everyone
see
my
screen?
Okay,
yes,
awesome
cool!
All
right!
A
A
Taylor
is
also
using
to-do
list,
so
I
figured
it'd
be
a
good
way
for
us
to
collaborate
on
a
few
things,
so
the
first
one
up
on
my
list
at
least
was
proposed.
Delaying
the
119
start,
so
we
talked
about
that
a
little
bit
and
and
what
that
could
look
like
and
I
think
we've
decided
that
we're
not
going
to
do
that
right,
Taylor,
based
on
some
of
the
targets
that
we're
trying
to
hit
for
the
cycle.
If
you
want
to
talk
about
that,
a
little
bit
yeah.
B
Absolutely
so
yeah,
that's
a
100%
yeah
that
was
definitely
in
the
gut
of
a
lot
of
us
is
just
you
know,
with
everything.
That's
going
on,
be
nice
to
take
a
bit
more
time,
strengthen
some
of
the
things
we're
trying
to
come
into
the
119
release
with,
and
unfortunately
looks
like
that
through
code
freeze,
as
well
as
a
couple
other
dates
into
jeopardy
through
cluster
to
July,
4th
and
summer
holidays,
and
so
you
know
it's
kind
of
like
we'd
have
to
hit
those
dates
before
all
of
that
happens
rather
than
after.
B
If
we
wanted
to
guarantee
you
know,
I'm,
actually
getting
some
of
those
things
done
and
giving
people
some
leeway
so
we're
looking
at
that.
We
still
want
to
target
all
the
dates
that
we're
going
to
set.
But
we
want
to
you
know,
talk
about
the
cigs
and
make
sure
that
they
know
let's
focus
little
bit
more
instability.
Yes,
features.
Is
there
fantastic,
but
let's
try
to
make
this
a
little
bit
more
mistype
word
release
and.
A
A
B
So
this
is
the
pull
request.
That's
that
is
literally
pulling
in
the
119
release,
leads
and
then
I
believe
we
have
one
of
the
proposed
shadows
on
the
call
as
well
Bob,
so
smoking
thin
and
speaking
with
a
couple
more
people
about
release,
lead
shadow
position.
The
release
lead
survey.
It's
going
to
go
out
a
little
bit
later,
today's,
what
we're
aiming
for.
So
we
could
start
to
pull
more
shadows
in,
but
we
do
have
the
leads
in
place
and
PR
is
open.
A
Check
it
out
and
a
lot
of
this
information
should
not
be
surprising
anyone.
These
shadows
were
selected
on
the
on
the
selection
issue
or
if
these
leads
excuse
me
or
selected
on
the
selection
issue
for
for
119,
kicked
up
in
the
118th
cycle,
the
an
additional
ad
since
then
as
a
Tim
is
going
to
be
joining
the
team
as
the
emeritus
advisor.
So
we
talked
about
following
the
the
118
retrospective.
A
It's
it's
something
that
I've
been
staring
at
for
a
few
few
cycles,
and
you
know
I,
think
that
you
know
the
the
community
meeting
or
the
retrospective
the
two
parts
of
the
retrospective
or
one
really
big
opportunity
that
we
have
to
basically
showcase
to
the
community.
What
we've
been
working
on
for
the
quarter
and
I
really
believe
that
we
should
do
our
best
to
make
sure
that
the
issues
that
we
talked
about
during
the
retrospective
actually
get
completed
for
for
the
next
cycle.
A
So
that
said,
I
think
that
you
know
Taylor
myself,
Tim
agreed
Tim
has
an
abundance
of
knowledge
as
a
previous
release.
Team
lead,
as
a
you
know,
a
sub-project
owner
for
a
lot
of
the
sub
projects
that
we
have
or
all
of
the
sub
projects.
So
you
have
four
sig
release
as
well
as
one
of
the
the
sig
release
co-chairs.
A
The
Tim
would
be
an
excellent
candidate
to
to
run
through
and
kind
of,
ensuring
that
we're
we're
running
through
that
backlog
of
previous
four
retrospective
issues,
as
long
as
as
well
as
applying
all
the
appropriate
context
that
he
has
from
from
experiences
and
the
release
team
lead
role
in
the
sig
chair
role
was
one
of
the
patch
release
team
members,
so
I
think
that's
going
to
be
super
valuable
for
the
team.
I'm
super
excited
to
have
that
happen
and
yeah.
It
should
be
I,
think
and
I
think
it.
We've
got
a
great
crew
of
people.
A
A
A
A
Right
and
you
know
some
of
these
dates
like
these
dates
are
just
kind
of
like
mental
dates
for
myself
to
start
looking
at
things,
not
so
much
for
you,
but
I
will
put
together
a
document
that
kind
of
talks
about
what
we
we
should
be
looking
at.
So
some
big
things
are
like
the
the
cube
ATM
out
of
tree
cap.
A
If
you
saw
earlier
today,
Lube
mirror
sent
out
an
email
talking
about
how
we
manage
client
components
that
could
be
out
of
tree
that
are
currently
in
tree
right
and
how
we
kind
of
guide
them
in
that
process,
from
going
going
from
entry
to
out
of
tree
right,
so
the
things
that
are
required.
They're
branching
and
tagging
strategies
release
strategy,
how
we
do
packaging
for
those
for
those
client
components
or
things
that
we're
really
looking
to
discuss
and
drive
down
for
this
cycle.
A
You
know
cube
ATM
is
one
of
them,
cube,
CTL
will
likely
be
next,
and
then
there
are
slew
of
other
components.
You
know
within
kubernetes
kubernetes
that
we
need
to
look
at.
So
you
know
this
is
this
is
interesting
because
it's
it's
one
of
those
things
that
we
have
tie
essentially
like
fundamentally
rooted
into
the
way
we
do
releases
right.
A
So
you
know
it's
it's
in
the
the
release,
library
or
the
make
files
within
kubernetes
kubernetes,
and
then
you
know,
maybe
it's
rooted
in
checks
that
are
done
in
an
go
to
publish
to
certain
locations
based
on
these
client
components.
So
there
a
lot
of
things
that
we
need
to.
We
need
to
stare
at
and
we
need
to
figure
out
how
to
start
detangling
that
ball
of
wax.
A
A
The
next
one
is
the
working
group
LTS
support
policy,
all
right,
so
there's
a
there's.
A
cap.
That's
currently
open-
and
I've
mentioned
these
a
few
times
these
through
to
open
caps
right
now.
The
LTS
support
policy,
essentially
discussion
of
bringing
our
support
policy
up
from
nine
months
or
approximately
nine
months
up
to
a
year
right,
so
giving
people
more
opportunity,
operators
more
opportunity
to
upgrade
their
components
in
a
way
that
is
more,
maybe
amenable
to
their
schedules,
while
keeping
them
within
the
support
cycle.
A
A
And
if
anyone
wants
to
copy
links
over
for
some
of
these
things
until
it
would
be
appreciated,
thank
you
cool,
so
the
next
one
is
a
post.
Merge
work
for
the
enhancements
kept
all
right,
so
yeah,
I
didn't
enhancements.
Kept
and
I'll
show
this
to
you
real
quick.
So
this
is
kind
of
like
the
the
aggregate
of
the
multiple
hats
that
I
have
on
at
times.
A
We,
what
did
we
do?
We
did
this
so
Tim.
How
can
put
up
a
pr2
to
do
some
improvements
to
how
we
manage
the
cap
artifacts,
so
you'll
see
this
start
to
pop
up
in
our
enhancements
collection
for
119
I,
believe
it's
an
architecture
and
improve
kept
implementation.
Okay.
So
if
you're
familiar
with
the
meta
cap,
which
was
kept
kept
1
a
right,
it's
kind
of
an
offshoot
of
cap
1,
which
defines
what
the
cap
process
is,
the
the
meta
cap
has
become
6:17
right.
A
So
what
we're
doing
there
is
we're
now
binding
keps
to
the
issues
that
they
are
related
to
right.
So
one
of
the
ideas
is
that
so
you
can
see
617
enhanced
a
kept
implementation.
This
is
opened
a
while
back
and
it's
connected
to
a
few
things,
and
you
can
see
some
of
the
things
that
I'm
talking
about
here,
but
we
wanted
to.
We
thought
it
was
a
good
time
to
step
in
and
do
some
improvements,
so
this
or
catch
people
up
on
what
we've
been
working
on.
A
A
What
issue
would
enhance
an
issue
this
cap
is
connected
to
right.
You'll
also
see
that
they're
in
a
directory
now
right.
So
it's
a
directory
named
the
what
was
originally
the
kept
title
and
we're
breaking
out
into
two
separate
files.
One
is
the
readme
which
is
actually
the
kept
content
right
and
the
second
one
is
kept
yamo
and
the
kept
IMO
is
what
was
originally
the
front
matter
for
the
caps
right.
A
So
you
can
see,
the
cap
number
has
come
back
as
17,
and
now
we're
binding
kept
numbers
two
to
the
issue,
the
the
enhancement
issues.
So
there
is,
you
know
the
original
concern
around
that
was
was
essentially
having
collisions
on
the
numbers
and
for
people
who
worked
in
our
earlier
release
cycles
around
enhancements.
We
saw
that
there
were
quite
a
few
collisions
while
people
were
working
on
caps,
so
we
think
that
this
will
prevent
some
of
that.
A
A
So
what
else
did
we
add
right?
So
here
we
want
to
add
a
notation
that
allows
people
to
see
that
certain
things
are
not
resolved
right
and
we
might
bike
shed
on
what
this
notation
looks
like
a
little
bit,
but
right
now,
it's
kind
of
like
unresolved.
You
know
two
less
than
signs
square
brackets
and
unresolved
right,
and
the
reason
for
this
is
if
we
wanted
it
to
be
visible
on
the
document
and
not
get
eaten
by
any
comment,
formatting
from
HTML
or
markdown
right.
So
we
have
to
choose
some
arbitrary
thing.
A
There
has
to
be
a
better
way
to
do
this,
which
we
will
think
about
a
little
later,
but
changing
the
names
of
the
caps
as
I
mentioned
right
directory
structure
that
we
were
just
talking
about.
Having
the
metadata
split
out,
we
removed
some
of
the
fields
from
the
metadata.
We
realized
that
editor
is
not
really
used.
Last
updated
can
be
tied
to
get
history,
so
it's
kind
of
easy
to
present
this
field,
just
based
on
the
last
time
that
the
the
document
was
updated
and
then
the
superseded
field
was
also
removed
right.
A
So,
additionally,
we
want
to
make
it
very
clear
that
one
enhancement
is
equal
to
one
cap
right,
the
and
the
enhancement
issue
and
the
kept
track
the
track.
The
evolution
of
a
cap
from
you
know
from
baby
sages,
provisional
alpha
phase
into
its
its
GA
right.
So
there's
not
a
requirement
for
for
you
to
open
a
new
cap
for
every
you
know
for
every
phase
of
an
enhancement.
A
It
is
a
requirement
that
you
update
the
cap,
the
existing
cap
as
you
move
through
those
phases
and
you
work
through
the
the
release,
team,
checklist
and
so
on.
You
know,
and
and
and
make
sure
all
that
stuff
is
up-to-date
run
through
the
implementation.
History,
add
some
things
add
some
had
some
Doc's,
where
needed
so
also
the
adjusting
some
of
the
tooling
a
lot
of
the
stuff
that
we
a
lot
of
the
stuff
we've
done.
So
we've
done
the
add
kind
kept
to
to
community
and
K
features
which
are
now
K
enhancements.
A
You
can
see
this
cap
is
showing
it
to
age
with
these
links,
but
you
know
so
those
labels
are
implemented
and
we're
going
to
you
know
I
think
they've
now
been
removed
from
K
community
since
we've
done
that
sweet.
But
we
also
you
know,
we've
done
this
move
into
K
enhancements.
We've
I
think
what
we're
just
going
to
do
is
deprecated
the
architecture.
Documents
are
deprecated
design
proposals
rather
and
K
inque
community,
so
that
you'll
see
that
come
soon.
A
There'll
be
a
blockade
added
to
K
community
to
prevent
people
from
issuing
new
design
proposals
to
that
I
think
that
we've
kind
of
close
out
the
existing
design
proposals
already
and
and
and
pointed
people
towards
caps.
But
this
will
just
be
a
final
enforcement
mechanism
to
make
sure
that
people
can't
commit
there
anymore,
and
then
you
know
and
then
working
on
making
sure
that
people
understand
this,
this
new
directory
structure
and
probably
adding
some
tooling
around
helping
conversions
between
the
old
and
new.
A
The
next
one
is
rapture
right,
so
rapture
is
a
rapture
as
a
tool
that
is
used
internally
at
Google
to
essentially
rapture
packages
from
one
place
into
the
place
that
they
belong
and
that
it
are
the
official
app
tinium
repos
for
Google,
which
are
the
ones
that
we
use
for
the
release
process
to
publish
our
depth
and
rpms.
So
I
think
it's
important
that
we
understand
how
a
little
bit
more
about
how
that
works
as
we're
starting
to
change
the
way
that
we
produce
these
artifacts
right.
A
We
want
to
make
sure
that
we're
building
a
system
that
understands
the
inputs
and
outputs
of
rapture
so
that
we
can
build
tools
like
Q
P
pkg
around
that
right,
Googlers,
the
the
build
admins
or
the
set
of
Googlers
that
have
access
to
publish
to
the
package
repository.
They
essentially
use
an
older
version
of
our
repo
to
to
publish
to
use
the
scripts
and
tools
to
two-putt
to
output,
debs
in
rpm,
so
then
publish
to
two,
the
their
official
app
in
Yama
repose.
So
we
we
don't
want
that
right.
A
A
A
So
we
want
to
move
towards
a
place
where
the
community
has
full
ownership
of
of
these
artifacts
the
generation
publication
of
these
artifacts.
But
for
that
to
happen,
there
are
lots
of
things
in
the
middle
of
that
so
sasha.
I
think
you're
on
the
call
we
were
talking
about.
You
know
what
does
it
look
like
for
us
to
to
do
our
own
apt
and
yum
repos?
Where
do
we
put
those
or
the
permissions
behind
that
who
who
is
managing
who's?
Managing
those
details?
A
Gpg
key
is:
how
do
we
sign
these
things?
How
do
we
make
sure
that
they're
published
in
the
correct
way?
How
do
we
make
sure
that
the
people,
only
the
people
that
are
supposed
to
have
access
to
that
GPG
key
to
do
signing,
and
how
do
we
do
all
of
that
in
a
safe
way
right?
So
lots
of
questions
to
answer,
and
so
far
this
has
been
a
kind
of
backburner
in
comparison
to
you
know
in
comparison
to
some
of
the
other
stuff
that
we've
worked
on
in
migration
to
secure
brunette
ease
infra.
A
A
So
yeah
so
build
is
a
little
less
important.
Builds
will
be
more
so
easier
to
solve
once
we
move
over
to
kubernetes
infra
on
the
prow
side
right,
because
we
want
to
make
sure
that
we're
we're
publishing
I
would
love
us
to
get
to
a
point
where
we
can
publish
artifacts
for
nightly,
built
right
or
have
you
know,
have
this
process
run
end
to
end?
A
So
a
few
things
have
happened
on
the
staging
side
and
if
you
saw
there's
a
feature,
branch
called
prototype
that
I've
been
trying
to
you,
know,
search
and
replace
variables
and
undo
certain
things
in
an
AA
go
and
the
release
libraries
to
make
it
function
for
for
different
for
different
GC
key
projects,
different
GCS
locations,
different
GC,
our
container
registries,
some
of
that
work.
So
a
lot
of
it
is
creating.
A
You
know
making
sure
that
we
have
the
correct
I
am
privileges
attached
to
to
certain
people,
ensuring
that
we
have
kms
access
for
our
GC
p
projects
and
making
sure
KMS
is
even
enabled
right.
So
we
can
store
keys
like
the
github
token
and
pull
those
out
and
put
them
where
they
need
to
be
so
that
we
can
publish
releases
or
you
know,
sign,
assign
get
commits
things
like
that
right.
A
The
so
a
big
part
of
this
was
was
creating
the
new
projects,
its
themselves
and
updating
scripts
on
the
Kate's
io
repo,
to
enable
us
to
kind
of
you
know
we
have
the
staging
project
setup
right
now,
staging
and
kind
of
test
prod,
but
because
release
kind
of
has
subdivision
in
this
hierarchy
of
people
who
need
to
control
certain
things
and
assets
that
are
sensitive.
We
have
a
bit
more
work
to
do
there,
so
I
think
most
of
that
work
is
done
right
now.
A
So
the
next
phase
that
we're
looking
at
is
phase
two,
which
is
the
the
vdf
the
gates
GC
Rio
cut
over.
So
you
might
have
seen
emails
from
Linus
and
myself
over
the
past
few
weeks,
just
talking
about
when
this
thing
is
going
to
happen.
You
know
if
you
want
to
check
out
this
issue,
it's
something
that
we've
had
opened
since
2017,
so
it's
kind
of
exciting
to
see
that
this
is
finally
going
down.
A
But
part
of
you
know,
part
of
that
is
part
of
that
is,
is
one
making
the
changes
on
the
the
Google
side,
so
Kate's,
GCR,
I,
thought
I/o
is
a
vanity
domain
that
points
to
the
Google
containers
project,
which
is
where
we
store
store
all
the
the
containers
that
we
use
for
the
release.
You
know
so
the
first
class
images
things
like
the
API
server
controller
manager,
scheduler
proxy,
so
on
and
so
forth,
but
also
kind
of
these.
A
These
space
images,
things
like
cube,
cross
and
debian
base
and
debian
hypercube
base,
and
literally
anything
that
is
behind
that
cait's
that
GC
r
dot
io
vanity
domain.
We
need
to
make
sure
that
we
backfill
that
into
Kate's
artifact
prod,
which
is
a
new
project
for
everything
that
is
being
promoted
up
from
staging
right.
So
this
week
are
we
here,
we
hope
to
hear
some
more
about
what
the
progress
is
on
the
Google
side.
A
So
we
can
push
forward
in
because
in
coordination
it
requires
a
change
on
the
on
the
release
engineering
side
to
turn
that
on
for
a
na
go
and
our
release,
libraries
right
so
expect
more
of
that
work
within
the
next
few
weeks,
stuff
to
happen
with
in
changes
to
in
aw
go
Spence,
but
also
a
big
change
for
the
release.
Managers.
A
Okay,
all
right,
so
next
one
up
is
the
create
CI
signal
project
I
was
Jorge.
I
was
prepping
for
some
some
presentations
today,
so
I
didn't
get
to
do
that
yesterday,
but
essentially
we
have
an
issue
up
and
I'll
I'll
calm
it
today,
I
have
an
issue
up
for
someone
opened,
it
I
forgot
who
it
was.
It
was
me,
I
think
it
was
me
yeah,
but
we've
had
lots
of
discourse
and
that
issue
around
creating
a
CI
signal.
A
Sub-Project
right,
it's
clearer
and
clearer,
as
we
move
through
these
cycles,
that
we
need
a
team
that
is,
is
not
just
focused
on
the
quarterly
work
around
CI
signal.
So
the
you
know
so
the
119
branch,
as
well
as
the
master
blocking
and
forming
tests,
but
also
the
entirety
of
CI
signal
health
for
for
kubernetes
kubernetes
right,
so
making
sure
that
we
have
feedback
loops
between
us
and
the
teams
that
are
responsible
for
those
tests.
Making
sure
that
we
are
are
vicious.
A
Yes,
it's
a
nice
word
arounds,
the
the
criteria
that
we
hold
for
promoting
bringing
tests
in
to
informing
and
promote
blocking
right,
making
sure
that
these
are
actually
tests
that
we,
you
know
that
we
care
about
right,
that
we
care
about.
They
have
value
to
the
community
at
large
and
there
are
things
that
can
and
should
block
a
release
right.
So,
sir
writing,
so
we've
got
some
great
documentation
there
already,
but
you
know
buffing
that
up
even
further
and
having
a
team
that
can
be
responsible
for
for
creating
these.
A
These
connections
collaborations
between
multiple
SIG's
around
testing.
So
there
are
some.
There
are
some
things
that
have
to
be
hashed
out
on.
On
that
issue,
around
scope
and
really
when
I
opened
it,
it
was
meant
to
be
I,
was
kind
of
a
brain
dump.
I
said
these
are
the
things
in
my
head.
These
are
all
potential
things.
That's
the
eye
signal
could
do
here.
You
go
right
and
I
think
we
need
to
walk
back.
Some
of
that,
give
really
tightly
scope
them
to
say
hey.
We
have
found
we've
identified
people
across
the
cycles.
A
They've
been
helping
out
with
this,
and
at
this
point
we
need
to
turn
them
loose.
Give
them
like
give
them
this
list
as
a
loose
list
of
hey.
These
are
potentially
things
that
could
be
in
scope
right
and
then
have
that
team
of
people
who
have
already
been
working
on
this
determine
what's
in
and
out
of
scope,
because
there
is
some.
You
know
there
are
some
tighten
overlaps
between
that
projects,
creation
and
the
Charter
for
sake
testing.
A
C
A
B
A
A
A
Is
the
front
the
front
section
of
our
of
our
release
cycle
right,
so
we're
gonna
be
talking
with
our
I
have
been
talking
with
a
cigar
connector
as
well
as
some
of
the
enhancements
leads
on
a
enhancements
sub-project
right,
so
the
enhancements
sub-project
currently
lives
in
cig
p.m.
right.
It
was
migrated
out
of
sega
architecture
and
into
sake
PM
around
the
time
that
we
were
also
doing
some
of
these
kept
modifications
right.
It
was.
It
was
pretty
clear
at
that
time
that
ownership
should
should
be
under
cig
p.m.
A
right,
and
you
know
across
the
I
guess
it's
been
a
few
years
now
right.
So
you
know,
across
across
those
years,
have
kind
of
seen
that
we
don't
necessarily
have
the
the
viewership
subscribership.
You
know
contributors
in
place
in
cig
p.m.
to
continue
cig
p.m.
so
you're,
like
some
of
you
might
be
hearing
here
first
and
you'll
see
later
in
the
week.
Some
emails
go
out
for
me
about
retiring
sig
p.m.
so.
A
A
A
Okay,
so
that's
I
would
say
that
that's
super
secret
information,
but
it's
not
a
recorded
call
now.
So
it's
coming
soon,
so
the
next
one
up
is
talking
about
removing
fast
forwards.
So
this
is
going
to
affect
the
release
process
in
ways
that
maybe
have
not
calculated
yet
because
this
is
also
around
tooling
changes.
But
the
general
idea
is
that
you
know
one:
how
do
we
get
one
one?
Do
we
need
to
do
fast
forward
at
all,
right
and
and
two?
How
do
we
get
people
to
work
on?
A
How
do
we
get
people
to
operate
as
expected
for
the
various
boundaries
that
we
have
throughout
the
release
cycle?
So
if
you
think
a
code
phrase
and
code
code,
thaw
and
enhancements
freeze
and
all
these
things,
like
it
kind
of
rolls
into
the
way
that
the
next
portion
of
the
cycle
will
function
right
so
in
my
head,
what
I
see
happening
is
more
releases
for
the
cycle
and
well
maybe
one
more
one
or
two
more
right
so
want
to
decrease
the
amount
of
alphas
right.
A
A
A
So,
if
you're,
you
know,
if
you've
been
an
operator
or
a
service
provider
for
some
time,
you
know
that
there
is
a
tendency
for
people
not
to
be
too
excited
about
picking
up
a
dot,
zero
or
picking
up
an
alpha
of
anything
right
regardless
of
the
team,
that's
behind
it
and
the
amount
of
work
that
goes
into
it.
You
know
it's
it's
early
days
and
they
don't
necessarily
want
to
be
the
first
person
to
jump
out
and
try
those
things
out
all
right.
A
A
So
additionally,
I'd
like
to
add
at
least
one
more,
are
see
towards
the
end
of
the
cycle
and
I
think
that
the
RC
is
a
good
time
to
cut
the
branch
right
and
then
we
can
start
to
impose
restrictions,
because
it's
on
a
branch
we
can
start
to
impose
restrictions
there.
We
can
say
that
maybe
the
RC
happens
at
code
freeze
great
and
what
this
allow
we're
allowing
to
happen
there
as
well
is
that
we
push
people
earlier
into
so
we
have
a
cherry-pick
deadline
that
is
very
close
to
the
end
of
the
cycle.
A
D
A
Has
to
be
cherry-picked
right
now.
The
cherry
pick
has
an
additional
level
of
rigor
there
right,
and
it's
also
for
cherry
pick
to
be
approved.
It
has
to
be
reviewed
by
some
release
manager
right
so
I
think
that
that's
an
additional
gate
that
it
may
seem
like
a
hurdle
for
four
contributors,
but
I
think
it's
an
additional
gate
that
allows
us
to
be
a
bit
more
diligent
about
what
we
led
into
the
release
right.
A
You
know
if
a
branch
manager
is
reviewing
it
so
I,
you
know
the
the
ownership
of
that
branch
stays
on
the
branch
manager
until
the
the
dot
zero
comes
out
right,
so
the
branch
manager
would
work
with
the
patch
release
team
to
review
some
of
the
stuff
and
go
okay.
Well
is
this?
You
know
is
this
something
that
you
know
the
biggest
question
you
you
want
to
try
to
answer
with
a
patch
is:
is
this
something
that's
going
to
detrimental
e
affect
this
release
right?
Is
it
something
that
introduces
new
functionality
that
maybe
shouldn't
right?
A
A
You
know
there.
It's
the
fuzzy
line
between
whether
it's
a
feature
in
a
book
right.
Sometimes
you
enable
new
functionality
say
this.
This
comes
up
very
often
on
the
cloud
provider
side
right,
reenable,
new
functionality
on
the
cloud
provider
which
effectively
effectively
nullifies
a
bug
right
and
those
are
situations
that
we
look
at
and
go.
A
Okay,
maybe,
but
convince
me
right,
so
I,
you
know
figuring
out
exactly
how
to
do
this
because,
like
Onaga
is,
is,
is
wired
today
to
to
automatically
do
you
if
you're
doing
a
beta0,
it
will
turn.
It
will
turn
that
beta
zero
into
two
releases
right,
so
that
beta
zero
and
then
they
alpha
zero
on
the
on
the
the
master
branch.
Alright,
now,
what's
cool
about
also
doing
the
our
C's?
A
Is
that
the
the
alpha
that
we
cut
now
become
the
new
alpha
or
the
alpha
next
rate
that
we
cut
for
the
master
branch
is
now
a
lot
closer
in
line
and
feature
set
to
what
the
RC
is
for
the
118
or
119
right.
So
one
of
the
problems
that
we've
had
before
is
you
know
we
release.
We
release
the
alpha
zero
and
people
who
need
to
consume
alpha
zero
start
doing
so,
but
alpha
zero
still
looks
a
lot
like
what
beta
you
know.
A
What
118
beta
zero
was,
for
example,
right
so
by
shifting
that
over
we
get
a
little
closer
to
to
having
the
the
V
one.
Next
look
closer
the
V
one.
Next
alpha
zero
look
closer
to
what
the
rcs
looks
like
right
for
for
the
previous
cycle,
so
I
think
it's
you
know,
then
the
net
effect
will
be
good,
but
there
are
stuff
that
we'll
have
to
work
out
in
our
tooling
to
make
sure
it
actually
works.
A
That
way
and
I
think
that
moving
to
moving
to
that,
cadence
will
put
us
closer
to
having
the
RC
on
that
code.
Freeze
line
right
so
not
only
will
we
be
able
to
enforce
some
of
the
things
that
are
happening
are
some
of
the
things
that
we
expect
for
code
freeze
within
updates
to
the
way
that
prowl
handle
certain
labels,
but
we'll
also
be
able
to
enforce
that
by
having
additional
rigor
with
the
branch
managers.
Looking
at
those
PRS
as
well.
C
A
Know
what
it's
I
don't
have
a
good
answer
for
you.
We
did
a
survey.
I
would
say
it's
about
a
year
ago,
at
this
point
to
see
who
was
consuming
what
and
I
think
we
were
so
focused
on
more
so
focus
on
minor,
minor
and
patch
versions.
In
that
survey,
I
did
a
poll
on
Twitter
super
official
about
you
know
about
who
was
consuming
what
right.
A
So,
like
my
friend
Dalton
he,
you
know
he
he
works
on
the
distribution,
for
he
works
on
typhoon,
which
is
an
open-source
distribution
for
kubernetes
right
and
he
consumes
everything
right,
but
you've
got
you've.
You've
got
other
people
who
did
not
know
it
existed
right,
so
I
would
say
you
know.
Maybe
200
people
responded
to
that
survey
and
50
percent
of
them
about
50
percent
of
them
didn't
know.
Pre-Releases
existed
right,
so
I
think
that
this
is
a
mechanical
thing
that
we
can.
A
A
A
All
right
so
I'm
going
to
jump
around
a
little
bit
one
of
the
things
that
we're
talking
about
right
now,
I
sent
an
email
out
to
contributes
and
the
community
talking
about
issue
triage
workflow
automation,
improvements,
so
we're
gonna,
we're
trying
to
start
small
here
and
you
can
see.
There's
a
bunch
of
conversation
on
this
cap
are
ready.
A
I
have
to
respond
to
Tim
on
this
one
later
today,
but
the
basic
idea
here
is
that
we
want
to
make
it
easier,
and
this
is
something
that
will
affect
the
release
team
to
you,
because
we're
trying
to
make
it
easier
for
no
don't
edit,
okay,
trying
to
make
it
easier
for
people
to
triage
the
issues
that
are
open
right.
So,
if
you
read
this
cap,
you'll
see
that
they're
on
the
order
of
twenty
one
hundred.
You
know
we
can.
A
We
can
look
at
this
right,
so
total
twenty
nine
sixty-eight
between
issues
and
PRS,
open
and
kubernetes
at
any
one
time-
and
you
know
it
hovers-
it
hovers
right
around
that
three
thousand
range
right
and
various
various
ones
are
in
various
states
of
staleness
right,
so
stale
rotten
are
frozen,
frozen
and
maybe
stale
as
well
right.
So
that's
about
you
know
it's
about
twenty
percent.
If
we
aggregate
those
numbers
and
and
40%
and
42
percent
of
issues,
I
could
potentially
require
attention
right.
A
So,
looking
at
the
user
stories
and
and
again
I
tried
to
make
this
kept
pretty
short
so
that
we
could,
we
could
merge
quick
and
iterate
right.
So
the
the
stories
are,
you
know,
as
a
group
lead,
a
cig
share,
technical
lead,
working
group,
user
group
organize
or
sub
project
owner
I'll
be
able
to
easily
triage
my
groups,
backlog
of
open
issues
in
pers,
accelerate,
merge,
velocity
and
issue
resolution
right
as
an
reviewer
or
approver.
I
want
a
simple
system
to
categorize
issues
and
PRS
in
my
purview,
so
I
can
prioritize.
A
What's
a
review
first
and
as
a
contributor
I
want
be
able
to
submit
issues
or
PRS,
and-
and
this
is
you
know,
you
know,
constant
contributor-
are
a
drive-by
contributor
right.
I
want
to
understand
how
the
community
works
to
address
those
new
submissions.
I
want
to
have
some
assurance
that
they'll
be
routed
to
the
correct
group
and
I
wanna
I
want
to
have
them
addressed
in
a
timely
matter.
Right-
and
you
know
this
all
seems
I
think
it
all
seems
reasonable.
A
So
phase
zero
of
this
right
is
to
create
a
needs.
Triage
label
right,
so
the
needs
triage
label
would
operate
much
in
the
same
way
that
the
needs
kind
needs
priority
and
needs
sick
labels
operate
where
they
are
mutually
exclusive,
with
with
a
corresponding
kind
priority
or
sake
label
right.
So
the
idea
is
that
we'd
bring
in
two
new
labels
needs
triage
and
triage
ready,
we're
bike.
Shutting
the
same
and
I
said
you
know
somewhere,
that's
yeah,
you
know
it
should
be
considered
a
placeholder
name.
A
You
know
in
this
provisional
state,
depending
on
what
we
decide
is
more
appropriate
name
and
then
the
second
you
know
adding
a
restriction
here.
One
of
the
things
that
we
heard
from
from
you
know
when
we
shot
this
with
the
sig
chairs
and
technical
leads,
was
that
one
this
is
generally
useful
just
having
this
label
and
being
able
to
search
on
this
will
give
you
some
signal
about
what
to
attack
next.
You
know,
especially
if
you're
sick
does
triage
planning
our
our
planning
meetings
and
then
the
second
part
is
you
know.
A
The
request
from
Tim
was
basically
that
a
sig
should
not
be
able
to
so.
Ideally
only
people
from
that
sig
or
people
who
are
authorized
to
do
triage
are
removing.
This
label
are
applying
this
label
right.
So
my
thought
here
is
to
you
know,
in
the
same
way
that
we
restrict
the
way
people
can
apply
a
milestone.
We
to
use
the
milestone,
maintainer
x'
team,
to
restrict
who
can
apply
a
triage
label
that
doesn't
get
us
the
granularity
of
being
able
to
do
it
by
sig,
but
to
be
able
to
do
it
by
sig.
A
We
need
to
or
any
group
we
need
to
be
able
to
essentially
splat
those
groups
right
and
and
figure
permissions
and
I
think
that
that
is
messier
than
then
we
need
to
mess
your
rap,
then
we
need
to
to
go
down
so
I
think
that
milestone
maintainer
to
gets
us
most
of
the
way
in
terms
of
that
restriction
and
then,
from
there
you
know
a
cig,
would
you
know
cig
would
go
through
whatever
their
triage.
Workflow
is
right,
so
you
know
sig
cluster
lifecycle
has
a
grooming
document
about
how
they
do
what
they
do
right.
A
So
the
second
part
of
this
would
be
removing
unused
triage
labels
right.
So
currently
we
have
triage
duplicate,
triage
needs,
more
information,
triage,
not
reproducible,
support
and
unresolved
right,
proposing
that
we
remove
the
duplicate,
the,
not
reproducible
and
the
unresolved
labels
right.
These
are
labels
that
are
commonly
unused
and
leaving
that
needs
information
label,
the
ready
label
or
whatever
we
decide
to
call
that
label
and
the
support
label
right.
So
I
I
think
there
was
a
response
about
keeping
triage
support
and
I
kind
of
agree
with
what
Tim's
comment
on
the
cap.
A
I
think
it
would
probably
be
more
appropriate
if
we
renamed
this
label
to
kind
support
right.
The
idea
for
these
is
like
you
know,
if
you
open
a
support,
question
and
group
in
Andy's
kubernetes
someone
supposed
to
come
along
and
close
that
issue
right.
The
issue
is
essentially
there.
My
understanding
at
least
issue
is
there
to
provide
people
a
venue
to
submit
it
right,
but
then,
from
there
we're
supposed
to
point
you
to
more
more
appropriate
venue,
whether
that
stack,
overflow
discourse
slack
right
to
get
you
support
for
that
right.
A
We're
supposed
to
be
handling
things
like
failing
tests,
flakes
regressions,
bugs
features
right
within
kubernetes
kubernetes
and
not
anything
support
related
right.
That's
not
meant
to
be
one
of
our
support
channels,
Bob
I,
think
you're.
Here.
Do
you
want
to
talk
on
that?
A
little
bit
yeah
your
suggestion?
Was
it
actually.
A
Cool
cool
so
updates
to
this
kept
coming
today
later
today
and
I,
we
hope
to
I've,
said
a
lazy
consensus
date
for
for
merge
for
this
Thursday,
barring
any
more
blocking
comments.
I
think
once
I
do
this
update.
We
should
be
good
to
go.
Tim's
suggestion
on
the
triage
ready
was
to
be
triage,
accepted
by
sig
and
honestly
I.
Don't
care
like
if
it
works
for
people
like
we
can
name
it.
You
know
whatever
we
you
know
whatever
people
want
just
that
we
have
a
label
that
functions
in.
A
That
way,
is
what
I
care
about
right
and
I.
Think
that's.
You
know
a
lot
of
the
sig
chairs
and
leads
Express
that
just
having
to
say
having
the
needs.
Triage
label
solves
a
lot
of
their
problems
right,
so
I
think
that
this
is
a
net
improvement,
and
this
is
also
one
of
those
weird
things
where
there
are
certain
things
that
we
try
to
tackle
for
the
cycle
that
can
kind
of
only
be
successful
if
we
do
it
at
the
beginning
of
the
cycle.
A
So
this
one
has
kind
of
you
know:
we've
kicked
the
can
down
the
road
a
few
times
on
on
this.
One
I
think
it's
time,
I
think
it's
time
we
do
it.
People
are
hurting
lots
of
email,
threads
back
and
forth
about
how
you
know.
We've
got
a
ton
of
issues
and
and
and
not
a
really
easy
system
to
work
through
them.
So
this
would
be
a
start.
You
know
afterwards,
we
want
to
talk
a
little
bit
more
about
entry
and
exit
criteria
for
for
issues
and
PRS
within
kubernetes
kubernetes
right.
A
Whatever
they
apply,
whatever
triage
magic,
they
have
and
move
it
into
the
state
of
ready
or
accepted
by
say
whatever
we
end
up
calling
it
and
from
that
there
we
can
see
that,
like
hey,
this
issue
is
ready
to
be
worked
on
right.
Maybe
it's
maybe
at
that
point
it's
also
assigned.
Maybe
it
has
a
priority.
Maybe
it
has
a
good
first
issue
label
attached
or
a
Help
Wanted
label
attached,
so
we
kind
of
we
talked
about
a
few
different
ways
to
do
this.
A
Maybe
we
use
the
Help
Wanted
label
and
automatically
apply
that
that
seemed
a
you
know
that
that
seemed
not
necessarily
helpful
if
it
wasn't
properly
triage
at
the
same
time.
So
I
think
that
this
is
a
reasonable
path
forward,
at
which
point
we
can
talk
about
okay.
Well,
what
does
the
waiting
room
look
like?
Do
we
have
a
needs
info
label
where
you
know
it
essentially
means
waiting
for
user
or
blocked
on
user,
or
something
like
that
and
we
can
sort
by
those
two.
You
know
to
determine
if
something's
ready
to
work.
A
So
maybe
you
triage
two
streams
or
you
know
so-
lots
of
lots
of
stuff
to
discuss
and
I
think
lots
of
opportunity
to
bike
shed
there.
So
this
list
kept
intentionally
short
to
kind
of
close
the
areas
for
where
potential
bike
sheds
could
open
up.
So
we're
going
to
try
to
merge
this
quickly
decide
what
needs
to
happen
to
move
this
to
implementable
and
start
and
start
knocking
out.
A
Some
of
that
work
for
for
119
there
are
already
carry
PR,
is
opened
intestine
for
us,
it's
linked
in
the
implementation
history,
where
you
can
see
the
work
of
add
actually
adding
needs
needs
triage,
and
this
will
be
renamed
to
triage
and
creating
those
labels
and
then
making
sure
that
they
we
need
to
do
some
stuff.
Okay,
yeah.
This
is
the
proud
configuration
right,
so
so
needs
needs
triage
and
what
work
and
and
repo
its
operating
over
and
the
regex
that
it
applies
to
and
yada
yada
yada.
So
I
need
to
clean
this.
This
up.
A
Now
that
we've
had
some
updates
the
cap,
but
the
PRS
are
pretty
much
ready
to
go
for
this,
so
we
just
you
know.
The
bigger
part
is
because
this
is
a
change
that
will
affect
the
entire
community.
We
need
to
drive
community
consensus
around
it
right
so
know
that
that's
coming
for
119.
This
will
affect
the
way
that
the
bug
triage
team
works
and,
in
general,
every
team
I
think
teams
that
are
looking
at.
You
know,
like
teams
like
CI
signal
who
are
looking
at.
A
You
know
newly-opened
failing
tests
in
flakes
and
regressions
and
then
also
teams
like
bug
triage,
who
are
looking
at
newly.
You
know
newly
created
issues,
issues
that
are
in
milestone
or
needs
to
be
moved
out.
What
have
you
I
think
it'll
be
a
net
improvement
for
the
bug,
triage
experience,
because
you
know
this
is
kind
of
a
trickle-down
effect
right
where
if
the
SIG's
can
triage
their
stuff
more
effectively,
that
means
less
of
the
triage
work
is
going
to
be
on
on
the
bug
triage
team,
which
I
yeah
and
again
I.
A
Think
I've
said
this
previous
cycles.
I,
don't
think
that
work
should
be
on
bug,
triage,
I,
don't
think
I,
don't
think
a
team
of
four
people
should
be
responsible
for
a
you
know
ensuring
that
insuring
that
the
states
are
correct.
For
potentially
you
know,
hundreds
of
issues
within
kubernetes,
kubernetes
I,
think
they're
pushing
more
of
that
work
into
the
SIG's
and
some
projects
it's
going
to
be
a
net
win
for
the
SIG's,
as
well
as
the
release
team
and
and
and
the
sub
project
owners
and
role
leaves
on
the
cig
release
side.