►
From YouTube: Kubernetes WG LTS 20190709
Description
The Long Term Support Working Group (WG LTS) is organized with the goal of provide a cross SIG location for focused collection of stakeholder feedback regarding the support stance of Kubernetes project in order to inform proposals for support improvements.
"WG LTS" is simply shorter than "WG To LTS Or Not To LTS" or "WG What Are We Releasing And Why And How Is It Best Integrated, Validate, And Supported", but should NOT be read in that shortness to imply establishing a traditional LTS scheme (multi-year support; upgrade from LTS N to N+1, skipping intermediate versions) is the foregone conclusion of the WG.
Charter: https://git.k8s.io/community/wg-lts/charter.md
Meeting Minutes/Agenda: https://bit.ly/2HI8ppj
Maling List: https://groups.google.com/forum/#!aboutgroup/kubernetes-wg-lts
A
Hey
everyone:
this
is
another
meeting
for
working
group
lts
and
this
meeting
is
getting
recorded.
It
will
be
on
the
internet
on
youtube
posted
later.
We
follow
cncf
guidelines
and
that
just
means
be
nice
to
everyone,
don't
be
a
jerk.
So
let's
start
the
meeting
with
the
agenda
that
I've
created
today.
If
you,
if
you
want
to
add
anything
on
the
agenda,
the
agenda
has
a
space.
Today
I
have
pasted
the
link
for
the
agenda.
Docs.
Please
add
yourself
as
an
attendee
there,
with
as
much
details
as
necessary
that
you
can
be
reached
later.
A
The
first
topic
I
have
is
on
kubernetes
api
stability,
I'm
trying
to
carrying
forward
from
the
last
meetings
discussion
where
I
shared
some
information
about
how
the
api
conformance
reviews
team
was
working
on
using
the
confirm
using
the
api
snoop
data
to
create
information
on
what
kind
of
tests
were
creating.
Api's
server
coverage
data,
and
I
wanted
to
make
sure
that
we
have
jordan
had
pointed
out
that
it's
not
sufficient
and
not
complete.
So
I
wanted
to
get
some
brainstorming
ideas
on
how
to
how
can
we
do
that?
A
B
A
A
B
A
A
A
A
Wasn't
exactly
you
know,
we're
trying
to
make
sure
that
every
quarter
there
is
a
release,
and
if
there
are
conferences
and
other
project,
ubcon
kind
of
events
happening,
then
it
gets
difficult
to
maintain
a
quarterly
release,
and
this
discussion
was
punted
to
say,
okay,
we
should
probably
have
this
discussion
in
working
group
lts
to
actually
where
we
can
define
how
much
should
be
a
release.
So
I
just
wanted
to
start
this
discussion.
A
B
B
C
D
Yeah
yeah,
I
mean
like
I,
I
agree
darval.
It
does
kind
of
make
sense
for
us
to
start
talking
about
a
little
bit
here,
because
you
know
this
is
literally
the
stuff
that
we
have
been
talking
about
for
the
last
year
or
so
about
how
many
release
windows
do
we
do
we
support
things
for
how
often
the
listing
knows
all
that
sort
of
stuff,
but
like
I
don't
kind
of,
also
agree
that
there's
not
that
much
that,
like
I
mean
we've
talked
about
it
a
bit.
D
We've
got
a
couple
of
proposals,
for
you
know
what
you
know.
What
changes
to
the
release
train
would
look
like,
but
you
know
we
haven't
managed
to
move
for
any
further
past
that
yet
so
I
mean
yeah
like
the
you,
it
does
feel
like
we
should
be
involved.
That's
the
whole
reason
for
us
being
here,
but
the
but
yeah,
I'm
not
sure
where
to
go.
Is
I
guess
what
I'm
saying
I
mean.
B
If,
if
conferences
and
sort
of
annual
cycle,
things
tend
to
make
one
release,
one
of
the
quarterly
releases
shorter
one
way
to
kind
of
normalize,
that
would
be
to
say
well
individual
quarters,
ebb
and
flow,
but
over
a
year
you
know
it
all.
It
all
comes
out
in
the
wash.
If
you
go
on
an
annual
cycle,
and
so
I
know,
we've
talked
about
exploring
what
the
cost
would
be
to
support
four
releases
instead
of
three
that
would
at
our
current
cadence.
B
That
would
get
us
to
a
one-year
support
window
which
would
align
pretty
well
with
a
fair
number
of
users,
and
a
variety
of
you
know:
roll
out
upgrade
strategies
that
that
seems
like
a
pretty
tractable
change
to
propose
and
it
doesn't
require
changing
like
getting
buy
in
on
changing
development
processes
and
planning
processes
and
like
restructuring
the
whole
project.
So
I
I
I
think
that
might
be
a
good
middle
ground,
at
least
to
start.
C
I'd
like
to
plus
onenet
that
actually
from
when
you're
trying
to
stay
in
support,
an
annual
cycle
is
much
easier
because
all
the
people
I've
interacted
with
have
annual
events
that
that
impact
their
ability
to
to
do
upgrades.
So
as
an
example,
all
the
banking
customers,
I
know
have
big
change
features
around
christmas.
A
B
B
So
practically
speaking,
there
is
kind
of
three
releases
plus
a
few
weeks
if
that
became
four
releases,
plus
a
few
weeks
kind
of
a
final
cleanup
patch
release
of
the
of
the
fourth
version,
yeah
just
figuring
out
everyone
who
would
need
to
agree
to
that.
I
know
some
of
the
sig
release
processes
have.
B
D
I
mean,
I
think,
to
be
honest,
it
sounds
like
that
is
the
most.
This
is
the
thing
that
every
time
you've
talked
about
it,
jordan,
we've
we've
all
sort
of
said
yeah.
That
sounds
like
a
good
idea
and
that's
been
in
for
a
long
time
now.
You
know
that
to
me
feels
like
the
most
immediate
thing
that
we
could
do
to
you
know
to
actually
be
delivering
something
out
of
this
ltsc.
If
nothing
else
we
can
say
this
is.
A
A
If
you
want
to
go
to
latest,
if
you
have
lagged
a
year
behind
it
and
you
want
to
upgrade,
you
have
to
do
incremental
upgrades
and
then
once
you
reach
the
incremental
upgrades,
you
might
have
deprecated
something
out
which
is
not
a
guarantee
that
your
workloads
will
work
so
it
kind
of
gets.
You
know
the
predictability
of
upgrades
once
you
expand
it
more
than
they
say
three
releases.
The
predictability
goes
down,
so
maybe
we
need
to
also
look
at
how
we
can
guarantee
upgrades,
maybe
and
mine,
support
n
minus
two
upgrades
and
track.
A
Some
kind
of
that
features
are
deprecated
only
after
a
year
after
the
application
notice,
as
are
yeah.
Something
like
that.
I
mean,
if
you
know
it
takes.
We
also
need
to
measure
how
much
it
takes
from
us
for
us
to
go
from
alpha
to
stable,
because
if
the
features
are
staying
alpha
for
a
year
or
more,
they
could
change
very
drastically
and
users
who
are
dependent
on
them
are
literally,
I
mean
so.
There's
no
guarantees
there
sometimes.
So
we
need.
B
I
don't
think
it's
likely
that
without
significant
improvements
to
both
review
and
testing,
we
could
actually
do
skip
level
upgrades
for
people
depending
on
alpha.
That
is
something
we
have
discouraged
and
should
discourage.
People
should
not
use
alpha
features
and
expect
them
to
be
forward
or
backwards
compatible.
Like
that,
that's
why
they're
disabled?
By
default?
B
A
Yep
and
I
think
that's
not
being
followed
and
a
lot
of
people
who
are
still
using
it
and
getting,
but
I
I
believe
there
should
be
some
middle
ground
in
the
upgrade
story,
because
once
we
increase,
I
mean
once
we
have
yearly
support
cycles,
we
would
have
with
the
next
biggest
problem
would
be
upgrades,
I'm
getting
too
far
away
from
the
latest.
You
know
I'm
like
one
year
away,
so
I
need
to.
If
I
want
to
go
faster
ahead,
then
I
need
that
understanding.
A
So
I
think
we
need
to
come
up
with
a
recommendation
which
says
I,
the
working
group
lts
will
not
be
solving
it,
but
can
be
a
second
proposed
second
document
that
says:
okay.
We
also
propose
this
so
that
we
can
split
the
concern
and
the
the
jury
can
go
and
look
at
the
first
proposal
and
say
this
is
fine,
and
this
looks
like
a
good
goal
for
say
six
months
or
one
year
to
achieve
like
let's
improve
the
project
in
the
next
one
year
like
this
and
immediately.
D
Yeah,
I
think
the
yeah
I
agree.
It
makes
sense
to
me
to
have
the
like.
There
be
a
thing
that
says
you
hey,
we
kind
of
we
recommend
moving
from
the
deprecation
cycle
being
three
releases
to
four
releases
so
that
it's
blank
yeah,
yeah
four,
so
yes,
four
point
releases
so
that
it's
roughly-
and
we
put
in
you
put
in
that
document
saying
it's
so
that
it's
roughly
an
annual
cadence
instead
of
a
nine
monthly
cadence,
because
that's
less
surprising.
D
A
D
B
A
When
we
started
the
project
in
the
charter,
we
had
listed
couple
of
sigs.
That
would
be
impacted
by
this.
I
think
we
should
go
and
first
we
should
go
and
get
the
approval
from
the
six
that
you
mentioned:
sick
testing,
cigar
architecture
and
sig
release
as
keep
key
sigs
and
then
go
once
we
get
good
feedback
from
them
and
improve
the
proposal.
We
should
go
to
the
rest
of
the
six
and
say
hey.
It
looks
like
from
these
things,
which
are
broad
sigs.
We
have
gotten
good
approval.
A
A
I
I
I
I
think
I
would
work
on
two
proposals.
One
is
how
should
upgrades
change
and
the
policy
for,
like
the
development
policy,
that's
kind
of
on
the
roadmap
for
saying,
okay
next
one
here
we
should.
These
are
the
areas
where
we
should
improve
on
and
that's
why?
I'm
looking
at
api
stability
too,
to
say
that
okay,
we
need
to.
We
need
a
way
to
track
how
long
our
features
are
in
alpha
and
they
are
not
moving
ahead.
What's
the
actual
pace
of
our
project,
so
some
kind.
B
A
B
Yeah,
so
if
we
start
a
document
that
says
here's,
the
proposal
here
are
the
changes
that
we
would
be
required
like
specific
changes,
and
then
we
can
like
tag
the
the
sigs
for
each
area
into
those
docks
and
say
like.
Are
there
other
things
that
need
to
be
called
out
here?
Other
benefits
or
other
costs
just
so
we
can
kind
of
lay
all
of
those
out.
That
seems
like
a
good
next
step.
A
B
A
Yeah,
I
think
I
will
follow
that.
I
mean
it's
easier
to
comment
and
collaborate
on
the
talks,
so
we
can
start
there
and
then
all
the
key
people
in
this
group
can
start
commenting
and
then
once
we
are,
we
can
create
a
timeline
where
we
say:
okay,
this
is
the
end
period
a
month
or
two
where
we
could
get
to
discuss
on
the
proposal
and
other
topics
and
then
we
can
move
forward
from
there
and
then
just
create
a
cap
out
of
it
and
then
propose
it.