►
Description
This is our weekly community meeting, for more information check this page: https://github.com/kubernetes/community/blob/master/events/community-meeting.md
A
All
right
welcome
everybody.
It
is
the
kubernetes
community
meeting.
It
is
Thursday
July
28th
to
2018
I.
Am
your
host
today,
Jay
singer,
Dumars
I
work
at
Google,
okay
and
we're
going
to
have
the
regular
community
meeting
today
and
a
special
thing
that
happens
every
three
months,
which
is
the
release
retrospective,
where
we
have
some
high-level
discussions
about
what
happens
during
these
last
three
months
as
we've
created
the
next
iteration
of
committees
so
to
get
started.
If
somebody
in
the
audience
is
feeling
adventurous
and
wants
to
take
notes,
that
would
be
super
helpful.
A
B
All
right
so
I
got
roped
into
this,
because
I
think
Justin
Cormack
from
doctor
signed
up
for
it,
and
then
he
was
traveling
today.
So
hopefully
this
was
this
little
fit.
What
Justin
was
going
to
show
you
I'm
gonna,
try
and
kind
of
briefly
go
over
container
D
and
then
show
demo
of
a
cluster.
That's
that's
running
container
D
as
a
runtime
underneath
kubernetes.
B
So
brief
background
container
D
has
been
around
for
a
couple
years.
It
existed
about
the
time
that
run
C
and
the
OCI
work
started
up.
Docker,
specifically
Michael
Crosby,
created
as
a
supervisor
for
run
C
processes,
so
docker
would
be
disconnected
from
driving
Brendan
C
directly
in
the
last
year
and
a
half
that
was
spun
out
into
a
more
formal
project.
Several
other
contributors
got
involved
and
then
it
was
contributed
to
the
CN
CF
lots
last
March
and
so
I
assume
everyone
kind
of
knows
that
background.
Obviously
the
idea
is
hey.
B
Container
D
could
be
useful
as
a
stable
runtime
without
Dockers
sort
of
opinionated,
client
and
other
pieces.
Just
the
runtime
just
driving
the
OCI
run
C
binary
with
container
D
100
added
the
additional
features
needed
to
buy.
For
example,
the
CRI
with
image
registry
interactions
which
didn't
exist
in
the
original
container
D
project,
like
I
said,
has
been
going
for
for
quite
a
few
years
now,
a
good
number
of
contributors
over
time.
B
This
data
is
roughly
accurate
but
of
course,
because
container
D
existed
long
before
the
container
d1o
project
in
a
relative
sense,
because
we're
talking
about
an
extra
year
or
so,
but
about
the
first
half
of
its
life,
had
some
activity
from
folks
who
no
longer
contribute,
obviously,
with
red
hat,
focusing
on
creo,
they
are
truly
contributing
to
container
D
but
obviously
had
some
activity
here
as
well.
It's
in
the
CN
CF
overseen
by
mobi
technical
steering
committee,
which
is
separate
from
Dockers
original
btfo
model.
B
Obviously
the
intention
of
container
D
was
kind
of
rethink
some
of
the
original
docker
engine
decisions
around
design.
So
a
lot
of
us
feel
it
has
a
cleaner,
of
course,
LG.
Our
PC
based
design
with
discrete
components,
the
main
focus
being
just
run
OC
on
containers,
don't
get
involved
in
abstracting
that
so
OC
is
a
straight
pass
through
and
if
we
have
enough
time
to
dig
that
far
you'll
see
that
when
kubernetes
CRI
calls
the
root
container,
D
or
any
other
runtime,
it's
just
a
no
CI
spec.
B
That's
not
modified
or
rehab
stur
acted
by
container
D,
a
lot
of
focus
around
stability
and
performance
and
decoupling.
These
various
systems
that
in
the
docker
engine
over
the
years
had
become
a
little
too
tightly
coupled
currently
we're
at
1:100
released.
Back
in
april,
we
have
a
1
1
1,
that's
NRC,
available
this
week.
1
2
is
kind
of
our
next
point:
release,
adding
more
complete
windows
support
and
a
few
other
things
coming
in
there.
B
Obviously
docker
continued
to
continues
to
use
container
D.
They
switch
to
the
container
d
1x
codebase
as
of
late
last
year,
although
docker
doesn't
use
all
the
features
of
container
D.
There's
still
refactoring
has
to
happen
for
docker
to
get
rid
of
some
code
and
use
container
DS
implementation,
for
example,
snapshot
drivers,
which
replaces
the
graph
driver
concept
in
docker
proper.
B
Obviously,
we're
gonna
look
at
the
kubernetes
CRI
and
the
CRI
plug-in,
which
was
a
separate
project
now
part
of
the
container
d
upstream
github
project
linux
kit
and
build
kit
projects
you
may
or
may
not
have
heard
of
our
heavy
users
of
container
d
as
well.
The
Cloud
Foundry
community
has
a
run
C
based
executor,
but
they're
proposing
moving
to
container
D.
We
have
people
at
IBM
on
the
open,
wisk
serverless
framework,
looking
at
using
container
D
as
an
executor
vs.
the
doctor
engine,
and
there
are
other
companies
puppets
using
it
as
well.
B
B
You
can
see
that
effectively
I'll
skip
talking
about
this,
because
there
was
a
great
blog
post
that
came
out
last
month
about
the
integration
going
G
a
LAN
town
from
Google
and
Mike
from
IBM,
contributed
to
this
and
there's
a
lot
of
great
information
in
there
about
the
design
and
architecture
and
some
performance
metrics
of
using
docker
versus
container
D.
As
the
runtime.
B
Where
things
are
today,
you
can
obviously
deploy
container
D
via
Kelsey's
the
hard
way
repo.
As
far
as
public
clouds
GK,
he
came
out
with
our
alpha
release.
You
can
you
can
deploy
an
alpha
supported,
container
deep
cluster
IBM
we're
currently
using
well
testing
kubernetes
1.11,
which
of
course
was
released
yesterday
in
staging
using
container
d
and
that'll,
be
something
we
push
to
production
later
this
year,
Gabe
for
Microsoft
mentioned
that
aks
is
definitely
moving
the
container
D
at
some
point.
You
can
already
see
some
of
that
deployment
technology
and
their
ACS
engine
project.
B
B
Yeah
I
I
hate
to
say
I
can't
make
an
exciting
demo
out
of
container
runtimes
underneath
kubernetes,
so
this
can
be
as
quick
as
we
want
I'm
sitting
on
a
worker
node
in
actually
it's
IBM
cloud.
We've
got
a
container
d
here:
well,
a
cluster
effectively
named
container
D
that
has
two
worker
nodes,
I'm
logged
in
to
one
of
the
two
worker
nodes.
Obviously
you
can
see
the
kubernetes
1.11,
you
can
see
I,
don't
have
docker
installed
here,
but
obviously
there's
many
container
d
processes
running,
including
everything
that's
running
the
the
pod.
B
So
if
I
do
cry
cuddle
PS,
we
can
see
again
the
dashboard
and
genetics
other
pods
running
here
and
if
I
use
the
container
D
client,
we
can
also
see
that
same
view
through
container
D.
So
obviously
container
D
is
is
driving
the
workloads
on
this
kubernetes
cluster
and
obviously
we
we
could
deploy
things
we
could
buy.
B
A
A
C
Yes,
there's
a
pull
request
there
that
you
want
to
link
to.
We
have
303
github
teams
and
that's
not
becoming
very
workable,
so
Christoph
has
opened
a
proposal
for
us
to
look
at
how
we're
organizing
that
and
try
to
make
something
same
out
of
it.
So
please
follow
through
if
you
have
strong
opinions
on
to
the
link.
Thank
you.
A
And
shoutouts
this
is
a
very
busy
shout
out
season
because
of
the
release
and
all
the
great
things
happening,
so
shout
outs,
Josh,
Jordan,
Lincoln
for
diagnosing
and
fixing
the
controller
performance
issue
that
is
haunted
us
since
last
August
and
to
Julie
Evans
for
reporting
original
issue,
another
plus
one
day,
Jordan
Liggett
for
always
helping
anyone
with
an
off
question
of
the
channel
kindness.
Also
I
could
buy
myself
I
had
a
shout
out
Parris.
Thank
you
for
all
of
your
work.
A
Helping
to
keep
our
community
safe
and
inclusive
I
know
that
you've
spent
countless
hours
or
funny
or
zoom
usage,
documenting
testing
and
generally
being
super
proactive
on
this
people
have
no
idea
how
much
you
do
Parris
behind
the
scenes,
and
thank
you
so
much
for
that.
Nikita
shout
out
to
Christoph
lekker
for
excellent
meme
skills.
That
is
absolutely
true.
Mr.
Bobby
tables
I
just
want
to
give
a
big
shout
out
to
a
whole
release
team.
Thank
you
for
your
effort
and
getting
one
living
out.
The
door
slightly
smiling
face
serious.
A
great
job.
A
Misty
entered
chin
for
last-minute
111
Docs
related
her
ox
tunic
chase
for
amazing
release.
Notes,
Josh,
burkas
from
being
a
very
patient
and
available
release
lead,
and
this
was
Misty's
first
time
of
the
release
team,
although
you
would
never
know
it
because
misty
did
the
most
amazing
stuff,
Thank
You
misty,
for
all
that
Josh
Jordan
for
last-minute
trip
and
today
Chase
for
marathon
release,
notes
log,
yes,
Josh
to
a
whole
bunch
of
people.
Truly.
This
is
the
111
release
team.
He
says
best
release
team.
A
Yet
as
a
former
release
team
leader,
I
I,
think
we've
had
all
great
release
teams,
but
you
can
say
that
Josh
I
totally
get
it
and
the
release
team
back
at
Josh,
amazing
leadership,
Josh
and
and
I
felt
so
confident.
Turning
the
release
process
over
to
you.
Thank
you
for
all
of
your
hard
work,
those
truly
impressive
and
to
everybody
else,
the
thousands
of
contributors
during
the
the
release
process.
A
This
is
my
personal
thanks
to
you
for
all
of
the
things
that
you
did
for
all
the
hours
that
you
spent
maintaining
a
high
level
of
trust
between
the
communities
project
and
the
people
who
use
communities
for
their
livelihoods,
so
alright
without
further
ado,
we're
going
to
roll
into
the
release
retrospective.
There
is
a
link
in
the
community
meeting
notes
to
the
retro
doc.
I'm,
not
gonna,
screen
share
I'm,
just
gonna
go
ahead
and
go
through
it,
so
screen
share
along
if
you'd
like
and
we'll
go
from
there.
A
So
one
thing
we're
doing
differently
this
time
in
our
spirit
of
iteration
is
that
we
are
paring
down
the
main
points
of
the
released
retrospective
that
are
sort
of
at
a
higher
community
level
and
going
over
those
in
this
meeting,
as
opposed
to
depth
analysis
of
all
the
things
and
the
reason
we
want
to
do
that
is
just
for
time
sake
and
also
that
sync
release
originally
was
supposed
to
be
organized
around
making
the
release
process
better.
So
a
lot
of
these
deep
comments
and
and
feedback
mechanisms
are
better
served
by
stick
release
so
fYI.
A
This
is
probably
how
we're
going
to
do
it
moving
forward.
I
will
make
a
personal
note.
This
is
the
two-year
anniversary
of
the
first
released
retrospective
I
held
the
kinase
project
so
back
in
2016.
This
is
how
this
all
started.
So
it's
nice
to
see
it
still
happening
in
still
thriving,
so
first
up
we're
going
to
go
through
things
that
worked
and
we
should
do
again,
but
before
I
I,
just
want
to
say
that
if
you
are
participating
in
the
retro,
please
be
respectful
of
other
people's
feelings.
A
Opinions
and,
with
your
communication,
be
solution-oriented,
make
sure
that
you
meet
when
you're,
not
speaking
and
respect
time
boxes,
and
if
you
have
some
sort
of
concerns
about
anything,
that's
happening
this
retrospective,
please
private
message
myself
or
Paris,
and
let
her
know
so
that
we
can
intervene
if
you
feel
like
this
is
not
a
safe
environment
for
you
to
share
your
feelings
or
that
you
feel
that
something
that
is
happening
in
this
retrospective
is
not
in
alignment
with
with
your
with
your
needs.
So
please
do
that
and
moving
forward
Zach.
Are
you
on
the
call?
D
Cool
thanks,
I
loved
the
more
aggressive
Doc's
deadline
than
110
I
wasn't
part
of
the
110
process,
but
I
personally
thought
that
when
we
had
the
the
real
push
to
make
sure
that
everything
that
was
going
to
be
merged
was
already
documented,
then
it
kind
of
forced
a
higher
level
of
quality
through
I,
think
the
code
and
and
even
I
think
it
continued
to
push
us
forward
and
we
actually
hit
every
single
deadline.
I
think
the
release
was
off
by
one
day,
which
I
mean
for
three
months
out:
I.
Think
it's
absolutely
incredible.
D
The
lots
of
things
contributed
to
it,
but
I
just
thought.
The
more
aggressive
Doc's
deadlines
certainly
contributed
to
making
sure
like
okay,
we
know
exactly
what's
going
on,
because
if
it's
well
documented,
then
you
know
pretty
much
what
your
feature
is
going
to
look
like
when
Doc's
come
like
right
at
the
end,
that's
like
okay,
I
can
wait,
I
can
wait,
I
can
wait.
I
can
wait,
I
didn't
make
it
nevermind
cool.
E
I
generally
agree
with
the
practice,
but
I
think
the
reality
behind
a
lot
of
situations
is
that
the
documentation
either
falls
out
of
legs.
The
release
entirely
or
is
not
part
of
the
actual
PR
itself.
If
we
had
a
blocking
change
that
says
before
your
feature
can
go
to
Bay
or
before
your
feature
can
get
to
alpha
state,
you
have
your
docs
are
required
as
part
of
this.
That
would
be
a
forcing
function,
actually
ensure
that
we
have
docs
percent
feature,
but
instead
we
kind
of
went
what's
actually
missed
here.
E
Is
that
there's,
probably
a
bunch
of
stuff
that
went
in
that
were
not
well?
It
wasn't
documented
off
because
there's
always
a
push
at
the
end
of
the
cycle
to
get
the
code
in
right
and
because
the
docs
freeze
was
at
a
date
right
near
the
code.
Freeze
I'm,
almost
certain
that
this
is
the
case.
I'd
have
to
dig
through
the
code
to
get
a
good
handle
on
it,
but
I'm
pretty
sure,
given
history
that
this
is
probably
what
has
transpired.
Okay.
D
I
think
JA
I
mean
Josh.
Burke
has
also
had
an
alternative
like
going
beyond
just
a
features
tracking
spreadsheet
that
we
had.
He
had
a
111
milestone,
PR,
spreadsheet
and
individually
went
through
almost
every
single
day,
looked
at
every
PR
and
said
okay,
this
looks
like
it
might
need
dogs
this.
Might
this
might
not
this
one,
maybe
I'm
not
sure
when
we
made
sure
to
follow
up
with
everybody
that
looked
like
it
would
probably
need
documentation,
but
I
think
you're
right
it
it
does.
It
does
pose
a
problem
too
cool.
A
F
It
gave
everybody
a
little
bit
more
time
to
work
on
development
and
they
certainly
were
because
the
number
of
PRS
we
had
literally
hours
before
code
free
started
was
huge
I
and
you
know
I.
This
is
up
to
Tim,
of
course,
but
I
think
we
can
plan
on
sticking
to
a
shorter
code
freeze.
Now
there
are
other
things
we
want
to
tinker
with
in
the
schedule
that
we'll
get
to
later
on,
but
I
think
the
shorter
code
freeze
was
a
success
in
something.
Would
you
try
to
stick
with.
E
Sinclair
I
think
the
reason
the
shorter
code
freeze
was
good
in
the
cycle
is
because
I
did
an
awesome
job
as
this,
the
test
signal
lead
I,
think
without
that
it
probably
wouldn't
have
gone
as
well
so
shut
up
there
as
well
as
if
we
want
to
be
able
to
make
this
productive.
We
need
somebody
who
can
manage
that
workload.
F
Yeah
so
well,
yeah,
there's
one
of
the
parts
of
that.
By
the
way
it
was
one
of
the
things
that
delayed
the
110
release
was
performance,
scalability
issues
that
didn't
even
get
looked
at
until
code
freeze,
alright.
So
this
time
we
made
sure
to
look
at
those
early
and
then
the
six
scalability
team,
because
shyam
and
would
Jack
stepped
up
and
created
a
performance
presubmit
as
part
of
our
our
acceptance
testing
and
the
result
was
that
passing
the
performance
test
became
an
on
concern
for
this
release
and
and
did
not
result
in
delays.
G
So
this
was
my
first
release
so
as
part
of
being
oh,
the
risk
of
being
over
Bobo's
I
started
sending
out
the
CI
signal
reports
every
week,
which
I
think
helped
in
two
ways
a
it
helped
me
as
a
sig
signally
to
actually
scrub
the
different
issues
regularly
on
a
weekly
basis.
This
is
like
looking
at
it
at
the
last
minute
and
also
be
it
really
I
think
helped
get
a
lot
of
SIG's
and
developer
attention
on
these
issues
early
in
the
game
and
as
Josh
and
Jim
is
saying.
This
really
helped
us.
G
This
went
a
long
way
in
actually
making
the
code
free
shuttle.
So
one
thing
that
I
would
like
to
propose
again:
it's
it
depends
on
the
CI
leader
and
depends
on
each
release.
Team
is
making
sending
out
these
reports
as
part
of
the
signal
lead,
see
a
signal
lead
workload
itself,
because
I
believe
this
will
really
help
folks
to
get
early
insight
into
the
failures
and
step-like
things.
Wave
has
yeah.
F
F
People
did
not
blow
her
off
and
say
well
we're
still
four
weeks
out,
you
know
five
weeks
out
from
code
freeze,
oh
look
at
that
later.
They
responded
and
they
actually
fixed
the
problems
again,
so
that
that's
like
a
big
thank
you
to
all
of
our
contributors
for
treating
stuff
as
urgent,
even
if
it
wasn't
yet
code.
Freeze,
yes,.
F
In
addition
to
Isis
CI
reports,
two
things
no
one
is
in
addition
to
Isis
CI
reports.
I
actually
put
it
some
periodic
release
status
reports
I'm
just
what
was
going
on
with
the
release
and
release
status.
I
didn't
really
get
a
sense
from
any
kind
of
feedback
anywhere
either
on
disgust
or
email.
Whether
or
not
anybody
was
reading
those,
and
so
that's
a
wondering
whether
or
not
it's
worth
the
next
release
lead
actually
doing
them
because
I'm
not
I'm,
not
sure
anyone's,
actually
reading
them.
F
The
the
other
thing
that
we
changed
this
time
around
was
we
had
a
couple
people
in
the
team
on
different
continents
in
the
release
team
plus,
we
have,
in
our
contributor
base
a
wider
variety
of
people
in
time
zones
around
the
world,
so
both
for
release
team
meetings,
the
early
once
a
week,
meetings
and
then
later
on
for
the
more
frequent
burndown
meetings
we
alternated
time
slots
and
that
allowed
some
people
to
attend
those
meetings
without
taking
a
meeting
at
9:00
p.m.
their
time
or
worse.
Yet
2:00
a.m.
A
H
If
not
the
process,
the
features
process
that
hasn't
been
that
changed
earned
a
long
time.
It
hasn't
been
changed
for
around
two
years
and
finally
was
dis
released.
We
have
started
moving
forward
with
sweat,
enhancing
it
and
adopting
a
two
different
for
their
royalties,
because
two
years
ago,
their
entire
cabinet,
its
world
anti
cabinet,
its
contributors
and
development
was
totally
different.
H
This
time,
this
time,
I'd
like
to
make
a
shadow,
Steven
Augustus
was
the
feature
shadow
and
he
made
a
huge
number
of
enhancements
to
the
current
features
process
and
did
a
huge
amount
of
job
behind
the
scenes.
I
would
also
would
also
like
to
see
this
moving
focus.
The
upcoming
releases,
especially
we've,
had
a
few
questions.
Why?
Why
do
we
need
a
feature?
Freeze
and
hope
can
deprecated
it
at
all.
So
it's
it's
another
item
for
their
current
discussion,
but
I
definitely
would
like
to
see
the
process
enhance
another
future
purposes.
A
You
were
ten
thousand
Chad
also
features
Misty's
probing
for
does
this
feature.
Have
dogs
from
early
on
was
a
notable
positive?
Yes,
hugely?
Yes,
yes,
alright!
So
moving
on
to
the
meat
of
the
retro
four
things,
we
need
to
change.
So
this
is
really
our
opportunity
to
identify
areas
that
could
it
be
approved.
So
I
just
want
to
reiterate
that
it's
easy
to
get
sort
of
bogged
down
and
negative
feelings
about
things,
sometimes
because
there
are
points
for
its
frustration
or
challenging
as
we
go
through
this.
F
F
The
and
then
the
other
thing
that
I
just
came
in
with
his
suggestion
later
on.
Once
we
got
past
code
freeze,
is
that
the
sort
of
six
working
days
we
currently
have
in
there
for
code
Soph?
That
is
the
time
between
the
end
code
freeze
and
the
time
that
we
release
is
not
really
long
enough
because
it
takes
like
almost
48
hours
for
the
submit
queue
to
clear.
Now
that
may
be
different.
Once
we
move
to
tied,
it
may
be
less
of
an
issue
once
we
moved
to
tied,
but
the
result
was
in
this
cycle.
F
The
so
one
of
the
suggestions
to
shuffle
this
whole
thing
of
when
Doc's
are
due
and
and
still
having
a
shorter
code
freeze
and
everything
else
would
be
to
keep
a
shorter
code
freeze,
but
to
have
a
longer
code
thaw
that
is
a
longer
period
between
end
of
code,
freeze,
an
actual
release,
and
so
that's
kind
of
the
proposal.
There
I
don't
have
a
specific
proposal
number
of
days,
that's
kind
of
up
to
Tim
pepper,
but
that's
what
we
took
out
of
you
know
continuing
to
improve
the
schedule.
A
Tim
Timothy
is
one.
E
I
think
everything
you
said
is
accurate
and
correct.
I
do
think
that
I
think
there's
there's
some
process.
We
need
to
refine
with
regards
to
feature
promotion
and
box
to
make
it
clear
to
developers
land
and
how
we
should
expect
our
documentation
and
also
like
what
things
we
wanted
vacuum
it
because
I
think
there's
like
some
fuzziness
that
exists
with
what
we
consider
a
feature
right
and
what
is
user
facing
and
what
requires
documentation
that
that
fuzziness
and
ambiguity
I
think
is
the
the
reason
for
you
know
we
we
had
problems
that
said
cluster
lifecycle.
G
I
Into
Doc's,
potentially
coming
after
code
test
cases,
don't
always
flow
in
with
code
as
well,
so
that
becomes
a
challenge
as
we're
trying
to
figure
out
which
test
adds
do
yet
add,
potentially
to
stabilizing
things.
Do
we
make
them
blocking
or
not
and
balancing
and
having
sufficient
understanding
of
the
scope
and
depth
of
the
feature
overlaps
across
SIG's
and
an
implications
is
the
thing
just
alpha
versus
stable?
Having
a
lot
of
communication,
there
is
important
for
the
release
team
to
be
able
to
manage
those
choices.
F
A
F
Yeah,
this
will
all
be
part
of
Tim's
sort
of
setting
up
the
calendar
and
so
look
for
email
and
discussed
post
etc
from
Tim
with
a
new
calendar,
because
there
will
be
changes
to
it
that
make
it
different
from
the
110
and
111
calendars.
And
if
you
don't
like
the
changes,
that's
when
you'll
need
to
speak
up
not
waiting
until
those
deadlines
actually
hit.
Okay,.
A
To
that
so
that
can
get
a
contributor
community,
so
I
just
want
to
understand
it.
Alright.
So
let's
move
on
to
feature,
freeze
and
feature
tracking
as
a
meta
item
here
and
then
there's
some
things
under
this
that
looks
like
Josh,
misty
or
and
Steven
F,
so
I'm
gonna
go
ahead,
turn
over
to
you
Josh
and
do
you
mind
sort
of
curating
the
conversation?
Yes
yeah.
F
So
you
know
I'm,
particularly
when
take
the
first
part
of
this,
which
is
the
sort
of
feature,
freeze,
date
and
schedule
and
then
we'll
take
the
documentation,
part
of
it,
which
is
a
a
different
but
frankly
related
problem,
so
feature
free
schedules.
This
is
me
or
Steven
is
Steven
on
the
call.
Stevens.
Are
you
here?
F
F
Freeze
date
now
part
of
the
reason
for
that
used
to
be
for
comes
and
PR,
but
because
of
what
I
observed
after
that
comes
in
PR
stopped
putting
out
blog
posts
based
on
the
feature,
freeze
information,
because
there
was
so
much
that
would
change
about
it,
because,
basically
we
had
this
list
originally,
if
I
believe
forty
three
features
of
which
eighteen
got
dropped
before
the
release,
they
got
pushed
off
to
112.
Something
else
happened
because
of
whatever
problems
with
their
development.
So
that's
you
know
almost
half
of
them.
F
I
got
pulled
out
of
the
release
in
the
meantime,
a
bunch
of
other
things
that
people
had
not
really
expected
to
finish
for
one
eleven.
They
got
to
you
know
a
week
out.
You
know
three
days
four
days
out
from
coke,
slash
and
they're
like
hey.
This
is
basically
done.
Can
we
still
get
it
in,
and
so
I
really
feel
like
this
process
that
we
have
of
having
this
declarative
feature
freeze
in
which
all
the
SIG's
are
supposed
to
list
their
features
by
this
date
a
month
out
from
code.
F
F
We
need
to
mention
in
the
blog
posts
and
everything
and
it's
not
because
we're
both
losing
a
lot
of
the
things
that
are
declared
and
we're
getting
things
that
are
not
declared,
and
then
we
have
trouble
keeping
track
of
so
I
feel
like
we
need
to
change
that
process,
somehow
I'm,
just
not
all
sure.
Now
your.
H
Yeah
yes,
you'd
like
to
second-ever,
send
it
you
said
a
year
or
so
initial
way
of
establish
the
feature.
Freeze
deadline,
mostly
from
the
marketing
perspective,
because
our
goal
was
to
understand
what
other
features
going
to
be
present
in
their
release
and
what
we're
going
to
see
in
this
release
and
actually
was
the
best
time
to
start
working
was
demerged
in
teams
to
merge
engine
from
cnc
aftermarket
indians
from
from
other
companies
who
I
involved
to
go
through
this
process
from
the
amongst
understand
it.
It
seemed
to
him
from
my
experience
in
every
terminators
release.
H
We
had
similar
issues
as
josh
has
just
mentioned,
so
we
had
we've
had
some
defined
list
of
features
around
40
feature
associated
5
features.
Every
every
time
was
ever
to
be
naked
in
terminate
his
release,
but
in
the
next
few
weeks,
before
their
cold
freeze,
we
had
some
of
them
come
from
the
milestone,
go
to
move
to
the
next
next
milestone
because
they
came
in
finished
in
time
and
it
will
spread
a
few
new
propose
because
they
have
been
delivered
without
any
indication.
And
so
so
we
probably
can
simply
remove
the
feature.
F
Well,
pretty
much
I
mean
the
the
other.
The
big
things
are
testing
and
Docs
right,
because
if
something
is
a
new
feature,
it
needs
to
have
documentation
and
it
probably
needs
to
have
test
coverage
not
just
unit
test,
but
also
in
the
test
word,
and
so
the
feature
tracking
sheet
has
been
our
way
to
track
it.
F
And
this
ties
into
the
second
problem-
and
this
is
where
I'm
gonna
call
on
a
misty
as
well,
which
is
one
of
the
problems,
is
that
we
sort
of
treat
these
as
two
different
things,
as
in
you've
got
major
features
that
need
all
of
the
tracking,
and
then
you
have
other
stuff
that
doesn't.
The
problem
is
that
we
have
a
lot
of
things
that
a
lot
of
PR
s
that
involve
API
changes
or
that
involve
changes
to
minor
changes
to
user
interface,
they're,
changing
a
command-line
switch
and
those
things
nevertheless
need
documentation.
F
They
might
need
changes
to
tests
and
we're
not
tracking
that
right
now,
if
they
don't
rise,
the
level
listed
feed
feature.
The
tracking
of
that
is
very
ad
hoc
yeah
and
it's
difficult
for
the
release
team
to
do
because
they
have
to
do
things
like
what
I
was
doing,
which
is
checking
on
the
PRS
after
they
go
in
and
making
a
judgment
call
and
whether
or
not
those
things
needed,
Docs
or
tests
and
then
trying
to
get
somebody
to
pay
attention
to
those,
and
it's
not
very
effective,
so
I
feel
like.
F
We
still
need
something
to
accomplish
the
goal
right.
We
need
something
that
allows
us
to
track
major
features
and
minor
features
as
soon
as
possible.
Why?
Even
from
the
time
that
somebody
thinks
they're
going
to
have
them
done,
even
if
it
means
they
cancel
them
later,
so
that
we
do
track
Docs
and
and
tests,
and
eventually
marketing?
For
these.
F
J
This
because
I
was
thinking
about
the
same
thing
with
regards
to
release
notes
and
whether
or
not
something
needs
to
have
release
notes.
One
one
place
where
we
can
ask
for
help
with
this
is
to
ask
for
viewers
to
make
sure
that
these
things
are
tagged
properly.
So
I
was
going
to
suggest
that,
rather
than
you
know,
if
you're
a
reviewer
and
somebody
says
to
you,
can
you
lgt
em
this?
J
K
Can
I
I
love
that
this
is
misty
I
love
that
suggestion
release
notes
are
really
hard
and
sometimes
the
person
writing
the
code
doesn't
even
know
if
something
needs
a
release.
Note
but
I
think
that,
rather
than
saying
no,
if
you
don't
know,
maybe
reach
out
to
the
docs
team
or
reach
out
to
the
release
team,
to
try
to
help
you
figure
it
out.
I
know
that
Josh
had
asked
my
feedback
on
the
issue
of
tracking
things
that
are
not
tracked
in
kubernetes,
slash,
features
and
I.
K
Think
well
like
we
had
problems
from
both
sides
on
this
one,
because
we
had
like
I
think
it
was
almost
half
of
the
things
that
were
tagged
as
features
didn't
make
it
in.
So
that
seems
like
it
doesn't
necessarily
help
marketing
to
plan
either.
If
that
was
the
original
intent
and
also
there
were
several
things
that
were
late-breaking
surprises
because
they
got
in
through
a
cig,
but
they
weren't
tracked
in
the
features,
and
they
were
features
like
effectively.
They
were
features,
and
we
had
to
like
figure
out.
K
Did
this
thing
actually
make
it
into
111
or
not
in
a
couple
of
places?
And
that's
kind
of
distracting
and
it
also
points
to
the
fact
that
that
thing
might
not
have
test
coverage
it
might
not
have
like
cross
cig
buy-in.
So
maybe
you
put
in
a
feature,
but
it's
gonna
break
somebody
else
in
unexpected
ways.
So
it
seems
like
there
is
definitely
a
communication
gap
I'm
not
necessarily
proposing
a
solution
because
I'm
pretty
new
to
this
project,
so
I
think
we're
doing
great.
But
we
can
definitely
do
better.
F
No
just
you
know,
as
usual,
with
these
things,
where
we
identify
stuff
that
really
need
to
change.
People
should
be
aware
of
should
look
out
for
probably
in
the
community
meeting
on
it.
I'll
leave
this
up
to
Tim
how
Tim
is
going
to
tackle
this
in
terms
of
the
1:12
cycle,
but
number
one.
If
anyone
has
any
ideas
of
how
we
could
do
this
differently,
please
jump
on
sig
release
and
suggest
them,
and
then
look
for
communications
from
Tim
pepper
about
how
we're
going
to
change
the
process.
Yes
and.
A
F
Oh
yeah,
by
the
way
that
was
actually
something
that
was
something
I
meant
to
put
in
on
the
things
that
are
going
well,
that
that
I
forgot
to
put
in,
which
is
that
the
the
amazing
thing
this
time
is.
We
have
a
next
cycle
release
team
pretty
much
completely
staffed
before
code
freeze
was
even
over,
and
so
this
means
that
the
existing
the
111
release
team
is
turning
over
stuff
directly
to
the
next
generation
release
team,
which
is,
which
is
awesome
and
something
I
think
we
ought
to
make
a
habit
out
of
yes.
H
Yeah
and
the
good
thing
about
the
new
team
is
that
almost
the
phone
you
team
is
from
from
the
existing
shadow
members
from
the
press
release
for
those
situations,
especially
from
1.11
and
coming
back
to
this
equation,
still
analysis
who
was
shadow
Fisher's
shadow
for
the
press.
Release
is
going
to
be
elite
in
the
upcoming
release
and
he
is
the
best
person
to
work
on
the
on
the
new
feature
guidance
place.
This
work,
this
team,
your
situations,
can
you
enhance
their
features
purposes,
I'm
stepping
down
this
time.
So
let's
do
it
in
a
basically
I'm.
I
A
A
Wasn't
mine,
I
think
I
might
have
been
filled
with
rock
or
maybe
kale,
oh
by
the
way
Caleb
sends
his
regards.
He
wasn't
able
to
attend
today,
but
you
he
said
he
was
really
wish
that
he
could
be
here
amongst
everybody.
I'm
Caleb
gets
a
shout-out
for
being
amazing.
The
the
the
branch
manager
job
is
very,
very
time-consuming
and
difficult.
It's
very
complicated,
so
shout
out
to
to
that
cuz.
That's
a
no
small
job
testing
Josh.
Do
you
wanna?
Okay,
so.
F
F
Somebody
ought
to
take
this
on
and
it
will
require
somebody
actually
making
a
commitment
that
this
is
their
thing,
which
is
getting
the
betas
and
our
C's
tested,
because
right
now,
if
somebody
random
jumps
into
kubernetes
users
on
slack
and
said,
hey
I've
got
some
free
time.
I
use
kubernetes
I'm
interested
in
helping
test
the
betas.
What
do
I
do
we
have
no
answer
for
them
like
we?
Don't
even
have
installation
instructions
for
the
betas,
the
so
I.
E
This
is
kind
of
a
meta
problem
that
the
release
artifacts
are
not
all
published
as
part
of
every
single
thing.
We
do
and
there's
kind
of
a
separation
of
concerns.
It
would
be
ideal
to
if
we
try
to
push
this
so
that
any
Basile
build
that
anyone
could
do
would
be
equivalent
to
the
all
the
artifacts
necessary
for
a
person
to
be
able
to
beta
test.
G
So
this
is
specifically
around
a
great
testing
so
currently
the
upgrade
downgrade
tests,
they're,
not
part
of
our
release,
block
the
release
blocking
dashboard,
but
as
part
of
one
of
the
action
items
we
took,
we
started
looking
into
them
quite
early
in
the
game,
but
towards
the
end
they
kind
of
became
the
long
pole,
because
these
tests
were
not
historically
always
green.
There
were
a
lot
of
flakes
in
them,
but
the
fact
that
we
were
looking
at
them
continuously
we're
expecting
them
to
stabilize,
and
this
was
the
reason
we
had
a
days
delay
as
well.
G
So
I
would
like
you
to
understand
how
blocking
operators
should
really
be
and
as
part
of
this
and
want
will
probably
weed
out
the
flaky
ones
and
also
the
ones
that
are
not
necessarily
Cuban.
It
is
release
rocking
the
gke
ones
and
then
put
them
in
the
appropriate
dashboards
so
that
more
directly
responsible
teams
can
take
a
look
at
it
on
a
regular
basis.
G
So
that
was
one
of
the
action
items
we
wanted
to
follow
up
on
in
112
and
also
they're
a
bunch
of
cubed
minute
free
tests
that
the
cluster
lifecycle
say
they
constantly
monitor.
I,
wasn't
even
looking
at
the
dashboard
until
into
code
freeze
when
I
learned
about
it.
So
probably
if
we,
if
we
want
that
code,
part
to
be
monitored,
then
we
also
should
somehow
bring
that
into
the
blocking
or
or
have
some
visibility
into
those
DM.
A
F
And
so
the
really
hard
part
about
this
is
going
to
be
honestly
the
upgrade
tests,
because
we're
in
a
situation
where,
if
you
actually
look
at
the
history
of
upgrade
and
downgrade
tests,
the
majority
of
them
fail
most
of
the
time
for
reasons
that
have
nothing
to
do
with
what
code
has
been
checked
it.
So
if
we
move
the
flaky
tests
out
of
there,
we're
going
to
discover
that
we
really
need
new
upgrade
and
downgrade
tests,
the
whether
they're,
based
on
coop,
admit
or
otherwise
right.
L
I
wouldn't
like
that,
I
would
think
that
we
would
restrict
what
tests
are
and
they're
based
on
how
responsive
they
are
because
the
like,
for
example,
the
that
we
have
the
OpenStack
conformist
Selman
right
now
and
DIMMs,
maintains
those
along
with
few
other
folks
over
there.
They're
very
and
that
signal
has
been
good.
Okay
and
it's
not
as
a
cross-reference,
so
I'm
not
sure
that
necessarily
like
external
there's,
a
problem
so
much
as
unresponsive
test
mean
to
you.
Yeah.
F
We're
not
gonna,
hear
anything
from
anybody
for
a
week
and
a
half
and
and
I
think
that
that
will
be
an
issue
with,
because
the
thing
is
for
tests
that
run
on
stuff
that
is
controlled
by
tests
infra.
We
can
always
get
somebody
else
to
take
a
look
at
it,
but
for
the
external
test,
it's
often
not
possible
to
get
somebody
else.
A
Yeah
so
I
think
that
goes
actually
more
to
having
a
formulated
SLA
and
so
basically
that
again
that
if
you,
if
your
tests
fail
and
you're
blocking
for
three
days
in
a
row,
then
your
tests
are
going
to
get
yanked
out
and
you're
gonna
have
to
lobby
with
the
number
of
successive
positive
test
runs
to
get
back.
In
so
I
mean
we
just
have
to
have
the
this
is
ultimately
a
very
human
oriented
process
and
there's
not
much.
We
can
do
about
that.
A
E
It's
also
slowly
confusing
and
that
it's
a
volunteer
army
and
that
all
the
owner
and
the
owner
has
change
over
time
so
like
so,
the
owner
of
some
of
the
cluster
directory
is
pretty
much
Google
and
that
you
know
it's
in
a
six
wheelhouse,
but
the
the
owner
kind
of
shifts
over
time
and
the
may
have
shifted
responsibilities
so,
like
I,
think
keeping
the
owner
references
up-to-date
as
part
of
evaluation.
If
you
see
a
sea
ice
and
you
had
a
trouble
finding
a
person
to
own
it,
we
should
update
the
owner
references.
A
+1000,
absolutely
keeping
those
current
is
huge
and
you
look
at
the
success
of
release
roles.
I
mean
we're
passing.
You
know
huge
critical
parts
of
project
around
to
different
people
successfully.
That
means
this
can
be
done
there.
There
is
absolutely
a
model
through
which
this
works.
We
can
I
issues
yeah.
G
I've
been
as
part
of
from
my
learnings
in
the
past
few
months,
I've
been
putting
a
table
of
like
this
say
this
person
is
most
responsive
ownership.
I,
don't
know
where
to
publish
it,
a
and
B
keeping
it
up-to-date
evolving.
It
is
also
a
challenge,
but
maybe
it's
something
that
can
be
handed
over
from
one
see:
I
leave
you
to
others
that
at
least
there's
some
amount
of
history
can
go
back
to
increase.
G
A
Great
we're
on
we're
running
out
of
time.
We've
got
six
minutes
and
there's
two
relatively
large
sections
left
docks
being
a
huge
one.
I
would
like
to
turn
over
the
remaining
time
to
docks.
If
that's
okay,
because
this
is
a
big
deal-
that
okay
with
you
Josh
Tim,
do
you
feel
like
that's
a
good
use
of
time?
Okay,
yeah.
F
A
So
I'm
turning
over
you
and
Misty
and
Nick,
and
to
wherever
else
and
and
before
we
go
out
of
there,
I
gotta,
say
one
shout-out
to
Caitlin,
who
did
an
amazing
job
on
the
communications,
the
blogs,
those
are
the
consistent
quality
of
those
has
been
phenomenal
into
CN,
CF,
first
sponsoring
that
she
she
had
not
gotten
any
props
yet,
and
that
is
not
good,
because
she's
amazing
and
super
big
props
to
Caitlin.
Thank
you.
A
F
So
the
first
part
of
the
docs
thing
is
I'm.
Gonna
suggest
there's
two
policies
we
need.
As
far
as
I
know,
these
policies
don't
exist
at
least
I
couldn't
find
them
with
searching
and
I
couldn't
find
anybody
you
knew
where
they
were
one
is.
We
do
not
have
a
policy
for
what
needs
to
be
listed
in
the
release,
notes
as
a
dependency
version,
because
we
changed
the
versions
of
things
and
go
DAPs.
We
change
the
versions
of
external
dependencies
every
release.
What
needs
to
be
listed?
What
does
not
need
to
be
listed?
F
F
The
second
one
where
we
don't
have
a
policy
is,
as
far
as
I
know,
we
do
not
have
you
know
a
policy,
a
guide
for
what
needs
a
release
note
and
what
doesn't
need
a
release,
though
we
guy
was
going
over.
The
sort
of
what
I
guard
is
the
misuse
of
release.
Note
none
and
then
I'm
like
how
can
I
call
it
misuse
when
we
haven't
told
somebody
with
the
rules
are
so
we
need
to
write
down
the
rules
of
this
needs.
A
release.
A
K
K
I
I
A
J
J
J
Oh
no
I
mean
I
mean
using.
We
tried
as
an
experiment
using
flat
files
in
github,
oh
yeah
yeah,
so
we
always
yeah.
So
we
went
back
to
we
went
back
to
mark
down
in
the
Google.
Doc
I
did
take
a
look
at
how
can
be,
and
yeah
I
mean
it.
I
haven't
actually
logged
into
it
because
it
seems
it
seems
like
we'd
have
to
pay
for
it
in
order
to
get
the
public
functions
and
we're
already
getting
we're
already
getting
a
public
cherub,
'el
editable
document
with
Google
Docs.
J
J
This
way
actually
I'm
gonna
say
no,
because
that
that's
not
entirely
true.
Last
time
we
did
it
with
basically
Google
formatting.
We
then
had
to
hurt
what
we
did
this
time
is.
We
just
took
the
markdown
and
dropped
it
into
a
couple
document
and
edited
as
markdown
in
the
Google
document,
and
then
we
were
able
to
pretty
much
just
dump
it
over
and
Misty
didn't
have
to
make
a
few
tweaks
to
it,
but
not
nearly
the
horrible
epidemic
version
job
I
had
to
do
last
time.
Yeah.
K
A
Alright,
we
have
to
wrap
up,
I
have
to
go
start
a
cigar,
texture.
Everybody.
Thank
you
so
much
for
another
reason:
release
you
all
deserve
great
props
for
for
delivering
a
day
off,
which
is
incredible
again,
how
many
enterprises
with
people
being
forced
to
do
this,
but
you
are
that
successful
at
mediator
in
Atlanta,
so
best
community
ever
best
release
team
ever
best
everything
you
guys
are
just
amazing,
I
love
you
all
and
I'm
really
privileged
to
be
part
of
this
community.
Thank
you.
F
Thank
you,
everyone,
and,
and
thank
you
for
just
our
amazing
community
of
contributors,
because
that's
the
other
big
part
of
it.
It's
not
just
the
release
team.
It's
not
even
primarily
the
release
team,
but
people
were
just
super
responsive
to
almost
all
of
our
requests
and
that's
what
made
this
really
successful.
All.