►
From YouTube: Kubernetes SIG Release meeting 20191007
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
A
Be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general
just
be
excellent
to
each
other
I
think
that
should
be
fairly
simple
for
this
great
group
of
people.
So
we've
got
a
few
things
on
the
agenda
and
someone
not
here
me.
Sorry
I,
hear
you,
okay,
anybody
else,
I
think
it
might
be
a
you.
George
I
can
hear
you
loud
and
clear
all
right,
so
we've
got
quite
a
few
things
on
the
agenda.
I
am
going
to
do
some
shuffling
as
we
talk
in
the
meantime.
A
If
you
have,
if
you
have
things
that
should
go
on
the
agenda,
if
you
have
not
seen
the
agenda
I'm
popping
it
into
the
chat
right
now,
please
take
a
moment
to
put
your
names
on
the
agenda
if
you're
in
attendance
and
if
you
have
any
additional
topics,
please
put
it
at
the
bottom
of
the
agenda.
Let
me
just
move
that
and.
B
A
Or
did
I
okay,
I'm
gonna
move
the
github
issue
for
a
eyes
to
the
bottom,
since
that
one
can
take
will
take
a
while
I'm,
not
sure
if
that
we're
actually
going
to
get
through
this
agenda
today.
This
is
pretty
a
jam-packed,
but
let's
kick
it
off.
The
first
one
is:
should
artifacts
published
by
the
publishing
bot
be
released,
blocking
I
have
Aaron
and
kita
listed
as
the
owners
for
that
question.
A
I
believe
this
is
something
that
came
up
in
the
115
a
eyes,
but
I'm
not
sure
if
either
of
them
are
on
the
call
doesn't
look
like
either
are
okay,
my
my
idea,
yes,
I,
think
they
should
be
so
people
who
are
not
familiar
with
the
publishing
bots.
Essentially,
it's
a
set
of
configs
that
allow
you
to
take
something
that
is
living
in
staging
repo
are
staging
a
folder
of
the
kubernetes
kubernetes
repo
and
move
that
from
and
move
that
from
the
essentially
like
migrated
a
little
bit.
A
It
still
stays
in
the
repo,
but
it
also
lands
in
its
own
repo
right
in
the
publishing
bot
is
is
responsible
for
that
config
or
yeah.
So
there
is
I
think
it's
pretty
important
for
those
to
be
released,
blocking
as
a
lot
of
our
subsequent
releases
depend
on
that
are
the
underlying
our
underlying
release.
Artifacts
could
potentially
depend
on
that.
So
I
think
it
would
be
important
that
they're
released
locking.
So
that's
just
my
two
cents.
C
It
makes
sense
to
me
to
have
them
release
blocking,
but
I
feel
like.
There
was
some
sort
of
inversion
where,
like
the
the
sequencing
or
something
we,
we
had
issues
with
that.
But
I
don't
recall
if
that
was
just
a
historical
situation,
but
maybe
we
can
specifically
try
and
invite
Aaron
and
Nikki
to
the
next
meeting
in
two
weeks
to
hash
out
specifics.
A
We
just
do
a
issue
for
this,
proposing
it
I
think
we
can
do
that.
Yeah
I
have
there's
an
there's,
an
action
item
on
the.
If
you
scroll
to
the
bottom
of
the
notes,
the
github
issue
for
a
is
for,
let's
say,
retro
a
is
right
and
that
one
includes
some
of
the
the
eyes
from
115
as
well
as
116
I
think
there
might
be
a
few
more
to
capture
that
I
have
to
add
in,
but
that
is
most
of
the
list,
so
I
think
it's
near
the
top
of
it.
A
Alright,
alright!
So
next
one
is
publishing
instructions
on
how
to
consume
alpha
beta
RC.
Today
it
will
get
better
once
we
have
release
channels
for
daily
testing
and
prod
builds
indubitably,
but
in
the
meantime
we
could
write
up
a
tldr
right.
So,
yes,
totally
agreed
I
had
I,
don't
know
a
few
months
ago
started
a
super
official
Twitter
poll
about
whether
or
not
people
are
consuming
alpha
beta
or
our
seas
of
kubernetes
and
out
of
the
hundred
something
people
I.
Think
that
responded.
A
A
Essentially
what
we
want
to
make
sure
that
we
do
is
when
we
publish
artifacts
they
publish
to
places
where
they're
very
clear
that
the
artifacts
are
either
a
Knightly
artifact
or
a
testing
artifact
or
actual
release
artifact.
So
the
idea
would
be
to
have
multiple
channels,
and
we
also
need
to
determine
what
we
mean
by
artifact
in
this
case
right
is
it?
Is
it
a
Deb
or
is
it
a
Deb?
Are
rpm?
Are
we
just
talking
terrible
like
we
should
be?
D
A
Come
on
computer,
all
right,
cool
and
then
CI
is
here
and
essentially
those
are
those
are.
You
know
those
are
a
pretty-pretty
web
browser
on
top
of
GCS
buckets,
those
GCS
buckets
hold
all
of
the
artifacts.
That's
the
that
our
CI
jobs
kick
out
are
that
are
a
part
of
our
release
process,
our
staging
and
release
process.
So
if
no
one
has
seen
them
before
it
contains,
it
contains
the
release
for
the
constancy
artifacts
for
the
server
components
that
the
node
components
of
the
test
components
as
well
as
at
least
today
hypercube.
B
A
Free
releases,
so
this
stock,
you
can
check
out
too
so,
if
you're,
using
cube
ATM
today
and
you're
interested
in
testing
with
pre-releases,
it
gives
some
instructions
there
overall
I
think
that's
the
documentation
that
we
may
have
on
the
subject
is
kind
of
not
as
easily
visible
as
it
could
be.
So
we
can.
We,
we
do
have
an
action
item,
this
cycle
to
clean
some
of
that
stuff
up.
But
if
you
have
explicit
use
cases,
we'd
love
to
hear
them
so
I'll
stop
talking.
B
E
A
Marky
yeah
for
sure,
let's
I
think
it
would
be
super
useful
to
understand
what
the
future
design
would
look
like,
so
that
we
can
figure
out
how
best
to
integrate.
But
yeah
we
can,
if
you
and
Carlos,
want
to
sync
up
and
I'm
happy
to
stay
out
of
the
loop
as
you
all
work
on
that,
but
feel
free
to
ask
me
any
questions.
Cool.
B
A
A
Collaboration
going
on
all
right,
so
any
questions
comments
concerns
on
that
one
before
we
move
on
all
right.
Okay,
next
one
is
definitions
of
priority
right,
so
this
one
came
up
as
it
is
I
think
everyone
has
somewhat
of
a
different
definition
of
what
priority
is.
So
we
have
a
few
ones
that
we
use
pretty
frequently
in
kubernetes
and
those
are
priority
important
long-term
priority
important
soon
and
priority
critical,
urgent
right,
I'm
going
to
caught
hold
on.
A
So
the
yeah,
so
one
of
the
so
I
think
I
think
having
a
singular
definition
of
what
each
of
these
mean
will
be
useful
going
for
it.
I
think.
The
reason
this
came
up
is
that
the
the
bug
triage
team
has
difficulties
towards
the
end
of
the
cycle,
trying
to
determine
what
is
something
that
is
truly
high-priority
right
or
the
I
think
the
release
team
in
general
right.
What
is
what
is
what
is
truly
higher
priority?
So
the
if
you
take
a
look
at
the
test
in
fro
labels.
A
Are
you
mouse
over
any
one
of
these
labels?
It
will
give
you
a
definition
right
and
I
like
okay,
so
I,
like
looking
at
the
the
critical
urgent
one
right,
because
it
says
says
highest,
priority
must
be
actively
worked
on
as
someone's
top
priority
right
now
and
then
the
comment
says
stuff
is
burning.
If
it's
not
being
actively
worked
on,
someone
is
expected
to
drop
what
they're
doing
immediately
to
work
on
it.
Team
leaders
are
responsible
for
making
sure
that
all
issues
labeled
with
this
priority
in
their
area
are
actively
worked
on.
A
Examples
include
user,
visible,
bugs
and
core
features.
Broken
builds
or
tests
and
critical
security
issues
right,
so
that
is,
that
is
an
expanded
definition
that
probably
deserves
to
be
part
of
the
mouse-over
definition
right.
We
can
figure
out
how
to
kind
of
compact
that,
but
I
tend
to
agree
with
stuff
is
burning.
This
is
like
this
is
so
broken.
A
A
B
Well,
so,
basically
we
can
you
hear
me
yep,
okay,
so
critical,
urgent
one
is
okay,
but
important
clock
tell
me
what
its
own
ones
might
be
like
it
is
what
I?
What
I
think
personally
is
that
it
might
be
hard
some
time
to
decide
between
long
term
its
own.
How
is
someone
going
to
no
visit
to
really
need
it
or
not,
because
is
it
needed
right
now
or
not
and
I?
B
A
A
A
Right
so
say,
I
have
a
priority,
important
long-term
issue,
and
it's
not
an
umbrella
right.
How
do
I
handle
that?
How
do
I
move
it
through
the
release
cycle?
Is
it
the
job
of
bug
triage
to
even
watch
that
I?
Don't
I
don't
think
that
that's
true
right
a
should
be
responsible
for
determining
the
priority
of
the
of
the
issues
or
PR
that
they
have
in
place.
A
I.
Don't
think
that
a
you
know,
something
that
is
marked
as
important.
Long-Term
is
less
important
than
something
that
is
maybe
say
important
soon
right,
it
still
needs
to
land
and
it
may
need
to
land
it
may
need
to
land
in
the
same
time
as
an
important
tune
right
just
for
it
to
be
just
for
that
long-term
status
to
hold
right,
I
need
to
land
it
over
five
cycles,
but
I
I
won't
make
I
won't
make
good
progress
unless
I,
don't
unless
I
get
this
bit
in
for
this
cycle
right.
A
So
maybe
that
needs
to
be
broken
up
and
said
so
an
issue
or
like
I.
You
know
I
think
we
should
not
have
to
make
that
determination
for
SIG's
right.
I
would
also
see
a
problem
in
bumping
the
priority
of
something
for
the
stake
of
making
sure
that
it
gets
into
release
right,
I,
don't
think
that's
the
way
we
should
be
going
about
doing
suffer
that
same
should
be
going
about
doing
stuff.
I
doubt
there
are
many
cases
of
that,
but
I
can't
imagine
that
there
are
probably
a
few.
A
Say
very
rarely
yeah
so
depending
on
I
think,
depending
on
what
it
is
and
depending
on
who
you
are
like.
As
a
sig
chair,
I,
try
to
go
in
and
update
priorities
when
I
can,
when
I
touch
an
issue
or
if
I'm
doing
grooming
of
some
sort.
I
can't
say
that
it's
it's
going
to
be
common
for
every
contributor,
though
it
depends
on
how
much
you
how
much
you're
invested
in
the
entire
ecosystem
of
all
the
issues.
F
A
Do
we
determine
that
something
that
is
so
it
when
it
comes
down
to
it
and
they're
scanning,
through
the
backlog
of
like
things,
are
critical,
urgent
or
things
are
important
long-term?
How
do
we
understand
like
the
importance
at
that
point
in
time,
for
that
issue
right
yeah?
Is
it
something
that
we
need
to
go
back
and
chase
the
sig
and
say
like
hey?
Are
you
actually
trying
to
land
this,
or
is
it
something
we
can
bump
right.
C
C
But
the
gap
right
now
that
we're
perceiving
is
in
how
people
use
them.
So,
for
example,
not
just
on
the
current
release
team
deciding
what
goes
in
or
if
something
should
be
deferred
from
the
current
release
on
patch
releases.
Also
we're
supposed
to
only
be
bringing
in
things
that
are
critical
agent,
but
the
vast
majority
of
what
gets
merged
for
the
patch
releases
is
labeled
important
long
term
and
almost
I'd
have
to
go
and
pull
the
numbers
specifically.
C
But
I
feel
like
the
majority
of
things
that
go
by
say
important
long
term,
and
there
are
things
where
there's
like
a
nullpointerexception
or
a
panic
or
like
very
clearly
obviously
serious
bugs
and
are
there
no
brainers
to
merge,
they
should
have
been
labeled
critical
urgent,
but
for
whatever
reasons
they
they
weren't
viewed
that
way.
So
if
we,
if
we,
if
we
aren't
using
these
labels
in
with
any
sort
of
consistency
today,
then
that
means
they
don't
have
like
that.
The
next
level
simplification
would
be
to
just
remove
them
entirely.
Yeah
and
they're.
C
B
B
G
C
I
think
in
a
lot
of
organizations,
you
end
up
with
to
a
two
level:
priority
scheme,
the
urgency
of
the
thing
and
the
severity
of
the
fan,
so
we
we
have
them
conflated
and
in
a
single
set,
so
things
that
are
clearly
major
consequential
types
of
things,
but
have
been
around
for
a
long
time.
In
our
corner
case
types
of
major
failures,
you
know
if
you're
cubelet
by
is
that's
like
a
that's.
A
pretty
big
deal
is.
G
E
G
Oh
I,
don't
know
what
this
it's
severe
or,
if
you're
using
this
alpha
feature,
it's
not
severe
in
like
production,
supported
default
configuration
so
I
will
also
say,
but
you
know
I
know
you're
not
saying
we
should
drop
all
the
labels
Tim,
but
like
these
also
are
useful
in
sort
of
local
stock
ranked
contexts.
So
if
a
particular
cig
is
looking
at
prioritizing
their
work
for
a
release-
and
they
say
what
are
all
our
open
issues-
that
our
labels
are
cig,
let's
go
broadly
and
kind
of
make
sure
the
priority
buckets.
G
Look
right
like
here
are
the
two
critical
issues
that
we're
working
on
right
now
and
here's
the
20
things
that
we
really
think
should
be
fixed.
This
release
and
here's
the
things
that
we
wouldn't
want
to
age
out
like
these
are
important
long-term.
We
want
to
keep
them
open,
like
that's
how
I
use
them
personally,
like
with
a
bi
machinery
and
say,
go
off,
and
so
it
might
be
that
we're
trying
to
serve
too
many
audiences
with
not
enough
signal
for
these
labels
like
if
we're
wanting
them
to
mean
identical
things.
G
Me
is
the
biggest
signal
like
if
the
Sega
is
keeping
issues
in
the
milestone,
like
that's
a
signal
that
they
think
that
this
is
release
blocking
for
the
milestone
I
and
like
the
the
criticality
or
priority
that
can
like
if
there
are
things
critical,
marked
critical
urgent
in
the
milestone
like
we
as
the
SIG's
working
on
it
and
the
release
team
monitoring.
It
like
there
should
be
more
frequent
feedback
and
updates
on
those
things,
and
we
should
think
really
hard
before
we
kick
one
of
those
out
of
the
milestone
yeah.
A
Cool
yeah,
no
I,
take
that
so
George
T
to
your
point,
I,
don't
yeah
I,
don't
find
the
I,
don't
find
the
lifecycle
active
label
to
be
useful
at
all.
Personally,
it's
it's
one
of
those
things
that
if,
if
it
becomes
inactive-
and
it
has
that
label
on
it
like
what
what
does
it
mean
so
yeah,
that's
just
my
two
cents
I,
but
yes,
some
SIG's
do
use
lifecycle,
actives
and
to
denote
that
someone
is
working
on
the
issue.
A
My
you
know,
the
the
signal
is
for
me
is
it's
someone
assigned
to
the
issue
that
if
they
are
assigned
to
the
issue,
then
they
or
have
intent
to
work
on
it
if
they're
not
working
on
it
already,
I,
don't
think
that
it
provides
a
good,
a
good
signal
of
like
in
progress
right,
because
these
things
get
stale
across
time.
So.
A
A
My
you
know.
My
concern
at
the
end
of
the
day
is
not
so
much
about
the
priority
stuff,
but
about
the
priority
should
not
concern
us
too
much
as
much
as
it
concerns
a
another
sake.
Milestone
anxia,
as
Jordan
would
was
mentioning
so
I
think
that
you
know.
Overall,
we
need
more
of
a
solution
around
what
we
do
towards
the
end
of
the
cycle.
Remove
are
clear
on
milestones
and
I
think
that
this
is
also
a
question
that
came
up
through
during
the
retro.
It
might
be
listed
in
our
notes
today.
Actually.
C
Quarter
to
lettuces
question
on
what
are
we
trying
to
solve?
I
think
we
we
actually
got
into.
Should
we
change
things
before?
What
are
we
trying
to
solve,
and
the
first
thing
that
we're
trying
to
solve
out
of
the
retro
is
hey.
These
are
actually
defined
inconsistently
in
a
lot
of
different
places.
Could
we
just
tighten
up
the
documentation
and
what
that
would
solve?
Maybe
is
a
fairly
weak
thing,
but
it
would
solve
the
documentation
being
inconsistent.
C
A
Yeah
so
I
think,
first
and
foremost,
if
we
get
we
have,
we
should
look
at
the
label,
definitions
and
decide
if
we
agree
with
those
right
overall,
I
ones.
That
I
saw
right
so
I
think
that's
the
first
place
because
those
allow
those
allow
mouse
overs
for
each
of
the
labels,
so
fixing
that
first
and
then
tracking
down
everywhere
that
we
have
documented
priority,
whether
it
be
in
handbooks
whether
it
be
in
release
guides.
So
is
anyone
interested
in
taking
that
work
on.
A
I
would
say
the
mouse
overs
are
a
little
bit
of
higher
priority
to
me,
because
I
think
that's
that
will
pop
up
for
I
mean
that's,
that's
something!
That's
you
know.
Anyone
who
may
not
have
read
our
documentation
can
can
mouse
over
right
and
then
figuring
out
all
the
places
that
the
documentation
that
mentions
priority
is,
and
you
can
use
you
can
use
hound
for
that
so
and
if
you
haven't
seen
hound
Thank
You
Tim's
by
the
way.
F
F
A
F
F
Triage
but
right
like
can't,
we
have
something
like
that
to
address
things
like
this,
just
as
she
has
too
many
labels,
or
you
know,
I,
don't
know
various
other
like
janitorial
things,
because
I
mean
fate
of
on
or
sorry
triage,
but
I
guess,
while
it
is
annoying
I
mean
it's
I
found
it
very
useful
and
telling
me
things
you
know
like.
Oh,
this
is
stale
or
you
know
do
something
about
it.
So.
A
F
F
Critical
urgent-
and
let's
say
it,
has
no
be
assigned.
Maybe
that's
a
problem
like
do.
We
know
for
a
fact
that
all
Creek
origin,
you
know
labels,
have
somebody
assigned
to
it
with
like
some
sort
of
status.
You
know
that
it's
like
fresh,
like
people,
are
actually
updating
these
things
and
there's
like
a
window
and
like
we
actually
know
what's
going
on,
instead
of
just
somebody
oh
like
maybe
somebody
is
assigned
but
they're
not
working
on
it,
because
a
lower
priority
ticket
is
actually
being
worked
on
instead
of
that
one
yeah.
So.
A
F
A
F
A
F
F
Example,
this
issue
has
been
marked
priority
super
super
urgent
for
over
a
month
should
we,
you
know,
reduce
the
priority
level,
because
it's
not
whatever
you
know
just
to
align
the
I.
Guess
expectations
better
or
something.
If
something
is
just
you
know
not
being
looked
at
or
there's
no
say
it's
in
a
row.
Yeah.
A
That's
that,
like
that's
kind
of
like
my,
only
concern
there
so
yeah
so
yeah
Bob,
is
saying
just
comment
on
the
bottle
says
some
folk
have
already
chimed
in
and
said
that
they
have
rules
that
pretty
much
dump
lot
responses
to
the
trash,
because
how
much
spam
they
get
all
right.
So
if
you
take,
if
you
take
for
one
really
great
example,
is
the
you
know,
are
the
bot
responses
on
test
failures
right.
A
There
are
some
people
who
send
those
straight
to
the
trash
right
and
as
a
results
that
issue
might
be
getting
lost,
even
though
it's
actively
being
worked
on
right.
So
that's
you
know,
that's
one
of
the
concerns,
because
there's
so
much
bot
spam
around
test
failures.
Some
people
don't
even
look
at
them
right.
A
So
this
is
something
to
be
aware
of
and
I
like
that.
That's
that's
part
of
my
fear.
In
introducing
introducing
more
seat,
Jordan
immediately
filters
all
about
responses.
So
that's
that's
one
of
my
concerns
in
introducing
more
bot
responses
to
to
the
workflow
today.
I
think
that
if
you,
you
know,
if
you
are
a
cig
and
you're
doing
review
of
your
issues,
you
should
be
watching
the
issues
that
come
up
and
the
ones
that
are
priority
critical
urgent.
G
Just
a
level
set
like
in
the
whole
repo
in
the
kubernetes
kubernetes
repo.
There
are
10
issues
marked
critical
urgent
today
and
that
there's
spread
across
things.
So
each
cig
might
have
one
two
three
which,
like
that
doesn't
seem
out
of
control
to
me.
So
I
would
hesitate
to
put
like
tons
of
process
and
bot
nagging
and
like
ten
issues
as
a
number
that
we
can
actually
like.
Go,
look
at
and
ask
questions
of
humans,
and
it's
not
that
big
a
deal.
A
So
alright,
so
I
think
we
need
to
do
more
noodling
on
it,
I'm
not
sure
that
we
have
a
thing
that
we
need
to
do
outside,
of
making
sure
that
documentation
is
clear
about
what
we
mean
by
priority
from
there.
I'm,
not
I'm,
not
saying
that
maybe
BOTS
aren't
the
answer
in
some
way,
shape
or
form
for
something
later
I.
Just
don't
know
what
that
thing
is
right
now,
I
I
think.
G
The
place
I
see
the
most
confusion
is
actually
around
cherry-picks,
because
we've
said
things
like
only
critical
urgent
issues
should
be
back
ported,
and
so
it
might
be
helpful
to
expand
that
no
Tim
just
went
and
updated
like
the
cherry-pick
guidelines.
It
might
be
helpful
to
give
specific
examples
like
if
this
is
a
crashing
bug
and
a
default
configuration
it's
okay
to
mark
this
critical
urgent,
like
even
if
it's
rare,
even
if
it
escaped
to
releases.
A
C
At
this
point,
here's
here's
what
the
review
typically
looks
like
we,
we
look
and
see
what
labels
come
in.
It's
probably
50/50,
whether
it
even
is
labelled,
cut
with
a
kind
and
then
I'd
say
it's
probably
5050
whether
it
has
a
priority
as
well
and
of
the
those
that
do
have
priority
generally
they're
important
long
term.
So
it's
like
there's
low
signal
there,
but
when
it
comes
in
with
a
kind
bug
kind,
failing
test
priority,
critical
urgent,
like
those
are
some
initial
indicators,
but
then
we
go
off
and
we
we
look
at
the
parent
PR.
C
G
A
G
A
So
so
all
my
all
I'm
implying
there
is
that
that's
a
process
that
you're
going
to
go
through
anyway
right
you're,
going
to
determine
the
criticality
you're
going
to
determine
some
of
the
impact
and
all
that
stuff
right
as
the
patch
release
team
right.
So
so,
yes,
while
it
gives
you
initial
signal
like
it
is,
is
it
you
is
it
super
useful.
C
Based
on
based
on
what
you've,
what
you
found,
no
I,
so
what
I
was
gonna
summarize
with
the
final
words
I
didn't
quite
say
it
was.
We
basically
don't
use
it
it's
if
it's
there
and
it's
marked
critical,
urgent
and
the
rest
of
the
evidence
supports
that
it
tells
it's
part
of
the
story,
but
on
its
own,
it's
a
very
low
quality
signal.
Okay,.
A
Okay,
all
right
all
right,
I
think
we
have
all
right
we're
down
to
discussing
stability
for
exhibits.
Can
we
do
it
in
17
minutes?
Let's
see
alright.
So
there
has
been.
There
have
been
multiple
requests
across
multiple
years
in
multiple
venues,
whether
it
be
Twitter
issues,
face-to-face
calls
at
cube,
con
about
doing
stability,
doing
stability
releases
right
and
Jordan
has
put
some
really
good
feedback
on
that
one.
So
far,
my
initial
push
back.
A
There
was
a
a
Twitter
thread
that
started
and
my
initial
push
back
there
was
that
deciding
that
117
would
be
a
stability
release,
that
it
does
not
give
anyone
enough
time
to
actually
do
planning
any
meaningful
planning
of
what
stability
means
to
them.
For
you
know,
for
sig
related
work
or
for
company
related
work
for
companies
who
have
product
teams
that
focus
on
kubernetes
related
things.
They
may
have
set
their
roadmap
already
and
we
can't
ask
them
it's
not
fair
to
ask
them
to
try
to
pivot
that
within
the
span
of
a
few
weeks
right.
A
So
this
is
something
that
I
think
that
we
can
focus
on.
But
it's
something
that
I
want
to
make
sure
is
well
planned
because
I
end
of
it
I,
don't
want
to
say
our
stability.
What
release
was
a
failure,
because,
because
of
planning,
that
seems
a
that
seems
a
silly
reason
for
it
to
be
a
failure.
So
you
know
additional
notes
on
that
is
that
we
should
try
like
I
I
kind
of
don't
like
the
idea
of
a
stability
release,
because
we
should
always
be
stable
right.
A
The
the
idea,
like
the
stability
release,
implies
that,
like
the
rest
of
our
releases
are
not
as
stable
and
and
I,
don't
want
that
to
ever
be
true.
The
one
of
the
big
problems
that
we
have
here
is
that
we
need
to
codify
what
it
means
to
be
stable
right
and
we
don't
have
the.
We
have
some
of
the
signals
that
we
need
to
do
that
today,
but
we
need
to
coalesce
them
into
something
usable
and
actionable,
and
Jordan
mentions
a
bunch
of
stuff
and
I.
G
Are
they
flaky
and,
if
so
like?
Where
are
the
issues
and
pull
requests
that
are
fixing
those
flakes
like
these
are
I.
Think
I
mentioned
the
extensibility
work
that
we
did
over
115
and
116,
and
that
was
a
big
part
of
what
we
did
was
burning
down
all
the
flakes
and
in
the
process
fixed
a
bunch
of
real
bugs
and
so
that,
like
it's,
it's
I
think
it's
a
cop-out
to
say
not
a
cop-out,
I
think
it's
easy
to
say.
We
want
to
always
be
priority.
G
Prioritizing
stability
and
then
never
give
in
to
specifics
and
from
my
experience
like
the
best
way
to
make
things
stable
is
to
make
sure
there
are
tests
and
make
sure
they're
green
and
make
sure
they're
green
all
the
time
and
like
that
flushes
out
a
lot
of
issues,
and
so
I
would
like
to
see
like
when
we're
getting
close
to,
freeze
or
feature
freeze
for
117
like
push
on
the
test
plans.
For
these
things,
like
be
specific,
what
you
give
me
a
link
to
the
test
grid
that
filters
down
to
the
tests
for
this
feature.
G
So
if
I'm
looking
at
a
cap,
I
can
click
and
see
like
how
many
tests
are
there?
How
green
are
they
and
forcing
that
level
of
specificity
around
tests
and
test
health
I
think
will
make
it
a
lot
easier
for
the
release
team?
It's
like
look
at
a
cap
and
say
alright.
Are
we
in
good
shape
for
this?
Let
me
here
are
three
tests
grid
links,
nope,
totally
red
and
flaky
like
this
is
bad
and
without
kind
of
the
binary
feature
or
fix
mentality.
D
G
And
some
of
that
is
like
until
you
write
the
code
and
know
what
package
it
lives
in
and
what
the
tests
are
gonna
be
called
like
you
don't
know
exactly
what
the
filter
will
be,
but
at
the
same
time
like
you,
can
pick
a
tag
name
for
your
e
two
E's
and,
like
you
know,
reconstruct
a
link.
A
lot
of
it
is
examples
like
the
cap.
G
Template
doesn't
have
examples
of
like
you
should
include
a
test
grid
link
here
with
the
tag
for
your
EEE
tests
and
then
add
that
tag
to
your
ete
tests,
like
even
something
as
simple
as
that
would
kind
of
point
people
in
the
right
direction
to
go
like
oh
right,
I
should
have
a
place.
I
can
look
for
healthy
tests
and
kind
of
getting
people
going
in
that
in
that
direction.
G
D
G
C
A
A
D
G
D
G
G
And
I
I
think,
like
the
quality
thing,
I,
don't
think
anyone
would
disagree
that
we
want
it.
A
half
of
it
is
getting
distracted
with
a
million
things
going
on
and
like
you,
you
do
the
implementation
and
get
it
reviewed
and
then
I'll
get
to
that
like
next
week
and
the
next
week.
Someone
else
is
on
fire
and
so
like
just
having
the
more
things
we
can
put
in
front
of
people
to
remind
them.
Oh
yeah,.
H
G
H
Might
once
I'm
in
just
maybe
more
from
what
I
perceive
is
an
emotional
need,
then
just
as
much
a
technical
need.
There
seems
to
be
just
the
idea
that
hey
we
have
a
lot
of
tech
out
that
are
there.
We
don't
have
enough
time
to
address
bugs,
or
things
feel
unstable
and
I.
Think
that's.
Why
there's
this
notion
of
there
needs
to
be
a
point
where
there's
like
at
least
at
check
it
like
a
periodic,
predictable
cadence,
where
teams
do
that
sit
down,
review,
they're,
able
to
see
okay.
How
healthy
am
I?
H
A
So
this
is
something
I
mentioned
that
like
it
would
be
good
to
have
cig
planning
events.
Every
cig
go
and
do
this
right
around
code.
Freeze
time
right.
Supposedly,
your
code
is
frozen
right.
So
that's
a
good
time
to
go
in
introspect
on
the
work
that
you're
doing
the
work
that
you
plan
to
be
doing
for
the
next
cycle,
as
well
as
accessibility
of
the
features
that
you
have
land
for
for
the
current
cycle,
but
I'm
not
sure
how
many
people
actually
do
planning
events
to.
G
C
And
that's
part
of
why
I
opened
the
initial
the
the
issue
initially,
it
was
like
I
know
that
this
is
a
change
in
pattern.
Let's
discuss
it
to
see
like.
Is
it
conceivable
since
it's
a
pattern
that
exists
that
everybody
would
be
willing
to
do
one
altogether
or
what
the
complexity
of
that
would
be
like
what
it
looks
like
and
there's,
obviously,
a
lot
of
there
conflicting
opinions
on
it.
C
The
other,
the
other
thing
I,
think
that
we
don't
really
discuss
is
that
it's
kind
of
become
a
pattern
in
our
fourth
quarter
of
the
calendar
that
we
have
a
lot
of
conflicts
on
the
calendar.
So
we
we
have
a
shorter
cycle
and
we
try
to
at
least
message
that
SIG's
should
try
to
reduce
the
amount
of
work
they're,
putting
on
new
features
and
by
virtue
of
that
shift,
a
little
focused
towards
stability,
just
because
there's
less
time
to
do
major
things
and
and
get
something
actually
ready
for
release
with
quality
and
a
shortened
cycle.
C
Yeah,
that
could
be
any
time,
but
if
we're
already
doing
a
two-month
thing
that
we
we
signal
from
the
early
scene,
we'd
like
to
be
a
stability,
a
more
stability
focused
release
and
feature
focused
release.
It
feels
like
an
incremental
change
to
say.
Well
what
would
it
look
like
to
do
this?
This
other
thing
that
we
see
other
projects
doing
these
shorter,
stable
releases
and
feature
releases
alternating
in
some
way,
yeah.
C
C
Would
we
need
to
have
alignment
from
other
things?
If
we
think
of,
or
would
this
only
be
KK
focused
and
what
the
end
user
experience
still
be
lacking
if
the
set
of
things
that
form
a
running
cluster,
if
you
think
of
that
as
a
distribution
that,
at
a
distribution
level,
it
wasn't
the
stability
release,
do
that
does
it
matter,
even
if,
if
KK
did
something
like
that,
would
it
be
discernible
to
a
end
user?
The.
C
I,
don't
think
I
could
read
it
yeah
on
the
flip
side,
if
if
we
were
managing
the
dependencies
or
third-party
integrations
more
tightly,
and
they
were
all
versioning
themselves,
whatever
their
way
of
doing,
it
was
if
we
had
some
way
of
assessing
the
quality,
and
maybe
we
don't
pick
their
latest
release
it,
because
it's
just
come
out
in
his
bleeding
edge.
But
we
we
go
one
prior
or
things
like
that
is.
That
is
a
pattern
in
existing
distributions.
C
They
pick
and
choose
and
curate
what
they
bring
in
to
their
next
major
release
integration,
but
that's
something
that
that's
a
pretty
major
level
of
sophistication
from
a
release:
integration
and
documentation
testing
compared
to
what
we
do
today,
making
that's
subjective
analysis
on
all
of
those
things.
As.
C
G
C
G
I,
what
I
want
to
make
sure
we
do
is
that
we
actually
raise
the
bar
and
don't
just
sort
of
McCulloch
people,
my
favorite
phrases,
stability,
theater,
where
we
like
declare.
This
is
the
stability
release
and
we
change
our
practices
for
release,
but
maybe
don't
actually
advance
the
bar
as
much
as
you
think,
and
then
we
go
back
next
release
and
kind
of
just
resume
future
future
future
feature
no
tests
or
flaky
tests.
Yeah.
A
B
A
What's
the
theme,
and
and
and
quite
frequently
we
go
it's
stability.
Kubernetes
is
like
it's,
it's
it's
stable
and
it's
boring
now
and
and
like
I've
said
that
enough
times
that,
like
I,
couldn't
count
at
this
point,
but
you
know
it's
it,
it
should
be
consistently
true.
It
should
be
something
that
we
we
strive
to
achieve
for
every
release
and
have
a
framework
in
place
to
do
that.
I
know
there.
A
There
were
some
mention
about
like
error
budgets
for
SIG's,
and
things
like
I
was
like
I,
don't
know
how
far
I
want
to
go
into
that
I.
Don't
think
that
it's
needed
it
would
be
nice
to
introspect
on,
but
I'm,
not
sure
that
it
should
be
a
requirement,
but
yeah
we
are.
We
are
one
minute
to
the
close
of
the
meeting.
I
feel
like
we
have
more
to
talk
about,
but
we
should
figure
out
a
structured
way
of
doing
this
like
what
is
the
next
step?
What
is
the
first
next
step
right
there?
A
There
are
quite
a
few
things
that
we
need
to
do
to
get
this
done
or
to
provide
a
framework
for
making
this
more
successful.
So
what
do
those
look
like?
So
we
should.
We
should
chat
again
about
this
sounds
good,
alright!
Everyone
thank
you
for
your
time,
always
fun
chatting
with
you.
All
I
will
catch
you
in
two
weeks
on
the
next
cig
release
meeting.
Take
it
easy.