►
From YouTube: Kubernetes WG LTS 20190122
A
B
A
A
A
We
follow
the
kubernetes
code
of
conduct,
so
ask
that
folks
adhere
to
that
please
after
the
meeting
the
recording,
so
this
is
being
recorded
after
the
meeting,
the
recording
will
be
posted
to
our
YouTube
channel
I
want
to
start
I
see
a
couple
of
folks
whose
names
look
new
to
me.
So
I
wanted
to
start
just
with
maybe
Colin
out
seeing
if
anybody
wants
to
introduce
themselves
why
they
have
come
today.
C
I'm
happy
to
go
first,
yep
I'm,
you,
my
name
is
David
lang,
I
work
with
Hannes
we're
from
pivotal
and
also
with
Jim
himself
shortly.
So
our
interest
from
pivotal
is:
we
are
very
involved,
helping
pivotal
cloud.
Foundry
customers
keep
up
to
date
with
a
nine
months
release
cycle
and,
as
pivotal
has
more
kubernetes
customers.
We
would
like
to
learn
about
what's
happening
in
terms
of
helping
customers
keep
communities
up
to
date
and
whether
there's
any
information
that
we
have
from
the
car
foundry
ecosystem
that
might
be
of
assistance.
A
All
right,
well
I've
got
a
couple
things
on
that
I
thrown
in
on
the
agenda,
and
obviously
it's
open
as
well.
If
folks
want
to
put
other
topics
there
that
they'd
like
to
talk
about,
there
are
a
couple
action
items
we
had
out
of
last
meeting
two
weeks
ago,
the
the
first
one
survey
prep.
So
we've
talked
about
putting
out
a
survey
for
users
of
kubernetes
operators
of
kubernetes
to
understand
where
their
upgrade
pains
are
or
what
their
desires
are
in
terms
of
support.
A
Those
types
of
things
so
we'd
had
quite
a
bit
of
feedback
on
that
and
Nick
and
I
sat
down
and
scrub
through
the
response
comment,
so
I
think
we
have
a
pretty
cleaned
up
survey,
I,
guess
I'd,
throw
it
out
there
for
folks
to
review
the
link
is
in
the
document.
If
you
want
to
put
any
additional
comments
in
it,
but
then
Hannes
last
time,
you'd
mention
that
you
might
have
some
sort
of
survey
designer
people.
You
know
who
you
might
be
able
to
have
a
look
over
it
see.
A
E
A
The
comments
on
the
dock,
I
hadn't
seen
any
new
or
different
folks
names,
so
I
I
don't
know
if
they'd
seen
it
or
not,
based
on
that
either
but
yeah.
If
you
could
follow
up,
that
would
be
useful
or
maybe
maybe
we
do
or
don't,
but
that'd
yeah
I
think
anything
that
we
could
do
in
that
way,
just
to
try
to
measure
up
the
quality
of
data
we
hopefully
get
back,
oh,
and
to
that
end
also
one
of
the
things
that
Nick
and
I
noticed
was.
A
A
A
So
we
noticed
that
there
are
some
similarities
to
the
cube
ADM
survey
that
they
did,
which
a
number
of
us
found
pretty
interesting
in
terms
of
results
and
similarity
and
some
of
the
areas.
So
we
kind
of
copy
pasted,
got
rid
of
our
questions,
suggested
answers
or
check
box
and
copy
paste
it
in
there's,
so
that
if
we
maybe
are
then
able
to
have
done
the
same
question,
maybe
we
can
see
some
correlation
between
results
later.
A
F
A
Yeah
one
thing
that
I
think
may
I
mean
I,
don't
know
what
the
design
intent
on
the
cube
idiom
one
was,
but
from
our
perspective
here
I
think
we're
not
necessarily
looking
for
like
a
a
random
sampling.
So
I
think
that
we
should
be
really
reaching
out
and
trying
to
get
folks
that
we
know
who
are
operators,
for
example,
of
clusters
to
feed
and
the
results.
G
A
F
We
basically
decided
with
a
survey
like
last
minute
before
cube
coal
was
it's
yellow
Sarah
and
we
saw
I
sat
down.
I
wrote
the
questions,
the
initial
draft.
We
basically
decided
to
no
questions
within
a
couple
of
days
in
a
closed
environment
between
all
the
cube,
a
DM
leads
maintainers
and
we
didn't
expose
this
to
the
public.
So
we
basically
four
people
edited
the
questions
within
a
couple
days
and
we
advertised
on
a
bunch
of
slack
channels,
read
it
I,
think
Twitter
and
the
kubernetes
def
mailing
list,
and
that
was
it
very
much.
A
C
C
You
know
like
their
motivation,
you
gonna
have
to
do
some
work.
What's
the
what's
the
payoff
and
you
would
think
new
features,
but
that
doesn't
feature
highly
in
the
Cloud
Foundry
ecosystem.
The
only
one
we've
found
is
they're
about
to
fall
out
of
support
and
not
get
security.
Patches
is
anything
around
that
being
asked.
A
A
C
I
propose
a
question
to
that
effect,
sure
and
then
the
second
one
is
what
organizational
constraints
block
you
from
doing
an
upgrade.
So
we
see
enough
in
our
enterprise
customer
base.
Many
many
customers
have
large
change
freezers
where
no
one's
allowed
to
do
any
changes
or
very
long
periods,
to
request
a
change
window
up
to
several
weeks
to
be
allowed
to
do
a
change.
C
H
H
A
Josh
burkas
again
in
the
zoom
chat,
says
I'd
also
like
a
question
that
covers
inside
earnest.
That
is
how
involved
it
is.
The
answer
in
the
community
I
think
will
get
very
different
answers
about
upgrading
from
contributors
versus
general
users
yeah.
So
we
we
were
trying
to
to
figure
out
like
from
a
design
perspective,
how
we
do
that.
The
very
first
question
tries
to
get
at
the
particular
persona
of
the
person
and
then
the
second
one,
following
up
with
their
expertise
relative
to
that
persona.
A
Me
so
there's
a
link
there
in
the
zoom
chat
but
I'm
wondering
so
that
that
link
is
shared
with
yeah,
that's
with
shared
with
k-dub,
so
you
should
be
able
to
access
that
one.
The
the
meeting
agenda
for
folks
who
haven't
seen
that
we
need
to
get
opened
up
to
K,
dev
and
I'm
having
permission
troubles
at
the
moment,
so
we'll
fix
that
one
but
yeah
the
survey
link.
Is
there.
H
I
One
could
provide
a
variety
of
answers
to
that
first
question
that
still
doesn't
define,
for
example,
the
the
amount
of
time
that
they
spend
in
kubernetes
slack.
If
you
follow
me,
I,
just
I
just
think
we're
gonna
get
based
on
my
experience
from
doing
this
in
another
project.
I
think
we're
gonna
get
very
different
answers
from
you:
users
who
are
actively
involved
in
the
community
versus
users
who
aren't
obviously
for
the
users
who
aren't.
We
also
need
to
settle
the.
I
A
A
Most
of
the
respondents
were
running
very
small
clusters,
which
kind
of
led
to
sort
of
an
impression,
at
least
it's
hard
to
say
how
accurate,
but
of
whether
inside
earnest
or
not
they're
on
there
the
end
goal
of
the
cluster
was
it
a
production
cluster
or
was
that
sort
of
a
devtest
cluster
or
even
a
hobbyist
cluster
and
I?
Think
for
for
these
types
of
bigger
picture,
support
conversations,
we
need
to
make
sure
that
we
get
like
production
level
deployments
heavily
weighted,
I,
think
and
I
know
cube
idioms
aiming
for
that.
F
So
we
didn't
I,
don't
think
we
got
a
lot
of
responses
from
China
to
my
understanding
in
China
we
have
big
companies
consuming
Cuba
diem
for
production.
So
again,
this
is
a
very
small
sample,
as
I
said
and
I
emphasize,
on
the
fact
that
it's
going
to
be
very
hard
to
collect
the
data
that
you
actually
need
based
on
a
survey.
A
The
only
thing
that
Nick
and
I
talked
about
it
or
we're,
seeing
sort
of
as
a
pattern
in
the
questions
that
we
had
initially
drafted
was
that
there's
there's
kind
of
two
things
we're
doing
here:
one
trying
to
collect
kind
of
the
raw
data
like
what
are
you
doing
today,
but
also
kind
of
like
a
phishing
for
what
are
your
problems?
What
are
the
unknown
unknowns
like
there's
a
lot
of
things
that
we
expect
from
people
to
hear
and
we're
wondering?
A
So
we've
got
a
couple
of
open-ended
questions
at
the
end
and
I
I
know
cube
a
DM.
Similarly,
how
to
open
a
question
and
lots
of
kind
of
sentence
form
feedback
there,
so
it
some
of
that
we
may
have
to
wait
and
see
and
then
hopefully,
we'll
get
enough
people
also
who
are
willing
to
give
their
email
address
for
follow-up,
so
that
we
can
go
back
and
dig
into
some
of
the
details
behind
it.
G
J
G
I've
I
think
that
you're,
probably
writing
about
the
about
the
myriad
that
the
yeah
there's
a
good
chance
that
we
won't
get
a
big
sample
size,
and
if
that
is
the
case,
then
we
really
want
the
people
who
you
if
people
are
willing
to
be
very
called
because
they're,
you
know
cross
about
things,
then
that's
gonna.
That
is
going
to
be
a
good
indicator
that
yeah
they
probably
actually
do
really
care
yeah.
K
Just
just
a
warning
that
there
is
quite
a
bit
of
resistance
to
this
idea,
I'm
sure
most
of
you
aware,
because
it's
hard,
you
know
it
creates
all
sorts
of
difficulties,
and
there
is
some
skepticism
as
to
whether
it's
in
fact
something
we
want
to
be
encouraging
people
to
do
is
have
these.
You
know,
installations
that
last
long
time,
etc.
So,
unless
we
actually
come
back
with,
you
know
reasonably
compelling
volume
of
data.
I
think
we're
gonna
have
trouble
getting
the
rest
of
communities
supportive
of
this
idea.
K
So
if
we
go
into
this
thinking,
we're
not
gonna
get
a
decent
volume
of
data
back.
We
should
probably
think
pretty
hard
about
whether
that's
a
solvable
problem
leav
that
might
render
the
whole
exercise
not
not
just
the
exercise,
the
questionnaire,
but
the
exercise
of
this
working
group
kind
of
not
very
more.
If
we
come
back
with
not
enough
data
yeah.
G
I
mean
I,
certainly
I'm
planning
to
push
it
out
to
a
bunch
of
people.
As
I
said,
these
there's
the
it
is
that
there
is
an
enterprise
made
up
here
and
see
needs
that
that
I
talked
to
a
couple
of
people
so
one-on-one,
but
I
definitely
interested
including
the
organizer
so,
and
we
have
a
meeting
coming
up
soon,
so
I'll
be
pushing
it
really
hard
there
yeah,
so
yeah
I
think
it's
going
to
be
up
to
us.
G
Those
of
us
who
active
here
to
to
to
do
a
bunch
of
pushing
in
a
bunch
in
a
few
channels
and
say
you
know
hey
if
you
want,
if
you
care
about
the
upgrades
and
everyone
I've
talked
to,
does
everyone
I've
talked
to
has
some
opinion
about
upgrades.
You
know
whether
it's
what
should
be
improved
or
you
know
how
musician
there's
really
no
circus.
Tessa's
being
obvious.
That's
fine!
Like
yeah.
G
L
Also,
I
also
think
that
there's
a
spectrum
of
things
that
could
be
improved
or
changed
and
so
on.
On
the
one
end,
there's
kind
of
the
yeah
I
want
to
set
up
a
cluster
and
leave
it
for
multiple
years
and
never
change
it
and
get
support
like
that's
one
end
of
the
spectrum,
but
there's
also
a
lot
of
things
kind
of
all
the
way
across
so
like
extend
support
by
one
release
so
that
you
get
four
quarters
or
one
year
of
supportive
releases.
L
That's
like
a
small,
pretty
incremental
change
to
the
way
we
run
the
project
today
or
things
like
extend
the
sku
support
on
cue
controls,
so
the
latest
do
control
works
against
all
supported,
API
servers
again,
that's
like
a
fairly
small
adjustment
that
would
like
have
test
impact,
and
things
like
that
or
some
of
the
quite
a
lot
of
the
questions
are
talking
about.
Like
what
problems
do
you
run
into
and
upgrades,
and
so
the
outcome
of
that
might
not
even
be
let's
change,
how
we
run
the
project
but
more
like?
L
Are
there
tools
or
improvements
we
can
make
to
ease
some
of
those
difficulties,
so
I
agree.
Quentin
like
if,
if
we
wanted
to
take
the
output
of
this
and
kind
of
advocate
for
like
a
fundamental
change
to
the
way
the
project
manages
releases
yeah,
the
burden
of
proof
is
pretty
high.
You
need
volume
and
depth,
but
if
we're
looking
for
ways
to
improve
of
real
pain
points
in
incremental
ways,
I
think
that
information
could
be
pretty
useful.
Even
if
it's
low
volume.
A
There's
an
uncontroversial
aspect
here,
like
people
are
recognizing
that
there
is
a
need
to
make
some
improvements,
in
particular
like
the
stuff
that
Jordan
started
spearheading
documenting.
What
does
it
mean?
What
we
like
this
nine-month
thing
is
fuzzy.
What
does
it
really
start
to
mean
when
you
get
down
into
the
nitty-gritty
details
of
version
skew
things
like
that
and
then
what
specific
API
is?
A
K
Think
data
carries
a
lot
of
weight.
Certainly
the
people
that
I'm
aware
of
that
are
strongly
skeptical
of
this
would
be
significantly
swayed
if
we
came
back
with
a
lot
of
data
that
not
convincing
I
may
be
wrong,
but
I,
but
I
think
that
if
you
have
no
data-
and
it's
all
anecdotal
and
I
think
we
need
this,
and
you
think
we
don't,
then
those
conversations
tend
to
go
nowhere,
whereas
I
think
we
need
this
and
here's
a
whole
lot
of
data
to
support
what
I
think
that's
a
much
more
fruitful
production
conversation,
that's
kind.
A
Of
that
I
think
is
the
point
of
why
we
started
trying
to
formalize
a
working
group
as
well,
because
exactly
what
you
said
like
there's
been
a
lot
of
talk.
There
hadn't
been
data
or
formalization
behind
it
and
it
stalls
out
at
that
point,
because
if
you
have
a
strong
opinion,
you're
gonna
hold
your
strong
opinion.
H
In
one
of
the
ways
the
survey
works,
here's
that
I
mean
we
have
a
working
group
and
you
have
active
members,
but
there
are
a
lot
of
people
who
won't
be
attending
the
working
group
or
the
users
who
don't
have
the
culture
of
attending
SIG's
and
works
groups.
We
are
trying
to
be
inclusive
when
trying
to
get
their
voice.
I
think
that's
where
the
survey
would
help
and
also
get
us
data
on
what
the
rest
of
the
community
is
thinking.
H
K
Think
if
we
go
through
the
CN
CF,
we
might
be
able
to
broaden
the
distribution
of
this.
You
know
pretty
dramatically
specifically
to
end-users
as
opposed
to
contributors.
If
we
get
a
day
of-
or
you
know,
a
lot
of
the
internal
mailing
list
for
kubernetes,
we
probably
going
to
be
ending
up
hitting
contributors
more
heavily
than
we
want
to,
whereas
lots
of
small
kind
of
queue,
Connie
type
events
have
personally
a
bigger
participation
and,
secondly,
I
think
more
end-user
focused.
A
A
All
right,
then,
so
the
the
working
group
formation
Charter
6:00
p.m.
all
the
community
pulled
29:11,
so
that
is
still
sitting
there,
because
we
do
need
sign-off
or
agreement
from
community
as
part
of
a
working
group
formation
process.
I
have
been
chatting
with
people
side
channel
between
slack
and
going
to
meetings
from
the
the
key
SIG's
that
we've
highlighted
there
just
to
give
folks
an
update,
so
60
Li.
A
A
Derek
was
relatively
ambivalent,
is
well
or
had
some
concerns
just
around
viewing
working
groups,
often
there's
just
being
talking
as
opposed
to
action,
which
is
a
reasonable
concern,
and
then
Don
hadn't
had
much
visibility
into
what
we've
been
talking
about.
So
was
going
to
review
this
stuff
I
need
to
circle
back
with
them
and
see
if
either
of
them
is
willing
to
give
LG
TM
on
it.
At
this
point,
so
we
will
see
where
that
goes
this
week.
A
And
I
don't
know
I'm
not
like
a
political
lobbyists.
I
feel
like
this
is
a
this
is
a
community
process
discussion
and
whether
whether
we
have
formally
accept
it
or
not,
like
I,
don't
feel
compelled
as
much
as
I've
stepped
up
to
sort
of
do
some
pushing
on
organizing
to
really
go
out
there
and
convince
people.
If
but
I,
don't
know
what
other
people's
thoughts
are
like
is
it?
A
K
Yeah
I
think
that's
true,
I
mean
I.
Think
that's.
Actually.
One
of
the
objections
to
roadblocks
is
at
least
objections
to
working
groups.
Why
don't
you
just
go
and
do
this
stuff
and
and
come
up
with
some
input
to
various
SIG's
so
but
but
it
does
I
mean
it
does
have
some
value
in
that
you
you
have
a
like
a
real
name
and
you
you
know
you
can
you
can
stand
up
as
so
XYZ.
A
Feel
like
a
portion
of
that
legitimacy,
though,
comes
from
operating
in
an
open
and
transparent
way,
and
at
this
point
we
are
doing
that
so
we're
following
the
kubernetes
way
in
terms
of
having
public
meetings
recorded
posted.
We
have
open
agendas
minutes
all
of
all
of
those
trappings
of
of
community,
so
that
it's
not
just
this
weird
thing
off
on
the
side.
A
K
Yeah
I
think
that
perspective
it.
What
dooms
is
here
actually
and
I
think
that
perspective
is
fairly
simple
like
if,
if
there
are
enough
cigs
that
think
this
is
a
good
idea,
then
they
will
be
fine
with
it
and
if
you
can't
find
things
that
are
interested
or
nobody
thinks
it's
useful,
then
it's
probably
not
useful.
A
One
question
that
had
come
up
in
that
regard
over
the
last
couple
of
weeks
is
so
we
need
a
algae
team
from
sig
leadership,
but
if,
if
those
individuals
aren't
as
convinced
of
the
merit,
perhaps-
but
maybe
there
are
lots
of
people
in
there
sig
like
is
it
a
sig-
leads
responsibility
to
be
a
representative
into
the
community
of
their
sig
in
to
what
extent,
how
would
they
weigh
those
people?
So,
like
there's
been
a
lot
of
people
across
almost
all
of
the
SIG's
who
have
said?
M
L
The
more
concrete
the
outcomes
and
recommendations
become
the
clearer
the
implications
for
all
the
various
SIG's
become
right,
and
so,
if
they're,
the
ones,
maintaining
these
components
like
a
thumbs
up
to
go
like
talk
to
users
and
find
out
what
problems
they
might
be
running
into
seems
like
very
low
commitment.
I.
Think
one
of
the
concerns
is
that
a
thumbs
up
to
that
is
sort
of
implicitly
saying.
L
Whatever
comes
out
of
that,
we're
signing
up
to
do
the
work
to
address
that
and,
and
so
the
clearer
we
can
be,
that
the
first
step
is
gathering
information
and
coming
up
with
a
list
of
sort
of
like
we
talked
about
the
spectrum
like
a
list
of
small
things,
two
big
things
that
could
address
some
pain
points
and
a
promise
to
say
like
at
the
point
where
we
decide.
If
these
are
things
we
want
to
take
on
we're,
gonna
come
back
and
get
buy-in
from
the
people
like
it's
not
what
you're
agreeing
to
is
not.
L
We
will
sign
up
and
do
the
work
to
do
whatever
we
dream
up
out
of
this
survey,
the
clear
we
can
be
about
what
the
initial
phase
is
and
what
what
the
next
steps
would
be,
I
think
the
more
agreement
you'll
get,
the
more
willing
people
will
be
to
say
yeah.
This
seems
valuable.
I,
don't
have
the
time
but
I'm
happy
to
yeah
I'm
happy
to
get
this
information
and
start
to
process
it
and
try
to
think
about
next
steps.
So
I
know
we've
kind
of
been
over
this
ground
before.
L
M
M
You
know
these
are
the
smaller
blocks
of
things
that
we
aim
to
do
in
various
SIG's
before
we
kind
of
like
finally
brand
that
Cubana
does
is
LTS
does
LTS,
you
know
the
easier
it
is
going
to
be
for
us
to
get
okay
from
different
people
and
also
the
okay
I
I.
Don't
feel
that
it
has
to
be
like
a
the
the
sig
leads
are
not
like.
Okay,
this
is
GTM
from
me
vs.
LG
TM
from
the
whole
of
sig.
Then
they
have
to
go
poll.
Everybody
and
you
know
we
have
keep
it
low
barrier.
L
Other
thing
too,
like
unfunded
unfunded
work,
doesn't
get
done,
and
so
one
of
the
things
that
we
talked
about
here
as
if
there
are
vendors
who
have
an
interest
in
seeing
support,
lengthen
or
improve
or
change
today,
they
are
either
just
wishing
that
it
would
happen
or
they
are
sort
of
doing
it
themselves
and
in
some
cases,
duplicating
efforts
or
things
like
that,
and
so
a
key
outcome
seems
like
it
would
be
if
we
identify
additional
work.
That
needs
to
be
done.
L
We
have
to
that.
Work
has
to
be
funded
somehow,
and
so,
when
we're
describing
kind
of
our
vision
for
what
comes
out
of
this
survey
or
what
comes
out
of
the
things
we
discuss
here.
If
there
are
things
that
require
work
and
we're
taking
it
to
the
sig
responsible
for
that
area,
saying
here's
something
we'd
like
to
see
happen.
That
seems
like
it
would
address
user
user
issues.
L
This
is
a
good
place
to
coordinate
from
the
people
who
would
benefit
from
that
like
vendors
and
people.
It
would
be
consuming
that
to
say.
Well,
if
you
want
to
see
this
happen,
the
sig
doesn't
have
banquets,
they
say
they
need
two
people
or
three
people
dedicated
to
this
who's
gonna
step
up
and
do
that
and
so
we're
not
just
asking
people
to
do
more
work.
L
We're
saying
we're
trying
to
identify
useful
work
and
then
give
a
coordinated
ten
points
so
that
people
who
would
benefit
from
that
have
a
place
to
coordinate
and
actually
contribute
so
kind
of
holding
that
out
as
well
saying
we
we'd
like
to
identify
useful
things
and
help
facilitate
vendors
or
people
who
would
benefit
stepping
up
to
do
that.
Work
right.
M
I
mean
one
example:
I
can
give.
You
is
like
we,
we
are
doing
really
well
with
defining
rules
and
sig
release
right.
So
if
we
have
a
rule,
that's
kind
of
well-defined
for
taking
care
of
test
failures
in
and
say
that
this
is
a
template
that
different
six
can
use
for
their
own.
You
know
monitoring
their
own
CI
bills
and
making
sure
that
they
don't
fall
over,
because
you
know
we
are
promoting
different
versions
of
Pro
and
there's
always
something
or
other
breaking
every
week
because
of
changes
made
in
the
main
Kuban.
It
is
repository.
M
So
if
we
define
rules
that
they
can
post
jobs
for
you
know
that
will
take
away
that'll
help
them
become
more
efficient
and
it
will
also
help
us
go
towards
LTS,
because
once
we
stop
the
breakage
of
jobs
for
like
the
last
couple
of
releases
and
adding
a
new
release
and
going
from
nine
nine
months
to
twelve
months,
it's
gonna
make
things
like
that
easier
for
them.
Right
now.
If
we
go
and
say
you
need
to
patch
something
up
from
1-10,
one.
Nine
and
people
are
gonna
say:
forget
it
biggie,
we
are
not
gonna.
M
H
I
like
to
highlight
the
student,
the
signal
I
remember
that
they
were
the
objections
were
coming
based
on
the
concept
of
working
group.
That
is
the
current
context
of
work,
this
working
group,
so
that
the
comments
came
out
like
the
working
group
look
at
say,
working
group,
X,
I
will
name
anything.
There
is
a
lot
of
discussions.
They
are
dying
out
unknown.
Real
work
is
coming
out
so,
which
was
the
objections
from
signal,
came
more
from
perspective
of
the
working
group
itself,
rather
than
this
particular
working
good.
M
M
M
I
A
Within
that,
the
specific
implementation,
like
one
of
the
one
of
the
things
as
I've
talked
to
folks
about
this
I
mean
I,
think
I
mean
I.
I
can't
necessarily
hear
it
the
way
they
hear
it,
but
I
feel
like
I,
say
the
exact
same
things
that
Jordan
and
Dems
were
saying
to
folks
and
and
of
course
now
there
isn't
the
track
record
to
prove
like
that.
A
It's
not
just
words
that
there
is
gonna,
be
us
pulling
in
vendors
and
resources
and
Manning
specific
things
and
driving
concrete
improvements,
but
the
there's
that
that
sense
there
that
okay
I
hear
the
words
you're
saying
but
I
also
hear
you
saying
LTS
and
talking
about
moving
to
LTS
and
and
I
know
that
that
is
gonna
mean
work
for
me.
No
matter
what
you
say,
there's
there's
gonna
be
stuff
that
comes
from
that.
So
I
think
that
there's
gonna
always
be
a
certain
resistance
to
that.
Because
of
what's
built
into
that
phrase.
A
So
I
guess
we'll
see
where
it
goes,
but
it
seems
like
kind
of
the
consensus
here
is
like
we
don't
need
to
worry
about,
that.
That
can
kind
of
keep
going,
that
there
there's
plenty
of
other
weather.
Sig's
are
working
groups,
who've
sat
there
early
I
mean
cloud
provider
was
talked
about,
four
was
eight
a
year
or
two
before
it
came
into
existence.
Now
working
group
is
supposed
to
be
time
box.
A
K
The
mechanism
for
resolving
that
I
can
quite
believe
that
that
might
be
the
case
in
some
sense,
and
the
mechanism
is
to
get
a
steering
committee
and
say
I,
don't
think
the
leadership
of
this
thing
is
representing
being
just
of
that
sink.
The
majority
of
the
contributors-
and
you
know
people
can
disagree
or
agree
with
you,
but
that's
that's
what
you
would
have
to
do
to
be.
A
Clear
I
wasn't
was
not
attending
to
assert
that
as
much
as
that,
it's
ambiguous,
like
there
are
people
in
each
of
the
SIG's
who
are
interested,
but
the
SIG's
also
have
to
weigh
like
all
of
that
staffing
and
all
those
those
reasons
to
where
they
are
I
do
think
they
are
representing
the
whole.
The
sig
right.
M
Also
in
the
couple
of
meetings
that
I
did
attend,
Tim,
it
was
more
about,
like
you
were
coming
to
us
with
something
I
have
to
go
back
and
talk
to
other
people
and
come
back
to
you.
Who
was
the
kind
of
response?
I,
don't
know
about
myself.
I
have
to
go
talk
to
the
rest
of
the
people
in
the
seg,
so
it
was
not
like
okay,
they
are
telling
me
something
about
I,
don't
want
to
do
it.
It
was.
A
I
want
to
move
on
to
talking
about
doing
some
specific
things.
We've
got
a
big
list
that
came
out
of
the
initial
things
that
that
Jordan
was
was
pushing
into
the
docs
website.
So
there's
eight
eight
bullets
of
follow-up
discussion
topic
ideas,
only
one
of
which
I
think
has
an
associated
issue
or
PR.
Next
to
it.
So
I
wanted
to
talk
about
starting
to
move
towards
work,
so
Jordan.
A
L
L
M
L
A
L
Did
have
one
question
about
where
the
best
place
for
sort
of
the
third-party
dependencies
tracking
that
version
stuff
where,
where
the
best
place
for
that
is
I
guess
the
two
most
obvious
places
would
either
be
in
a
single
document
on
the
website
or
in
the
sort
of
release,
notes
or
something
that
is
per
release
and
so
I
wasn't
sure
so
the
pright.
Now
the
document
is
version
neutral.
L
It
server
does
everything
in
terms
of
like
version
an
and
n
minus
one,
and
so
it
is
intended
to
be
correct,
no
matter
what
version
you're,
referring
to
as
we
start
documenting
specific
dependencies,
that's
going
to
change
over
time
and
so
like
a
table
or
a
matrix
sort
of
gets
unwieldy.
Once
you
have
more
than
a
couple
versions
ready,
it
has
a
potential
to
so
I
I
wasn't
sure
if
we
wanted
to
tack
it
onto
this
document
or
make
it
her
release
or
what
people's
thoughts
were
and.
F
L
A
The
swig
release
perspective.
This
is
something
we've
been
beating
up
against
on
every
release,
and
none
of
us
are
happy
with
how
it
goes.
I
think
that
we
split
into
two
two
aspects
there,
one
like:
what
are
we
doing
for
this
release
and
two?
What
is
the
big
picture?
Intent
is
the
whole
splitting
we
get
into
the
splitting
the
monolith
and
what
is
a
distribution?
What
is
kubernetes
discussions
and
we
bike
shed
and
rathole
on
that
so
there
is.
A
There
is
an
open
issue
in
cig
release
around
better
formalizing
the
process
of
collecting
the
dependency
list
for
that
release,
and
it
I
believe
yeah.
It's
it's
mark,
milestone,
114.
So
it's
something
that
Aaron
is
looking
to
improve
this
time
around
for
114,
but
still
that's
just
the
this
time
around
every
three
months.
What
do
we
have
and
I?
Don't
know
that.
L
Okay,
I
did
and
I
think
this
list
is
bigger
than
people
realize
at
first
like
and
people
think
oh,
the
third
party
dependencies
sed
container
runtime
container
network
interface
and
Inter
storage
interface
and
then
maybe
some
specific
implementations
of
the
container.
When
times
that
we
test
with,
like
oh
we've,
got
like
five
or
six
things
to
document
versions
of.
But
if
you
actually
look
at
the
release,
notes
and
look
at
all
the
add-ons
that
ship
as
part
of
a
kubernetes
release,
it's
a
long
list
and
there's.
D
D
F
A
Of
them
are
in
files,
one
of
the
things
that
when
this
first
came
not
clicking,
it
was
I
think
it
was
the
or
the
first
time
I
saw
is
an
issue.
Is
you
know?
Maybe
the
110
release
on
the
day
of
release
the
the
changelog
or
the
the
release
notes.
Person
said:
hey,
we
don't
have.
We
didn't
update
this
list
and
we
did
a
quick
dive
to
go,
find
the
versions
and
it
was.
We
came
up
with
a
list
of
20
or
30
things
that
were
cold
from
20
or
30
different
source
files.
A
F
A
K
Was
just
gonna
ask,
it
seems
like
we
have
two
conflicting
requirements.
The
one
is
that
we
want
to
be
able
to
go
to
a
single
place
and
find
out
what
the
canonical
set
of
versions
is,
and
the
other
one
is
that
we
want
to
be
able
to
maintain
that
thing
efficiently
in
the
right
places
and,
and
the
first
of
those
seems
to
sort
of
imply
a
single
document.
That
is
the
canonical
truth
and
the
other
one
seems
to
imply,
like
multiple
documents
managed
by
different
things.
K
Presumably,
certain
components
are
kind
of
the
purview
of
certain
things,
and
those
things
should
be
able
to
decide
what
the
canonical
versions
are
for
the
things
that
their
control
so
isn't.
Isn't
that
mechanically
an
appropriate
solution
is
to
say
there
is
a
single
place
that
that
points
to
all
of
the
places
where
the
versions
are
kept.
Those
are
maintained
by
the
sinks
that
look
after
the
versions
of
those
particular
components,
and
it
is
machine
readable
by
traversing
this
tree,
that
is
maintained
in
a
distributed
fashion.
I.
A
A
And
more
out
of
kaykai,
these
types
of
federated
single
sources
of
truth:
I,
don't
know
if
that's
an
oxymoron
or
what.
But
it's
gonna
be
a
common,
an
increasingly
common
pattern
that
we're
gonna
need
mechanisms
for
coalescing
information
from
a
standardized
data
format
and
in
all
the
places,
I
guess.
H
Would
this
be
something
that
we
say
is
part
of
the
proposal
that
we
come
out
it
or
so?
Is
there
something
that
we
should
be
part
of
the
cap,
or
do
we
go
back
to
signal,
use
and
say
hey
with
this
person?
What's
the
way
that
a
something
that
you
need,
how
does
it?
How
does
how
do
we
make
the
best
use
of
what
we
have
already
discussed
and
and
save
this
somewhere
and
share
this
with
others
and
use
it.
F
So,
first
of
all,
first
of
all,
if
it's
machine
readable,
we
can
use
a
tool
to
generate
the
release,
notes
automatically.
It
can
also
link
to
the
PRS
that
implemented
the
bump
of
a
version
and,
at
the
same
time,
we
had
requests
that
people
do
not
know
what
is
the
actual
HCD
version
for
this
particular
release
of
companies
unless
they
they
look
at
the
source
code.
So
that's
a
problem.
H
Little
mean
I
get
the
perspective.
I
just
wanted
to
say
that
it's
a
plus
one
from
me.
It's
just
that
we
have
discussed
a
couple
of
designs
now,
I
wanted
to
understand
how,
in
general
you
are,
the
safes
are
other
working
groups
or
steering
committee.
How
do
we
save
this
knowledge
that
we
have
all
dispersed
today
and
how
do
we
use?
How
do
we
share
I
think
that
we've.
A
Got
the
the
issue
that
I
linked
for
cig
release?
That's
about
how
the
release
team
collects
the
information,
but
that's
partly
just
kind
of
band-aid
like
because
we
know
we're
not
happy
with
the
state
of
where
the
information
is
right,
so
telling
a
person
how
they
go
out
and
manage
the
stuff
together
is
one
thing
but
I
think
we
need
a
cig
release
issue
and
I'll
go
ahead
and
open
one.
The
sooner
people
agree
that
that's
a
reasonable
place
to
do
it
to
track
formalizing
that
consistent
way
of
collecting
the
data.
F
So
right
now
the
way
I
helped
with
the
release
loans
for
the
last
release.
I
basically
opened
the
old
release,
notes
looked
at
the
PRS,
look
at
the
looked
at
the
files
that
the
PRS
touch
and
then
saw
the
latest
bumps
and
extracted
the
latest
versions.
Out
of
like
the
appearance
that
touched,
the
version
updates
and
it's
a
kind
of
tedious
process,
and
we
need
definitely
automation
around
this.
A
F
A
Did
it
as
part
of
the
normal
presentation
track
because
we're
not
formally
a
working
group,
so
I
don't
see
us
as
part
of
the
maintainer
Streck
it's
for
the
working
groups
and
SIG's,
but
we'll
see
what
the
program
committee
says
to
that.
If
there's
somebody
who
knows
that
they
are
going
to
be
able
to
go
to
China
and
as
interested
in
doing
similar
for
cube
con
China
I,
think
that
would
be
really
good
to
do.
I
know
I
will
not
be
able
to.
A
Not
here
so
I'll
just
put
that
shout
out
there
we're
at
the
top
of
the
hour,
but
if
there's
folks
who
are
interested
is
if
or
think
they
might
be
able
to
as
you
is,
your
plans
become
more
solidified
think
about
maybe
stepping
up
the
volunteering
to
do
that.
It
would
be
greatly
appreciated.
O'quinn,
says
he'll
probably
be
there,
so
that
maybe
as
an
option,
alright.