►
From YouTube: Kubernetes 1.13 Release Team Meeting 20181008
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
Okay,
I'm,
beginning
to
record
right
now,
hello.
Everyone
welcome
to
the
second
meeting
of
113
release.
I'm
your
release
lead
and
for
those
of
you,
you
just
join.
If
you
haven't
added
your
name
onto
that
Lee's
list,
please
do
so
and
as
always,
this
meeting
is
being
recorded
and
will
end
up
in
YouTube.
So
please
be
mindful
of
what
you
say:
let's
started,
let's
get
started
here:
I
have
a
few
general
updates,
but
I'll
keep
it
till
the
end,
because
we
do
seem
to
have
quite
a
bit
of
agenda
already
up
there.
A
B
Everybody
been
getting
the
flurry
of
emails
this
morning.
It's
been
annoying
yet
so
yeah.
So
that's
that's
sort
of
what's
happened.
So
all
a
hundred
and
twenty
something
open
issues
got
pinged
over
the
past
week.
Thank
you
to
a
few
of
the
shadows,
who
stepped
up
and
really
kind
of,
took
it
upon
themselves.
B
We
got
a
few
of
those
that
are
still
kind
of
lagging
behind,
but
we'll
get
that
taken
care
of
in
due
time
as
of
today
and
actually
as
of
about
10
seconds
ago,
as
I
updated
this
we
had
one
more
added,
so
we've
got
38
features
enhancements.
I'm
gonna,
keep
catching
myself
saying
that
38
enhancements
that
have
been
added
to
the
dock
for
113.
B
Now,
as
I
pointed
out
here,
there's
four
of
them
that
are
being
untracked,
and
this
is
because
I'm
sort
of
in
a
in
a
bind
whether
there
really
should
be
tracked
or
not-
and
these
are
all
related
to
Steven.
Augustus-
is
sort
of
over
kept
process,
so
whether
they
should
really
be
tracked
because
are
they
really
enhancements
to
kubernetes
or
they
enhancements
to
a
process?
And
so
that's
why
I'm
kind
of
looking
at
it?
B
A
B
A
We
is
Stephen
on
the
call
today,
don't
think
so.
I
can
follow
up
flying
with
them
about
the
first
Kendrick
and
my
inclination
is
to
not
have
them
there
if
they
are
not
really
contributing
to
the
code
itself
in
113,
but
we
can,
if
there
must
be
some
reason
why
he
wanted
it
to
be
there
versus
tracking
them
separately.
So
we
can
follow
up
and
close
out
on
those
okay.
B
D
B
Aren't
necessarily
in
the
features
repo,
so
I
actually
had
not
looked
or
added
those,
so
I
would
kind
of
just
look
to
some
guidance
and
see
what
everybody
else
here.
Sort
of
thinks
is
the
proper
way
to
go
about
this.
Do
we
tell
them
or
should
I,
go
ahead
and
open
a
feature
or
sorry
enhancement,
issue
for
them
and
start
copying
them
in
and
making
sure
they
are
tracked.
A
So
for
some
context,
these
actually
came
up
from
the
bug
triage
handbook,
so
they
were.
There
was
a
few
queries
that
were
pulling
these
in
and
when
I
looked
into
that,
they
were
all
like
featured
there,
Marcus
kind
feature.
So
that's
where
the
confusion
was.
Should
this
be
more
like
an
enhancement
person
tracking
it
versus
like
the
back
triage
me
talking
it
tracking
it
and
when
I
spoke
to
Nico
looks
like
he
was
not
actively
tracking
these
because
they
had
the
feature
label
on
it.
A
E
F
G
E
E
A
Brings
another
point
also
the
ones
that
were
called
trying
clean
up
again.
I
just
want
to
make
sure
that
our
is
that
being
tracked
as
a
feature,
or
should
that
again
come
under
buck
triage,
which
is
the
next
that
actually
catches
these
and
tracks.
These
I
know
@cd.
We
wanted
to
call
it
a
cleanup,
but
we
also
opened
like
a
feature
issue
for
that,
so
so
that
was
more
of
I'm,
fine
like
not
putting
it
the
feature
table,
but
I
just
wanted
to
make
sure
that
it
comes
into
someone's
radar
I.
B
A
A
B
It
sounds
good
I'll
go
ahead
and
just
keep
going
down
the
agenda
since
I
know
we
have
some
things
to
hit
so
I
should
I
have
been
sort
of
splitting
the
workload
and
hitting
every
single
sig
meeting
we
possibly
can
to
just
kind
of
give
them
an
update
of
one
to
say
hello,
introduce
ourselves
as
who
we
are
again
to
also
give
them
an
update.
This
is
the
expectations
of
what
113
is
gonna,
be
a
little
more
stable
release.
B
Let's
try
to
stay
away
from
massive
alpha
features
that
could
break
things
because
of
the
aggressive
timeline.
That's
sort
of
just
been
the
the
message
that
we've
been
putting
in
there
I've
been
pretty
well
received.
There's
a
course
there's
a
few
things.
We'd
always
bring
up
the
the
features
repo
with
that
that
particular
cig
and
see.
If
there's
anything
that
could
be
outstanding.
However,
I
think
everything's,
probably
on
a
pretty
good
track
right
now,
for
what
people
had
said
that
they
want
to
commit
versus.
B
When
we
had
said
this,
they
said:
okay,
well,
I,
guess,
there's
some
things.
We
should
probably
back
out
one
of
the
ones
that
stood
out.
In
my
mind
was
the
out
of
tree
cloud
provider.
They
were
sort
of
really
thinking
well,
I,
don't
know
if
we'll
actually
make
it
this
time,
so
they
are
gonna,
probably
talk
about
a
little
bit
more,
but
probably
look
in
that
is
being
deferred
to
114.
A
Yeah,
we
kind
of
mostly
prioritize
the
six
that
had
some
features
falling
from
12113,
so
those
were
the
ones
we
were
going
off
first,
but
I
can
put
a
list
together,
yeah
and
yeah.
The
couple
of
things
that
kind
of
worried
me
is
like
the
cold
ian
is
they
are
trying
to
make
that
default,
this
still
in
113,
and
then
the
paint
node
stuff
they
are
still
trying
to
land
it
in
113.
So
those
two
things
I've
asked
them
to
have
requested
them
to
learn
things
by
end
of
October
if
possible.
A
B
Yeah,
and
so
there
were
some
questions
that
came
up
in
these
meetings
more
or
less
around
organization
and
how
things
are
tagged,
and
we
had
a
conversation
with
Stephen
to
kind
of
get
his
idea
about
this,
because
we
were
a
little
bit
well,
a
we
didn't
really
know.
Oh,
we
need
to
actually
close
out
the
past
milestone,
so
we've
got
to
get
things
out
of
that
milestone
and
remove
them
to
a
next
one,
so
we
can
actually
close
it
out.
B
B
So
we
found
that
the
track
labels
do
serve
a
purpose,
so
they
are
there
for
as
of
about
30
minutes
ago.
Every
one
of
the
features
should
have
a
tract
yes
or
tract
no
label.
So
if
it's
tracked,
yes,
that
it
is,
that
means
it
is
in
the
tracking
sheet
track.
No,
of
course,
means
it's
not
in
there.
So
that's
sort
of
what
we
came
away
from
that
I
should
teach
you
everything
to
follow
up
on
that
as
well.
A
Yeah
the
make
the
bigger
question
that
some
six
were
expecting
guidance
around
was
ok
if
feature
is
staying
in
the
same
stage.
This
milestone,
for
example,
if
I
graduated
to
beta
and
if
it
continues
to
stay
in
beta,
do
we
remove
the
milestone
or
or
should
we
just
retain,
like
the
previous
cycles,
milestone?
What
is
the
process
around
it?
So
when
can
recognize
poke
we
and
with
Steven
it
looks
like
we
removed
the
milestone.
We
said
we
clear
the
milestone
so
that
they
can
attribute
it
to
a
future
milestone
whenever
it's
graduating
so
Kendrick.
A
B
That's
good
question
I'm,
not
too
sure
to
be
honest
with
you.
Okay,.
A
We
can
dig
that
up
and
unless
anybody
on
the
call
knows
where-
which
is
a
good
place,
to
put
this
information
but
yeah
that
that
state
Automator
is
worth
it
almost
exam
missing.
At
this
point
at
least
it
came
up
with
a
couple
of
sites.
So
if,
if
it's
possible,
we
should
clear
it
up
so
that
we
have
like
a
process.
There
are
multiple
ways
to
do
this,
and
we
should
just
pick
one
at
least
for
the
short
term,
so
that
the
other,
the
future
releases
can
update
it
as
they
see
fit.
E
I,
don't
have
anything
concrete
here,
other
than
to
say
that
I
feel
like
continuing
in
the
vein
of
stabilization.
It
would
be
a
good
idea
if
we
involved
somebody
from
saying
architecture
earlier
on
in
the
process.
So
I
was
thinking
of
having
a
run-through
of
what
the
features
list
looks
like
prior
to
feature
freeze
to
give
side
architecture
a
chance
to
have
some
input
there,
and
then
we
could
potentially
have
another
review
prior
to
entering
code
freeze
to
have
more
of
an
idea
of
like
given
where
we
are
right
now.
E
A
H
Howdy
so
I,
just
so
people
know
this
week,
I'm
mister,
producing
CI
signal
reports
on
Tuesdays,
so
you'll
see
that
tomorrow
we
have.
We
have
what
looks
like
a
whole
bunch
of
failing
tests,
but
it's
actually
not
it's
the
same
test
failures
being
played
out
across
multiple
tests,
the
so
there's
a
couple
of
things.
One
is
a
whole
bunch
of
upgrade.
Tests
are
failing
for
for
different
reasons.
Number
one
is
we
have
to
upgrade
tests
that
kind
of
lack
ownership?
D
H
H
So
that's
that's
honestly.
That
demon
set
issue
is
the
rest
of
the
upgrade
failures.
We
have
a
couple
of
recent
test
failures
that
we
don't
know
if
they're
significant,
yet
I
such
as
I
VMware
conformance
tests
just
failed.
We
don't
really
actually
understand
that
test.
It's
relatively
new.
We
have
a
bunch
of
new
conformance
tests
in
the
blocking
suite,
which
is
a
good
thing.
H
E
A
little
vaguely
unclear
on
how
conformance
tests
got
added
in
to
release
master
blocking
for
what
it's
worth.
Okay,
could
you
maybe
sync
up
with
me
offline
I'd
like
to
see
the
issues
it
showed
this
getting
added
and
the
discussion
that
went
back
and
forth
on
that
because
I
am
I,
do
believe
in
where's
conformance
test
to
be
like
yeah
there's
submitting
results,
but
from
a
couple:
different
environments:
okay,.
H
So
it'd
be
nice
to
do
that.
Gce
scale
performance
is
flaking.
This
is
not
a
new
thing,
but
we
do
need
to
follow
up
with
six
scalability
to
see
if
the
flakiness
means
anything
via
I
do
notice.
That
was
removed.
That
particular
test
was
removed
from
112
blocking
during
blocking
which,
which
makes
me
think
that
flaking
was
pretty
serious
towards
the
close
of
1:12
and
then
tests
infra
is
actually
in
the
process
of
sort
of
reconciling
the
canonical
list
of
blocking
tests
for
release.
H
H
Right
now,
I'm
looking
at
master
blocking
because
one
thing
I
did
go
as
I
went
through
the
list
of
to
see
if
there
were
any
tests
and
went
well
blocking
that
there
wasn't
an
equivalent
for
in
master
blocking
yeah,
and
the
only
thing
I
could
really
find
was
the
one
eleven
on
one
twelve
four
cubed
min,
but
there
currently
isn't
any
equivalent
of
that
for
master.
That
I
can
look
at
as
far
as
I
know.
Okay,.
A
A
E
C
E
H
E
Going
to
be
clear,
josh
is
looking
at
release
master
blocking
as
CI
signal
guy
to
make
sure
that's
the
health
of
the
release,
but
that,
in
terms
of
reconciling
the
list
of
blocking
tests
to
make
sure
they're
the
same
and
consistent
everywhere,
we're
starting
with
released
one
twelve
locking
is
the
authoritative
source
and
comparing
that
to
all
the
release,
one
dot,
Y
blocking
dashboards
and
then
once
those
all
look
good
will
then
make
sure
that
that
lines
up
with
release
master
blocking.
That's.
E
H
H
I
Hello,
so
first
week
was
I
automated
the
tracking
sheets,
which
can
be
found,
which
is
basically
I,
made
Google
sheets
to
to
pass
the
links.
That's
half
certainly
and
milestone
130,
and
then
the
additional
fields
are
regex,
picking
up
title
and
six
etc
and
I
wonder
if
this
can
be
used
for
other
release,
themes
or
generally.
A
A
A
A
And
this
one
would
really
help
for
us
to
know
if
any
labels
are
missing.
So
that's
probably
a
good
idea
to
expand
it
to
the
dip
that
I
know
that
are
like
four
different
queries
at
triage:
a
spot
triage
attract
once
we
expand
that
it'll
be
good
to
know
which
issues
don't
have
their
expected
levels
and
six
and
everything.
I
A
F
Have
not
they've
always
operated
responsibly
and
sufficiently
to
be
doing
their
own
thing,
and
especially
in
the
last
cycle,
I
sort
of
viewed
that
as
a
as
an
example
of
how
the
splitting
of
the
monolith
should
work,
we're
saying
that
everybody's
gonna
be
able
to
operate
on
their
own
cadence
and
they
can
mark
and
track
the
things
that
happen
in
their
timeline.
But
I
I
do
have
worries
that
we
just
sort
of
scatter
to
the
wind
and
somehow
or
the
release
team
is
inferring.
F
E
It's
not
up
to
us
to
cut
wellmaybe
cuvee
diem
is
still
locked
in
tree
I
kind
of
I
kind
of
forget,
but
like
it's,
not
something,
we
should
be
tracking.
It's
something.
The
coop
EDM
team
should
be
tracking
as
a
downstream
consumer
of
kubernetes
release.
They
are
still,
unfortunately,
locked
in
tree.
Okay
and.
F
I
F
We
run
into
an
issue
if
nothing
else,
at
the
release,
notes
point
where
we're
trying
to
define
our
document,
which
things
were
were
used
and
tested
and
coordination
with
each
other
and
then,
as
we
do,
that
we
find
people
going.
Oh
that
thing's
revved
I
didn't
realize
that
so
I
need
to
make
this
change.
So
we
we're
having
some
late-breaking
integration
challenges
increasingly
I
feel
like
because
of
this.
F
E
For
better
for
worse
cube,
a
DM
is
not
the
thing
with
which
we
exercise
all
of
our
integrations
and
head-ons
and
features
across
all
of
the
200
cloud
providers.
And
what
not?
So
it's
no
surprise
to
me
that
cube
ATM
will
end
up
tripping
on
a
couple
cases
here
or
there.
If
there
was
increased
signal
from
them.
That
could
certainly
be
helped.
But
it's
why
we
kind
of
have
to
focus
on
just
like
one
tool
for
standing
up
clusters
as
much
as
possible,
rather
than
focusing
on
like
the
five
to
ten
different
tools.
E
G
E
G
E
A
A
J
A
E
It
was,
there
was
thinking
that
it
would
be
really
cool,
slash
convenient
if
we
could
just
auto
label
PRS
during
this
period
or
sorry
auto,
milestone
PRS
during
this
period
and
then
switch
it
over
to
a
manual
process
when
we
had
burned
out.
The
thinking
was
that
if
every
PR
belongs
to
a
milestone,
we
can
start
asking
ourselves
questions
like
how
many
pull
requests
have
been
merged
this
far
into
the
release
cycle,
and
how
does
that
compare
to
our
velocity
last
release
cycle?
E
F
A
A
So
that
the
main
reason
was
I
I
do
see
a
whole
bunch
of
yeah
I
see
a
whole
bunch
of
PR
skating
in
a
bunch
of
most
of
them.
Don't
have
the
milestone
tag
that
so
I
was
just
curious.
How
how
aggressively
should
we
be
even
looking
at
what
goes
in
right
now,
wes
is
just
you
know,
just
care
about
it
too.
It's
closer
to
code
slush.
So
that's
where
this
whole
yeah,
the
last
one
came
historically.
A
Cool
so
I'll
watch
out
for
a
beer
from
you
to
update
the
dog
stand.
Thank
you.
Alright.
That
brings
us
to
the
next
one
test.
Infra
I
know.
Last
week
we
bumped
the
coercion
to
111
and
I
do
see
a
couple
of
we
are
still
open
to
bump
Travis
and
publishing
broad
are
all
the
CI
image
is
pumped
cold.
You
know
you
have
any
updates
there.
J
Yeah,
so
basically
the
big
change
was
that
previously
we
didn't
necessarily
have
separate
versions
of
every
job
for
every
branch
if
it
was
appropriate
for
a
version
of
a
job
c'mon,
multiple
grandmother's
we
just
hold
on
as
always,
but
at
this
point
we'd
like
to
start
creating
individual
versions
for
every
branch
that
we
have
to
make
sure
that
we
can
do
updates
properly.
Without
any
problems
like
we
did.
J
So
that's
kind
of
the
main
takeaway
going
forward
with
how
we'll
be
kind
of
creating
jobs
going
forward
for
your
branches
will
always
be
creating
separate
jobs
and
sometimes
yet
reusing
existing
versions,
but
as
of
now
I
believe
then
was
taking
the
charge
of
switching
a
lot
of
the
jobs.
Number
I
think
all
the
ones
that
we,
that
would
for
sure,
be
breaking
up
and
fixed,
and
we
don't
see
any
more
failures.
If
there
are
any
more
that
are
noted,
like
notice,
we
can
fix
that,
but
I
think
we've
got
everything
taken
care
of.
A
A
A
K
We've
got
a
couple
of
open
PRS
from
the
last
recycle
main
aims
for
this
week,
just
to
make
sure
the
tracking
spreadsheet
is
up-to-date
and
that
those
old
open
PRS,
they
don't
need
any
updates
or
if
they
do
that.
It's
correctly
tracked
slowly,
reaching
out
to
enhancement
owners
this
week
to
ensure
the
accuracy
of
the
tracking
sheets
and
to
begin
pinning
pinging
them
for
the
working
progress.
Prs
and.
A
C
A
That
was
me
again.
This
came
up
in
another
sig
sync
up
that
we
had.
This
is
more
of
a
question
for
SiC
p.m.
and
the
release
team
in
general.
So
how
do
we
do
it?
My
inclination
is,
we
would
not
be
mentioning
about
out
of
tree
stuff
in
our
release,
notes,
but
just
curious
to
know
what
we've
done
this
done
in
the
past
and
I
can
follow
up
with
CPM
I.
C
A
A
C
Yeah,
so
the
pending
items
that
I
have
on
my
plate
that
I
have
to
do.
Ideally
this
week,
I'd
like
to
begin
both
of
these
things
is
I'd
like
to
set
up
a
I,
have
three
shadows,
I
think
and
I
haven't
really
met
any
of
them
face
to
face.
Yet
so
I'd
like
to
set
up
a
face-to-face
like
weekly
or
bi-weekly
meeting,
with
my
shadows,
get
that
going
and
then
I'd
like
the
main
action
item
for
me
from
last
release
that
I
really
want
to
get
started
on
his
own.
C
One
thing
that
was
really
difficult
is
that
we
would
cop
we
would
generate
the
release.
Notes.
Document
copy
edited
realized
that
we
wanted
to
make
some
sort
of
structural
changed
how
we
were
rendering
the
document
do
that
copy
over
all
the
copy
edits
and
that
kind
of
consistent
copying
a
royal
a
copy
edits
was
really
our
jewess
process.
So
I
want
to
come
up
with
some
sort
of
strategy
for
allowing
us
to
make
those
copy
edits
to
release
an
ongoing
basis.
C
Ideally,
we
would
be
able
to
just
edit
people's
PRS,
because
you
can
edit
release
knows
release
note
texts
if
we
edit
the
descriptions,
but
that
would
require,
like
an
obnoxious
level
of
github
permission.
So
I
think
it
would
be
easy
to
do
with
a
little
bit
of
tooling
so
I'm
going
to
work
on
that,
and
you
know
rendering
the
document
on
an
ongoing
basis.
A
A
A
H
A
F
Is
useful
to
read:
go
back
to
the
earlier
conversation
about
like
do
we
follow
what
PRS
are
not
closely,
but
if
you,
if
there's
things
that
Josh
or
others
in
their
sort
of
weekly
roll
up,
so
the
community
happenings
have
noted
its
handy
context
for
the
release
team
to
have
a
sense
of
where
things
are
going
just
in
the
in
the
broad.
In
this
phase.