►
From YouTube: Kubernetes 1.12 Release Team Meeting 20180821
Description
B
B
B
B
B
B
Out
of
this
big
set
that
originally
was
66
features
as
time
goes
by
things
start
to
fall
away
because
they
just
weren't
being
gotten
to
so
I
still
think
that's
going
to
be
the
case,
looking
at
some
of
the
features
in
the
list
and
looking
at
status
on
github
of
things,
but
nothing
formal.
So
the
there
was
just
some
back-and-forth
about
that.
There
were
a
couple
in
particular
that
were
discussed.
B
Actually
only
one
of
them
hit
the
minutes,
but
it
was
more
sort
of
early
speculation
and
nothing
concrete
had
been
decided
quite
yet
so
we'll
get
more
specific,
hopefully
in
the
next
couple
of
weeks,
and
then
by
that
point,
where
we're
getting
very
close
or
in
two
weeks
we're
hitting
code
for
you.
So
it'll
be
very
obvious
at
that
point.
If,
if
somebody
hasn't
written
code
and
we're
at
code,
freeze
then
kind
of
got
a
face
reality
at
that
point,
the
particularly
big
thing
this
week
to
call
out
was
in
test
infrastructure.
B
B
We
focused
on
the
release,
master
blocking
and
the
release
master
upgrade
there
and
in
those
names
master
refers
to
the
master
branch.
So
last
week
we
created
the
release,
1.12
branch
and
now
there's
corresponding
testing
and
test
grip.
That's
happening
on
that
branch
in
addition
to
master.
So
in
the
minutes,
I've
got
those
two
linked,
and
at
this
point
they
they
basically
are
the
same
thing
as
master
we've.
B
We
forged
the
branch
but
daily
the
the
content
of
Master
is
being
fast
forwarded
or
merged
through
get
over
to
the
release
branch
because
we're
early
in
the
cycle-
and
there
is
basically
just
a
tracking
branch,
so
master
test
is
actually
still
important.
This
was
a
question
yesterday.
Do
we
still
pay
attention
to
the
master
branch
testing?
And
yes,
we
do
because
that
moves
over
sort
of
once
a
day
into
the
release
branch
and
it's
our
initial
heads-up.
B
It
definitely
becomes
cherry-picks
because
then
master
reopens
and
we've
got
113
development
just
steaming
ahead,
and
we
want
to
only
pull
things
that
are
specific
key
fixes
back
into
112,
so
they
they
slowly
start
to
diverge
and
actually
there
there
is
I
believe
just
one
commit
currently
on
the
released
112
branch,
that's
different
because
how
the
api's
are
automatically
generated.
That
has
to
be
versioned
and
at
the
point
that
112
moves,
it's
got,
the
112,
versioning
and
master
can
start
moving
forward.
B
B
A
B
I,
don't
understand
exactly
the
history
of
why
I
feel
like
the
the
main
friction
that
I've
seen
is
at
the
integration
point,
and
especially
this.
This
usually
crops
up
a
little
bit
later
in
the
cycle.
So
right
now,
we've
got
a
bunch
of
work
going
on
on
implementation
and
over
the
coming
weeks,
that's
really
gonna
start
to
land.
B
People
have
to
get
things
in
a
head
of
code
freeze
if
two
or
more
parties
have
been
working
on
semi-related
code,
but
I
haven't
been
interacting,
we
start
to
see
either
merge
conflicts
or
something
break-in
test
and
I
feel
that
that's
kind
of
a
symptom
of
not
using
feature
development
branches
earlier,
because
if
you
have
those
feature
branches,
you
can
enable
tests
on
them
and
they
become
a
pre
integration
point.
So
if
a
particular
cig
is
working
on
something
big,
they
can
start
doing
stuff
in
a
particular
branch.
B
Together,
that's
not
master,
and
they
can
start
to
prove
out
that
things
work
there
as
a
unit,
and
it
becomes
a
point
also
where
you
get
a
little
more
visibility.
If
I've
heard
about
sig
sig
who's
working
on
feature
bar
I
can
go.
Look
at
that
branch
I
can
clone
it.
I
can
check
it
out.
I
can
play
with
it.
I
can
see
what
they're
doing,
if
maybe
I've
heard
that
they're
doing
this
particular
feature
and
I
wonder
how
they're
gonna
do
something
that
maybe
could
impact
me
depending
on
the
implementation.
B
I
can
go,
look
at
it
a
little
easier
when
it's
sitting
there
and
I
could
maybe,
if
I've
got
some
code
that
I'm
thinking
out
build
on
top
of
it.
I
could
start
working
on
on
that.
B
A
A
B
Surprises
that
I've
seen
have
been
things
that
merged
accidently,
which
is
actually
kind
of
amazing
I.
Think
given
there's
like
six
or
seven
labels,
that
a
lead
has
to
apply
to
an
issue
to
say
yes
actually
merge
this
during
code
freeze
and
then
to
have
something,
come
back
and
be
a
hoops
that
was
for
the
next
release.
B
So
they're
the
branch
manager
as
they
get
to
the
point
of
doing
fast
forwards
later
in
the
release.
Ideally
we're
only
seeing
a
few
commits
a
day
and
they
can
look
through
them
and
say
like
does
this
seem
plausible
for
this
release
or
something
that
was
maybe
more
forward,
and
then
we
either
have
to
revert
that
or
cherry-pick
around
it
in
terms
of
testing
I
think
that
testing
is
one
of
the
current
concern
areas
broadly
in
the
project
so
like.
B
If
you
look
at
conformance
conformance
testing,
it
has
a
pretty
low
percentage
coverage
and
to
me
that
means,
if
we're
making
a
release,
we
want
to
know
that
that
release
doesn't
break
users.
If
you
don't
have
a
lot
of
code
covers
there,
you
can't
make
a
high
confidence
assertion
on
that.
So
that's
an
area
that
I
think
is
currently
weak,
but
that
hasn't
necessarily
translated
to
friction
and
and
I'm,
not
sure.
B
Yeah
there's
something
else
is
gonna
say
about
test
Oh
as
I
actually
see
a
lot
more
potential
friction
going
forward,
so,
as
most
of
the
code
had
been
in
the
kubernetes
kubernetes
repo,
it's
easier
to
track,
and
if
you
get
some
little
friction
points
that
are
an
integration,
you
notice
them
more
quickly.
Is
we
split
the
monolith
in
two
separate
repos?
Something
may
seem
consistent
in
the
cake,
a
repo
itself,
but
then
later
other
consumers,
whether
it's
just
a
development
perspective
within
the
project.
B
B
Today,
it's
in
the
the
cluster
life
cycle
meeting
and
talked
to
them
about
what
we're
seeing
in
tests
and
get
a
little
bit
more
triage.
A
few
of
the
things
are
liable
to
be
cluster
lifecycle
upgrade
itself
versus
tests
that
are
running
in
a
particular
domain
after
the
upgrade
is
seemingly
succeeded.
B
If
we
don't
have
a
clean
signal,
we
aren't
gonna
be
able
to
tell
which
new
code
destabilize,
something
is
just
basic
software
engineering.
You
have
to
do
that
top
velocity,
so
we
gotta
get
this
stuff
resolved
this
week
and
that
the
the
worry
is
that
if
we
don't,
then
we
need
to
start
thinking
about
elongating.
The
code
freeze
and
my
bias
would
be
to
pull
it
in
so
have
it
start
sooner.
B
Sig's
aren't
gonna
like
that,
because
they're
planning
to
get
completion
by
a
certain
date,
but
the
alternative
is
to
have
the
release
late.
If
we
release
late,
especially
in
this
cycle,
that
means
the
next
release
is
either
going
to
be
a
very
short
cycle
or
pushes
into
January,
because
that
release
most
likely
will
be
kind
of
the
middle
of
December
right
before
the
end
of
the
year
and
there's
a
an
awkward
gap
with
holidays
through
December.
B
Bugs
not
much
to
say
we
continue
to
have
a
low
volume
of
reported
bugs,
and
it's
kind
of
expected
at
this
point.
Not
there's
not
a
huge
focus
on
trying
to
use
things
that
are
coming
in
to
the
release
at
this
point,
because
it's
just
a
little
bit
too
early,
so
I'm
not
seeing
reports
then
of
issues
to
slightly
new
things.
We
don't
normally
talk
about
Docs
and
release
notes,
so
documentation
is
hitting
a
deadline
just
to
open
a
PR.
B
That's
trailing
so
it's
made
it
difficult
for
the
docs
team
to
try
to
pull
everything
together.
Just
it's
last-minute!
So
last
cycle
we
trialed
kind
of
nudging
people
a
little
earlier,
like
hey,
open,
a
PR.
Just
let
us
know
what
files
you
intend
to
edit
like
that's,
not
a
particularly
onerous
task.
It
doesn't
take,
but
a
couple
of
minutes
to
do
so.
That
seemed
like
it
was
successful
in
the
last
release.
B
B
Seven
PR
is
open,
so
not
a
huge
response
yet,
but
they
were
pushing
more
aggressively
yesterday
to
try
to
get
more
folks
to
meet
the
deadline
today
and
then
release
notes,
I
checked
in
just
because
I
wanted
to
see
if
Nick
had
any
questions
or
concerns-
and
he
said
I
checked
back
in
a
week
or
two
and
it's
early
right
now,
not
as
much
stuff
has
merged
and
there's
not
so
many
things
that
have
come
in
with
a
particular
release.
Note
tag
in
the
issue
or
the
the
PR.
So
a
little.
B
B
B
Freeze
so
code
freeze
is
mechanically
enforced
and
the
submit
queue
looks
at
incoming
PRS
how
they're,
labeled
and
tagged
and
github
and
traditionally
code
freeze,
one
of
the
labels
that
was
required
was
this
status
approved
for
milestone,
I,
think
this
goes
back
a
year
or
so
to
when
these
status
labels
had
gotten
implemented,
but
it
just
isn't
really
working
and
and
really
what
you'd
often
see
is
we're
in
code.
Freeze
somebody's
come
up
with
a
PR.
B
It's
clearly
good
everybody's
approved
and
it's
not
merging,
and
you
see
like
almost
the
the
mashing
on
the
keyboard,
like
adding
of
labels
like
trying
to
fit,
remember
and
figure
out.
How
do
we
make
something
merge
and
code
freeze,
because
on
the
release
team,
we
have
a
little
bit
more
focus
on
this,
we're
thinking
about
it,
but
the
broader
community,
random
person
who
opens
a
PR,
doesn't
know
about
this.
B
Now
your
cig
leaves
and
approvers
should
understand
it,
but
right
when
code
freeze
first
starts,
maybe
it's
not
on
the
top
of
their
mind,
so
you'll
you'll
just
suddenly
see
a
flurry
of
labels
get
applied
where
somebody's
just
trying
to
assert.
Yes,
I
really
do
approve
of
this.
So,
given
that
that's
the
case,
we
have
two
seemingly
redundant
things
that
we
do
when
we
set
the
milestone
on
the
pr2.
We
label
it
status,
approved
for
milestone
and
because
those
are
kind
of
coming
as
a
pair.
B
My
proposal
is
that
we
just
drop
one
of
them
and,
at
this
point,
we're
not
really
using
those
status
labels
anywhere.
So
a
follow
on
assuming
there's
no
strong
objection
to
this
is
a
follow
on
will
probably
be
that
we
actually
drop
those
labels
from
from
our
label
seeking
across
the
repos
in
the
org.
So
if
you
have
any
thoughts
on
that
feel
free
to
chime
in
on
the
mailing
list,
hopefully
this
is
just
a
little
bit
of
a
simplification
and
I.
B
Our
process
here
is
kind
of
loose
and
we
could
do
better
from
a
process
perspective.
But
if
we
onedrive
process
changes
in
the
community
and
the
current
process
is
kind
of
feels
heavy
to
people
and
they're
they're,
maybe
not
project
management
minded
enough
to
think
about
like
there
is
a
point
to
understanding
where
we
are
in
the
status
of
an
issue
as
it
evolves.
B
They
just
see
friction
there
to
get
their
code
merged.
So
I
see.
This
is
maybe
just
one
little
token
of
goodwill
to
say,
like
hey
those
of
us
who
are
looking
at
this,
we
do
actually
want
your
process
to
be
light
to
have
less
friction.
So
here's
some
less
friction
for
you
we'll
be
looking
at
making
bigger
process
changes
in
the
future
to
make
it
a
more
robust
system.
But
then
we
kind
of
set
the
bar
that
we
intend
to
keep
friction
low
and
whatever
we
do
for
process
changes.
B
B
Went
to
three
to
the
kubernetes
dev
list
and
you
just
don't
check
that
I
say
that's
right
to
kubernetes
dev
list,
which
is
which
everybody
should
subscribe
to
if
they're,
if
you're,
not
it
went
to
the
kubernetes
sic
leads
list,
which
is
just
it's
a
relatively
short
list
of
sig
leadership,
and
then
I
also
sent
it
to
the
milestone
burned
down,
which
is
the
list
which
this
meeting
is
the
calendar
invite
us
into.
So,
if
you
have
a
calendar
invite
for
this,
you
should
have
gotten
it.
B
B
I
am
as
much
as
I
sent
this
out
to
like
6000
people
or
something
I,
I
suspect
like
six.
Who
will
see
it.
It's
one
of
those
things
in
a
big
community
with
lots
of
email
flying
by
you
never
know
how
much
people
see
it.
I
would
like
to
hope
that
the
cig
leads
email.
The
cig
leads
at
least
filter
that
to
hit
their
eyeballs
a
little
more
than
just
getting
filtered
away,
but
and
that's
a
very
low
volume
list.
So
hopefully
it's
getting
seen.