►
From YouTube: Kubernetes WG LTS 20190305
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
hey
everyone
welcome
to
another
plucking
crew,
Peltier's
meeting
and
I'm
the
world
punished
ali.
I'm
your
host
today.
Let
me
start
with
reminding
you
that
today's
meeting
is
getting
recorded.
The
core
of
cnc
of
code
of
conduct
is
in
place,
so
be
awesome.
Everyone
and,
since
its
recorded,
don't
say
anything
that
you
don't
want
to
say
and
get
it
recorded
on
the
internet.
A
B
Get
that
on
the
agenda
you
you
had
mentioned
to
me
that
I
had
volunteered
to
make
a
little
bit
of
a
project
management
thing
and
I
had
completely
forgotten
about
that
and
I
not
sure
that
it
had
ended
up
in
that
day's.
Note.
So
I
think
steven
augustus
made
this
for
us
but
need
to
actually
put
cards
and
content
in
it.
So
I
will
do
that,
but
other
than
that
I
just
wanted
to
mention
that
the
board
exists.
It's
blank
right
now,
yep.
A
C
B
E
B
E
The
org
in
general,
so
I
just
thought.
You
know
we
actually
have
bought
management
of
github
teams
now,
which
is
pretty
great.
So
if
we
had
a
group
LTS
a
team
people
can
ask
to
be
added
that
to
that
team
via
for
requests
and
so
that
that's
a
pretty
reasonable
way
to
manage
membership
and
then
or
invisible
or
public
visible,
makes
sense.
C
A
A
A
A
A
A
Yes,
so
something
that
came
up
in
the
kubernetes
release
meetings
was
the
discussion
on
dependency
of
other
projects,
and
one
of
the
dependencies
was
go.
One
of
the
reasons
that
Aaron
Creek
and
Berger
mentioned
as
they
are
updating
the
1.12
is
the
support
cadence
and
it's
much
better
over
the
long
term
to
have
go
one
dart
well
and
move
to
new
events,
of
course,
sooner
and
at
least
for
1.14,
since
we
have
another
week.
A
A
The
discussion
didn't
go
further,
but
I
think
it's
kind
of
important
to
notice
that
a
lot
of
other
six
are
noticing
and
we
need
to
kind
of
define,
define
where
you
know
that
the
definition
of
kubernetes
as
a
project,
what
are
the
boundaries
and
how
do
they
bound
trees,
interact
with
the
support
key
with
respect
to
the
support
cadence?
So
it
was
a
good
discussion.
I,
don't
think
it
made
any
progress,
but
maybe
something
in
the
cig
release
to
bring
up
next
time
and
see
how
the
working
group
can
look
at
it.
A
A
How
can
we
homogenize
the
releases
of
kubernetes
and
for
older
versions
of
kubernetes?
What
would
we
do
with
unsupported
versions
of
docker?
So
I
did
see
a
male
thread
on
that
on
followed
up
by
signal.
Chair
I
forgot
the
name
so
yeah.
Probably
after
this
meeting
there
is
a
signal
meeting.
So
if
anybody
is
interested,
we
should
probably
plug
in
there
I'll
probably
next
week,
give
you
the
status
on
what
happened
in
that
meeting
should
be
interesting
to
see
where
it
goes.
A
A
The
survey
monkey
link
is
available,
so
I
encourage
everyone
to
just
go
and
fill
the
surveys
ourselves
and
also
forward
it
to
anyone.
You
think,
is
the
right
candidate
for
the
survey
I've
reached
out
to
kubernetes
ter
for
this
and
I'm
planning
to
go
to
all
stakeholders
meetings
and
do
this
I
wasn't
well
last
week.
So
I
was
a
little
slow
and
going
to
some
of
this
meetings
or
adding
to
their
agendas
reached
out
to
sea
and
CFE
Hall
is
helping
us
and
reaching
out
to
the
C&C
of
end-user
community.
A
F
A
Got
any
numbers
here
on
how
many
people
have
done
already?
You
don't
have
access
to
that,
because
the
admin's
are
a
and
probably
a
couple
of
more
people,
so
stiffener
is
one
of
them
and
he
was
kind
enough
to
help
this
yeah
shout
out
to
safe
infer
sitting
about
for
five
hours
with
me
multiple
days
across
multiple
days
after
working
hours,
so
yeah
we
were
able
to
get
the
survey
out
and
make
the
best
after
the
survey
monkey
tool,
we
did
find
the
user
experience
of
Survey
Monkey,
not
being
that
great.
A
So
if
you
have
lots
of
questions
and
moving
the
questions
around
is
quite
it's
quite
a
challenge
and
you
need
to
really
know
the
tool
to
work
with
it.
So,
yes,
one
experience
I
mean
ultimately
the
user
experience
of
filling
a
survey
is
great
with
Survey
Monkey,
but
creating
a
survey
is
not
branching
was
challenging.
Also,
so
we
did.
The
questions
are
have
a
yes
or
no
questions
before
you
fill
a
section
so
that
she
won't
sell
answers
that
do
not
matter
to
you.
A
If
you
think
there
is
any
change,
you
know,
there's
a
typo
or
anything
that
needs
to
change
in
the
survey
please
reach
out
to
me:
I'll,
try
to
our.
You
know,
reach
out
to
us
and
there
anyone
on
the
working
group
LTS
channel
and
then
we
probably
Steven
or
someone
else
who
has
admin
access,
can
make
modifications.
I,
don't
know
if
you
can
make
modifications
now,
but
I
did
see
it.
You
see
a
behavior
which
I
thought
we
could
modify
or
tweak
little.
So
every
star
to
stiffen
am
here
to
here.
Back
on
that.
C
A
B
A
Timeframe
for
what
these
sick
PMS
last
year's
survey
was
also
on
for
around
a
similar
period,
so
it
should
be
probably
a
good
time
frame
and
good
will
give
us
a
good
time
to
go
and
reach
out
to
other
people
to
as
many
people
as
we
want
and
I'll
try
to
find
out
from
Steve
and
how
many
have
already
responded
based
on
our
communications,
regular
channels.
And
what
else
can
we
do
to
reach
out
to
more?
A
F
I've
got
some
pretty
good,
like
individual
responses
just
to
the
idea
of
the
survey
when
I've
been
talking
to
people
about
our
meetups
and
user
groups,
and
things
like
that
yeah,
so
people
have
been
very
interested,
especially
I.
Try
to
phrase
it.
As
you
know.
Oh,
if
you
found
upgrading
a
bit
tricky
and
you
want
to
rent
it,
somebody
guess
what
there's
a
great
place
for
you
to
do
that
people
usually
are
more
interested.
F
B
A
F
A
A
F
Just
gonna
ask:
is
it?
Has
anyone
had
any
chance
to
think
about
Tim
st.
Claire's
kept
proposal?
I
had
a
bit
of
a
look
at
it
and
have
been
yeah
just
thinking
about
it.
I
talked
I've
actually
talked
to
a
few
people
about
it
as
well.
The
general
consensus
from
my
end
user
people
I've,
talked
to
as
being
reasonably
positive.
I
think
that
at
this
point,
people
will
take
anything
we
give
them
to
help
improve
the
Okwe
story.
A
bit
I.
B
Still
have
the
action
advil
interdealer
sketch
of
the
drawing
he
had
done
and
I
want
to
make
that
into
like
a
online
shareable
format.
So
it's
easier
to
communicate
visually
what
he
was
describing.
I
I've
been
thinking
about
it
back
like
kicking
it
back
and
forth
in
my
head
and
I
I
have
some
concerns,
but
I
also
think
like
there's,
there's
multiple
different
ways
that
you
can
change
Cadence's
to
do
this
type
of
thing
and
that's
definitely
an
established
pattern,
what
he
was
describing
there,
but
at
the
the
Devils
in
the
details,
always.
A
A
Things
like
how
many
days
with
the
stable
release
overlap
that
along
the
stable
release.
What
is
the
benefit
of
that
overlap?
What
is
the
operationalization
I
mean?
How
will
the
kubernetes
project
implement
is
what
needs
to
be
done
from
the
kubernetes
projects
perspective?
Also,
the
survey
data
will
kind
of
tell
us
what
areas
the
Eucharist
the
users
are
facing
issues
and
will
how
will
this
proposal
solve
those
problems?
So
these
are
some
of
the
things
I
think
would
be
good
to
target
it.
A
E
Following
what
what
it
will
change
as
far
as
development
and
when
he
called
the
dev
stream
as
far
as
mechanics
about
how
experimental
things
or
alpha-level
things
for
we're
done
and
then
not
included
in
the
stable
branch
or
disabled,
but
in
a
way
that
a
lot
of
flexibility
to
change
them
in
the
Alpha?
That
branch
I
had
a
pretty
hard
time
following
that
to
understand
if
it
was
feasible.
E
F
Yeah
I
agree
and
that's
that
that's
exactly
the
sort
of
thing
that
I've
been
sort
of
not
sure
about
I
mean
I
kind
of
more
the
kind
of
more
than
end
user
representative
in
this
group,
and
so
I
don't
have
a
lot
of
familiarity
with
the
general
how
the
general
program,
project,
stuff
works,
and
so
yeah
yeah
I'll,
probably
agree
that
that
feels
like
the
thing
that
will
be
the
hardest
to
figure
out.
Whether
stuff
feels
easier
to
me
that.
B
One
of
the
things
I,
don't
think
we'd
really
I
forget
if
we'd
gotten
into
in
the
discussion
two
weeks
ago,
but
I
had
at
some
point,
I'd
asked
him,
maybe
one
on
one
this
like
would
this
be
done?
A
A
B
B
It's
been
a
way
of
managing
some
of
this
flux
to
give
a
place
where
things
can
be
trialed
and
matured
ahead
of
merging
into
something
for
a
more
formal
release,
oriented
branch
or
support
oriented
branch,
but
that
that
staging
of
early
stuff
ready
to
use
stuff
to
a
pible
of
being
supported
stuff
that
that
flow
is
it's
not
super
formal
I
feel
like
in
this
project
and
I
I,
don't
know.
If
that's
something,
then
that
you
would
want
to
change
the
formalities
over
the
mechanisms
around.
B
So
like
what
it
I
don't
know,
if
the
question
was
like
what
is
a
future
branch,
but
the
idea
it
yeah
branches
we
arbitrarily
mostly
develop
on
master
branch
people
make
powers
against
master
branch.
You
don't
have
to
work
that
way.
You
could
have
the
branch
that
is
the
one
where
a
bunch
of
different
work
is
aggregated
for
some
kept
feature.
Something
larger
like
that,
and
when
the
stakeholders
are
happy
with
it,
they
PR
the
content
of
that
branch
over
to
two
master
or
whatever
the
support
stream
branches.
A
Yeah
I
think
it
would
be
much
more
easier
if
there's
a
documentation,
kept
kind
of
to
explain
what
are
the
bounds
of
feature
branch
or
and
what
you
create
a
feature
branch
purchase
you
wouldn't
there
is
a
chance
of
feature
branches
living
there
forever,
not
getting
rebased.
There
are
issues
with
there
are
coaches
of
each
of
brands.
It
would
be
interesting
to
see
this
at
the
scale
of
kubernetes
project.
How
does
this
help
and
this
and
this
questions
can
be
asked?
A
F
I
mean
to
go
back
to
go
back
to
Tim's
proposal,
I,
guess
that
the
it
seems
like
the
things
that
we
need
are
you
to
make
it
more
specific,
I
think
things
that
we
need
are
yeah
a
bit
more
clarity
around
like
if
you're
gonna
have
a
develop
train
in
a
stable
train?
What
does
the
as
Jordan
said?
What
does
the
like
to
the
vowel
train?
Look
like
compared
to
what
the
master
one
looks
like
now?
How
do
you
yeah?
How
do
you
do
like?
What
are
the?
F
How
would
you
mechanically
turn
off
the
code
from
between
the
devel
and
a
stable
branch?
Is
it
just
future
flags
and
documentation?
As
tim
says,
you
know,
I
think
those
are
the
sort
of
the
two
key
things
that
we
need
to
establish
to
then
be
able
to
put
more
detail
around
how
something
like
that
might
even
work
and
I
think
we
need
to
have
the
detail
around
before
how
it
might
even
work
before
we
can
talk
about
it,
talk
very
cogently
about
if
it's
a
good
idea
or
not
and.
A
E
The
two
things
I
want
to
make
sure
we
avoid
are
decoupling.
The
dev
branch
process
was
from
the
stabilizing
influences
of
release
without
but
doing
it
in
a
way
that
that
unstable
nature
actually
bleeds
through
into
the
release
branch
like
if,
if
we
say
oh
yeah
well,
def
branch
is
just
always
in
dev.
E
You
can
always
check
in
anything
all
the
time,
and
you
don't
have
to
worry
about
when
release
dates
are
like
just
develop
away
and
make
progress,
but
then
we're
actually
regularly
taking
snapshots
from
that
or
rebasing
on
that
or
pulling
that
into
the
stable
branch
in
a
way
where
the
instability
is
actually
affecting
this
differential,
even
if
we're
doing
our
best
to
like
disable
things
or
gate
things
off
or
whatever
that's
problematic.
Suite
again,
the
more
we
know
about
the
specifics
of
the
mechanism.
E
We
can
evaluate
whether
that's
actually
fire
walled
off
and
then
the
kind
of
on
the
flip
side.
If,
if
the
mechanisms
that
are
being
proposed
in
order
to
protect
the
release,
branch
are
sort
of
doing
violence
to
the
the
code
like
well,
we
are
gonna
rip
all
the
experimental
code
out
like
the
process
of
doing
that
could
itself
be
just
forgiving,
though
the
intent
is
to
keep
the
stable
branch
super
super
stable.
E
A
B
Some
other
I
wonder
if
some
of
the
viability
on
the
project
were
that
he
was
describing
having
done
this
type
of
a
flow,
if
that
was
dependent
on
a
robust
and
healthy
CI
and
and
test
suite
and
infrastructure
like
this
is
easier
to
imagine.
If
you
know
you
have
a
solid
base
from
which
you
build
on
in
a
culture
of
always
keeping
CI
green,
but
the
opposite
of
that
was
like
what
shortened
sort
of
says
like
if
dev
is
just
anything
merges
and
health
is
at
whatever
yeah.
E
Super
thorough
coverage
of
all
the
inputs
and
outputs
to
the
system,
so
one
of
the
things
that
I've
been
looking
at
is
generation
or
fuzz.
Testing
of
API
is
to
make
sure
that
every
API
field
that
we
know
how
to
encode
and
decode
whether
there
are
alpha
or
beta
or
GA
or
whatever
is
represented
in
the
test
that
not
only
make
sure
we
can
round-trip
and
everything
on
the
particular
release
wrong,
but
also
says
well.
Could
this
have
been
persisted
in
the
previous
release?
E
And
if
we
encounter
that
persistent
data
are
we
going
to
fall
over
or
still
be
able
to
read
it,
and-
and
we
don't
have
a
great
processes
in
place
for
capturing
the
data
that
can
make
it
from
release
to
release
right
now,
but
I
I
agree.
If
we
had
much
better
coverage
of
things
like
that,
then
maybe
we
would
know
when
we
broke
something,
and
you
can
imagine
that
feeding
back
into
processes
in
the
dev
branch
and
say
no
I'm,
sorry,
a
released
snapshot
could
have
persisted
this
data.
E
A
E
Is
very
coarse-grained:
it's
not
nearly
at
the
level
that
we
need
it
to
be.
So
it's
at
the
level
of
is
this
API
call
made,
but
we
have
no
idea
of
what
individual
fields
are
being
exercised
and
most
of
the
exercise
unit
test
level,
which
means
you
don't
get.
The
benefit
of
cross
version
like
creed
and
persistent
data
from
the
previous
release,.
B
That
you're
testing
upgrade
downgrade
as
well
or
have
a
plan
for
how
that
would
be,
but
that's
still
that's
different
than
having
a
test
that
actually
covers
it,
because,
as
developers
were
often
bad
at
recognizing
the
need.
So
like
you,
you
might
write
up
a
cap
and
get
it
passed.
Even
all
your
stakeholders.
That
says
we
didn't
have
anything
that
needed
covered
there,
but,
like
Jordan,
says
like
if
you
don't
actually
feed
in
a
representative
set
of
older
data,
you
don't
know
whether
you
have
is
something
like.
A
You're
betting
business
think
we
should
probably
track
on
github
as
issue
that
you
know
that
is
I
see
this
as
a
solvable
problem
in
a
way
that
it
is
a
challenge
in
technology
rather
than
a
process.
Ii
respect
to
your
further
it
matches
the
proposal
or
not,
but
probably
good,
to
have
coverage,
analysis
and
metrics.
That
would
tell
us
the
health
of
the
project
and
health
of
the
master
versus
any
any
orally.
So.
F
E
F
Yeah
was
the
key
book
config
file
because
we
tweaked
a
whole
bunch
of
the
the
QPS
settings
for
talking
back
to
the
API
server
and
those
basically
turned
out
to
be
reset
back
to
default,
even
though
we
had
them
supposedly
present
in
the
file.
But
that
was
the
ya
know
posit
doing
its
thing
being
like
that
case
is
wrong:
that's
not
a
real
value,
I'm,
just
gonna
throw
it
away,
and
it
was
not
clear
that
it
was
runaway.
F
Oh
and
you
know
I'm
I'm
more,
not
today,
yeah
like
it's
fixed
now
right
like
but
yo,
he
was
just
an
interesting
case
of
something
where
it
broke
in
a
really
subtle
way,
because
you
know
the
key
s
changes
mean
don't
yeah.
We
only
only
encounter
that
for
a
specific
problem
when
clusters
are
pretty
busy,
and
so
obviously
that's
problem.
You
only
see
in
prod
really
and
yeah.
The
like
I
said:
I,
don't
know
how
you
test
for
it,
but
it
really.
It
was
very
annoying
to
find.
B
Part
of
this,
like
we,
we
have
unit
test
coverage,
but
this
is
more
of
an
integration
or
in
the
end
sort
of
thing,
and
you
need
a
corpus
of
representative
data
needs
curated
and
that
that's
like
that's
a
big
task
to
create
great
and
then
I
feel
like
too
at
the
moment
and
that
this
kind
of
goes
back
to
the
dependency
stuff.
There's
there's
a
little
bit
of
hesitation
in
some
parts
of
the
project
to
making
these
opinionated
choices
like
what
is
representative
or
which
set
of
things.
Are
we
gonna
integrate?
E
E
Do
we
have
a
test
that
crates
the
object
without
that
field
present
and
with
that
field
person
like
I'm
I'm,
not
looking
for,
like
the
end
end
behavior
I'm,
purely
looking
at
the
inputs
and
outputs
to
the
API
yeah,
so
I'm
hopeful
that
in
my
mind,
something
like
that,
you
could
actually
generate
and
then
kind
of
refine
with
hints
to
the
generator.
That
are
the
kinds
of
things
that
we
wanted
to
put
in
our
schema
anyway.
E
So
for
a
new
fields
like
having
a
structured
way
to
say
here
are
the
possible
values
like
that
would
be
good
for
the
generator
that
would
also
be
good
to
put
in
the
documentation,
so
the
types
of
things
that
I
would
see
being
needed
to
be
changed
to
support
something
like
this
are
generally
useful.
Things
would
also
support
usability
goals
as
well.
C
E
You
can
always
introduce
new
major
versions,
and
they
typically
would
follow
at
least
like
a
beta
GA
stage
in
the
case.
In
the
case
of
the
case
change
the
field
case
didn't
actually
change.
It
went
from
being
case
insensitive
to
being
case
sensitive
or
hey,
sensitive
briefly
case,
insensitive
and
minute
back,
and
so
it
was
a
case
of
like
pick,
which
version
you
want
to
be
incompatible
with
yeah
yeah
I
mean
yeah.
C
E
F
I
mean,
like
I,
said
it
was
it's
not
so
much
that
you
really
care
that
there
was
a
problem.
It
was
more
that
it
was
an
interesting
problem
because
it
was
kind
of
we
just
got
super
unlikely
that
we
happen
to
generate
our
config
files
in
the
version
where
it
was
case,
insensitive
and
so
yeah
I
mean,
and
there's
also
the
state
their
standard
other
stuff
that
you
see
with
the
analyzing
things
where
he
possibly
in
field
where
the
string
you
will
lose.
A
Hey
coming
back
to
a
proposal,
I
think
the
proposal
will
not
be
able
to
cover
everything
we
should
always
be
pragmatic
about
you
know
not
everything
would
be
addressed
by
the
proposal
nod.
The
project
will
be
in
perfect
shape,
even
if
it
decided
to
go
ahead
with
the
proposal
as
the
recommendation.
So
a.
E
B
Back
to
the
the
discussion,
it
cube
con
in
Seattle
that
we
had
and
kind
of
the
buff
there.
We
had
a
bunch
of
things
like
this.
That
we
talked
about
is
just
generic
needs
and
I
think
is.
We
is
rehashing
these
back
and
forth.
We're
gonna
at
some
point
have
something
for
a
document
that
kind
of
covers
the
the
desired
outcomes
and
improvements
and
any
of
these
potential
caps,
because
I'm
imagining
we
might
have
multiple
caps
or
proposals
around
prospective
changes.
B
I
see
those
as
things
that
we
would
then
use
to
weigh
a
proposal
to
say
like
how
is
it
going
to
address
these
types
of
things
and
and
maybe
they're
orthogonal?
We
do
them
regardless,
but
that
we're
we're
looking
at
those
being
kind
of
like
a
gating
criteria.
Maybe
having
these
things
established
as
part
of
whatever
we're
doing,
and
then
we
need.
We
need
hands
building
all
of
these
things.
It's
not
just
like
documenting
the
needs,
but
then
actually
driving
to
implementation.
C
C
So
if
we
consider
the
OTS
as
a
we
just
be
conversion
of
LTS,
we
can
then
not
have
to
back
port
in
API
changes
at
all.
We
can
keep
this
LDS
as
a
separate
stream
and
not
consider
API
changes.
Only
critical
bug
fixes
and
the
question
is
what
is
a
critical
bug
fix
and
we
can
define
that
I
think.
But
my
view
is
much
more
simple
than
what
Tim
proposed,
but
I'm,
not
sure
it's
war
fever
kept.
C
Maybe
I
can
write
a
Google
Doc,
how
I
see
LTS
from
my
perspective,
but
I,
don't
consider
API
sorrow
for
out,
yes
notice,
it
just
released.
We
pick
116
and
our
instance,
and
we
basically
supported
with
security,
fixes
and
critical
bug
fixes
if
you
have
to
bug
port
and
API
change
is
because
there
is
some
sort
of
critical
fix
that
requires
API
tweak
and
we
yes,
I,
think.
B
This
is
kind
of
like
what
I
was
calling
like
the
documentation
path.
You
at
some
point
you
snapshot.
You've
got
your
thing
that
you're
gonna
call
support
it
for
some
period
of
time,
but
that
act
of
snapshotting
or
branching
or
whatever
that
the
mechanism
there
is
at
that
point
you
have
code
in
that
branch.
B
Well,
you
either
do
or
don't
write
you're
either
gonna
have
code
there.
That
is
some
alpha
beta
early
dev
state
or
you
rip
it
out
like
Jordan
was
saying
and
or
you
have
some
type
of
mechanism
that
allows
that
stuff
to
be
turned
off,
so
the
the
stable
user
isn't
subjected
to
that
stuff
and
I
think
our
proposals
are
gonna,
need
some
treatment
of
that
mechanism
and
the
choices
are.
C
B
Turned
off
or
does
a
user
need
prevented
from
using
it
or
like?
Are
there
other
choices
there
that
need
declared
because
I,
like
Tim,
was
sort
of
proposing
that
stuff,
wouldn't
maybe
and
I,
think
that's,
maybe
what
Jordan
was
asking
like?
There
was
a
some
treatment
there
like
how
chunks
of
bigger
feature
code,
move
or
don't
I
think.
C
B
Don't
have
criteria
on
that
and
I
think
that's.
It
hasn't
quite
been
an
issue,
but
it's
something
that
needs
formalized.
I
mean
that
there's
something
that
went
by
for
the
the
113
branch
just
last
week,
where
I
ping,
the
authors
and
said
like
this
looks
like
a
feature,
and
it
was
a
size.
Xl
change
so
like
that
that
definition
of
critical
bug
fixes
it
needs
more
clarity
and
we've
had
cloud
providers
and
a
couple
of
instances.
B
C
B
C
F
Yeah
I
mean
I
think
the
key
part
there
is
that
yeah,
it's
always
gonna
be
hard
to
write
their
own
rules
for
that,
because
I'm
all
product,
then
then
the
important
part
is
gonna,
be
how
those
rules
get
interpreted
by
people
doing
it.
So
just
having
it
your
ride,
having
a
smaller
set
of
people
who
are
the
people
who
apply
the
rules
mean,
will
give
you
a
bit
more
consistency,
I.
A
Think
one
one
point
to
make:
first,
if
you
don't
allow
api's
to
be
part
of,
you
know
standardization
of
API
to
be
part
of
it.
I
guess
in
some
ways
of
your
great
story
is
a
little
challenging
because
you
don't
know
whether
you
can
guarantee
upgrades
or
not
so
something
it
would
be
good
to
get
more
specifics
on
what
your
proposal
idea
is
in
a
doc.
It
would
help
compare
apples
to
apples
or
at
least
get
out
of
some
of
these
details,
so
so.
C
The
upgrade
story
is
not
challenging
because
you
don't
jump
from
an
LTS
branch
to
the
latest
master.
The
Windows
updates
how
they
work.
You
do
incremental
updates
you
jump
from
from
punishment
to
version
we
don't
jump
like
over
five
versions.
So
if
we
support
upgrades
between
incremental
versions,
we
don't
have
to
do
this
jump.
I.
F
Api
object,
application
cycles
in
the
time
that
your
LTS
will
be
running
so
that
I
think
that
that's
that's.
Why
I
think
that
you
think
Jordan
mentioned
it
before
but
like
I'll
add
a
large
part
of
what
defining
any
longer
term
thing
is.
Is
it
has
to
include
the
API
deprecation
policy,
because
otherwise
the
lifecycle
of
an
API?
If
the
life
cycle
of
an
API
object
is
smaller,
then
your
long-term
support
release
window.
Then
you
an
API
check
and
I
hope,
API
object
could
live
and
then
die
and
be
removed.
F
C
C
E
That
can
work
for
Cuba
DM
because
it
has
its
configuration
files.
You
don't
have
live
consumers
of
multiple
versions
of
your
api's
simultaneously,
but
the
rest
it
guys
that
kubernetes
serves
have
to
be
able
to
round-trip
back
and
forth
between
them
because
they
have
multiple
live
users.
So
if
you
are
only
dealing
with
the
configuration
you
can
do
forward
compatibility
only
you
don't
have
to
round
trip
necessarily
and
so
can
a
conversion
tool
that
takes
an
old
version
of
a
config
file
and
brings
it
up
to
date
with
the
new
version
works.
E
E
G
E
Back
port
API
changes
today,
I
agree
that
the
different
proposals
about
different
styles
of
LTS
should
probably
be
like
written
down
like
what
exactly
is
being
suggested
and
just
like
we're
kind
of
asking
for
Tim
Sinclair's
proposal
like
big
picture.
What's
the
idea
and
then
like,
if
there's
not
overriding
objection
to
it,
it's
like
alright,
well
we'd,
be
interested
in
hearing
the
mechanics
of
it.
Similarly,
to
what
you're
describing
like
big
picture,
what's
the
idea?
E
Is
it
just
support
one
release
for
longer
and
what
would
be
involved
in
that
some
of
what
we
talked
about
earlier?
We
wanted
to
support
one
release
for
a
year.
Does
that
fall
within
the
boundaries
of
support
windows
for
the
things
we
depend
on
like
golang
and
that
CD
and
things
like
that
kind
of
working
through
that
and
some
of
that
exploration
is
gonna,
be
similar,
no
matter
what
we
do
like.
E
If,
if
we
want
to
support
any
type
of
release
for
a
year,
we
need
to
make
sure
that
we
have
a
version
of
go
that
will
get
security
fixes
within
that
year.
If
we
want
to
go
longer
than
a
year,
we
would
have
to
make
sure
we
can.
You
know,
make
sure
our
language
runtime
will
support
us.
So
things
like
that
are
gonna,
be
common.
I
was
gonna.
Ask
actually
if
it
would
make
sense
to
split
some
of
those
questions
out
so
that
they
could
inform
any
LTS
proposal
that
came
along.
E
So
the
dependencies
and
supported
versions
and
lifetimes
seem
like
a
useful
thing
to
shard
off
and
let
people
go
figure
out
things
like
go:
it's
not
a
CNC
F
project,
but
it's
an
open
source
project
finding
out
what
their
support
statements
are
finding
out
why
they
are
the
way
they
are.
If,
if
it's
a
matter
of
manpower,
we
wanted
to
see
that
lengthened.
If
that
could
be
something
that
they
would
accept,
help
honor.
That
is
a
pretty
entrenched
like
to
version
one-year
policy.
E
Similarly,
for
at
CD,
that
is
a
ciencia
project,
so
there
might
be
more
involvement
there,
but
but
yeah
in
numerating
those
figuring
out
what
the
current
state
is
and
then
figuring
out
like
what.
If
we
wanted
to
see
those
lengths
and
to
support
LTS
to
a
year
for
releases
from
three
or
whatever,
the
proposal
is,
what
would
it
cost
timewise
people?
Why
is
money
wise.
B
We
would
never
do
that
and
I
think
we
need
to
find
somebody
who
would
present
like
that
similar
kind
of
proposal
document
if
here's,
what
that
world
would
look
like
if
we
didn't
do
that
at
all
I
think
we
would
owe
the
community
we,
as
a
community
Widow
the
community
of
consumers,
that
mechanism
that
does
like
it,
a
built
in
native
a
be
deployment,
migration,
type
of
thing
or
something
and
people
have
talked
about
having
those
themselves.
But
there
isn't
like
the
upstream
canonical
preferred
way
to
do
that.
F
C
A
Technical
depth
there
so
I
looked
at
test
in
front
I
was
being
involved
in
it
for
the
last
six
last
months
and
I've
seen,
there
are
scary
parts
and
there
are
scary
parts
in
all
products.
So
it's
kind
of
being
what
NCI
CD
for
the
last
10
years,
I've
seen
all
the
projects
that
had
so
many
scary
parts.
A
It's
you
know
it's
like
when
you
are
inside
the
project.
You
know
more
book
about
more
bugs
about
it
and
you
get
scared
about
it.
Release
engineering
is
a
prio
job
and
it's
kind
of
feel
that
yeah
we
are
having
issues,
but
they
do
not
prevent
us
from.
They
did
not
prevent
someone
from
running
kubernetes
in
production
today.
So
we
have
made
progress,
I
agree,
there
are
scary
parts
and
there
needs
to
be
changes,
but
I
think
API
standardization
getting
better
test
coverage.
A
E
E
Like
I,
are
you
for
structure,
makes
it
pretty
easy
to
spin
up
a
cluster
and
run
a
suite
of
tests
on
it
it
from
what
I
understand
it
doesn't
make
it
very
easy
to
say:
I
want
to
test
this
British
version
of
this
component
with
that
version
of
that
component
and
then
run
a
suite
on
it.
Is
there
someone
who
could
engage
with
sig
testing
to
find
out
if,
if
that
capability
exists,
and
if
it
doesn't
it,
that
would
make
sense
to
kind
of
develop
separately
or
as
part
of
the
existing
tooling,
so.
C
I
already
have
a
call,
sir,
so
we
don't
have
such
a
such
a
mechanic.
To
basically
say
one
or
one
of
the
components
is
older
version.
We
don't
have
support
for
such
custom,
SKU
testing
everything
is
kind
of
kind
of
baked
a
custom
baked,
and
so,
if
you
want
to
test
for
GC,
for
instance,
you
have
to
have
a
the
so
called
deployer
written
in
for
the
cube
test
binary-
and
it's
is
far
from
customizable
in
terms
of,
for
instance,
the
couplet
in
the
cuba
in
the
end
tests.
C
A
You
would
like
to
call
it
checked
right
now.
Sorry,
hello,
bummer.
We
are
at
ten
one
minute
past
the
meeting
time,
so
we
should
probably
push
to
stop
at
the
next
meeting.
Also,
you
can
chat
on
slack
other
than
this,
and
I
would
like
to
end
this
meeting,
because
I
also
need
to
rush
to
another
meeting,
and
so
this
meeting
is
recorded
and
if
you
have
any
action
items,
please
mark
it
on
the
minute
talks,
it's
easier
to
do
it
that
way
and
I'll
post
up
the
recording
link.
Once
it's
available
to
me.
Thank
you.