►
From YouTube: Kubernetes 1.15 Release Retrospective (Part Two)
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).
B
B
D
C
D
C
D
B
C
C
Like
so,
the
unusually
I
usually
share
my
screen,
but
but
like
I'm
only
on
my
laptop's
is
like
difficult
to
see
both
yeah.
E
C
D
D
D
D
I'll,
do
the
I'll
do
the
the
standard
kubernetes
cig,
meeting,
doodad,
hello,
everyone?
This
is
the
cig
release
meeting
for
July,
2nd
2019.
This
is
a
recorded
meeting
that
is
on
the
internet
that
will
be
on
the
internet.
So
please
be
mindful
of
what
you
say:
please
be
sure
to
be
good
to
everyone
and
adhere
to
the
kubernetes
code
of
conduct.
This
will
be
the
second
part
of
the
kubernetes
115
retro,
we're
gonna
kick
off
the
meeting
with
that,
Christine
will
be
facilitating
so
I
will.
Let
you
take
it
away.
Christine.
C
B
C
D
So
we
mentioned
I,
said
I
think
we
mentioned
that
I
believe
that
Tim
maybe
had
questions
on
that
feeling
that
there
were
some
things
that
should
remain
in
the
repo,
because
that's
the
standard
way
of
doing
things
so
I
I
don't
have
strong
opinions.
I,
like
the
website.
I,
think
that
the
website
is
great.
I,
don't
have
strong
opinions
on
where
the
rel
notes
live.
I
know
rather
the
stuff
that
we've
done
to
trim
the
the
changelog
is
good.
We
should
continue
doing
some
of
that,
but
if.
D
B
D
F
The
plan
is
over
the
next
release,
we're
going
to
not
we're
going
to
take
out
the
bash
markdown
generator
and
replace
with
the
golang
generator,
and
then
that
way,
whenever
people
you
know,
run
a
Nago
or
whatever
it
is
and
then
actually
generates
a
release.
It'll
automatically
generate
the
JSON
and
then
essentially
cut
a
PR
against
the
website
to
update
the
JSON
that
is
used.
D
F
D
Yeah
yeah
I
think
my
only
comment
there
would
be
like
I
think
it
said
like
relevant,
kept
and
I
think
that
it
would
be
obvious
that
it's
relevant
if
it's
in
the
template,
so
maybe
just
kept
and
linked
or
docx
or
something
it
could
be.
The
array
instead
or
the
set
of
lists
yeah
yeah
I
should
I
should
comment
that
on
the
the
PR,
so
I'll
do
that.
C
So
next
one
unless
Josh's
joins
so.
D
Josh
is
not
here
yet,
but
I
guess
yeah
I
guess
I
can
talk
about
that.
A
little
bit
yeah.
D
The
requirement
becomes
like
hey:
I
have
to
go,
find
all
the
places
in
the
code
where
I
put
that
thing
and
make
sure
it
gets
bumped
and
make
sure
the
tests
pass
or
I
didn't
miss
this
thing
or
I
didn't
push
this
thing
and
I
forgot
to
push
this
thing
or
I
tell
that
person
that
they
had
to
cut
this
release.
So
I
could
do
that,
so
they
were
kind
of
like
there's.
There
are
a
few
things
at
play:
trying
to
bump
a
dependency
in
kubernetes.
So
what
we
were
thinking
and
I
think
there's.
D
So
that
is
here
and
there's
already
some
active
discussion.
You
seen
is
put
up
the
pr
for
that.
Dims
has
commented,
I
believe
and
Tim
pepper
is
interested.
I
know,
that's
something
that
we
I
think
that
it's
something
that
you
know
downstream
dependence
of
group
entities
as
well
will
benefit
from
being
able
to
add
a
clients
know
like
if
I'm
consuming
kubernetes
on
a
fork
or
something
like
that
and
I
need
to
bump
blah
right.
D
I
know
how
to
do
it
right
if
I'm
pushing
if
I'm
pushing
PRS
for
blah
I
know
how
to
do
it
very
quickly.
I
know
myself:
I
ran
into
trying
to
uncover
the
bits
around
what
how
we
package
kubernetes
CNI
right.
So
that's
like
the
CNI
tool,
so
we're
at
like
I
think
the
last
few
we
did
we're
like
zero
six:
zero,
zero,
six,
six
one
zero,
seven,
five,
zero
eight
one
is
the
most
recent
one,
so
I
have
issued
PRS
for
for
that
in
urban
eighties
release,
as
well
as
kubernetes
kubernetes.
D
The
tricky
thing
about
it
is
like
one
has
to
land
at
certain
time,
for
this
thing
happens
and
then
like.
If
you
don't
do
that,
then
the
tests
will
fail.
So
I'm
discovering
that
people
we
have
no
idea
how
we
release
certain
things
and
kubernetes
yeah
Seanna
is
one
of
them
so
having
a
dependencies
list
ahead
of
time,
knowing
exactly
where
to
go
where
to
where
to
pump
these
versions
and
tweak
tweak.
Things
would
be
super
helpful,
so
I
think
everyone
who
consumes
group-
and
it
is
yeah.
G
Okay,
yeah,
so
the
the
interesting
thing
you
know,
if
I'm
not
wearing
my
release
team
hat
at
the
moment,
but
as
somebody
who
worked
on
caps
and
had
a
particular
feature,
enhancement
come
in
for
115
what
ended
up
happening
in
my
experience
was
we
signed
off
on
the
cap
and
everybody
was
okay
with
it.
Then,
when
we
brought
the
implementation,
there
was
a
lot
of
bike
shedding
that
was
contradictory
to
the
cap.
G
So
just
an
interesting
observation:
when
you
try
to
land
large
changes
to
code
existing
code,
there's
not
a
good
split
between
actually
showing
up
and
writing
the
code
as
a
court
according
to
what
was
defined
in
the
cap
without
getting
into
kind
of
that
ultimate
bike
shedding
I.
Think
specifically,
I
called
out
two
different
issues
which
were
comments
on
the
the
PR
that
we
put
in.
That
was
as
part
of
the
work
that
was
defined
in
the
cap
that
were
basically
like.
G
So
that's
kind
of
a
it
was
more
just.
How
do
we
want
caps
to
work?
It
was
worth
calling
this
out,
I'm,
not
sure
if
it,
if
everybody
can
relate
to
this
specific
use
case.
I
think
this
was
a
complex
bit
of
work.
So
not
everybody
would
have
this,
but
I
think
the
challenge
that
I
got
and
what
I
wanted
to
bring
back
was
there
from
the
engineers
that
worked
on
this
change.
It
was
hard
to
understand.
G
A
G
C
D
G
D
Like
phase
zero
of
this
project
is
going
to
be
seven
bullet
points
right,
I,
go
I,
implement
the
seven
bullet
points
and
be
done
with
it
right
if
I
say
they.
If
I
say
in
this
kept
we're
going
to
blah
right
and
blah
is
very
fuzzy,
loosely
defined
ding.
Then,
yes,
that's
going
to
open
that's
going
to
open
up
people
to
like
shedding
during
the
actual
actual
implementation
right.
D
The
point
of
the
cap
is
to
try
to
lay
down
some
of
the
idea
of
what
the
implementation
is
going
to
be
ahead
of
time
right,
and
there
are
lots
of
other
points
to
the
cap,
but
I
think
that
a
tightly
defined
cap
is
more
valuable
than
a
loosely
defined.
One
I
think
that
trying
to
do
everything
at
once
is
is
not
great
either
right,
so
I
have
big.
You
know,
I
have
this.
D
You
know
large
ominous
project
and
I'm
going
to
write
a
kept
and
I'm
going
to
try
to
define
every
detail
for
this
thing
right
like
that,
is
that's
going
to
be
hard
to
do
right,
so
I
think
you
know
I
think
I
think
I
know
the
one
that
lucky
is
talking
about
in
particular
because
we've
chatted
about
it.
But
you
know
it's
one
of
the
thing.
G
D
That
you
know
what
it
was
was.
It
was
well-defined
and
you
know
in
retrospect,
people
are
going
and
they're
like.
Oh
well,
I
realized
that
you
know
well
now
that
we're
touching
this
thing.
What
if
we
did
blah
right
and
III,
think
that
you
know
if,
if
you'd,
if
you
have
a
well-defined
kept,
you
should
feel
free
and
feel
empowered
to
say,
like
here's,
what
we
defined
here's,
what
we
plan
to
do
right.
C
H
H
So
we
had
a
number
of
burn
downs
where
the
lead
was
not
available
for
that
burn
down,
and
they
did
not
designate
a
shadow
to
deliver
it
in
their
place,
and
you
know,
and
the
second
half
of
this,
which
is
not
done
yet,
which
is
writing
documentation
for
this,
because
there
is
nowhere
in
the
documentation
that
says
that
you
should
do
this.
Hence
some
people
not
knowing
about
it
yeah.
D
I
try
to
echo
this
every
time
we
mention
shadows,
but
you
know
I
think
that
you
know
one
of
the
points
of
this.
This
thing
that
we've
been
doing
for
a
little
while
is
like
to
to
groom
people
to
take
over
the
role
right,
but
you
know
part
of
that
is
a
level
of
a
level
of
ownership
and
leadership
in
that
right,
so
stepping
into
the
role
feeling
that
you
can
take
on
certain
items
so
so
to
anyone
on
the
call
listening
who's.
D
That's
you
know
that
is
I,
think
you
know
one
of
the
the
in
terms
of
like
the
like
how
the
sausage
made
when
we
were
building
the
release
team
for
the
next
season
right
or
cycle
cycle.
Like
that's
one
of
the
things
we're
looking
at
like
did,
the
person
show
up
are
they
active
in
are
like?
Do
they
try
to
be
active
in,
say,
release?
D
Do
they
like
cig
release
in
general
and
the
release
team
asking
what
they
can
can
do
to
help
I've
seen
several
shadows
for
this
cycle
really
like
step
up
without
you
know,
without
any
interaction,
just
like
hey.
What
can
I
work
on
or
start
picking
up,
Help
Wanted
issue,
like
that's
the
kind
of
thing
that
we
want
to
see
like?
That's
that's
what
signals
does
so
like
you're
ready
to
take
the
role
right
so
and
then
you
know
in
terms
of
the
the
documentation,
I
I.
D
Every
time
we
mention
the
handbooks
I
say
like
they're
living
they're
living
documents
right,
you
should
feel
comfortable
again
questioning
the
things
that
are
written
down
in
the
handbook.
Helping
us
tweak
the
process
right,
there's,
not
something
that
we,
you
know
as
the
sig
chairs
are,
as
the
release
team
leads
or
as
the
emeritus
advisors
or
like
writing
policy
from
on
high
right.
This
is
a
team
activity.
D
E
Josh
I
know
you'd
sent
out
a
survey
as
well
for
the
shadows
as
like
an
exit
survey.
I,
don't
know
if
you've
had
a
chance
to
or
if
you
need
any
help
like
synthesizing
some
of
those
results,
but
I
wonder
if
we
can
use
that
survey
to
get
an
idea
of
level
of
engagement
from
shadows
release
their
perceived
level
of
engagement.
That
was.
H
H
C
C
D
A
No,
that's
that's
what
it
is.
It's
just
that
hard
to
understand
what
the
context
is,
because
there's
so
many
things
in
flights
and
things
that
are
changing
cookies
does
help
that,
and
you
know,
I
know
that
George
at
one
point
in
time
was
trying
to
get
ahead
of
the
you
know,
some
of
the
blog
posts
and
wrote
out
one
that
you
know
and
ended
up
not
flying,
but
I
was
like
that's
fine,
even
if
you
did
that
you
know
looking
at
glass-half-full,
we
could
still
use
that.
A
Just
not
you
know
within
this
release
happen
later,
so
we
can
start
to
do
things
like
that
for
sure
in
terms
of
deliverables,
but
that's
that
is
definitely
a
plus
one
in
terms
of
trying
to
find.
How
do
we?
Actually?
How
do
we
know
what's
going
on
and
in
any
given
point
in
time
and
then
align
once
we're
ready
to
dig
in,
and
this
is
exactly
what
ownership
yeah.
D
So
instead
of
five
days
of
kate's,
it's
like
30
days
of
Kate's
right,
but
we're
not
actually
going
to
do
that
like
like,
but
as
an
example
right
just
having
more
consistency
around
the
process.
I
think
that
I
think
that
having
non
CN
CF
people
or
is,
is
that
advantageous
so
that
we
feel
like
that.
It's
owned
truly
by
the
community,
but
but
there
will
be
I,
have
already
started.
Speaking
to
C&C,
effers
and
former
seen
effort
about
the
communication.
Sub-Project
so
stay
tuned
for
that,
because
they
will
be
involved.
This
long.
C
All
right
anything
else
on
this
one:
okay,
so
next
is
a
ten
minute.
Bleep
he's
not
here
so
I'll
read
this
one
scalability
probably
will
have
the
ability
to
simply
revert
commits
on
master
and
probably
also
on
the
release
branch,
although
they
don't
currently
monitor
much
C
male
thread
feature
request:
Allah
sent
to
a
mix
of
steering
minetti's
bunch
of
email
groups,
so
yeah
anyone
want
to
talk
about
this.
One
yeah.
D
So
I
think
I
think
Josh
and
I
can
tag-team
this
one,
so
I
I
forgot,
who
initially
sent
out
the
thread
but
I'm
the
one
who
see
seed
like
all
of
those
those
lists
on
it,
because
there
was
I
mean
there
are
a
few
things
going
on
right.
There's
one
part
of
it
that
the
that
sig
scalability
has
within
their
charter
right.
D
So
this
is
something
this
is
a
document
that
has
told
you
what
sig
scalability
plans
to
do,
or
what's
a
scalability
has
capacity
and
and
governance
to
do
within
the
project,
and
one
of
those
things
is
to
be
able
to
pull
the
trigger
on
removing
code
that
affects
the
the
consistency
of
any
branch
right.
This
is
a
power
that
they
have
like
it
has
been
decreed
in
their
Charter
and
signed
off
by
by
steering,
but
they
have
not
had
the
power
to
do
that
and
they
still
don't
right
so
they're.
D
Not
so
for
you
to
be
able
to
do
that,
you
need
to
be
on
the
top
level
approvers
and
and
a
top
level
approver
and
like
the
owners
file
for
for
kubernetes,
kubernetes
right,
so
I
believe.
Right
now,
none
of
them
are
so.
There
are
a
few
things
at
play.
Right
initially,
I
interpreted
this
to
mean
hey.
Well,
maybe
you
need
more
reviewers
and
approvers
right
and
then
try
to
turn
it
into
a
hey.
D
D
If
they're
responding
to
the
emails
is
a
different
story
right,
so
I
think
I
think
that
we
have
some
of
the
mechanisms
in
place
to
support
this.
What
it
you
know,
what
it
comes
down
to
is
also
a
process
change
for
the
sig
right.
If
you
are
going
to
say
that
your
job
can
block
a
release
or
that
you
have
the
power
to
you,
pull
things
out
of
a
release
of
a
master
of
a
release
branch.
Then
you
need
to
be
present
and
active
in
in
monitoring
these
things
right.
H
H
H
H
And
I
was
not
following
along
see,
I
signal
when
this
was
happening.
I'm
only
dealing
with
the
aftermath,
because
the
aftermath
is
well
Jack,
saying
that
we
have
to
change
the
Milwaukee
test
criteria
which
I'm
arguing
with,
but
but
now
it
means
that
I'm
getting
form
over
here.
Do
anybody?
Can
you
see
a
signal
team
here.
H
D
I,
don't
think
we
have
anyone
from
CI
signal
on,
but
the
you
know
like
the
TLDR
is
essentially
we
had.
We
had
a
few
jobs
that
were
read
before
forever.
Basically,
and
you
know
we
did
not,
you
know
it
got
to
the
point
towards
the
end
of
the
release
cycle
where.
G
D
Like
hey,
these
things
are
still
bad
like
what
do
we
do
like?
Do?
We
do
something
about
it?
Who
do
we
check
in
with
right?
And
you
know
and
communication-wise
I,
you
know
again.
As
Josh
said,
you
know
there
are
some
they're,
both
under
resource
and
and
also
difficult
to
reach,
not
their
fault
right.
They.
D
You
know
weird
time
zones,
well,
not
weird
for
them
trying
to
be
diplomatic
in
what
I
say,
but
like
no
they're
they're
on
you
know,
our
release
cycles
tend
to
skew
towards
us
time
zones
right
specifically
specifically
Pacific
and
you
know,
and
there
I
think
central
Eastern,
primarily
or
maybe
even
further
off
ya.
D
You
know
so
attending
some
of
these
meetings,
or
you
know,
is
it's
not
feasible
right
for
for
them,
and
you
know
there's
also
the
consideration
around
the
the
stuff
that
they
own
they're,
all
long
running,
high
cost
jobs
right
are
primarily
all
long
running
high
cost
jobs,
it's
kind
of
like
the
the
the
goal
of
the
sake
right.
So
what
becomes
really
difficult
is
like?
How
do
we
communicate
with
people
who
are
off?
D
You
know
who
are
off
the
usual
time
zones,
get
the
signal
and
time
and
know
how
to
you
know
and
know
how
to
move
forward
there
right
if
they
identify
a
regression
in
a
long-running
job
or
something
you
know,
then
they
have
to
determine.
Is
it
flake
right?
Is
it
a
flake?
Is
it
actually
regression?
How
long
is
it
going
to
take
for
me
to
deliver
this
fix?
How
long
is
it
going
to
take
for
me
to
test
this
fix?
D
D
D
That's
I
hope
that,
with
the
the
like
global
release,
calendar
that
we
put
out
for
this
cycle
or
and
for
every
cycle
that
people
will
be
more
aware
of
the
you
know
of
the
deadlines
for
for
certain
events
like
when
we're
actually
cutting
a
release,
because
it
was
a
little
disappointing
to
hear
that
like
when
we
were
asking
like
hey,
we
have
to
look
about
doing
this
release
very
soon,
and
you
know
they
were
under
the
impression
that
they
had
an
extra
week.
So
you
know
so
it's
so.
D
D
So
part
of
that
discussion
was
happening
right
now.
I
essentially
said
like
listen.
If
you
were
going
to
move
something
into
our
dashboard
like
you
need
our
approval
for
it
right.
So
then,
you
know
that's
that's
part
of
the
discussion,
but
it's
also
like.
If
we
need
to
tweak
the
criteria,
then
then
sure
like.
Let's
let's
meet
and
talk
about
how
to
do
that.
But
you
know
I
think
that
I
think
that
some
of
what
we
have
in
place
is
the
right
stuff.
D
C
H
C
D
So
so
part
of
that
work
that
Erin
did
to
define
better
to
find
the
release
blocking
jobs,
also
involved
enforcing
enforcing
certain
configs
right
within
test.
Infra
and
part
of
that
is
adding
email
addresses
to
alert
on
failures
right
so
for
the
release.
Team
I
took
a
look
at
it
and
most
of
the
things
that
I
think
that
our
release
team
related
or
sending
alerts
to
really
kubernetes
release
team
at
Google,
Groups,
comm
right,
the
stuff
that
is
specifically
release
cutting
related.
So
like
can
we
install
the
Deb's?
Can
we
check
for
this
thing
like?
D
Are
the
tests
on
kubernetes
release,
running
okay
stuff,
like
that
those
send
to
right
now
they
send
to
kubernetes
release
managers
at
Google
burst,
calm
right
so
having
the
the
release.
Engineering
team
handle
that
specifically
and
having
the
release
team
people
who
are
involved
in
CI
signal
receive
the
alerts
that
are
related
to
the
span
of
the
release
right.
So
you
know
the
ask
here:
is
that,
as
move
into
the
116
cycle,
that
CI
signal
TI
signal
is
incredibly
vigilant.
D
People
on
the
mailing
list-
even
you
don't
need
to
be
on
CI
signal
to
do
this,
for
the
shadows
on
the
call
listening.
But
you
know,
if
you
see
you
know,
if
you
see
something
fail
like
because
the
failure
will
come
through
right
and
you
know
for
I
think
you
know
for
anyone
who
has
done
s
re
DevOps
e
type
operations,
you
work
in
the
past.
You
know
there
are
some
things
that
you
see
and
you're
like.
D
Oh,
my
god,
that's
broken
like
I,
have
to
stop
what
I'm
doing
and
fix
this
immediately
right
and
then
there
are
the
other
things
that
you're
like
well
that
failure
comes
in
at
least
10
times
a
week.
So
I
know
that
if
I
grab
this
on
Tuesday,
then
I'll
be
fine
right.
You
know,
so
we
have
to
make
sure
that
we're
not
we're
not
treating
these
alerts
in
the
latter
category,
we're
not
like
getting
so
used
to
seeing
them
that
we
don't
action
on
them
right.
D
So
the
hope
is
that
people
are
vigilant
in
in
assessing
those
alerts,
because
the
ones
that
come
into
the
cig
release
mailing
lists,
release
team
and
release
engine
release.
Semien
release
managers
are
ones
that
we
need
to
concern
ourselves
with.
There
are
ones
that
can
potentially
block
the
release.
A
C
B
D
C
Great
so
I
know
there's
a
kind
of
a
lot
on
this
topic.
This
is
actually
the
last
one
that
we
have
for.
What
will
we
do
differently?
Besides,
that
we
have
some
parking
lot
items,
but
I
figured
open
it
up.
If
there's
any
other
thoughts
comments
about
one
115
other
things
that
maybe
didn't
you
know,
we
didn't
have
enough
time
to
discuss
it
meeting
and
then
I
don't
know
if
we
generally,
if
there's
nothing
else,
we
ended
earlier.
There's
other
things
we
talk
about,
but
yeah
I
figured
it'd
open
up
first,
so.
D
Let's
break
into
I
think
we
can
I
think
we
have
time
to
to
look
at
the
parking
lot.
I
think
we
have
time
to
maybe
chat
about
some
of
the
action
items
and
I'm
just
checking
if
there
are
any.
So
there
is
one
item
on
the
like
cig
release
agenda,
but
the
item
is
also
about
cig
scalability
and
release
interactions.
I
think
that
we've
I
think
that
we've
ground
that
into
the
ground.
How
did
that
in
sky
I,
don't
know
whatever?
Okay.
A
D
C
So
the
first
one
we
have
up
is
is
quarterly
too
fast
to
release
crannies,
so
I
know
that
there's
some
like
side
discussion,
even
when
I
was
at
KU
bukan.
This
was
brought
up
looking
into
an
LCS
model,
but
yeah
I
think
we
were
talking
about
it
pretty
early
on
in
the
retro
last
time.
I
remember
the
specific
item,
but
yeah.
We
one
else
have
more
thoughts
on
that.
This.
E
One
came
up
around
some
of
the
comments
about
the
dates
being
difficult
being
right
after
coop,
con
and
I
think
it
was
Christoph
who
had
mentioned
the.
It
felt
weird
that
we
were
bound
by
like
a
desire
to
be
quarterly
in
our
release,
as
if
it
meant
like
the
project
too
fast,
for
features
to
keep
up
or
for
like
reviewers,
to
keep
up
reviewing
things.
So
they
could
land
in
the
release.
C
C
I
I
think
mostly
that
the
previous
that
the
six
which
complaining
about
this
perennial
II
should
do
a
better
job
scaling
their
reviewers
and
approvers.
I
I
I
I
can't
I
cannot
personally
understand
the
assertion
that
a
quarterly
release
schedule
is
too
quick,
especially
when
you
look
at
other
projects
of
similar
scope
or
import
that
are
able
to
release
the
you
know
a
factor
of
two
to
four
times
more
quickly.
I,
just
think
that
we're
you
know
we're
just
not
doing
ours
are
so
a
particularly
good
job
scaling
scaling.
I
You
know,
review
and
approval
out
of
the
SIG's
and
I.
Don't
want
to
put
back
pressure
on
the
release
cadence,
because
that
seems
to
only
force
more
things
in
at
the
last
moment,
I
mean
every
time
we
move
the
release
that
things
just
keep
like
that
is
flowing
I,
don't
imagine
there
is
a
length
of
time
we
could
find
that
would
not
cause
the
same.
The
same
failure
modes
being.
D
D
This
is
a
volunteer
effort
right.
This
is
volunteer
effort
of
people.
Every
cycle
like
how
do
you
plan
to
put
a
like
a
program
in
place
to
make
that
happen
more
frequently
or
less
frequently
right,
given
what
we
already
have
today?
Do
we
run
a
release?
Team
for
six
months,
I,
don't
think
that
that's
something
that's
feasible
right,
so
you
know
so
you
know
my
intending
to
entirely
be
fair
to
the
release
team.
You
know
one
of
the
questions
becomes
like
okay.
Well,
where
is
the
line
like
and
like?
D
How
do
we
establish
boundaries
around
the
release
seem
to
prep
protect
these
people
to
protect
their
time
right.
So
you
know,
one
of
the
things
is
like
we
frequently
get
the
the
oh
hey,
enhancements,
fries
or
features
fries
or
whatever
you
want
to
call
it.
We,
you
know
we
want
to
push
that
a
can
like.
Oh
can
we
get
a
few
extra
days
like
no,
you
can't
like
that.
D
No,
like
we
set
a
date,
you
knew
about
the
date
we
have
published
the
date
right
adhere
to
the
date
right,
because
that
one
that
allows
us
to
know
what
you
plan
to
release.
Okay.
That
gives
us
time
to
prepare
themes
for
the
release
instead
of
what
we
do.
Every
cycle
scramble
at
the
end
of
the
cycle
have
release
notes,
release,
notes
and
communications,
pour
through
release,
notes
and
try
to
like
decipher
what
the
theme
of
the
release
is.
Instead
of
having
a
cig
say:
hey,
these
are
the
caps
that
we
delivered
right.
D
These
are
the
gaps
that
we've
merged
as
implements
all
these
are
the
things
that
we
plan
to
work
on
in
this
cycle
feel
free
to
you
know,
feel
free
to
develop
your
themes
based
on
that
stuff.
If
things
drop,
then
they
drop,
but
guess
what
once
enhancements
freeze
locks
then
we
should
have
an
idea
of
what's
going
on
for
the
cycle
right
and
then
you
take
code,
freeze
or
code,
slash
or
code
thaw
and
all
that
stuff
right.
Can
we
push
this
thing
a
day?
Oh
this
thing
is
happening.
D
We
have
to
push
it,
you
know
like.
Can
we
do
it
a
week
later
or
something
like
that,
like?
No,
you
can't
great
again.
The
date
was
set
great,
the
second
you
push
that
out.
That
means
you
take.
You
take
30
to
40
people's
time
out
of
the
equation
and
say
like
yes,
you
will
be
waiting
on
this
thing
longer
and
I.
Don't
think.
That's
that's
fair
to
the
release
team,
so
I
care
about
the
release.
Team
first
and
foremost,
I,
think
that
having
deadlines
in
place
is
a
good
thing.
D
I
think
that
until
we
get
to
the
point
where
we
are
actively
meeting
the
standards
or
that
we've
written
down
at
least
and
and
hitting
those
deadlines
and
putting
things
in
place
to
protect
people
in
all
SIG's,
like
we
shouldn't
even
be
talking
about
what
the
release
timeline
looks
like
what
the
release
cadence
is
great
like
we're
not
there.
Yet
we
have
dashboards
that
are
full
of
little
red
marks
right
now,
like
we're
not
even
close
yeah.
D
Mean
there's
also
the
whole
you
know.
Even
so,
there
is
so
I
put
out
a
poll
on
Twitter.
Just
because
I
was
curious,
I
was
okay,
we
cut
the
RC,
we
cut
the
RC
for
kubernetes
1:15,
who
even
knows
we
had
our
C's,
who
knew
we
had
betas,
who
knew
we
had
alphas
and
people
are
like
right
so
like
if
there
was
an
opportunity
for
people
to
consume
some
of
this
stuff
sooner
right,
I
think
there
is
an
opportunity
we
just
need
to
like
put
the
tooling
in
place
to
allow
that
right.
G
H
Part
of
it,
the
other
part
of
it,
is
that
we
need
to.
We
need
to
change
the
project.
So
the
added
to
the
attitude
in
the
reality
is
tests
are
passing
all
the
time
unless
something
seriously
wrong
yep,
because
the
fact
is,
if
we
were
pushing
a
weekly
alpha
right
now,
you
couldn't
install
it
half
the
time
because
it
would
be
broken.
D
Another
one
of
the
conversations
that
was
on
Twitter
is
like
talking
about
LTS
straight,
and
it's
like
we're.
Having
this
conversation,
I
was
like.
We
have
an
entire
working
group
on
it
right,
but
I
think
that
you
know
the
people
who
most
often
request
this
or
scream
at
the
cloud
at
us
are
not
the
people
who
are
involved
in
the
project
right
so
like.
If
you
were
interested
in
making
an
LTS
happen,
come
to
the
meetings
show
up
right.
D
The
tools
takes
fix,
see
I
signal,
fixed
s,
infra
go
crazy
right,
but
you
know
like
this
is
again
it's
a
volunteer
army
right.
So
the
people
who
are
here
are
the
people
I
respect
because
they're
doing
the
job
right
and-
and
you
know
like
we
have
companies
for
LTS,
like
the
entire
companies
built
around
support
policies
and
building
engineers,
staffing
engineering
and
product,
and
support
people
to
make
that
happen
as
a
product
right.
We
are
a
project,
okay,
so
that's
something
to
consider
as
well
like.
C
G
I
would
just
to
just
attack
on
quickly
here.
I
think
you
know
the
the
other
side
is.
You
could
probably
attribute
a
lot
of
the
success
of
kubernetes
to
the
three-month
release
timeframe.
So
the
fact
that
we
are
getting
code
in
so
quickly
and
getting
it
out
for
people
to
use
so
quickly,
nobody
ever
kind
of
bothers
to
talk
about
that.
As
being
why
you
know
why
the
project
is
so
successful,
so
yeah
I,
don't
know
I
feel
like
it's.
G
Somebody
said
it
in
jest
really
to
say:
hey
I'm
not
going
to
do
these
reviews
in
time.
Why
is
it
like
this?
But
really
the
the
root
of
the
problem
is:
there's
not
enough
people
doing
reviews
if
you
space
the
thing
out
to
be
a
year,
there's
going
to
be
more
reviews
and
you're
going
to
come
down
to
the
last
week
anyway,
yeah.
E
G
Probably
actually
easier
on
them
right
now
than
it
would
be
if
we
said
to
hey
we're
going
to
show
up
a
week
before
and
it
releases
a
year's
worth
of
changes
and
you've
got
to
review
them
the
week
before
Christmas
with
a
week
before
New
Year,
they're
going
to
say
the
same
thing.
Well,
why
is
the
release
every
year?
Why
can't
it
be
every
two
years,
I.
I
Can
say
that
at
the
current
scale
that
if
the
releases
were
a
year
there
there
are
most
of
the
commercial
products
would
stop
who
they
would
cease
to
exist
to
give
in,
given
the
current
level
of
angst
of
the
operate
people
responsible
for
operating
kubernetes
and
qualifying
kubernetes
the
project
into
the
commercial
product,
there's
just
there's
no
way.
Yeah.
G
C
E
G
D
D
C
C
So
that's
a
good
thing,
but
we
have
five
minutes
left.
We
kind
of
already
talked
a
lot
about
the
six
scalability
and
I
know
there'll
be
another
meeting,
perhaps
on
this.
But
the
last
parking
lot
item
that
I'll
bring
up
is
discuss
our
CSS
release,
walkers,
so
I
guess
it's
kind
of
related,
but
yeah
I
forget
and
what
context
this
came
up
to
try
to
look.
But
someone
wants
to
kick
this
off
yeah.
C
C
D
Wondering
if
this
plays
into
the
like,
what
does
it
mean
to
be
alpha?
What
does
it
mean
to
be
beta?
What
does
it
mean
to
be
an
RC
like
if
the
RC
is
expected
to
be
of
a
certain
quality,
then?
Can
we
say
that
our
our
c-level
week
and
we're
close
to
being
able
to
cut
like
we
should
be
able
to
say
that
right,
but
again,
I,
don't
I
I,
don't
know
what
the
specific
context
is
for
this.
We
do
want
to
make
it
easier
for
people
consumed
in
general
right.
D
A
D
H
How
it's
supposed
to
work
right?
The
idea
of
an
alpha
feature
is
not
only
you
know,
you
might
change
it,
you
might
decide
to
cancel
it
entirely.
I
would
I
haven't
done
overall
stacks,
but
based
on
deprecation
notices,
I've
read,
I
think
we
kill
off
a
third
of
our
alpha
features
before
they
ever
reach.
Beta
nice.
D
Nice,
that's
awesome,
that's
I
mean
sit,
but
you
know
my
you
know
my
question.
There
is
who
who
decides
that
right
who's
the
the
populace
that
are
actually
playing
with
this
alpha
right?
If,
if
we're
saying
that
you
know
I
like
I,
can
like
I
can
guarantee
you
that
this
was
company
policy
right
that
you
know
they
said
we're
not
doing
it
right.
So
it's
the
people
who
are
trusted
to
be
service
providers
for
kubernetes
or
not
doing
it,
then,
who
is
doing
it
right?
Who
is
playing
with
the
Alpha
feature
right?
D
And
then
you
extend
that
further
to
when
people
and
I
I
often
hear
when
we
cut
a
dot
zero
people
are
like.
Okay,
winds,
winds,
ones,
15.1
coming
out
once
one
15.1
coming
out
right:
they
don't
want
to
touch
the
dot
zero
right.
It's
a
it's
a
thing
like
I.
Don't
want
to
be
the
first
person
who
touches
this
I
prefer
to
wait
for
the
bug
fixes
right.
So
we
have
to
push.
You
know
we
have
to
push
the
the
point
at
which
you
get
to
touch
it
too.
C
D
Yeah
sig
p.m.
hat
on
weekend,
we
can
do
a
survey
or
something
about
that,
but
from
from
the
poll,
I
was
actually
surprised
at
the
amount
of
responses
for
follower
count
or
whatever,
but
there
are
about
a
hundred
people
who
responded
and
and
fifty
five
percent
of
them
said
they
had
no
idea.
These
things
existed
right.
So
it's
not
just
it's
not
just
a
usage
thing
that
we're
tracking
we're
also
maybe
there's
a
lack
of
communication
around
there's.
A
lack
of
findability.
H
F
H
C
D
I
can
I
can
save
for
sure
if
you
were,
if
your
person,
who
is
expecting
to
consume
Deb's
or
rpms
for
some,
you
know
some
beta
version
of
kubernetes
right,
the
I
don't
know
the
the
the
Knightley's
or
the
unstable
channels
like
we
don't
have
that
he
wouldn't
even
be
able
to
do
it
today.
Right
so
like
you,
it
would
be
a
matter
of
finding
the
terrible
and
again
Josh
is
absolutely
right.
It's
it's
a
findability
thing.
C
I
can
do
it.
I
can
do
a
test
because
I've
never
done
it
before
so
I
can
do
a
test
and
see
how
long
it
takes
me
and
let
you
guys
know
my
name
s
last
word
but
anyway
we're
at
time
now.
So
any
final
thoughts
before
we
close
out
the
meeting
all
right
thanks
everyone
for
joining
in
I'm
gonna
try
to
clean
up
some
of
the
actions.