►
From YouTube: Kubernetes Weekly SIG Release Meeting for 20200421
Description
Kubernetes Weekly SIG Release Meeting for 20200421
A
Hello,
hello,
everyone
today
is
April
21st.
This
is
a
sick
release,
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and,
in
general,
just
be
awesome
people.
So
today
we
are
going
to
talk
about
one
email.
A
We
only
have
one
topic
on
the
agenda
and
that's
to
discuss
the
changes
to
our
the
potential
changes
to
the
release
timeline.
So
last
night
we
made
an
announcement
and
it's
kind
of
born
from
a
lot
of
the
different
conversations
that
we've
been
having
over
the
past
few
weeks
as
well
as
some
or
several
people
reaching
out
to
discuss.
So
we
wanted
to
walk
through
a
few
of
those
changes,
as
well
as
get
your
feedback
on
things
that
we
could
change
within
that
timeline.
A
A
B
A
So
so
this
cycle,
our
this
year,
is
kind
of
an
impressive
end
of
time
for
everyone,
and
we
wanted
to
recognize
that
and
we
wanted
to
try
to
make
the
release
more
accommodating
for
for
everyone
and
and
little
little
tweaks,
two
little
tweaks
to
the
to
the
processes
and
procedures
that
we
have
in
place
today.
So
there
is
some
extension
of
certain
aspects
of
the
release.
B
Maybe
right
like
so
like
my
internal
mental
map
would
be.
Why
could
we
not
just
do
119
when
we
would
have
done
120
and
just
leave
this
space
as
a?
If
you
want
to
work
on
something
you
can,
but
if
you're,
in
a
situation
where
you're
incapable
of
working
on
it,
just
don't
worry
about
it,
you're
not
missing
anything,
and
if
you're,
a
downstream
consumer
of
our
releases,
doesn't
matter
no
big
deal.
You
don't
have
to
worry
about
119.
B
A
So
I
mean
I
think
it's
I
think
it's
hard
in
in
so
far
as
we,
we
don't
really
pump
the
brakes
at
the
end
of
a
release.
Right
so
like
there
has
been
consistent
content
being
pushed
to
master
since
1/18
went
out
right
all
content
that
is
on
the
table
for
for
119,
so
I
think
it's
hard.
We
were
kind
of
kicking
this
around
as
well
as
we
were
thinking
about
these
changes.
A
What
would
it
look
like
if
there
was
more
of
a
break
in
front
of
the
release
cycle
or
at
the
back
end
of
the
release
cycle
right
and
and
given
that
we,
you
know,
it's
a
suddenly
me
email,
we
had
discussed
what
would
it
look
like
to
push
this
release
back
a
little
bit
right,
at
least
at
least
till
the
end
of
April,
maybe
early
May,
and
you
you
kind
of
can't
because
it's
it's
on
master
is
on
all
the
time
right.
So
so
there
was
content
constantly
being
pushed
to
it.
A
So
I
think
that
you
know,
and-
and
it
had
been
my
hope
for
a
few
years
now-
actually
that
I
guess
it's
a
few
years
now
that
more
of
the
time
in
between
releases
would
be
spent
resting,
planning
doing
triage.
You
know
roadmap
planning,
all
that
good
stuff
and
it's
you
know,
as
well
as
formulating
the
release
team
itself
right,
that's
something
that
we
kind
of
do
during
the
cycle.
A
B
What
I
would
ask
is
no
matter
what
right
now,
when
you're
pushing
content
that
content
must
sort
of
be
compatible
with
what
you
could
ship
in
119
right.
So
you
can't
sort
of
break
something
that
like
isn't
deprecated
and
must
be
like
you
have
to
follow
all
the
standard
timelines
for
adding
things
and
removing
things
the
grenades
release
right
right.
So,
if
you
extend
119
that,
in
essence,
at
least
from
our
API
level
guarantees
a
set
of
changes
that
you
cannot
do
right,
what.
B
You,
you
cannot
add
a
brand
new
API.
That's
like
you
know,
brand
new
custom,
REST
API
call
it
beta
right.
It
has
to
go
through
alpha
to
beta
and
like,
like
you,
have
to
do
the
time
right
and
to
me
like
having
these
two
cycles
still
encourages
that
stain
mentality
right,
like
I,
must
always
put
something
into
their
release,
because
then
each
boundary
I
get
to
do
something
better.
A
And
that's
I
think
that's
a
general
ask
in
talking
with
the
release
team
last
yesterday,
as
well
as
kicking
her
ideas
around
Jordan.
That's
what
we
want.
We
want
people
to
slow
down,
so
I
think
that
one
of
the
things
that
we
need
help
with
is
to
kind
of
shift
that
message
to
all
sig
chairs
and
forsake
chairs,
to
kind
of
let
that
message
trickle
down
there.
Sig
like
try
to
slow
down
on
future
development,
try
to
work
on
stability
instead.
C
Know
I
can
comment
there.
Anything
most
point
is,
is
a
lot
of
our
policies
are
on
deprecation
and
everything
are
written
around
releases
and
by
having
a
release,
we
are
actually
saying
that
that
you
know
you
have
an
opportunity
to
deprecate
or
advance
something
from
alpha
to
beta,
whereas
if
we
didn't
have
a
release
that
wouldn't
be
that
opportunity,
so
it
automatically
is
it
it's
not
just
sending
a
signal
at
that
point,
it's
actually
putting
an
enforceable
policy
and
saying
you
can't
make
certain
kinds
of
changes.
C
So
it's
somewhat
stronger.
You
know
that
boundary,
like
my.
My
only
concern
mo
around
around
not
having
a
119
is
that,
even
if
there
are
plenty
of
changes
that
can
be
done,
that
don't
change
ap
is
that
are
at
at
risk
and
and
accumulating
more
changes
accumulates
more
more
risk
around
around
that
sort
of
thing.
So.
B
You
know
I
mean,
but
to
be
fair.
They're
like
I'm,
not
saying
turn
CI
operate
like
CI,
should
always
be
green
and
do
all
the
standard
stuff
right
like
if
our
CI
doesn't
catch
things
that
we
break,
then
we're
basically
saying
that
our
customers
will-
and
this
is
not
like
a
great
place
to
be
right
so
but
I
I
do
understand
that
have
a
longer
release.
We
will
push
like.
We
will
like
accidentally
put
more
stuff
in
it,
just
because
we
have
more
time.
B
Alright
and
I
am
cognizant
of
data
and
don't
necessarily
know
how
to
incentivize
humans
not
to
do
that.
I
I
just
know
I
can
incentivize
people
not
to
try
to
move
api's
and
boundaries
and
deprecations
great
like
like
I
know
like
say:
God
wants
you
like.
You
won
the
CSRA
API
right
because
we're
supposed
to
get
rid
of
our
baby
eyes
and
do
all
that
and
wanted
to
do
that
in
119.
D
Give
a
schedule
that
leaves
room
for
contributors,
which
is
what
this
was
trying
to
do
to
say,
like
people
have
already
made
119
plans.
So
if
we
can
allow
them
to
execute
those,
but
then
give
them
buffer
not
jumping
right
into
120
at
the
end
of
that
to
give
contributors
some
buffer
and
then
by
adding
that
buffer
before
120
kicks
off
that
the
intent
of
that
was
to
give
time
to
get
feedback
on
the
release.
Candidates
give
time
for
consumers
who
are
stretched
and
aren't
ready
to
pick
up
a
119
like
the
second.
D
D
B
D
I
when
we
were
talking
yesterday,
the
thing
that
was
coming
to
my
mind
was
the
urgent
must
read
before
upgrade.
You
know
as
part
of
deploying
this
release,
you
must
make
these
changes,
or
these
adjustments,
or
whatever
like
in
the
abstract
I,
would
like
that
section
of
the
release
notes
to
be
empty
for
this
next
release,
so
that,
like
additions,
you
know
like
the
CSR
API
going
to
be
one
ingress
going
to
be
one
like
these
are
these
are
additional
things,
but
they
don't
affect
existing
api's.
D
These
are
graduation
things
like
that,
but
if
you're
using
the
beta
api's,
you
don't
have
to
change
to
deploy
this.
This
version,
that's
sort
of
the
general
guidance
I,
would
ask
the
the
sig
leads
and
TLS
to
be
focused
on
like
if
you're
doing
stability
stuff,
if
you're
moving
features
along
their
roadmaps,
that
that
seems
good
and
reasonable.
If
you're
doing
something
that's
going
to
require
people
to
react,
that's
a
much
bigger
thing
to
ask
people
to
do
if
they're,
under
pressure
rolling
these
releases
out.
A
A
E
F
D
So
pretty
much
the
intent
of
the
proposal
that
Stephen
sent
out,
which
was
don't
freak
people
out
who
have
already
planned
work
over
like
a
normal
119
timeframe,
but
at
the
end
of
that,
like
give
them
give
them
a
buffer.
Give
us
time
to
run
soap.
Tests
give
us
time
to
get
extra
feedback
on
the
release.
Candidates
give
people
who
are
going
to
be
consuming
it
a
breath
and
so
like
it
was
trying
to
balance
easing
contributor
load
and
easing
consumer
load.
G
Of
happens,
though,
I
mean
an
enhancement.
Freeze
doesn't
mean
everything
has
always
been
automatically
approved
for
the
release.
The
enhancements
team
does
look
through
and
question
things
so
that
questioning
could
happen
a
little
more
critically
with
a
little
more
pushback,
a
little
more
going
out
and
talking
to
owners
and
the
associated
chairs,
reviewer
approvers
and
saying
this
one.
It's
making
my
blood
pressure
go
up
this
one's
making
Moe's
blood
pressure
go
up,
maybe
how
horrible
would
it
be
if
we
deferred
this
one
to
two
later
right
and.
G
Serious
conversations
like
that,
like
it's
one
thing
for
those
of
us
in
this
meeting
here,
which
is
like
very
much
a
tiny
subset
of
the
community,
and
especially
the
leadership
and
owners
who
would
be
making
the
choices
on
what
mergers,
if
we're
going
out
a
little
more
targeted
with
some
aggression
like
come
on
people.
Let's
chill
this
release.
E
G
E
My
feeling
is
what
I
want
to
do
is
I
want
to
like
stop
everybody
from
doing
work
and
write
tests
for
all
the
things
that
are
broken
and
the
CI
jobs
that
are
broken,
get
things
back,
reduce
of
flakiness.
You
know
pay
down
some
of
the
debt
that
we
have
accumulated.
That's
where
that's
what
I
want
to
do
to.
A
Be
clear
so
I
mean
so
here's
the
thing
like
we
can't
stop
feature
work
like
we
have
never
had
the
stick
to
to
do
to
stop
merges
all
together
right.
We
have.
We
have
merge
restrictions
in
place,
so
this
is
the
kind
of
the
idea
of
like
the
back
half
of
the
cycle.
When
code
freeze
turns
on
code,
freeze
will
stay
on
essentially
the
merge
restrictions
around
code
freeze,
so
you
will
need
to
apply
a
milestone
and
it'll
need
to
obviously
be
approved
by
the
people
who
can
approve
it.
A
So
this
is
like
really
and
that'll
that'll
stay
on
until
post
release
all
right.
So
the
idea
is
that,
like
please
only
do
119
right
now
until
119
is
out
of
the
door,
then
start
on
120,
which
gives
you
some
opportunity
to
do
some
prep
work
in
the
meantime
right,
so
whether
it's
enhancements,
whether
it's
doing
you
know
doing
bug
triage.
Maybe
it's
writing
a
road
map.
A
Maybe
it's
I,
don't
I,
don't
know
right,
but
yeah,
but
we
felt
that
you
know
this
is
this
is
the
kind
of
splitting
the
difference
that
Jordan
was
talking
about?
We
felt
it
was.
It
was
weird
and
kind
of
disingenuous
to
try
to
move
timelines
that
had
already
existed
or
timelines
that
were
closed.
That
had
already
existed
so
within
Hanson's
freeze.
We
did
move
that
out
a
week,
but
we
tried
not
to
shift
any
of
the
timelines
in
the
front
half
of
the
cycle
where
more
of
the
changes
are
happening.
A
If
the
the
message
is,
try
not
to
get
it
into
119,
unless
it
absolutely
needs
to
be
in
119,
that's
a
message
that
every
approver
needs
to
carry
right,
because,
if
they're
preventing
the
work
from
getting
in,
then
then
that's
kind
of
the
enforcement.
It's
unfortunately,
it's
a
human
enforcement
as
opposed
to
a
mechanical
one,
but
it
is
there
right
or
it
is
there,
but
but
yeah.
Let's,
let's
go
through.
Let's
go
through
the
email.
D
The
category
I
was
thinking
of
was
the
action
required
bill.
Explodes
I
mean
we,
we
do
have
a
label
for
that
I.
Don't
it's
probably
applied
inconsistently,
but
if
we
discuss
with
the
cig,
leads
and
say
like
to
make
119
as
consumable
as
possible
on
whatever
timeframe
we
end
up
releasing
it,
we
would
like
to
avoid
having
action
required
release.
D
Notes
like
we
would
like
to
make
this
a
consumable
release
that
doesn't
require
reaction
by
by
people
who
are
consuming
it,
that
that
is
a
thing
that
we
could
query
on
and
and
say
you
know
what,
if
you've
got
an
action
required,
PR
like
we,
we
want
to
make
sure
this
should
go
into
119.
It
shouldn't
be
automatic
for
something
I,
don't
know
just
idea.
My.
E
So
there
are
two
thing:
how
many
things
let
let's
figure
out?
One
thing
is
reduce
the
load
on
contributors,
then
reduce
the
load
on
reviews
and
approvers
and
reduce
the
load
on
people
who
will
be
downloading
and
using
other
releases
are
those
the
three
sets
of
people
that
we
are
trying
to
address
here.
Yeah
I
think.
A
You
know
outside
of
the
release,
eventually
right.
If
someone
is
waiting
to
upgrade
and-
and
you
know,
they're
they're
forecasting
that
119
is
going
to
come
out
in
three
months,
then
there's
some
expectation
that
we're
going
to
deliver
it
around
that
time
right,
but
but
yeah
I
think
it's
I
think
it's
hard
to
catch
all
of
this
stuff
in
a
bucket.
So
right,
for
example,.
E
Right
Kellogg
we
to
get
that
going.
Then
people
have
to
make
code
changes.
People
who
are
consuming,
as
as
a
library
will
have
will
have
to
make
code
changes
right.
That's
one
aspect,
the
other
one
is
people
who
deploy
our
code
right.
So
this
at
least
two
categories
of
people,
they're
people
who
consume
our
code
as
well
as
people
who
deploy
our
code
in.
C
Fact,
if
I
could
say
that
was
one
of
my
concerns
would
be
when
it
was
just
a
three
week
push
on
the
end.
So
so
we've
been
talking
a
lot
about
the
contributor
approver
side.
You
know
we
have
some
sprays
and
what
happens
like
that,
but
the
point
is
like:
maybe
the
consumers
meaning
the
the
end
users
who
are
running
clusters
and
who
are
sitting
there
on
a
version
that,
when
119
comes
out,
is
all
of
a
sudden
out
of
support.
C
Those
are
the
people
I'm
most
concerned
about
because
then
they're,
you
know
the
people
who
are
going
to
upgrade
up
to
119
actually
aren't
that
much
of
a
concern
to
me
because
they're
kind
of
bleeding
edge
right
like
it's,
it's
the
people
who
already
have
a
difficult
time.
Keeping
up
with
this,
pretty
pretty
strenuous
release,
train
and
now
are
in
a
situation
where
they
don't
have
the
resources
to
do
it
and
they're
gonna
fall
out
of
support.
C
A
B
I
think
the
bit
that
Jordan
mentioned
about
the
release,
note
required
I
think
is
really
important
or
sorry.
No
action
required
is
really
important
because
that
one,
you
know
we
have
a
label,
we
can
track
pretty
easily,
and
you
know
we
can
try
to
you
know,
even
if,
like
I
mean
even
if
something
got
in
and
then
at
the
end
of
the
release,
we
were
trying
to
write
an
action
required.
We
could
be
like.
Maybe
we
should
just
revert
that
and
not
maybe
we
haven't.
B
We
have
a
lot
of
sort
of
functionality
there,
okay,
I
guess
what
I
don't
understand
is
like
that,
doesn't
necessarily
correlate
exactly
would
like
feature
work
right
like
you
could
be
messing
with
API
is
adding
new
ones
moving
them
across
boundaries.
I
might
not
require
like
an
action
required,
but
it
does
like
at
stuff,
like
you
know,
you're,
adding
some
inherent
risk
by
adding
so
like
like.
Are
we
wanting
to
try
to
quantify
that
in
some
way?
B
Are
we
gonna
like
try
to
say
that
we
need
really
strong
and
isolation
with
some
kind
of
feature
gate
or
something
like
like
I
mean
it
like?
Like
do
we
need
something
more
than
what
we
would
already
do
like
if
you
added
it
like
a
new
like
alpha
feature,
we
would
always
say
get
it
behind
something
to
make
it
not
run,
but
do
we
need
something
more
or
maybe
it's
just
so
you
just
you
can't
add
any
alpha
feature
or
not.
Might
you
think
I
don't
know
yeah.
A
So
I
mean
one
I
again,
I,
don't
think
we
have
a
way
to
block
that
today.
Outside
of
the
you
know,
outside
of
the
discretion
of
the
reviewers
and
approvers,
but
two
in
this
proposal.
We
we
wanted
to
try
to
not
add
new
things,
new
levers
bells
and
whistles
and
try
to
work
within
much
of
what
we
have
as
an
existing
process
today
and
see.
A
And
sorry
that
that
doesn't
really
solve
things.
I
think
that,
like
we're
dealing
with,
I
you
know
and-
and
I
feel
like
this
is
ever
since
I've
like
started
in
kubernetes-
this
has
kind
of
been
a
thing
on
the
table
that
we
don't
have
levers
to
block
things
like
this
right.
So
maybe
maybe
this
is
an
opportunity
to
consider
it
throughout
the
cycle.
I,
don't
think
it's
something
that
we
should
implement
during
the
cycle.
E
Stephen,
but
the
issue
also
is:
there
is
a
lot
of
inbuilt
problems
for
people
trying
to
get
code
in.
This
is
not
talking
about
just
right
now,
we're
just
talking
about
normal
cycle
without
co-ed,
and
it's
extremely
hard
for
people
who
are
not
full-time
contributors
to
get
anything
in.
So
adding
more
barriers
might
feel
good
right
now
and
it
might
work
for
the
co-ed
situation.
But
when
we
get
back
out
it's
going
to
become
even
worse
situation,
then
we
are
be
there
before.
A
It
makes
it
very
so
we're
like
we're
trying
to
be
very
we're
trying
to
tiptoe
around
a
lot
of
this
and
make
sure
that
we
don't
impact
anything
negatively.
One
thing
I
wanted
to
toss
out
onto
the
air.
Is
that
something
to
consider
and
I?
Think
Tim
was
mentioning
before
on
previous
calls,
or
maybe
zoom,
maybe
slack
chats
or
something.
There
are
some
people
that
so
there
are
two
categories.
A
There
are
some
people
that
can't
not
work
right
now
like
they
have
to
deliver
certain
things
right
now,
and
there
are
some
people
that
may
be
working
even
more
as
a
coping
mechanism
right
so
I.
Look.
We
want
to
give
some
deference
to
that
stuff
to
you
without
again
mangling
mangling
people's
workflows
too
much
so
sorry
a
little
bit
of
a
tangent.
But
so
let's
one
of
the
reasons
that
we
did.
The
extension
as
well
is
we're
starting
to
talk
about
the
stability
releases.
A
E
Can
go
to
the
schedule?
Okay,
yeah.
The
other
thing
with
what
John
was
mentioning
was
if
we
tack
on
an
additional
stable
release.
So
we
don't
let
people
fall
off
the
wagon
on
the
other
side
right,
the
older
releases,
who
we
we
basically
stop
supporting?
What
is
the
cost?
There
can
be
bear
that
cost
instead
of
the
other
things
that
you
know
we'll
be
working
on
kept
for
that
I
know
so,
I
sort.
G
E
So
if
we
do
that
as
an
kaqun
and
additional
stable
release
and
then
also
say
what
jordan
was
saying
like
no
action
required,
nobody
has
to
do
anything
to
do
an
upgrade
for
their
existing
clusters.
If
we
do
those
too,
then
we
will
probably
serve
a
whole
bunch
of
end-users
I
think
and
if
we
avoid
breaking
changes
like
the
client
goes
stuff
that
happened
Kellogg
we
to
that
is
going
to
happen.
Yeah
then
we'll
address
a
few
more
sets
of
people
who
consume
our
code.
I
think.
A
A
F
Random
question:
was
there
any
tag
given
to
actually
extending
the
early
cycle
by
for
more
than
three
weeks,
I'm
trying
to
do
the
math
in
my
head,
a
double
possibly
give
me
two
fifteen
week
or
so
releases
for
the
year
and
then
like
some
relatively
long
awkward,
a
point,
a
a
cycle
in
the
year.
That
is
not
enough
for
an
actual
release,
a
sub
like
what
about
extending
him
for
six
weeks
or
so,
or
something
else
to
actually
allow
for
people
to
in
and
also
to,
and
also
to
wait
to
go
to
team.
F
A
So
my
question
would
be:
how
long
is
long
enough
right?
Where
is
the
line
between
I'm,
not
saying
that
I
don't
disagree
I?
My
first
thought
was
make
this
at
least
a
four
month
release
cycle
and
add
more
of
a
break
in
between
right,
but
where?
Where
do
we?
Where
do
we
say
that
that's
fine
right,
I
think
that's
difficult
to
do?
I
do
think
that
it's
more
possible
given
that
we're
at
the
beginning
of
a
release
cycle
to
plan
a
120.
A
What's
that
kind
of
fluffer
but
yeah
I
mean
I
would
be
curious
if
people
want
more
than
yeah
it's,
it's
kind
of
like
six
of
a
dozen
you
know
so
like
I
would
I
would
be
curious
where,
where
would
people
be
happy
with
right?
We
felt
that,
like
the
three-week
line,
was
allowed
us
to
allowed
us
to
push
more
time
into
the
additional
our
sees
that
we've
added
at
the
back
end
of
the
release,
hopefully
giving
people
time
to
to
test
and
let
that
think
and
let
that
stuff
soak.
A
G
So
I
think
one
way
to
answer
Jorge's
question
is
we've
been
talking
about
this
for
years,
even
unrelated
to
the
current
thing?
What's
the
right
cycle
three
months,
there's
no
magic
to
three
months
mo
I.
Think
originally
last
week,
basically
was
kind
of
say
like
can
we
just
skip
it?
Could
it
come
out
it
the
next
one?
So
it's
making
this
one
a
six
month
cycle,
so
we
we've
bounced
it
back
and
forth.
G
There's
a
lot
of
hesitancy
to
to
do
a
longer
elongation
for
whatever
that
means
in
specific
weeks
or
months,
we're
kind
of
all
the
reasons
that
you've
just
been
hearing
over
the
last
41
minutes
that
like
there's
this,
we
know
we
have
on
manage
risk
in
the
project
to
go
to
Tim
statement
around
test
coverage.
Quality
completeness
this
is
really
complex
and
we
we
know
from
experience
and
software
development
that
the
longer
the
cycle,
the
more
of
that
unmanage
risk,
starts
to
build
up
in
it
does
bite
us.
G
A
Sooo
my
biggest
concern
there
is
less
so
mechanical
and
actually
doing
the
release
clicking
the
buttons
I
think
from
like
the
release
management
side.
That's
those
buttons
are
aren't
as
terribly
difficult
to
click
as
they
used
to
be,
but
more
so
from
the
release
team
side.
Extending
a
release
means
we
keep.
You
know
we
keep
40-plus
people
on
working
for
that
release
until
X
date.
Right
so
I
think
you
know
three
three
to
four
weeks
is
fine
or
could
be
fine,
but
you
know
like
five
six
months
it
yeah
it
doesn't.
G
Could
be
creative
there,
like
I,
think
it's
important,
even
though
this
is
a
sig
release
meeting
and
we're
sort
of
talking
about
starting
the
release
cycle,
it's
important
for
us
to
separate
the
project
and
its
consumers
from
the
release
team.
If
the
project
and
its
consumers
need
a
longer
cycle,
the
release
team
internally,
we
could
figure
out
a
way
to
make
it
to
team.
Some
sort
of
roll-on/roll-off
spread
the
load,
and
we
could.
G
We
could
make
sure
that
we
as
a
sig
release
or
not
tape,
I'm,
not
requiring
everybody
else
in
the
crew
Nettie's
universe
to
do
things
that
are
complicated
to
avoid
some
complexity
ourselves,
which
we
could
somehow
manage.
Probably
if
we
are
creative
and
and
not
and
not
be
adding
to
our
own
human
toil
I.
A
G
A
G
E
A
B
B
C
I
think
the
issue
is
the
words,
were
balanced,
different
priorities
so
with
the
three
month
with
like
there's
the
consumers,
those
downstream
people,
the
end
users
running
clusters.
For
them
a
longer
delay
is
better,
but
for
purely
from
the
sense
of
like
they
don't
they're,
not
forced
into
action.
The
the
the
tension
for
the
shorter
one
is
that
we
don't
want
to
accumulate
risk,
and
so
I
think
the
three
weeks
is
is
too
too
far
push
towards
the
not
accumulating
risk
in
my
opinion
and
that
we
eat
I.
C
Would
it's
all
just
a
judgment
call
like
Steven,
so
there's?
No,
none
of
us
can
really
know
what's
best,
but
in
my
judgment
like
giving
it
more
like
six
weeks,
ish
would
give
that's.
That's
like
a
real
relief
on
the
end
consumer
side,
as
opposed
to
three
weeks,
which
is
not
all
that
much
different
to
me
and
then
we
we
took
the
other
levers
that
we've
talked
about
to
address
the
risk
accumulation.
You
know
no
action
required
and,
and
all
of
that.
D
E
And
for
me,
one
of
the
things
is
like
we
always
say
the
dots
in
their
release.
Nobody
should
use
it.
Nobody
literally
uses
it.
Everybody
waits
for
the
dot
one
release,
because
you
know
week
we
keep
making
changes
till
the
last
minute,
so
it
might
be.
That
is
one
thing
that
we
we
can
ensure
that
this
time
a
dot
zero
release
is
definitely
something
that
we'll
be
happy
with
yeah.
A
I
think
that
yeah
I
think
that
one
thing
I
would
like
to
see
at
the
back
end
of
the
cycle
is
like
less
surprises,
the
the
and
adhering
to
the
cherry-pick
deadlines.
I,
don't
think
we've
managed
to
do
that
in
the
last
few
cycles
and
I
mean,
of
course
that's
because
someone
has
found
some
late
stage,
terrifying
bug
and-
and
you
know
and
and
fix
it,
but
you
know,
but
it
would
be
nice
to
see
a
long
period
of
settle
time
too
so
to
allow
you
know,
rc3
to
look
like
what
thought
zero
is
gonna.
A
Look
like
so
I
mean
I'm,
I,
think
I'm,
fine
to
add
more
time
in
between
the
rcs,
maybe
even
add
another
RC
for
whatever
that's
worth
and
keep
the
same
amount
of
time
right.
That
adds.
That
adds
an
extra
two
weeks
right.
So
that's
not
quite
it,
but
there
could
be
a
wait
period.
I'd
like
like
we
can.
We
can
play
around
with
it.
If
people
are
saying
that
the
people
are
saying
that
six
weeks
is
preferable,
we
can
we
can
start
playing
with
schedule.
A
D
We're
his
question
to
that
also
gives
us
sort
of
a
path
for
like
how
this
affects
releases
that
come
after
it
like.
If
we
look
between
now
and
the
end
of
the
year
like,
if,
like
we're,
not
setting
precedent
like
for
all
time
like
what
we're
gonna
do,
but
it
is
useful
to
think
about
like
okay.
What
what
does
the
next
release
look
like
like?
How
do
we
bump
up
against
holidays
and
stuff
the
end
of
the
year
and,
like
three
weeks
put,
does
put
the
next
release?
D
If
we
extend
when
I
need
my
three
weeks,
it
does
put
the
next
release
in
kind
of
an
awkward
position
where,
if
it's
a
normal,
normal
length
release,
then
the
fourth
release
of
the
year
is
basically
like
a
month
month
and
a
half
like
it's
just
crazy.
If
we
actually
bump
it
out
six
weeks,
then
we're
basically,
we
can
basically
split
the
difference
and
say,
like
one:
nineteen
is
relaxed
timeline.
E
B
D
D
So,
just
not
to
like
put
my
own
things
first,
but
one
of
the
caps
that
I
have
in
119
is
a
cap
for
surfacing
information
about
use
of
deprecated
things
to
users.
Right
I
was
talking
with
120
no
I
know
I,
know
I'm
just
learning
it
as
an
example
like
this
is
a
thing
that
addresses
a
long-standing
gap
and
actually
improves
user
experience
and
helps
them
recognize
risks
that
they
have.
D
But
it's
definitely
a
feature
I'm,
hesitant
to
just
say
no
features
at
all
for
any
reason,
I
think
it
has
to
be
more
of
a
like.
Is
this
a
feature
that
requires
a
reaction?
Is
this
a
feature
that
introduces
risk
and
that
gets
more
to
what
John
has
been
doing
with
the
production?
Writing
this
stuff,
like
calling
out
the
impact
of
a
change
and
evaluating
it
on
its
merits?
D
A
I
think
even
more
so,
like
all
changes
have
the
potential
to
bring
risk.
It's
is
it
acceptable
risk
right
for
us
right,
but
I
I
do
agree.
The
like
your
cap
is
something
I
want
to
see
and
I.
Think
a
lot
of
people
want
to
see
in
and
it's
yeah
I
think
it's
it's
tricky
to
say,
like
we've
had
that
that
issue
open
around
discussing
a
stability
release
and
it's
milestone
for
119
funny
enough,
so
it's
so
flaky.
It's
definitely
on
the
table
right
now.
A
It's
something
that
I
I
personally,
don't
think
we're
going
to
get
until
we
have
levers
and,
and
even
even
then
I
think
they're.
You
like
Jordan,
was
saying,
there's
and
there's
a
lot
of
nuance
between
what
is
a
feature
like
or
what
is
something
that
overall,
like
will
improve
our
overall
posture
over
time.
Right,
I,
don't
know
it's
the
short
version.
F
A
Really
just
want
to
throw
it
out
there.
That's
that's
the
tough
one
and
I
think
that
I
think
that,
ultimately,
like
we're
going
to
land
in
a
compromise,
there
is
no.
There
is
no
one
solution.
That's
going
to
solve
everything
for
everyone.
I
think
that,
ultimately,
we
need
to
take
the
the
needs
of
the
many
for,
for
whatever
that's
that's
worth.
A
A
A
All
right
so
I'm
sharing
my
screen
and
at
least
like,
let's
look
at
what
we
got
today.
So
everyone
is
on
the
same
page
and
is
that
my
computer
freezing,
maybe
all
right
so
kind
of
in
code
form.
What
we
are
talking
about
in
the
email
is
moving
enhancements
for
you
to
week,
5
moving
releases
all
releases
to
Tuesday,
there's
no
special
reason
for
this
outside
of
because
Ian
actually
asked
me
this
last
night.
A
E
A
Sorry,
my
computer
is
doing
stuff.
Sorry,
can
you
hear
me
see
me
again?
Yes,
we
can
okay,
all
right
so
yeah,
so
the
idea
behind
enhancements
for
uses
we're
simultaneously
sending
this
email
out,
but
we're
also
we've
also
merge
changes
to
the
enhancements
process
and
we
have
another
one
inbound
with
the
PR
our
template
coming
into
the
PR.
Our
questioning
are
coming
into
the
cap.
Template
so
I
think
that
it's
I
mean
it's
not
much,
but
it's
a
week
to
try
to
adjust
some
of
that
stuff.
Maybe
change
into
the
new
format.
A
Think
we're
gonna
have
a
hard
like
we
don't
do
any
enforcement.
Well,
we
do
some
enforcement
on
the
cup
side,
but
I
don't
think
we're
going
to
strictly
require.
You
know.
People
have
all
of
their
cups
in
the
new
format
before
enhancements.
Freeze
like
Moe
was
was
discussing
this
with
us
on
the
channel.
A
By
the
way,
I
can
keep
going
if
people
are
interested,
and
so
we
have
one
minute
yeah
so
yeah.
So
with
regards
to
schedule,
my
computer
is
doing
awful
things.
I
can't
screen
share,
but
right
now
we're
saying
Arceus
get
really
Sun
a
week,
bi-weekly
cadence!
So
that's
week,
9
and
week
11
week,
13,
the
119
zero
release
date
has
moved
to
week,
15
right
and
then
the
retro
is
moved
to
week,
16
right
so
overall
we're
looking
at
a
round
for
a
month
for
month
cycle.
A
A
A
Yeah,
if
we,
if
we,
if
we
go
for
December
and
we
go
for
an
early
December
date,
we
go
for
what.
If
we
were
to
say
all
of
August
is
frozen
or
something
right
and
land
it
directly
in
December,
early
December
right.
That
gives
us
that
just
gives
us
four
months
of
cycle
again
right
and
you.
If,
if
we
were
to
continue
down
this
road
right,
we
have
the
benefit
of
the
the
four
month
cycle,
actually
adding
a
release
to
kind
of
the
support
window.
C
J
C
A
And
then
I
mean
that's
also
assuming
that
we,
we
don't
like
this
right
like
what,
if
we
find
that
the
four
month
release
cycle
is
the
sweet
spot
right
and
then
all
of
a
sudden
you've
got
three
releases
a
year,
and
you
know,
and
you
get
a
little
extra
support
as
a
result
of
that
right.
You
get
an
order
and
change
a
support
as
a
result
of
that
yeah.
E
D
If
master
is
shut
down,
then
there's
actually
not
a
lot
of
rebasing
required,
so
the
rebasing
comes
in
when
you
have
a
long-standing
PR
and
master
is
changing
yeah.
Well,
that's
true
as
well.
Yeah
I
I'm,
actually
somewhat
like
we've,
talked
about
feature
branch
at
all
and
I
know
we're
running
over
time.
We
talked
about
feature
branch,
development
and
that's
been
very
difficult.
Actually
because
most
people
don't
do
feature
branch
development.
D
But
if
we
had
a
longer
period
of
fries
and
a
shorter
merge
window
for
a
given
release,
it
would
encourage
people
to
work
in
branches
stack
their
PRS.
The
way
we
do
for
API
changes
where
we
get
API
implementation
and
tests.
All
Green
was
a
long
CI
pass
history,
and
then
you
merge
it
as
a
piece
instead
of
trickling
changes
into
master
over
a
two
month
window
that
are
incomplete,
hoping
you
get
the
completing
changes
in
like
a
month
in
the
future.
All.
E
D
C
G
J
I
didn't
like
that.
I
do
like
that
sentiment
yesterday.
In
terms
it's,
you
know
the
mental
model
of
this
being.
This
is
an
experiment
and
we
can
figure
out
what
works
and
what
does
not
work
and
I
think
that's.
You
know
kind
of
we
+1
to
all
that
was
said
in
that,
like
yeah,
let's,
let's,
let's
see
what
works
for
us
and
what
doesn't.
A
Yeah
I
think
that
I
think
that,
hopefully,
things
will
start
to
become
clearer
as
we
gain
this
experience
towards
the
back
end
of
the
cycle.
I
want
to
make
sure
that
we
I
agree
by
the
way.
I
am
a
little
worried
about.
You
know.
Once
code
free
starts
there
is.
There
are
already
six
weeks
between
code
freeze
and
master.
Reopen
right,
I
feel
that
maybe
long
today
like
if
we,
if
we're,
if
we're
adding
an
additional
three
weeks,
so
we
feel
that
that's
too
much.
K
C
G
Like
this
would
definitely
get
people
a
flood
if
you
figure
like
a
week
or
two
to
notice
optimistically,
maybe
three
to
notice
that
it's
happened
a
week
to
start
your
branch
development
a
week
to
go,
whoa
gets
confusing
two
weeks
to
start
to
be
like.
Oh,
maybe
I
could
deal
with
this
another
week
to
be
for
them.
Like
there's
your
nine
weeks,
if.
C
It
is
the
remedy
for
people
who
are
stuck,
which
it
should
be,
then
you
know
we're.
Probably
I
probably
should
provide
some
guidance
on
how
we
want
expect
people
to
do
that.
You
know
I
mean
and
what,
when
they
go
to
merge
those
feature
branches
in
how
clean
they
have
to
be
and
what
they
look
like,
and
you
know
probably
should
provide
people
some
guidance
so
so
that
they
don't
have
to
figure
it
out
in
those
three
weeks.
It's
funny.
A
A
A
Are
we
good
from
because
all
of
the
stuff
that
we've
been
talking
about
has
primarily
been
back
half
of
the
cycle
right,
and
that
is
that
we
have
time
to
fix
if
we
need
to
right
or
tweak
whatever
you
want
to
call
it
the
front
half.
Are
we
fine
with
that
right
preceding
the
essentially
enhancements?
Freeze
is
the
only
thing
that
gets
shifted
back
a
week
and
proceeding
as
normal
with
the
timeline
up
until
code
freeze-
let's
say
yes
from
dims:
no,
how
you
feeling.
G
B
G
A
A
B
G
Well,
pause
to
let
people
read
that
I
guess,
first
of
all,
I
think,
especially
on
the
six
weeks
column
like
the
normal
column
in
the
plus
three
weeks.
Those
are
what
we
have
committed
in
the
git
repo
and
what
Stephens
current
PR
changes
to
that
final
column.
There
is
what
we've
been
loosely
discussing
and
I.
G
A
Okay,
yeah
so
yeah
we
discussed
yesterday
that
we
don't
want
to
push
code
freeze
because
that
encourages
more
content.
We
want
to
keep.
We
want
to
try
to
keep
the
dates
as
close
as
possible.
In
fact,
in
the
schedule
that
you
see
on
the
pr
code,
freezes
pulled
up
two
days
and
that's
literally,
it's
literally
just
to
get
the
releases
in
line
on
Tuesdays,
but
it
can
change
back
if
we
need
it
to,
but
but
yeah
I
think
we
I
think
the
the
time
needs
to
be
added
at
the
back
of
the
release
post
code.
A
G
G
A
Yeah
so
I
think
that
that,
like,
like
Tim
was
saying,
and
if
you're
done
with
your
caps
like
you
can
get
working
right,
there's
nothing
pre-empting
people
from
working
before
enhancements,
freeze
passes
it's
just
and
I
think
that
people
take
these
boundaries
to
be
hard
boundaries
right.
There
is
enhancements.
Freeze
like
you
can
deliver
a
cap
any
time
before
that
and
I
think
everyone
knows
that
yeah.
F
B
Yeah
like
for
me,
like
the
thing
I've
noticed
overall,
that's
like
a
limiting
factor
at
least
wish
to
God
is
just
and
with
I
think
there's
a
small
set
of
us
folks
that
work
on
this
stuff
so
like
that
the
deadlines
are
like
a
forcing
function
to
be
like.
Okay,
I
have
to
review
this
enhancement.
Now
it's
been
on
my
to-do
list
for
the
last
two
months,
heimo
made
it
or
Jordan
made
it
way
long
ago,
but
I
think
you
know,
I
could
put
it
off
so
I
did
because
boss
told
me
to
go.
B
Do
this
other
thing,
and
so
I
did
right
so
like
that
would
be
my
hesitation
right,
like
you
know,
I
have
a
kept
open
right
now.
I'm
working
on
changes
to
an
existing
kit
right
now,
right,
like
part
of
the
dates
is
just
like
I-
can
do
like
hey
Jordan,
hey
Mike,
please
review,
because
otherwise
it
just
won't
make
their
release
because
I
can't
like
I,
can't
I'm,
not
gonna,
merge
it
myself,
because
that's
ridiculous.
You
know
the
kind
of
defeats
the
point
of
making
pr's
I.
G
Have
one
concern,
though,
thinking
from
the
everybody
else
perspective
they're,
like
Moe's
on
top
of
stuff
he's
paying
attention
he's
here?
The
other
folks
are
still
sort
of
waiting
waiting
to
hear.
What's
going
on
with
119,
we
come
to
some
consensus.
We
get
an
email
out
by
Friday,
they've,
read
and
they're
like
whoa.
Wait.
A
second
enhancements
freezes
two
weeks
away,
I
only
get
two
weeks.
The
seat
this
time
for
enhancements
is
that
too
short.
G
A
A
A
A
H
B
G
C
I
think
we're,
since
we're
extending
good
I
think
the
18th
is
reasonable,
even
though
it's
a
little
more
time
which
we're
trying
to
not
encourage
more
content,
but
we
have
already
in
we're
pushing
out
the
backend
substantially
more
than
that.
So
I
don't
see
you
personally,
don't
see
that
as
a
problem.
A
Five
weeks,
I
guess
right
five
weeks
at
the
back,
half
post
post
code
freeze,
which
is
which
is
good
like
if
we
can
shorten
that
period
to
master
reopening
I
like
that.
Are
we
cool
with
maybe
saying
that
now
that
enhancements
freeze
is
even
further
extended?
Are
we
cool,
saying
no
exceptions?
No
dances
now
do.
G
Have
a
normal
way
of
people
justifying
that
their
thing
needs
an
exception
and
it's
it's
always
been
completely
subjective
on
the
lead,
how
they
choose
to
manage
the
risk
of
their
release,
and
we've
allowed
a
lot
this
time
we're
liable
to
allow
less
because
we're
worried.
But
with
this
change
in
cycle,
we
may
actually
feel
like
wow.
This
thing
is
everybody's
heard.
The
message
this
is
the
most
stable
release
we've
ever
had
as
we're
sitting
at
the
beginning
of
July,
and
maybe
a
few
things
do
get
lit
in
so.
B
B
B
G
Exceptions
that
are
filed
well
in
advance
of
the
date,
the
specific
date
probably
get
a
better
time
than
ones
that
are
filed
the
day
after,
but
ones
that
are
filed
the
day
after
the
deadline
may
also
still
come
in,
depending
and
especially
right
now.
I
think
we'd
want
to
be
a
little
bit
affiliative
on
that.
Like
oh
crap,
this
whole
week,
my
family's
been
sick,
but
my
thing
has
been
sitting
here:
ready,
I've
just
not
been
here.
What
y'all
think
I'd
like
to
think
we'd
be
like?
Oh,
okay,
yeah.
B
A
It's
one
more
it
like,
like
the
deadlines
we
have
today,
it's
one
more
thing
for
someone
to
smash
against
and
miss
and
like
we
have
to.
We
have
to
manage
that
anyway.
So
yeah
I,
think,
okay,
all
right,
I
think
we're
I.
Think
we're
good.
Are
we
good
I
think
we're
good
okay?
So,
let's
yeah,
let
me
let
me
pull
come.
G
B
B
A
I
mean
the
what
I
was
saying
before
like
we
just
have
to:
we
have
to
go
with
it
and
we
have
to
set
a
date,
and
we
have
to
be
able
to
message
this
out
again.
So
so,
yes,
all
of
all
of
that
I
will
update
the
PR
I
will
I
will
shoot
an
email
update?
Is
there
anything
outside
of
the
the
changes
to
those
states
that
we
wanted
to
discuss
or
that
we
want
a
message
in
that
email,
I.
B
Agreed
I
think
would
be
good.
To
call
out
is
those
categories
of
people
that
we're
trying
to
support
and
help,
because,
if
you're
like
a
core
contributor,
the
schedule
might
not
make
sense
because
you're,
not
necessarily
in
the
mindset
of
an
end
user
who's
trying
to
make
not
drop
out
support
or
keep
up
with
the
bleeding
edge.
Because
that's
what
money
for
like
I,
think
there's
a
lot
of
target
demographics
for
consuming
our
code
and
working
on
our
code
and
that
might
not
be
apparent
to
someone
who's.
Just
in
one
of
those
buckets
sounds.