►
From YouTube: Kubernetes 1.12 Release Team Meeting 20180724
B
A
A
All
right,
it's
two
minutes
past
the
hour
and
I
go
ahead
and
get
started,
I'm
dropping
a
link
into
the
zoom
chat.
Just
as
a
reminder
for
the
meeting
minutes.
I
see
a
couple
of
you
are
already
in
there
for
sure.
If
the
others
could
go
ahead
and
put
their
name
in
there,
just
we
can
keep
track
a
bit
of
who's
been
in
attendance.
That
would
be
useful.
A
That
was
on
the
agenda,
but
questions
so
the
the
main
three
things
that
we
have
going
on
across
these
release.
Meetings
are
looking
at
feature,
status,
test
status
and
bug
or
issue
status,
and
yesterday
we
we
briefly
went
over
test
status
and
in
the
prior
meeting,
I
had
intended
to
to
make
sure
that
we
got
a
little
bit
of
a
run-through
of
test
grid
put
on
the
agenda
and
I
forgot
about
that.
So
I'm
actually
going
to
put
that
on
the
agenda
right
now
for
next
week.
So
we
don't
forget
it.
A
But
in
the
short
term
we
have
an
issue
tracking
leader.
I
am
a
test.
Ci
signal
lead
and
their
primary
tool
is
what's
called
test
grid
or
test
grid
kate's
IO,
so
that
tool
is
sort
of
a
way
to
visualize.
What's
going
on
in
the
tests
and
we'll,
if
you
haven't
looked
at
it
yet
its
UI
is
interesting
and
sometimes
confusing.
A
So
we'll
do
a
little
bit
of
a
run-through
and,
and
the
biggest
thing
is
understanding
what
things
you
can
click
on
and
what
information
it
gives
you
and
give
a
walkthrough
of
kind
of
how
you
go
through
that
to
find
some
something
and
make
a
decision.
So
we'll
probably
have
Muhammed
do
that
next
week.
A
So
we
would
briefly
discuss
that
and
he
he
basically
gave
an
update
to
where
there's
been
a
few
things
in
failing
tests
both
for
what
we
call
the
the
release,
blocking
master
and
release
blocking
upgrade
and
he's
opened
some
issues
to
track
those
over
the
last
weeks
and
the
tests
were
mostly
failing
around
GCI
and
gke,
but
actually,
as
of
yesterday,
at
the
end
of
the
day,
things
were
actually
looking
a
bit
better,
I
would
say,
and
notably
better
than
the
prior
week.
So
testing
is
often
a
little
bit
of
a
Wiggly
wave.
A
A
The
other
thing
that
we
talked
about,
then,
was
bugs
or
issue
status
and
I
keep
trying
to
remember
to
specifically
say
bug
status
instead
of
issue
status,
because
we
bug
means
something
that
different
than
issue,
because
issue
is
a
thing
in
github
and
and
github.
We
have
issues
and
PRS
and
a
PR
could
be
implementing
a
feature
or
fixing
a
bug,
and
you
get
this
sort
of
weird
overlap,
because
the
nouns
aren't
completely
clear.
So
Guin
is
specifically
our
bug,
triage
lead
and
that
can
involve
looking
at
both
issues
and
PRS
right
now.
A
There
wasn't
much
of
anything
and
you
could
glance
through
the
notes,
if
you're
interested
from
yesterday,
but
more
than
that,
what
Gwyn
actually
did
was
look
at
features
in
the
kubernetes
/
kubernetes
repo
that
are
targeted
for
the
milestone,
because
early
in
the
release
more
than
creating
bugs
or
filing
the
PRS
to
implement
things.
People
are
starting
to
tract
what
feature
work
they
intend
to
do
so.
A
She
gave
just
a
little
bit
of
right
now,
there's
only
a
couple
of
things
in
the
kubernetes
kubernetes
repo
that
are
features
and
then,
from
there
we
hand
it
off
to
Kenny
Coleman
our
feature
shadow,
because
the
the
features
are
tracked
specifically
by
the
futures
lead
and
their
shadows,
and
this
is
a
slightly
odd
split.
So
for
folks
who
are
new,
especially
the
set
of
shadows
today
on
the
call
the
kubernetes
kubernetes
repo
isn't
where
features
work
is
tracked
from
a
planning
perspective.
There's
a
separate
repo,
called
kubernetes
features
and.
A
That
feeds
into
a
spreadsheet
and
we
got
off
into
a
fair
amount
of
discussion
about
spreadsheets,
then
so
the
features
spreadsheet
right
now,
and/or
the
kubernetes
features,
repo
or
tracking
I,
think
about
23
features
and
Steven
and
Kenny,
and
the
set
of
feature
lead
and
shadows
they've
been
reaching
out
and
pinging
folks.
Checking
in
like
is
this
thing
actually
still
on
the
schedule
for
112.
What
are
your
plans
for
testing
or
your
plans
for
documentation?
A
All
those
sorts
of
things
doing
some
initial
information
collecting
and
that's
particularly
important,
because
if
you
start
out
in
the
kubernetes
features
repo
at
the
beginning
of
the
cycle,
there's
a
whole
set
of
stuff
that
gets
labeled
for
the
current
release
and
if
you
look
through
the
actual
issues,
most
of
them
were
in
the
prior
release
and
often
on
the
reach
before
that.
So
the
release
before
that
so
there's
it
can
almost
become
sort
of
a
staging
ground
for
hoped-for
work
versus
actually
gonna
happen
work.
A
So
the
features
leads
going
out
and
really
poking
on
folks
and
asking
what
is
the
status
of
these
things
helps
drive
some
answers
there
and
then
also
that
kind
of
acts
as
a
reminder,
as
you're
talking
to
the
sigelei
to
say
what
else
is
there?
If
there's
not
just
these
things
that
are
carrying
forward
what
other
new
and
interesting
work
is
happening,
so
the
the
kubernetes
features
repo.
There
have
been
a
number
of
new
issues
opened
and
on
top
of
those,
and
that's
a
normal
for
where
we
are
right
now.
A
So
one
of
the
problems
that
we
typically
have
on
the
release
team
is
that
we're
using
github
and
whether
it's
the
debug
triage,
the
the
feature
lead
or
overall
release,
lead
CI
signal,
all
of
us
looking
at
github
to
try
to
understand
where
we
are
today.
It
only
tells
us
where
we
are
right.
Now
is
a
point
in
time.
If
one
of
you
does
it
get
hub
query
and
says:
hey
look
at
the
first
issue:
it's
really
interesting
and
I
do
a
github
it.
A
The
issue
I,
may
not
see
the
same
issue,
there's
new
things
coming
in,
depending
on
what
query
we've
done,
based
on
labels,
if
a
labels
removed,
it
may
no
longer
show
up
in
the
query.
So
for
the
release
team,
we
need
some
sort
of
persistence
inquiries.
It's
kind
of
sticky
query
is
where,
if
somebody
changes
the
label,
it
doesn't
disappear
from
our
view,
so
we
may
be
interested
in
a
particular
bug.
A
Today
and
be
really
curious
on
its
status
or
a
feature
that
were
a
little
bit
worried
about
and
if
we're
only
using
github
for
our
queries
tomorrow,
when
we
come
back
and
try
to
look
for
the
same
thing,
the
given
issue
number
may
no
longer
be
in
that
query.
So
what's
happened
over
time.
If
you
go
back
quite
a
way
is
in
history,
query
results
were
put
in
the
markdown
files
and
committed
to
get
so
they
were
visible
to
others
over
the
more
recent
releases.
A
These
are
getting
dumped
into
spreadsheets
on
github
or
sorry
on
Google
Docs,
outside
of
github.
But
those
are
all
kind
of
awkward
like.
If
you
have
to
make
a
PR,
then
there's
some
extra
work.
It's
hard
for
us
to
collaborate
on
a
markdown
file,
live
versus
like
a
Google
Doc,
but
Google
Docs
aren't
accessible
necessarily
to
everybody
in
the
community.
So
we've
been
trying
to
think
about
ways
to
to
cope
with
that,
and
it
turns
out
that
the
docs
team
and
Zach
Arnold
have
been
playing
around
with
something
called
air
table.
A
So
there's
a
whole
section
and
the
discussion
about
that
and
a
link
to
their
little
thing
and
it's
a
lot
like
a
spreadsheet,
a
Google
sheet,
but-
and
maybe
I
should
actually
hand
this
over
to
Zach.
Since
he's
on
the
line
today
say
I
wish
I
could
that's.
Fine
I
was
mostly
just
gonna,
speak
to
it
and
describe
it.
Do
you
want
to
do.
A
So
I
just
heard
about
this
yesterday
so
in
exact,
correct
me:
if
I
have
anything
wrong,
but
the
the
docs
team,
similarly
trying
to
track
and
make
sure
like
hey,
does
this
thing
have
Docs
and
if
it's
an
issue
or
PR
that
comes
up
in
a
query,
they
notice
it
and
start
thinking
hey.
We
need
to
get
some
docs
on
that,
but
it's
the
end
of
the
day
say
they
go
home
tomorrow
they
go
and
look
at
their
query.
They
have
a
vague
recollection
of
there
being
a
new
issue,
but
it's
not
there.
A
So
with
this
tool,
they've
got
something:
that's
scanning
github
noticing
new
things
that
are
of
interest
populating
the
spreadsheet,
so
you
could
sort
of
think
of
it
as
a
add,
only
or
add
mostly
spreadsheet,
the
same
as
what
other
folks
have
been
doing
lately
and
Google
sheets.
But
that
way
you
get
sort
of
persistence,
you're,
scraping
github
data
into
a
place
where
you
can
triage
and
address
it
and
know
that
you're
not
losing
things
or
you
have
a
better
chance
of
not
losing
things
anyway.
So
this
really
caught
our
attention
myself.
A
B
B
I
mentioned
tracker,
pivotal
tracker,
I,
don't
know
if
it's
very
broadly
known
outside
pivotal,
but
it
essentially
has
you
have
an
integration,
so
you
can
hook
it
into
Eury,
Perez
and
every
time
there's
a
new
github
issue
created.
It
will
create
a
story
or
a
bug
for
the
team
to
look
at
and
that
sort
of
stays
there
and
then
any
I
believe
I
might
be
wrong
here,
but
I
believe
that
any
changes
that
happen
on
the
github
issue
post
creation
end
up
as
comments
in
that
story.
So
you
sort
of
have
some
way
to
do.
B
A
The
biggest
thing
for
for
the
release
team
is
just
to
be
able
to
have
some
persistent
view,
as
things
are
coming
and
going,
and
it
may
also
be
possible
that
that
it's
easier
for
us
to
cope
with
notifications,
I
think
a
lot
of
the
broader
projects
problem.
Is
you
get
swamped
in
notifications
and
while
you're
on
the
release
team?
A
B
A
The
same,
the
biggest
one
would
be
something's
removed
for
the
milestone,
and
we
want
to
know
why,
because
we're
watching
it
and
a
very
typical
workflow
is
just
to
like
go
up
from
our
spreadsheet,
be
like
hey
that
things
no
longer
showing
up
in
the
query.
What
changed
and
tunnel
into
that
particular
issue
or
PR
and
github,
and
then
see
milestone,
label
removed,
often
you'll
see
that
and
no
comment
or
description
of,
why
you
being
the
person?
What
happened?
A
Oh
I
did
that
on
the
wrong
issue,
or
oh
we've
decided
not
to
do
that
and
okay
have
you
communicated
that
to
the
other
stakeholders,
because
this
other
feature
was
sort
of
codependent
on
that
or
people
were
planning
on
this
we
got
to
talk
to
the
docs
folks.
Let
them
know
to
remove
things
that
are
staged
for
the
website,
all
of
those
sort
of
follow-on
conversations
that
maybe
don't
happen.
If
the
release
team
isn't
tracking
and
checking
that
they
happen,
and
maybe.
C
A
I
hesitate
to
say
like
adding
another
label,
because
there's
there's
so
many
labels
and
so
much
effort
lately
to
kind
of
clean
up
the
big
label
space,
but
another
way
around.
It
would
be
if
the
release
team
had
privileges
to
add
and
remove
a
particular
label
that
others
didn't
to
say
like
release
track.
But
that's
just
like.
Why
is
that
different
than
milestone.
B
Yeah,
that's
interesting,
let
me
know
if
you
need
any
and
if
you
would.
B
A
In
the
meantime,
we
have
this
whole
shadow
world
of
spreadsheet
if
things
and
it
does
actually
work
and
and
even
if
there's
some
duplication
across
the
different
leads
it
times.
That's
also
been
helpful
because
one
of
the
big
benefits,
or
the
really
seem
is
just
a
good
set
of
eyes
and
across
that
diversity.
Somebody
notices
something
and
brings
it
up.
Oh.
A
And
I
didn't
other
thing
and
this
this
only
minimally
came
up
on
and
then
it
can
followed,
followed
on
in
conversation.
So
there's
there's
a
third
place
where
features
are
tracked
just
to
keep
things
exciting
and
this
third
place
is
actually
becoming
in
places,
unfortunately,
for
the
release
team,
so
going
back,
maybe
a
year
or
more,
not
sure
how
long,
but
for
quite
some
time
the
cluster
lifecycle
folks
working
on
cube
a
DM.
A
They
have
their
own
repo
on
kubernetes,
slash,
cube
ADM
and
they
have
issues
there
that
indicate
features
and
are
labeled
with
milestones
as
well
generally
they're
kind
of
often
I'm
gonna,
say
off
on
the
side
exactly
but
they're
they're,
often
there
they're
spaced
doing
their
thing,
and
it's
worked
fine
for
the
we.
We
mostly
coordinate
with
them
towards
the
end
as
we're
getting
ready
to
release
and
trying
to
make
sure
that
release
artifacts
line
up,
because
the
cube
ADM
tool
manages
deployment
configuration
of
of
clusters
and
to
do
that.
A
It
downloads,
artifacts
and
installs
them
on
cluster
nodes.
So
it
needs
to
know
when
new
releases
come
out,
understand
where
those
artifacts
are
to
consume
and
push
them
out.
So
a
little
bit
of
kind
of
integration
coordination
happens
over
the
qadian
folks,
but
that's
not
necessarily
like
feature
tracking
or
deployment.
So
they've
they've
done
a
pretty
good
job
of
doing
that
themselves
and
communicating
also
with
the
docs
team
on
their
futures,
especially
in
that
the
last
release
that
that
seems
to
have
gone
really
well.
But
this
is
a
trend
that's
coming
across
the
project.
A
If
you've
heard
people
talk
about
splitting
the
monolith,
everything
used
to
be
in
kubernetes
kubernetes
and
now
they're
starting
to
be
other
repositories,
and
this
potentially
becomes
a
friction
point
or
a
concern
for
the
release
team.
Do
we
only
focus
on
the
core?
How
much
do
we
pay
attention
to
the
other,
repos
and
I?
Think
the
release
team
disregards
those
other
repos
to
our
peril,
because
these
are
all
interconnected.
A
lot
of
people
are,
if
you
medium,
for
example,
is
the
the
tool
for
deployment.
A
There's
coupling
there
it's
gonna,
if
nothing
else,
just
the
way
it
downloads
artifacts,
but
each
of
these
things,
if
they're
releasing
on
their
own
cadence,
we
need
to
understand
where
they
are
and
what
what
risk
is
implied
on
the
core
and
do
they
do
but
stabilize
us
when
it
comes
to
doing
into
end
tests.
When
do
we
upgrade
their
version
number
in
all
of
our
configuration
and
do
we
de
ste
stabilize
them?
So
this
is
gonna,
be
a
whole
added
dimension,
I,
think
of
coordination.
A
That
needs
to
happen
increasingly
in
the
future
and
it
probably
won't
just
be
across
a
release
team,
but
across
the
whole
project,
people
are
going
to
need
to
talk
and
coordinate.
More
and
testing
is
one
area
that's
been
on
my
mind.
Lately
the
not
sure
folks
have
heard
of
or
followed
the
cloud
provider
splitting
it's
one
of
the
early
areas
that
where
the
infrastructure
as
a
service
that
sits
under
kubernetes,
those
things
are
being
broken
out:
the
provider
glue
code
and
two
separate
repositories.
A
We've
now
got
a
sig
cloud
provider,
but
as
you
do
that,
where
it
is
testing
happen
and
right
now,
a
large
portion
of
the
testing
is
happening
with
kubernetes
on
GCE,
but
that's
kind
of
homogenous
and
there's
a
whole
bunch
of
other
options
out
there.
We
should
have
good
CIC
D
on
those
as
well,
and
the
big
hope
there
for
the
release
team.
Is
you
get
some
a
be
testing
instead
of
test
status?
A
Being
read,
test
statuses
may
be
read
on,
say,
I'll
pick
on
myself
on
on
VMware,
but
it's
good
on
pivotal
and
good
on
GCE.
Well,
then,
we
we,
as
a
release
team,
know.
Okay,
the
core
is
probably
okay.
We
need
to
go
talk
to
the
VMware
people
and
figure
out
what's
going
on
on
their
platform,
so
this
will
be
a
really
useful
tool
to
the
release
team
once
it's
implemented,
but
it's
gonna
take
some
time
to
get
all
of
that
implemented
and
it's
an
early
days
discussion.
B
A
Main
thing
is
the
testing
and
it's
it's
maybe
not
so
much
of
a
new
risk,
because
that
depends
on
how
much
coverage
we
have
so
like
from
the
cloud
provider
spective.
If
most
of
the
testing
today
is
on
GCE.
Well,
the
other
cloud
providers
are
existing
risk,
so
we're
not
going
to
get
as
immediate
feedback
on
those
and
then
I
guess
there.
A
I
can
have
hope
because
we're
actually
building
towards
a
better
future
that
will
have
good
CI
there's
a
later
in
an
hour
or
no,
it's
a
sometime
in
a
couple
hours
got
a
look
at
the
calendar.
The
next
cig
testing
meeting
there's
going
to
be
some
discussion
of
this
and
the
cloud
provider
testing
options.
So
it's
good.
The
conversations
are
going.
Things
are
improving.
A
I'll,
throw
that
back
at
you
all
what
or
what
are
the
things
that
you
would
be
concerned
about?
It
is,
as
things
start
splitting
up
out
and
tracking
and
coordinating
you
got
the
classic
software
engineering
integration
is
hard
like,
but
what
are
some?
What
are
some
specific
things
that
you've
bumped
into
that?
You
might
worry
about
here
in
the
kubernetes
case,
anything
I.
B
A
Yeah
I
think
from
the
releasing
perspective
like
we're
if
we're
focused
on
releasing
kubernetes
kubernetes
that
becomes
much
more
of
a
project
release
cadence
where
to
some
extent
right
now,
it
feels
more
like
a
distribution
because
we
have
a.
If
you
look
at
the
documentation,
there's
a
big
set
of
dependencies
and
at
a
minimum
you
need
at
CD
right
to
run
kubernetes,
but
there's
a
big
tail
of
other
things
and
at
specific
versions
and
it's
it
starts
feeling
much
more
like
a
distribution
or
there's
a
set
of
integrated
things.
A
It
may
be
that
we
need
to
do
some
changes
to
more
explicitly
think
like
a
distribution
and
try
to
enhance
the
areas
where
right
now
we're
or
even
maybe
more
actively
just
focusing
on
the
kubernetes
kubernetes
repo
that
we
do
proactively.
Think
bigger,
I'm
curious
to
interact
more
as
time
goes
by
with
the
those
doing
distributions,
because
the
not
sure
if
you
all
have
seen
this
there's
a
spreadsheet
of
kubernetes
distributions
and
vendors
I,
think
the
CN
CF
maintains
us
drop
it
in
the
the
chat
there
are.
A
So
those
forty
two
entities
making
distributions
of
kubernetes
it
would
be
really
interesting
to
have
like
a
a
buff
at
one
of
the
conferences
and
talk
about
release
process.
How
are
we
all
managing
this?
For
those
if
they're
sort
of
downstream
of
us
in
a
way,
is
the
the
core
release
team
declaring
1.12?
Are
there
things
that
they
would
like
us
to
be
doing?
That
would
make
their
lives
easier?
Are
there
things
that
they
could
tell
us
that?
Hey
don't
worry
about
those
we're
gonna
always
do
those
ourselves.
It
would
could
be
really
informative.
A
A
A
A
Well,
if
there
isn't
anything
else
and
I
hope
this
was
informative
to
kind
of
get
a
little
bit
of
chat
time,
even
though
part
of
it
was
just
kind
of
a
super
lightweight
recap
of
some
of
the
stuff
discussed
yesterday,
Maria
I
appreciate
the
dimension
of
the
pivotal
tracker
and
gonna.
Go
look
at
that
and
think
about
it,
and
next
week
we
should
have
a
run-through
of
tests
graded.