►
From YouTube: Kubernetes 1.12 Release Team Meeting 20180820
Description
A
A
B
All
right,
it
is
to
past
so
I'm
gonna
go
ahead
and
get
things
started.
As
always.
This
is
a
public
recorded
meeting
that
will
be
posted
to
YouTube
so
act.
Accordingly,
the
minutes
image
and
a
document,
if
folks
could
drop
their
name
in
there
on
attendance
I,
would
appreciate
it
and
we'll
go
through
our
kind
of
standing
agenda.
We've
got
a
few
different
things
today,
I'm
going
to
start
with
features
around
this
time
and
prior
cycles,
we've
started
getting
word
potentially
of
features
where
they're
clearly
not
going
to
happen.
B
C
Was
66
one
was
removed
so
we're
at
we're
at
65
right
now,
there's
one
that
requires
an
exception
which
I'm
going
to
be
following
up
on
today
and
there's
one
that
is
I
have
continued
to
leave
it
in
an
at-risk,
because
all
the
data
was
there.
I
just
need
a
confirmation
if
it's
actually
going
to
be
in
the
milestone,
so
I'll
be
doing
that
today
as
well.
C
C
There
was
some
discussion
and
an
initiative
started
by
cluster
lifecycle,
but
the
back
and
forth
on
the
on
the
future
issue
has
been
that
while
we've
started
it,
it's
not
something
we
want
to
own
and
we
feel
that
it's
something
that
sake
release
should
own,
which
I
don't
disagree
about.
So
there
needs
to
be
a
bigger
discussion
on
who's
going
to
own
that
and
we
need
to
identify
who
and
put
that
up
on
the
on
the
future
as
an
official
owner
priority
and
preemption
I
am.
D
C
C
There
is
an
email
chain,
I,
don't
know
if
you're
on
it
Tim
regarding
core
DNS
being
set
as
default,
not
assume
that
okay,
so
that's
yeah,
that's
some
chatter
about
about
a
survey
being
sent
out
and
how
long
to
keep
survey
open
for
and
what
do
we?
How
should
we
track
this
and
and
if
core
DNS
is
going,
is
going
to
be
set
as
default?
Does
that
mean
we
should
have
a
deprecation
policy
for
keep
DNS?
We
let
them
both
be
a
ga
at
the
same
time,
what's
the
timeline
for
both
of
those
things.
C
B
The
multi-platform
one
is
complex,
I
think
we
need
to
discuss
it
at
a
sig
release,
meeting
and
and
see.
I
think
this
is
something
that
is
probably
also
beyond
the
scope
of
what
it
certainly
falls
within
the
scope
of
what
sig
release
should
do,
but
I
think
it's
beyond
the
scope
of
what's
been
available,
staffing
historically
so
figuring
out
how
to
to
not
just
say
a
sig
owns
it
but
ensure
that
they
actually
have
the
ability
to
operationally
own
and
act
on
it,
as
is
the
gap.
C
B
Okay,
so
moving
on
I'm
not
sure
do
we
have
anyone
from
test
and
fro
on
I,
don't
think
so,
so,
just
a
couple
of
notable
things.
So
last
week
the
112
release
branch
was
created
and
with
that
came
branch,
CI
testing,
so
that
stuff
is
visible.
If
you
look
in
test
grid
on
the
cig
release
tab
now
the
1.12
released
all
and
blocking
I
know
you
call
that
table
sheet
link.
Those
are
visible
there
and
the
one
that
eight
ones
have
fallen
away
and
I
think
that
was
all
I
wanted
to
mention
for
tests.
B
F
A
E
Yeah,
so,
based
on
what
I
did
there
have
been
more
table
to
operate
trailers
so
I'm,
actually
following
up
with
oh
gosh,
arrived
second
as
well
as
sig
DCP,
because
they
appear
to
be
TCP
freeze,
although
I
have
tagged
all
the
six
whose
deaths
are
affected
by
it.
So
that's
the
major
feeling
that
that
we
have
that
contract
failures
and
the
operators
that
there
has
been
recurrence
of
failures
and
master
blocking,
but
I
guess
now
that
we
have
12
should
I
stop
following
those
anymore
now.
B
We
need
to
keep
following
those
because,
though
so
initially,
the
two
of
sort
of
you
have
a
fork
but
they're,
basically
in
lockstep
for
the
time
being,
and
once
we
hit
code,
freeze,
master
will
keep
moving
with
some
portion
of
that
will
still
get
pulled
back
to
the
release,
so
master
is
sort
of
our
leading
signal
on
the
quality
and
health
of
what
we'll
want
to
cherry-pick.
Ultimately,
as
we
get
later
into
the
cycle.
B
E
B
And
that's
that's
tomorrow
and
in
about
24
hours
time,
23
hours
7
from
now.
Ok
I
will
try
to
join
that
one
as
well
and
yeah.
These
these
ones
have
been
failing
for
all
pretty
much
two
weeks
we
have
a
set
of
failures
there.
Now
there's
there
had
been
some
discussion
of
whether
that
it
was
upgrade
itself
or
subtest,
but
I
I
feel
like
the
discussion.
It
ended
up
back
at
it
being
upgrade,
but
we
need
a
we.
E
B
Right
now,
we
kind
of
have
multiple
parties
who
think
somebody
else
is
potentially
on
it,
but
we
really
need
to
nail
it
down
specifically
a
clear
set
of
issues
and
get
artifacts
into
the
issue
where,
if
we
talk
to
sack
Lester
lifecycle,
we
record
exactly
what
cluster
lifecycle
said
for
the
rationale
for
it
not
being
them
and
who
next
and
really
for
each
of
these
start,
taking
a
concrete
set
of
steps.
I'd
really
like
to
have
these
resolved
this
week
because
we're,
as
we
inch
closer
to
code,
freeze
the
set
of
stuff
that
it's
persisted.
B
D
E
There
are
storage,
so
most
likely
understood
that
there
are
I've
seen
that
there
are
tests
which
are
failing
on
six
storage.
So
that's
also
a
problem
point
where
I
am
considering
doing
the
similar
thing
with
them
as
well,
like
turning
other
meetings,
I'm,
actually
bringing
it
of
that
to
that
test,
fearing
for
some
time
now,
when
are
we
getting
the
yeah.
B
B
B
B
And
then
I
think,
probably
next
logical
step
depending
on
that,
the
the
word
that
we
get
back
probably
split
that
into
multiple
issues
where
each
because
there's
a
there's
a
good
chance
that
these
are
unrelated
and
just
on
average
I
feel
like
that.
That's
usually
the
case,
and
they
seem
to
be
failing.
It's
slightly
different
right,
so
I
I,
first
see
us
having
a
little
bit
of
a
family,
but
to
have
that
umbrella
is
good.
B
I
I
feel
like
we're
drifting
in
the
red
direction,
just
by
virtue
of
this
relatively
small
set
of
issues
about
having
persisted
for
a
while.
This
is
starting
to
become
really
worrisome
now,
all
right
so
Quinn
anything
else.
You
want
to
talk
about.
Besides
a
couple
you
mentioned
there
a
moment
ago,
yeah.
D
I'm
trying
to
figure
out
how
to
add
the
great
label
and
yeah
we
have.
D
Basically,
there
is
a
couple
new
issues
and
there
hasn't
been
a
whole
lot
of
activity
on
the
ones
that
I
followed
up
on
last
week.
So
a
lot
of
them
have
been
sort
of
silent
for
a
week,
but
I'm
going
to
follow
that,
but
some
of
them
also
have
PRS
open,
and
so
they
are
in
code
review
right
now,
and
so,
unless
that's
just
being
forgotten
about
which
I
think
it's
just
it's
just
taking
some
time
so
I
do
see
some
action
and
one
issues,
a
very
old
issue.
D
That's
popped
up
again
and
it
currently
has
no
priority.
So
I
need
to
follow
up
on
that
as
well.
I'm
a
little
bit
unclear
on
what
the
priority,
what
the
priority
label
does.
B
Of
that
falls
away,
but
get
in
towards
code.
Freeze
code
freeze
is
implemented
by
again
automation
that
looks
for
certain
labels
and
also
that
the
milestone
tag
so
that
the
the
tagging
on
the
github
issues,
and/or
PRS,
have
to
be
a
certain
way
and
for
code
freeze,
priority
critical
urgent
other
than
that
I
feel
like
these
are
kind
of
loose
planning.
B
D
Yeah,
that's
what
it
that's!
What
I
figured
so
I
didn't
immediately
follow
up
on
it.
I
just
saw
that
yeah.
We
got
two
new
issues
and
somewhat
sluggish
progress
on
a
couple.
Other
ones
and
I
keep
meaning
to
go
through
and
get
non
milestone,
labeled
bugs
out
and
see
some
of
that
look
at
some
of
those
trends
and
I
have
not
gotten
around
to
that.
I
think.
B
As
the
requirements
got
relaxed
really
two
cycles
ago,
around
issues,
mapping
to
PR
is
that
this
whole
workflow
started
to
become
much
looser,
a
regardless
of
the
workflow.
Even
if
we
had
formal
structure
around
requirements,
the
meeting
the
requirements
with
lag
issue
being
created
and
there's
a
release
team,
we
want
to
know
within
a
day
or
two,
especially
as
we're
in
the
final
weeks
of
the
release
that
issues
been
open
and
have
a
sense
of
okay.
This
looks
this
looks
like
a
big
deal.
It's
a
problem.
Dude!
B
B
G
E
H
Other
things:
yes,
all
right:
how
are
you
doing
good
all
right,
still
trying
to
wake
up
this
morning?
Some
of
my
third
cup
of
coffee
and
it's
not
working
so
Doc's-
are-
are
going
well
Oh
CB
here
from
Portland,
so
I
bet
the
coffee
is
way
better
there.
So
it's
craft
coffee
I
mean
here
it's
not
$9
a
cup,
but
it's
still
anyway.
Sorry.
H
So
obviously
the
PR
open
deadline
is
tomorrow,
so
Doc's
don't
have
to
be
complete.
Just
we
made
this
sort
of.
This
was
an
adjustment
that
Zac
or
lesson
made
for
last
release
that
misty
then
took
over,
which
was
it's
usually
a
good
indicator
that
a
feature
is
going
to
make
it.
If
somebody
can
open
up
a
PR
and
write
some
hello
world
type
text
of
like
this
is
generally
what
I'm
going
to
cover
for
this
feature.
H
So
we
made
that
determination.
It
should
be
a
week
ahead
of
code
free
or
code
slush,
which
is
tomorrow,
so
that's
tomorrow.
I
am
following
up
with
everybody
in
the
features
repo,
the
ones
that
are
marked
for
the
milestone
112
today
and
then
we'll
start
getting
a
bit
more
aggressive,
because
if
I'm
looking
at
this
correctly.
H
The
docks
deadline
is
two
weeks
from
today,
so
I
have
that
right
coat.
No,
today's
the
21st,
no
three
weeks
from
today,
two
weeks
from
today,
I
can't
do
math,
21
28
yeah
about
two
and
some
change
two
and
half
weeks.
So
yes,
so
obviously
it's
definitely
time
to
finish
features.
Definitely
enough
time
to
start
finishing
docks,
but
just
having
a
PR
open
is
our
goal
for
this
weekend.
So
we
have
six
open
right
now
and
right
now
right.
The
docks
is
in
Cincinnati,
so
they
are
actually
doing
a
PR
bash.
H
B
B
C
H
Docks,
yes,
oh
I
copied
the
timeline
from
last,
which
was
which
is
a
week
ahead
of
code.
/Was
was
the
docks,
PR
open
deadline,
so
just
just
literally
going
there
making
a
branch
opening
it
against
the
release,
1:12
and
saying
I
plan
on
editing
a
file.
It
doesn't
matter
what
file
or
what
you're
gonna
put
in
it
just
I.
H
B
But
then
people
were
more
around
I
feel
like
in
in
the
June
timeframe
and
this
cycle
because
of
how
we're
landing
right
now,
the
month
of
August
is
a
pretty
typical,
North
American
holiday
sort
of
time,
and
there
have
been
some
things
where
I've
kind
of
I've
worried
a
little
bit
like
oh,
what's
going
on
with
this.
But
then
it
comes
back
to
like.
Oh,
the
sickly
like
there
are
there's
stuff
and
flight.
The
sig
leaves
out
this
week
or
something
like
that,
so
that
that's
making
things
feel
a
little
herky-jerky.
B
B
B
So
we'll
have
those
discussions
this
week
and
depending
on
CI
signal,
but
then
the
bigger
picture
of
how
we
do
code
freeze
so
Aaron
crackin
burger,
had
been
here
on
some
previous
calls
and
was
talking
about
things
he's
doing
to
do
some
cleanups
around
labeling
and
process.
Streamlining
we've
had
a
few
PRS
and
flight
for
things
and
sig
release
and
sig
diem
around
process
improvements
and
lots
of
discussions.
These
are
all
great
Aaron's.
Doing
lots
of
little
Point
cleanups
that
make
sense
individually.
Sig
p.m.
B
sig
release
are
talking
about
some
bigger
picture
things
that
are
longer
term
I,
think
than
just
the
112
cycle,
especially
with
us
kind
of
having
six
weeks
to
go
here.
There's
not
a
lot
we're
gonna
massively
do
to
change
processes.
The
one
process
thing
that's
going
to
hit
us,
though,
yet
is
code
freeze,
so
code
freeze
has
been
implemented
as
a
couple
of
pieces
of
automation
that
look
at
the
submit
queue
and
how
things
are
merging
and
what
the
labels
are
there
and
then
there's
been
a
bit
of
documentation
that
describes.
B
If
you
want
your
code
to
merge
here's
what
you
have
to
do,
depending
on
the
phase
of
the
release
it
code
freeze,
you
had
the
the
normal
set
of
requirements
on
a
PR
merge,
plus
you
had
to
have
the
milestone
label
applied
and
then
also
a
status.
The
status
had
to
be
approved
for
milestone
or
in
progress
or
in
review
to
keep
it
the
milestone
from
automatically
being
removed,
and
what
you'd
see
is
sort
of
this
back
and
forth.
B
Somebody
to
add
the
milestone,
the
bot
would
notice,
it
wasn't
status,
correct
and
it
removed
the
milestone
and
you
sorta
go
back
and
forth
and
eventually
like
at
some
point
we're
in
code
freeze
and
there's
like.
Why
isn't
this
thing
merging
and
boom
boom
boom?
They
apply
like
six
labels
figure
out
the
magic
combination
and
it
merges
so
much
of
that
automation
has
now
been
turned
off
because
we're
really
getting
the
feedback
that
it
was
mostly
just
annoying
that
the
risk
management
was
happening
more
actively
by
us
watching
what
was
going
on.
B
So
we
do
need
to
still
implement
code
freeze
and,
as
we
turn
on
the
automation
that
gates
merges
during
code,
freeze
I
want
to
propose
that
we
remove
the
extra
requirement
around
status,
the
status
mostly
tied
into
the
bot.
That
would
automatically
remove
the
milestone
and
lead
to
this
weird
sort
of
feedback
loop
and
more
often
than
not
encode
freeze.
Once
people
have
got
sort
of
reminded
of
what
it
took
to
merge
something
they
would
just
apply
all
the
labels,
because
they're
just
saying
like
yes,
we
want
this
thing
to
merge.
B
So
I
think
that
practically
speaking
with
the
the
approvers
were
doing
was
saying,
I
approve
and
I
would
like
that
to
be
a
simpler
process
for
them
and
I
think
it's
reasonable
to
say
that
the
approval
is
simply
somebody
who's
allowed
to
label
it
with
the
milestone
and
then
the
list
of
people
who
can
do
that
is
actually
pretty
small
there's
well,
the
list
is
messy.
There's
there's
a
github
group.
It's
got
like
way
too
many
people
in
it,
probably,
but
it's
basically
sig
chairs,
sig
leads
or
leadership
of
SIG's.
B
So
it's
a
set
of
responsible
people
who
already
had
to
be
involved
to
approve
something
to
go
in.
So
if
we
reduce
the
number
of
things
that
they
have
to
do,
instead
of
making
two
check
marks
to
just
one
check
mark,
it
would
streamline
things
so
I've
got
something
that
I'm
gonna
send
out.
I
guess
today,
because
I've
balanced
around
a
few
of
the
leaves
and
prior
release
leads
as
well
to
get
a
little
bit
of
feedback,
and
generally
people
are
okay
with
the
proposal.
B
I
think
so
be
sending
out
this
email
later
today
proposing
we
make
this
streamline
thing.
So
just
FYI
you'll
see
that
email
for
for
Doug
our
branch
manager.
This
will
mean
one
potential
difference
that,
because
it's
been
a
multi-step
process,
it
has
given
the
opportunity,
at
least
for
somebody
to
notice
that
they'd
accidentally
labeled
something
for
another
milestone
and
then
catch
it
before
it
merged.
B
By
streamlining
this,
we
do
slightly
increase
the
chance
that
somebody
would
accidentally
label
something
they
meant
for
milestone
13
as
12,
and
it
would
be
able
to
just
straight
merge.
If
that
happens,
we'll
either
need
to
revert
it
on
master
or
Doug.
When
he's
II
would
normally
be
fast
forwarding
to
the
release
branch,
he
would
need
to
instead
start
to
cherry-pick
and
cherry-pick
around
that
I.
Don't
really
I'm.
Gonna
guess
this
probably
in
the
past
would
have
happened
once
or
twice.
B
Maybe
during
a
release
during
code
freeze,
so
I
don't
think
it's
gonna
incur
that
much
extra
pain,
but
it
means
that
we
need
to
be
cognizant
of
what
is
going
into
master
and
not
have
things
accidentally
go
into
master.
That
shouldn't
happen
anyway,
like
we
should
already
be
watching
to
make
sure
things.
B
So
until
we
come
up
with
a
solid
way
to
prevent
that,
we're
we're
we're
kind
of
where
we
are
and
and
that's
what
kind
of
leads
me
to
think
that,
rather
than
having
all
of
these
levels
of
complexity
that
everybody
has
to
understand,
we
make
life
easier
for
others
and
we,
as
the
release
team,
do
make
sure
that
we're
doing
the
due
diligence.
So
we
exist
for
that
reason,
keep
everybody
else's
life
a
little
bit
easier.
C
+12
it
I
know,
I
know,
Josh
burkas
was
mentioning.
Maybe
we
should
keep
around
the
status
that
grew
from
milestone.
I
agree
that
if
we're,
if
we're
properly
pruning
the
milestone,
maintainer
group,
that
we
should
only
need
the
milestone
as
that
as
that
metric
for
merge,
one
of
the
questions
I
had
around
milestone.
Maintainer
is
in
general,
I
know.
I
know,
we've
got
our
chatter
going
on
that
PR.
So
there
is
there's
simultaneously
the
the
github
group,
which
has
no.
B
So
I
went
through
that
so
last
week,
I
looked
at
everybody
who
is
in
the
github
team
and
in
the
owners,
aliases
and
and
then
I
looked
through
the
automation
to
see.
What's
consuming
these
two
lists,
what's
in
the
owners,
aliases
file
as
best
I've,
been
able
to
determine,
and
also
asking
with
the
testam
for
folks
I'm
completely
unused
so
that
that
list
is
not
now.
Sadly,
there
have
been
people
who
are
like
important
people
who
have
cured
themselves
into
that
list.
B
At
that
point,
that's
not
much
better,
because
we
actually
have
a
process,
we
have
PRS
and
we
can
have
reviews
of
who's
getting
added
and
removed
that
llamó.
Where
right
now,
the
github
team
is
completely
opaque.
I
I
have
the
magic
ability
to
add
and
remove
anybody
to
it,
but
that's
not
a
good
community
process
right
so
having
it
back
by
llamó
will
be
better,
but
right
now
we
have
what
to
be
two
sources
of
truth,
but
really
there's
only
one,
because
the
one
who
get
that
committed
and
the
repo
is
is
completely
unused.
B
F
B
Not
use
looking
but
I
couldn't
I
mean
I,
don't
have
every
single
repo
checked
out,
but
I
didn't
find
anywhere
where
it
was
in
use.
Okay,
yeah.
C
B
B
Xylene
this
difference,
so
my
proposal
for
streamline,
listen,
including
removing
that
from
the
owners
aliases
will
go
out
to
all
the
sig
leads,
so
hopefully
we'll
get
feedback
from
them
and
if
not
on
as
much
as
I'm,
trying
to
remove
pain
from
sig
leads.
This
is
a
process
where,
if
we
break
somebody's
ability
to
tag
a
milestone,
it's
very
trivial
and
easy
to
notice
that
they,
the
bots
gonna,
tell
them.
You
no
longer
have
privileges.
They're
gonna,
ask
hey:
where
did
my
privileges
go
and
I
mean
it?
B
B
And
that
ultimately,
will
be
much
better
because
there's
clear
visibility
on
it,
but
even
then
we'll
need
to
have
understanding
of
what
the
preferred
mechanism
is.
Do
you
inherit
via
the
owners
aliases
or
do
you
have
automation
that
consumes
the
github
team
so
that
there's
there's
not
fuzziness
there.
B
The
but
you
can
have
automation
that
does
it
get
hub
query
against
the
team
membership
or,
if
you
have
automation,
that
there's
a
check
out
of
KK
and
uses
the
contents
of
its
owners,
alias
that's
also
mechanically
viable
Brett.
B
G
Just
one
question:
so
after
proposed
changed,
him
will
milestone,
be
the
only
blocker
or
we
have
also
the
critical
urgent.
So.
B
All
the
existing
criteria
would
still
exist,
so
that
includes
like
a
stick
label.
The
the
critical
urgent,
nothing
else
in
terms
of
the
the
labeling
would
would
go
away
still
need.
It
looks
good
to
me
approved
all
of
all
of
that
sort
of
stuff,
so
code
freeze
has
always
just
been
an
additional
layer
of
labels.
So
my
proposal
is
to
condense
it
down
to
to
one
additional
okay.
C
So
well,
my
understanding
was
and
again
I.
Don't
I,
don't
really
touch
the
code
database,
but
my
understanding
was
the
priority
is,
was
also
used
for
the
milestone.
Much
Munter
so
now
sets
yes.
So
now
that
the
milestone
mentor
is
gone
and
we
still
have
priority,
how
are
we
getting
on
priority?
Are
we
getting
on
priority
there.
B
Is
nothing
today,
but
code
freeze,
as
has
been
implemented
in
the
past,
has
been
adding
a
so
turning
on
code
freezes
a
commit
that
adds
a
set
of
required
labels,
which
has
been
the
approved
for
milestone
and
the
the
milestone
v1
dot
whatever
and
then
those
things
those
that
commit
gets
basic
effectively.
Reverted
at
the
end
of
code,
freeze
to
turn
code
freeze
off.
So
what
this?
What
my
proposal
would
be?
C
B
C
B
Priority
is
important
that
that's
as
always,
that
part
has
not
changed
and
but
like
if
you're
asking
conceptually
I,
do
think
it's
important,
because
that
is
in
early
triage.
One
of
the
ways
that
we
we
highlight
so
issue
comes
in
when
we
say
like.
Oh,
my
goodness,
this
is
a
big
deal
or
or
it's
not,
and
that
first
splitting
allows
everybody
to
understand
like
should
we
focus
on
this?
Should
we
try
and
get
it
into
the
release?
B
So
if
a
priority
label
is
something
that's
on
the
lower
end
of
the
spectrum
that
will
currently
be
blocked
from
merging
in
the
through
the
submit
queue
during
code,
freeze
and
I
think
that's
that
continues
to
be
good
and
it's
been
reasonable
for
somebody
who
wants
the
thing
to
merge
to
go
and
lobby
through
the
sig
to
say
hey,
we
need
to
elevate
the
priority
on
this
and
it
is
really
critical
urgent.
So
I
think
priority
is
a
good
functional
mechanism
there
that
we've
been
using
successfully
okay.
C
B
B
C
C
B
B
So
I
I
haven't
explicitly
talked
about
this
with
Aaron,
but
I.
Think
Aaron
would
very
quickly.
I
feel,
like
he's,
got
some
magic
automation
in
the
background,
but
I
know
it's
just
like
his
his
spidey
sense
he'd
be
like
okay,
now,
I'm
gonna
remove
all
those
labels,
so
I
do
expect.
That's
a
logical
next
proposal,
yeah.
B
B
D
B
C
B
Right,
well,
we
will
repeat
tomorrow
for
Asia
and
Europe,
easier
time
zone
attendance
and
go
through
this
and
Mohammad.
Definitely
let
us
know
if
you
need
any
additional
help
on
CI
signal
this
week.
I
think
for
all
of
us.
This
is
the
the
priority
to
help
out
any
any,
where
possible,
to
to
get
those
conversations
turned
into
concrete
action
lists
and
get
the
signal
cleaned
up.
Yeah.