►
From YouTube: Kubernetes 1.12 Release Team Meeting 20180814
Description
A
A
A
B
A
A
All
right,
we
are
two
minutes
past,
so
I'm
gonna
go
ahead
and
get
started.
As
always.
This
is
a
public
meeting,
it's
being
recorded,
it
will
be
on
the
internet,
so
behave
accordingly.
I
feel
I
feel
like
an
adult
having
to
say
that,
but
it's
an
apartment,
a
reminder
so
kind
of
the
standing
agendas
features
test
failures.
Bugs
will
kind
of
go
through
that
briefly,
I
think
unfit
to
much
to
say.
A
Yesterday,
I'd
asked
Stephen
to
to
give
us
a
bit
of
an
update,
he's
gone
out
to
the
cigs
or
future
owners
for
a
bit
of
follow
up
folks
who'd
said
they
would
would
enter
data
on
tickets,
but
haven't
yet
these
kind
of
starting
another
scrub
of
requests
for
information.
There
I've
been
doing
a
bunch
of
reading
last
week,
I'd
mentioned
if
you
have
time
to
kind
of
go
through
an
oriented
bit,
but
there's
a
lot
of
information
that
are
trying
to
understand
a
little
bit
of.
A
What's
what
so
I'd
encourage
folks
to
continue
to
do
that,
just
to
have
a
sense
of
where
we
might
have
potential
risks
and
things
like
that
and
myself
and
I,
as
leads
also
have
been
doing
that
and
I've
asked
a
couple
of
SIG's
a
few
questions,
but
in
general
I'd
say
most
of
the
things
I've
read.
It
seem
like
they're
they're,
reasonably
documented
for
an
initial
state
and
then
there's
their
signs
of
progress,
I
would
say
associated
with
them
as
well.
A
Yesterday,
Zack
had
asked
from
the
dockside
he'd
heard
some
questions
about
whether
the
default
container
runtime
might
change,
and
we
had
a
bit
of
a
conversation
about
that.
But
the
the
the
summary
was
no
news.
There's
been
talk
of
things
for
quite
some
time,
but
nothing
in
particular
seems
like
it's
becoming
a
concrete
plan
and
then
from
there
we
got
into
the
CI
signal
if
you've
looked
at
test
grid
and
I
haven't
looked
at
it
honestly,
this
warning
just
yet.
So
let
me
just
do
that.
A
Looking
at
test
grid
late
last
week
and
then
getting
into
this
morning,
I
felt
it
was
a
little
bit
worried.
I
was
seeing
more
more
things
that
were
read,
but
then
looking
a
little
bit
closer,
it
was
sort
of
one
block
of
issues
around
storage,
things
and
release
master
blocking
and
those
were
actually
specifically
in
a
scale
test.
So
it's
a
test
that
only
runs
every
few
days.
So
it's
hard
to
tell
immediately
whether
we
have
a
flake
or
something
a
little
bit
more
persistent.
A
So
hopefully,
today
I'm
expecting
to
see
the
next
test
results
there
and
I'll
paste
this
in
the
chat,
so
release
master
blocking
the
GCE
scale
correctness.
There
was
a
set
of
failures
on
the
11th,
so
that's
been
three
days
now,
and
this
test
runs
every
sort
of
two
to
three
days.
So
hopefully
we
find
out
something
for
better
news
day.
Either
there
was
a
problem,
that's
been
noticed
and
corrected,
or
it
was
a
flake
somehow
or
we
get
the
sign
today
that,
yes,
we
have
a
problem
and
we
need
to
engage
people
more
aggressively.
A
Then
the
other
thing
that
was
a
little
worrying
and
release
master
upgrade.
There
were
quite
a
few
new
tests
that
had
failed,
but
today
they're
actually
green
again
and
talking
to
people,
it
appeared
that
it
was
probably
more
oh
actually
they're,
they're,
not
entirely
green
I.
Take
that
back,
maybe
yeah
so
talking
to
folks
and
sig
testing
or
the
and
the
tester
infrastructure
infrastructure
people.
It
came
to
be
a
little
more
apparent
that
most
likely.
A
This
is
a
gke
specific
issue,
so
the
the
splitting
and
understanding
can
be
a
little
complicated
when
a
set
of
things
look
like
they're
failing
consistently,
but
then
it
turned
out
that
looking
at
the
diffs
of
what
had
changed,
nothing
had
changed
in
kubernetes
and
then
the
cluster
of
changes
failures.
Even
though
the
failure
specifics
looked
like
test
case
failures
in
kubernetes,
probably
it
was
only
happening
on
gke
and
the
gke
people
were
aware
of
some
issues.
A
A
For
the
other
things,
there
are
a
number
of
issues
that
have
been
open
for
a
couple
of
weeks.
There
is
a
cluster
there
that
are
what
we
call
skew
tests
so
things
that
are
going
from,
but
between
certain
versions
that
are
fixed,
and
these
were
ones
I,
guess
more
so
in
the
bucket
of
1.10
to
1.12
upgrades
and
that
it's
less
expected
to
work.
Ideally,
those
work
as
well,
hopefully,
I
think,
has
been
maybe
something
historically,
but
the
supported
upgrade
path
is
from
adjacent
releases.
A
A
A
B
B
So
I
got
the
ball
rolling
on
those
and
that
and
that
one
issue
yesterday
was
in
fact
closed
in
error,
because
I
think
the
related
PR
said
partially
fixes
issue
number
and
then,
of
course,
the
bots
picked
up
on
fixes
issue
number
and
automatically
closed
it.
So,
but
there
is
a
related
PR
that
I
think
looks
like
it's
going
to
work
on
the
remaining
part
of
the
issue
and
it,
it
all
looks
very
active.
So
six.
B
A
A
B
A
We're
without
the
requirement
that
a
PR
have
an
issue
associated
the
the
volume
of
issues
has
gone
down
dramatically
and
in
a
way
that's
good.
I
mean
the
the
issues
are
focused
on
bugs
that
need
attention
and
if,
if
there's
a
bug
that
was
noticed
and
the
person
who
noticed
it,
just
immediately
made
a
PR,
it's
more
efficient
to
do
that,
but
it
it's
less
visibility.
It.
A
I,
don't
kind
bug
fix,
so
we
had
a
bit
of
a
conversation
yesterday
because
we
had
Aaron
from
who
I
think
he
Aaron
was
probably
representing
tests
slightly
more.
But
then,
as
we
got
into
this
discussion,
I
I
maybe
made
the
mistake
of
saying
I
feel
like
we
need
some
steering
committee
level,
but
somewhere.
A
If
there's
two
there's
two
extremes,
we
have,
on
the
one
hand,
there's
desire
to
say
every
PR
should
be
associated
with
an
issue,
that's
associated
with
a
cap
and
that's
that's
a
very
rigorous
set
of
tracking
and
if
nothing
else,
I
like
the
idea
of
PRS
being
associated
with
caps
if
they're
their
features
and
but
then
issues
is
more
ambiguous.
What
level
of
tracking
do
you
need
there
and,
and
then
people
start
to
game
if
the?
A
If,
if
there's
too
much
process
on
features,
then
they'll
say
well
well,
technically,
since
we
didn't
have
this,
it's
a
bug
and
they
they
like
to
game.
Metrics
like
that
I've
seen
this
over
and
over.
So
we
need
something,
that's
pragmatic
and,
to
a
large
extent,
I
would
say:
people
have
opted
out
of
the
heavy
process
and
that's
why
we
don't
have
issue
requirements
so
we're
drifting
in
the
the
other
extreme
direction.
Where
we
don't
have
issue
requirements.
We
might
have
five
issues
related
to
the
milestone
in
a
week
and
that's
a
tiny,
tiny
number.
B
B
B
B
B
A
A
So
people
could
propose
things
for
the
milestone,
but
then
you
need
an
approval
phase
and
there
it
makes
sense
that
if,
if
we
want
to
have
a
bit
of
control
that
you
have
somebody
in
a
little
at
least
in
a
specific,
slightly
higher
and
and
I
delivered
deliberately
ambiguous
like
is
it
somebody
with
a
reviewer
or
approver
status?
Or
does
it
have
to
be
a
sickly?
But
some
someone
other
than
anybody
on
github
should.
A
B
A
Need
some
some
level
of
gating
now
it
could
be
that
we
punt
all
the
labels
and
all
approvals,
but
then
we
we
have
a
merge
master
at
that
point.
Some
human
has
to
say:
okay,
only
the
stuff
merges
and
that
becomes
a
bottleneck
as
well
in
a
friction
point
and
I
I,
don't
see
that
being
a
happy
outcome,
so.
B
B
A
What
I
wanted
to
double-check
today,
but
then
I'm
not
sure
how
much
I'm,
not
sure
where
that
gating
mechanism
is
so
I
wanted
to
go,
poke
around
and
test
infrastructure
to
double-check,
which
code
is
enforcing
that
in
which
specific
criteria
there
are
because
it's
a
part
of
the
conversation
yesterday
was
that
I
had
opened
a
couple
of
issues
a
few
weeks
ago
to
move
our
documentation
of
these
criteria,
make
them
a
little
more
visible
and
and
and
readable
as
well,
because
that
they're
somewhat
confusing.
But
then.
A
We'll
actually,
no,
let's
not
do
that.
Let's,
let's
turn
off
the
milestone
manager,
because
most
of
the
documentation
was
explaining
to
people
what
the
milestone
manager
did
in
the
face
of
nobody.
Wanting
the
milestone
manager
still
need
this,
the
criteria
and
to
define
what
we're
gonna
do
and-
and
this
is
where
Aaron
I
think
was
pushing
with
his
steering
committee
hat
like
you,
the
release,
lead
and
us
the
release
team
need
to
decide
what
you're
gonna
do.
So
we
can
communicate
it
ahead
of
code
freeze
right.
A
A
Proj
people
I
thought,
though
I
mean
I
in
Contra,
Beck's
Christoph
Blocher
has
been
doing
some
cleanups
around
that
and
I
had
gotten
the
impression
that
that
list
of
people
had
been
scrubbed
to
a
very,
very
small
list,
but
then
conversation
yesterday
made
it
sound
like.
Maybe
it
was
still
scary
big.
So
that's
the
other.
A
So
there's
a
there's,
a
new
tool
coming
related
to
that,
so
that,
rather
than
just
github
teams,
we
have
the
prowl
commands
are
backed
on
permissions
and
basically
all
of
the
I
think
that
the
goal
is
to
have
kind
of
all
of
the
rights
not
tied
to
github
groups
but
tied
to
llamo
files
so
that
we
have
visible
process
within
the
community.
So
if
I
want
to
grant
Ana's
a
certain
permission,
I
make
a
PR
against
a
llamo
file.
It
goes
through
the
normal
process.
Maria
needs
some
other
permission,
the
same
thing.
A
So
the
this
new
tool
is
called.
A
It's
got
something
for
a
nautical
name:
I
think
Oh
No,
oh
yeah,
Greek,
Perry,
bolos
and
there's
a
drop
a
link
in
there
just
for
if
anybody's
curious,
so
that's
coming
but
I
don't
know.
I
need
to
chat
with
the
the
test
folks
to
understand
what
its
trajectory
is
because
I
my
impression
is
it's
coming
soon
and
and
maybe
then,
if
it's
in
place
ahead
of
code
freeze
and
we're
gonna
gate
things
on
some
specific
criteria,
we
could
go
ahead
and
document
and
encode
that
to
today
in
advance
getting
prepared
for
that
with
the
yam.
A
Also,
it's
it's
clear
for
folks
and
then
it's
one
less
Google,
Group
and
I
think
the
Kristof
would
be
happy
with
that
too.
So
my
my
commitment
to
Aaron
was
to
finish
reading
through
this
stuff
and
today
make
a
proposal
on
what
we
should
do
so
I'll
be
sending
out
an
email
later
today,
but
I
also
I
want
to
have
a
couple
conversations
later
today.
Sig
PM
meets
so
I
wanted
to
just
chat
with
them
a
little
bit
on
the
feature
side,
and
then
we've
also
got
a
sig
release
meeting.
B
B
B
A
B
B
C
A
B
B
A
Gap
where
I
see
worth
we
don't
have
the
issues,
because
there
have
been
a
couple
of
cases.
A
particulars
me
is
somebody
is
a
part
of
a
feature.
Work
or
a
bug
fix
will
vendor
in
some
new
go
code
and
that
will
bring
in
a
bug
or
some
new,
odd
interaction
and
the
person
who
notices
that
that
buggy
behavior
the
strange
interaction
they
will
try
to
fix
something
in
response
to
it
and
then
just
the
maybe
the
the
PR
review
there.
A
Somebody
will
say:
oh
wait,
no
I
think
maybe
it's
related
to
this
new
vendor
code,
or
they
might
also
make
a
change
to
a
test
case.
Then
the
vendor
code
gets
reverted
because
they
noticed
out.
This
is
where
the
problem
was
introduced,
but
the
original
PR-
and
this
comes
back
to
sort
of
general
hygiene
or
issues
like
the
reviewing
process,
didn't
lead
to
a
high-quality,
commit
message
and
the
original
PR
that
introduced
the
bug
was
fixing
something
or
adding
something
that
was
desired.
A
But
it
gets
reverted
round
in
a
way
so
person
notices,
symptom,
B
the
following
symptom.
Yet
they
managed
to
get
that
fixed,
but
they
break
rhe.
Break
the
older
thing
and
they're
having
an
issue
we'd,
be
able
to
at
least
reopen
the
issue,
it's
searchable
and
noticeable
that
people
are
having
a
conversation
about
this
set
of
things.
So
it
is
our.
A
If
they're
opened
and
reopened-
and
you
have
the
the
persistent
history
collated
in
the
one
spot,
if
in
random,
PRS
I,
don't
see
people
mentioning
five
other
random
pr's
that
happen
to
be
associated
code,
where
issues
issues
just
culturally
become
a
little
bit
more
of
an
umbrella
and
and
I
don't
know,
actually
I
don't
go.
Look
if,
in.
B
A
B
B
A
To
evolve
the
processes,
it's
really
important
to
understand
that
what
we're
doing
like
the
the
processes
should
follow
the
people,
what
the
people
are
doing
today,
they're
doing
because
that's
what
they
prefer
and
if
we
try
to
enforce
too
much
on
top
of
that
people
are
just
gonna
opt
out
of
it.
So
the
processes
need
to
follow
the
people
and
then.
A
I
think
that
you
also
need
to
instill
the
right
culture
in
the
people
so
that
they
are
everything's,
not
a
release.
Note
none,
because
that,
whether
it's
the
issue
or
the
PR,
if
there's
like,
if
it
basically
says
nothing,
that's
that's
my
Hill
to
die
on
that.
One
drives
me
crazy
and
I'm
constantly
poking
people
like
do
you
have
a
little
more
detail
to
the
description
here,
but.
B
A
In
there
I
think
we
really
have
to
lean
on
the
reviewers
approvers
and
probably
not
so
much
the
sigelei
it's
like.
If
we
go
the
other
direction
like
caps
and
and
issues
that
are
milestone,
manage
yeah,
the
zig
leads
are
gonna,
be
more
the
focal
points
there,
but
we
need
reviewer
and
reprove
errs
on
PR
is
to
push
back
and
say
you
know
what
I'm
not
going
to
give
this
the
looks
good
to
me
until
you
update
the
the
commit
message
to
give
a
little
more
information
for
posterity.
A
A
If
people
do
the
search,
because
right
now,
the
github
with
that
duality,
you
either
you
you're,
probably
going
to
do,
is
issue
or
is
PR
search
and
if
you're
not
doing
that,
you
still
need
something
to
to
say,
because
the
humans
gonna
say.
Is
there
a
bug
in
sharing
secrets
on
on
during
cluster
set
up
like
one
of
the
things
I
was
looking
for
yesterday,
just
trying
to
do
some
searches
like
that
and
you're
either
gonna
add
some
sort
of
a
word
for
like
bug
or
test
failure
or
flake,
or
something
like
that.
B
A
This
is
an
area
of
active
conversation
yeah
and
if,
if
issues
condense
or
collapse
down
into
PRS
for
the
most
part
than
some
portion
of
the
label,
expectations
on
issues
should
just
transfer
over
to
PRS,
as
well,
so
more
more
to
come
later
today,
here,
I
guess,
based
on
conversations
on
anybody
else,
have
any
thoughts.
Son,
I,
I,
know,
I,
know:
pivotal
folks
have
biffle's
renowned
for
its
opinions
on
software
engineering
practices.
I
would
be
kind
of
curious
to
hear
like
do
you?
Do
you
think
we're
all?
Is
this
the
Wild
West?
A
C
It
like
it's
pretty
interesting
because
it
is
completely
different,
completely
different
problems
in
different
situations
and
we're
talking
about
sort
of
like
to
make
it
more
concise.
Often,
projects
at
pivotal,
even
open
source
stuff,
have
the
trade
of
having
more
more
of
a
control
on
behalf
of
the
company
or
more
direction
offered.
So
here
it's
the
challenge
of
having
a
community
of
folks
that
don't
have
oftentimes
nothing
else
in
common
I
accept
project.
So
that's
why
I
found
fascinating
the
bit
that
the
moment
we
talked
about.
A
Also
I
am
the
part
of
me
that
wanted
to
say
like
let's,
let's
ask
whether
architecture
or
steering
committee
like
I
I,
know
that
that's
somewhat
unrealistic.
We
need
to
come
with
a
bit
of
a
baked
proposal
more
or
less
and
say
like
this
is
what
we
want
to
trial
for
code
freeze.
I
partly
feel
like
I
think
some
of
us
just
like
the
responsibility
of
release
lead
on
my
shoulders.
A
Like
do
I
I,
don't
know
that
I
I
should
make
this
decision
and
force
it
on
the
the
community
right,
but
at
the
same
time
this
is
really
a
probably
more
a112
experiment
and
we're
constantly
experimenting
and
evolving
the
process.
So
it's
not
like
any
of
this
is
binding
and
we'll
give
it
a
go
and
see,
and
and
and
really
in
every
priority.
A
Similarly,
things
have
happened:
we've
slightly
tweaked,
some
of
the
things
on
the
fly
and
and
I
think
that's,
that's
probably
good
as
much
as
it's
fuzzy
and
maybe
a
little
daunting
to
say
like
well.
Let's,
let's
try
going
this
direction
that
we
as
a
community
are
pragmatic
enough
to
try
things
and
adjust
and
shift
is
actually
I.
Think
a
good
sign
and
open
source.
A
A
A
You
know
we're
starting
to
collect,
so
both
Gwyn
and
I
also
are
active
and
the
contributor
experience
area
and
we're
starting
to
get
more
concrete
on
the
plans
for
cube
con.
What
we're
gonna
do
for
the
the
new
computer
workshop.
So
if
any
of
you
happen
to
be
interested,
if
you're
planning
to
attend
either
Q
con
China
or
Q
con
North
America
in
November
and
December,
and
are
able
to
be
there
the
day
before
the
conference
starts,
we've
got
a
new
contributor
workshop
and
are
looking
for
volunteers
to
share
information
across
the
contributing
process.
A
A
A
Oh
yeah,
so
concretely
for
you
specifically
on
so
what
Doug
and
I
wanted
to
do.
We
have
we've
got
two
things
today:
one
creation
of
the
branch
and
we're
not
sure
what
permission
that
takes
and
if
Doug
has
it
so
we're
gonna
stumble
through
that
and
then
document
it
and
then
the
release
update.
What
we
wanted
to
do
was
just
run
straight
through
the
documentation
that
we
drafted
trying
to
make
the
alpha,
since
that
one
was
a
little
rocky.
A
A
Alright,
so
later
today,
hopefully
that'll
all
be
happening
as
well,
and
then,
with
the
with
a
branch,
creation
will
start
fast-forwarding
the
branch
bringing
in
master
content
regularly,
and
that
should
be
a
really
simple
easy
process,
and
it's
one
that
we
want
to
have
the
shadows.
Do
sue
me
regularly
as
well
so
you'll
you'll
start
to
get
your
hands
into
things
in
the
coming
couple
weeks,
get
to
practice
and
play
great.
Thank
you,
yeah.
Alright,
one
last
call
anything
else.