►
From YouTube: Kubernetes 1.14 - Week 8 - Burndown 2019-03-01
Description
A
C
C
B
B
B
B
D
D
A
A
A
A
A
Feel,
like
I've,
been
giving
the
kubernetes
community
meeting
the
benefit
of
all
of
my
cat
t-shirts.
So
I
don't
know
how
many
of
you
attend
them
regularly.
I
try
to
do
a
new
cat
t-shirt
every
week,
because
somebody
mocked
my
my
I
need
coffee
right
now
t-shirt
at
the
very
first
week.
It
was
like
alright
I'll
see
your
cat
t-shirt
joke
so
today,
I
am
screaming
internally,
because
I'm
so
excited
it's
burned
down
it's
great.
This
was
last
week's
cat
t-shirt.
A
E
A
See
I
should
probably
tell
everybody
as
wait
for
things.
Let's
see,
let's
wait
for
people
to
roll
in
a
little
bit
more,
but
I'm
getting
really
lazy
about
trimming
and
editing
and
stuff,
so
I
apologize.
If
you
show
up
here,
realize
that
you
may
for
a
little
bit
until
I
remembered
you
trim
videos
just
like
be
on
camera,
looking
around
or
typing
in
your
keyboard
or
whatever
for
a
little
bit.
A
So,
okay
posted
a
link
to
the
meeting
notes
in
the
chat.
If
you
want
to
go
ahead
and
add
your
name
to
the
attendees
thing
as
usual:
I'm
kind
of
liking,
the
pattern
of
having
everybody
do
their
thing
and
I
clean
up
at
the
end.
So
we're
going
to
do
that
before
we
do
that
now
that
we
have
a
couple
more
people
here.
Thank
you
very
much
for
taking
notes.
Mike
I
would
like
to
welcome
everybody
to
Friday
March,
the
1st
third
month
of
the
kubernetes
114
release
cycle
last
state.
A
F
Eleven
of
these
enhancements
are
right
now
marked
at
risk,
because
they're
missing
test
plans
from
cuts.
That's
for
less
than
Wednesday
of
those
11
I
would
say.
The
majority
have
folks
who
are
actively
engaging
with
either
myself
or
PRI
into
the
cut
those
house
plans.
There's
only
three
that
I
would
say
are
probably
super
at
risk,
because
there's
been
no
response
from
an
on
release
team
member
in
15
plus
days
when
we
asked
them
for
either
caps
and
I've,
known
as
like.
F
A
I
mean
other
like
issue
triage
and
CI
signal.
Folks
can
speak
from
their
past
experience,
but
at
this
point,
as
we
start
to
see
a
lot
of
notification,
noise
on
github
for
many
people,
such
as
myself,
github
notifications
are
effectively
useless,
even
if
I
am
trying
to
just
follow
one
or
two
issues
and
so
reaching
out
to
people
out
of
fan
and
other
mediums,
be
that
in
the
sig
slack
channel
stocking
and
down
and
slack
and
talking
to
them
via
DM
emailing
them.
A
A
F
A
G
A
Any
questions
for
Silvia,
okay,
yeah
those
feel
like
there's
a
lot
of
red
out
there.
I'm
super
excited
we
finally
got
differece
or
psa's
fixed.
That
was
little
I
made
an
entire
slide
just
for
that
yesterday,
the
con
meme
for
that
one,
but
it
does
look
like
we
still
have
a
lot
of
flakes
and
it's
kind
of
unclear
which
tests
are
the
main
culprits
for
these
flakes.
So
even
though
we
fixed
that
the
job
still
seems
like
it's
mostly
red,
so
it's
just
yeah.
A
A
H
A
E
Sure
so
I
guess
we
get
merged
about
46
beers
in
KK
in
the
last
two
days,
which
is
okay
not
as
epic
as
last
time
but
sure,
and
then
we
are
also
trying
to
update
to
go
112.
We
updated
it
once
and
we
found
that
there
are
ghovat
failures
which
have
since
been
resolved.
I
believe
that
I
think
there's
a
PR
out
to
resolve
the
cube.
Idiom
go
ahead,
fillers
and
once
that
PR
is
in,
we
will
try
to
go.
I
have
another
go
at
it
and
that's
pretty
much.
A
Okay,
I
think
Lumiere
went
ahead
and
PR
most
of
his
suggestions
regarding
Cape
ADM,
so
Lumiere
I'm
gonna
go
double-check
that
all
that
stuff
looks
good,
especially
in
the
context
of
making
sure
we
got
the
same
set
of
jobs
across
all
the
branches.
It
looks
like
you
hit
all
the
appropriate
release
rates,
just
a
few
changes.
So
thank
you
for
that
and
for
four
contacts
to
the
NGO
112
stuff,
like
they
all
made
a
liar
out
of
me.
A
I
literally
said
in
the
meeting
that's
yesterday
or
in
Wednesday
that
yeah,
you
know
what
maybe
we
shouldn't
do
this
and
then
I
said.
Definitely
we're
not
going
to
do
it
yesterday
during
the
community
meeting
and
now
we're
doing
it,
because
it
turns
out
one
for
support,
ability
and
compatibility
reasons.
It's
way
more
worth
our
while
to
have
because
of
the
support
windows
of
kubernetes
and
go
and
the
way
that
they
are
staggered.
If
we
don't
get
kubernetes
114
on
golang
112,
we
will
eventually
end
up
in
a
situation
with
kubernetes.
A
114
is
built
with
a
version
of
going.
That
is
unsupported.
This
is
the
situation
that
we
find
ourselves
in
right
now
for
kubernetes,
111
and
112,
and
trying
to
figure
out
what
to
do
about
that.
The
second
reason
is:
there's
this
great
scalability
problem
that
it's
kind
of
wondering
how
we
could
more
effectively
test
this
in
the
future.
A
I
Sure
I'll
keep
this
pretty
short
and
sweet.
Today's
the
deadline
to
have
a
placeholder
PR,
looking
high-level,
looks
like
we're
missing
about
half
the
documentation,
but
I
don't
think
it's
worth
raising
any.
You
know
red
flags
or
alarms,
and
so
we
have
a
very
clear
picture
of
exactly.
What's
there
what's
missing,
so
live
a
clear
picture
on
Monday.
A
J
About
released
its
today,
yeah
sure,
so
the
latest
draft
there
is
PR
for
that.
That
was
submitted
yesterday
other
things,
so
we
met
last
week
in
consensus
on
the
changes
that
we
need
to
make
to
release
notes
for
1.14
and
we're
also
aware
of
dependencies
that
need
to
be
brought
in
as
much
a
manual
process
right
now.
So
we'll
also
take
a
look
of
if
any
of
that
came
and
be
automated,
but
it
is
on
our
radar
to
make
sure
those
are
brought
in.
A
That
kind
of
reminded
me
that
hey
do
we
even
keep
track
of
external
dependencies
and
so
right
now
it's
kind
of
in
release,
notes
playbook
to
notice
that,
like
we
should
at
least
have
a
step
to
manually,
keep
track
of
what
version
all
of
our
dependencies
are
at,
but
I,
don't
think
we
really
have
anything.
At
least
I
haven't
been
able
to
find
anything
in
my
spelunking,
but
I'm
not
the
best
at
Google,
though
I
do
work
here
but
like
when?
A
A
My
sense
is,
you
know
it's
pretty
clear
with
going,
for
example,
that
like
because
it
has
potential
performance
implications,
it's
something
that
needs
to
be
done
respectfully
in
the
con
texts
of
coke
fries,
probably
the
same
thing
in
in
terms
of
like
container
engine
versions.
Things
like
that
bumping
versions
of
the
sundry
add-ons
and
plugins
that
we
use
there's
a
little
bit
less
clear
to
me.
It
may
feel
to
some
people,
like
you
know
what
that's
just
a
Doc's
update,
no
big
deal
and
off
the
top
of
my
head.
I.
K
A
A
M
So
I
have
I
have
one
question
in
the
past:
under
the
external
dependencies
really
part
of
the
release
notes,
we
would
even
like
list
off
fluent
e
elasticsearch
cluster
add-on
changes
and
to
me
that's
not
an
external
dependency
of
kubernetes,
that's
something
that
is
an
add-on
to
kubernetes
that
we're
just
bumping
the
version
of
I'm.
I
don't
really
have
an
answer,
I'm
just
more
bringing
that
up
and
saying
that's
kind
of
weird
I.
Think.
L
The
way
we
differentiate
what's
an
external
dependencies
is
like
things
that
we
push
into
the
kubernetes
google
container
registry
or
something
like
in
some
way
we're
distributing
these
binaries
as
a
part
of
the
kubernetes
release
and
with
the
go
tooling,
we
don't
have
to
enumerate
those,
because
those
are
all
like
manage
with
go
depths,
but
with
the
extra
there's
just
some
containers
that
we
distribute
and
those
are
in
random,
manifests
and
and
I.
Think
that's
why
we
have
to
keep
them
in
there.
If
I
recall
correctly,.
D
During
the
working
group
IDs
stop,
there
was
a
discussion
on
when
the
run
CEC
we
came
out.
It
was
a
discussion
on
how
do
we
deal
with
the
external
dependencies
and
there
were
a
lot
of
opinions
shared
there,
but
no
consensus,
but
it's
a
discussion
worth
looking
at
and
something
that
the
working
group
was
also
thinking
of
taking
up
as
okay.
We
need
to
probably
think
about
this.
A
Yeah,
so
all
that
say
that
it's
like
okay,
it's
a
big
ugly
messy
thing
and
that's
not
what
I'm
asking
release
nits
to
solve
just
find
a
way
of
keeping
track
of
what
we
have
kept
track
of
before
and
talking
about
it
early
and
often
will
probably
help
us
avoid
surprises
and
we'll
just
have
to
accept
that
we're
kind
of
making
it
up
as
we
go
along.
Maybe
we
can
do
ourselves
some
favors
by
documenting
what
it
is
we're
making
up.
A
C
I
know
that
we
are
working
through
different
topics
for
the
blog
in
different
call
outs
that
we'll
be
working
and
looking
at
in
terms
of
features.
We're
still
kind
of
working
through
that
now,
definitely
with
all
of
the
all
the
caps
and
everything
that
are
coming
through
and
I'm
waiting
for
those
to
solidify
and
then
after
that's
done,
then
we'll
have
a
better
idea
of
what
we
want
to
call
out.
We
have
we've
some
some
base.
Ideas
in
that
front.
I
can
throw
that
documents
in
there
for
visibility
as
well,
be
awesome
like
what's.
E
N
C
A
O
Happened
this
time,
so
nothing
really
I
just
have
to
just
for
informations.
We
are
cutting
the
next
thing,
the
pizza
to
next
Tuesday,
and
you
might
have
seen
the
conversations
in
the
Zig
release
slack
channel.
Currently,
the
publishing
part
does
not
publish
release
113
things
into
the
external
repos,
but
people
are
working
on
that.
So
I
assume
it's
gonna
be
resolved
soonish.
But
just
if
people
ask
you
regarding
that,
that's
pretty
much
it
any
questions.
I.
A
O
K
A
F
A
That
makes
me
feel
extra
special
good
about
using
kind
that
as
part
of
our
release
process,
it
seems
like
it's
a
more
reliable
way,
catching
anything
weird
related
to
cube
ATM
and
it
doesn't
necessarily
expose
any
weird
behaviors
we
might
be
seeing
from
a
cloud
providers
perspective,
that's
cool,
there's,
no
right
or
wrong
answer
to
that.
You
notice
I
didn't
raise
my
hand,
I
feel
not
the
best
about
that,
but
that's
just
sort
of
the
reality
of
my
day-to-day
right
now.
So
thank
you
lucky
for
making
sure
being
the
guinea
pig
for
hottest.