►
From YouTube: WG LTS biweekly 20200512
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).
B
A
D
D
Yep
previously,
when
we
met
I
had
been
gonna,
send
out
a
message
Takeda
of
saying
hey.
We
think
this
is
implementable,
give
a
the
normal
lazy
consensus
number
of
days
and
and
just
kind
of
be
the
that
one
more
chance
for
people
to
object
or
support
publicly
if
they
wanted
to.
But
in
the
meantime,
planning
things
around.
The
119
release
brought
up
some
LTS
related
topics,
and
there
was
a
lot
of
back-and-forth
on
what
could
or
should
be
done
and
different
of
expectation.
So
I
feel
like
in
in
January
we'd.
D
So
119
is
a
place
where
we're
better
off
in
that
regard,
because
115
has
gone
out
of
support,
but
then
that
kind
of
brought
up.
That's
this
question
of
a
way
you
meant
only
for
119
and
forward,
not
as
of
119
operationally
that
we
would
be
supporting
things
for
longer
and
that's
that's
a
notable
distinction,
because
it
means
a
retroactive
change.
Really
if
we
were
to
go
that
direction,
it's
the
the
distinction
between
staying
for
119
and
greater
versus
as
of
this
summer,
we
start
offering
longer
support,
is,
is
a
big
difference.
Yeah!
D
E
D
D
We
need
to
talk
about
what
that
plan
would
be
and
where
people
weren't
comfortable
with
it
in
January,
is
there
some
pragmatic
middle
ground,
where
we
could
look
at
some
best
effort
support
still
for
118
117
116,
some
some
combination
of
those
or
do
people
really
only
want
to
do
119
and
later
like
we
could.
We
could
mark
the
kepis
for
119
and
later,
but
then
have
a
separate
discussion
about
the
in-between.
A
Yeah,
we
were
just
discussing
how
the
extension
of
schedule
for
119
has
affected.
What
was
our
original
cap
proposal,
and
you
know
they
brought
up
yeah,
because
the
question
is
open.
What
are
we
going
to
end
up
doing
about
117
and
118
right,
particularly
if
the
release
team
goes
back
to
a
four
releases
per
year
schedule,
although.
A
Thinking
about
where
we
are
right
through,
you
know
through
120,
that's
three
releases
this
year,
so
the
only
release
that
could
be
three
months
in
at
length
would
be
121
and
then,
after
that
were
on
to
the
119
support
timeline.
If
you
follow
me,
that's
us
make
sense
now
so
I
guess
what
would
be
the
special
problems
with
supporting
117
and
118
for
a
year.
D
Okay,
as
I
guess,
I've
been
thinking
of
this
more
from
the
community
perspective.
Where
we
in
this,
where
you
group,
we
were
trying
to
figure
out
like
one
of
the
big
objections
how
to
handle
like
the
SIG's
thing.
They
don't
want
to
do.
Support
for
long
or
like
really
steam
being
able
to
build.
One
16
doesn't
mean
that
people
are
gonna,
be
patching,
fixes
or
technically
able,
like
yeah,
depending
on
what
the
patch
is.
That
could
require
significant
work
to
to
backboard
or
fork
like.
A
D
A
D
A
You
know
this
would
be
a
good
pick
group
somewhere
champion
back
borders
like
Liggett
and
dims
and
dad's
people
who
do
a
lot
of
back
porting
of
patches
and
to
get
their
updated
perspective
on
things,
because
I
mean
I
would
expect
the
year
ago
release
by
the
time
it
is
in
its
last
three
four
months
to
be
getting
fewer
patches.
If
you
follow
me.
E
I
would
probably
group
the
work
into
three
ish
areas,
so
there's
just
sort
of
the
the
release,
staffing
release
and
CI
jobs
like
just
kind
of
keep
the
ship
running.
Nothing
particularly
special
there
and
it
sounds
like
we
can
keep
the
CI
jobs
running
and
we
can
cut
patch
releases
like
that.
That's
understood,
then
there's
the
cumin
like
kubernetes
fixes
that
get
backported
and
I
think
that's
also
pretty
well
understood
and
the
further
back.
E
We
pick
things
the
more
likely
it
is
that
the
code
is
changed
in
ways
that
make
a
backcourt
unfeasible,
and
so
we
we've
made
judgment,
calls
there
in
the
past.
You
know,
we've
said
this
bug
existed,
you
know
back
two
or
three
releases,
but
the
risk
of
picking
this
fixed
back
outweighs
the
benefit
of
the
severity.
So
we're
actually
only
going
to
pick
this
back
one
release.
We've
we've
made
that
call
before,
but
that's
within
our
control
right,
it's
our
code.
We
can.
E
We
can
pick
it
back
if
the
severity
and
the
benefit
outweighs
the
risk.
The
last
piece
is
what
Tim
was
talking
about
like
dependencies.
So
there
are
two
schools
of
thought
to
this.
One
is
for
us
to
say
we
support
in
releases
back.
That
means.
Every
single
dependency
we
have
must
have
must
also
be
supported
for
that
duration.
That's
one
school
thought.
The
other
school
of
thought
is.
We
will
pick
up
security
fixes
that
are
made
available
in
those
dependencies.
E
So
if
we
have
a
version
of
communities
that
is
on
a
version
of
go,
that's
three
releases
old
well
go,
isn't
really
seeing
security
updates
for
that
version
anymore.
So
we
we
will
pick
up
any
security
fixes
available
on
the
go
version
for
that
build
lip
kubernetes
and
turns
out.
There
aren't
any
more
available
that
that's
the
other
way
to
look
at
it.
I
tend
to
think
that
supporting
the
kubernetes
aspects,
the
code
that
we
have
in
our
control
gives
people
on
those
releases
of
choice.
E
I
would
like
to
see:
go,
extend
their
support
policy,
I'm
and
I'm.
Making
news
in
that
direction
to
try
to
stir
up
some
of
that
discussion,
but
until
that
happens,
I
still
think
there's
benefit
in
taking
the
kubernetes
issues,
but
by
far
most
of
the
things
that
make
it
into
kubernetes
patch
releases
are
fixes
to
kubernetes
bugs
bugs
in
our
code.
E
So
if
we
think
of
those
three
areas
like
the
rel
inge
CI
job,
just
mechanics
the
back
ports,
where
we're
already
making
judgment,
calls
about
whether
how
many
releases
back
a
fix
should
go
and
then
the
dependencies
I
don't
see
the
dependencies
thing
as
blocking
supporting
our
own
bug,
fixes
back
another
release.
Okay,.
A
A
So
I,
don't
I,
don't
know
when
you
joined
us,
but
one
of
the
things
we're
discussing
is
the
extension.
The
schedule
for
119
has
brought
up
an
issue
in
terms
of
what
schedule
117
and
118
are
going
to
receive
patches
on,
because
it
would
be
really
weird
to
have
116
de
facto
supported
for
a
year
and
then
revert
to
nine
months
of
support
for
one
17
and
18
and
then
extend
the
support
of
119
for
a
year.
But
there
might
actually
be
technical
reasons
to
do
that.
A
A
D
Definitely
more
worried
about
115
I.
Think
116
is
probably
a
lot
better
off,
but
we
hadn't
gone
into
specifics
on
it
versus
having
a
list
of
things
that
were
worries
in
115
yeah.
D
D
E
D
Were
all
of
the
problems
that
we
talked
about
there
just
pulling
up
the
thread
because
multiple
people
chimed
in
with
different
things.
D
Or
was
it
all
in
that
thread?
I
thought
more
than
Christophe
had
mentioned
so
Christoph
and
the
the
issues
with
dependencies
and
go
Ling,
but
I
thought
a
couple.
Other
people
had
chimed
in.
Maybe
that
was
separately
on
slack.
There
were
some
tests
related
things.
If
I
recall
correctly
from
on
the
test.
A
D
And
a
lot
of
the
conversation
that
are
like
is
we've
been
discussing
this,
the
the
things
that
people
were
happy
with
in
115
we
talked
about
a
year
ago,
kind
of
in
116
like
each
releases.
We
were
talking
about
LTS
and
what
might
be
an
acceptance
criteria
to
start
doing
longer,
support
at
any
point
in
time,
people
you
all
had
things
that
were
currently
on
their
mind,
but
the
further
we
go
back,
the
more
it's
like
I
remember.
There
was
something
bugging
me
back
then,
but
what
wasn't
it.
E
E
So
people
who
are
waiting
for
that
to
happen
so
they
could
drop
support
for
the
extensions
B
1
beta
1
workload,
guys
and
if
one
15
was
gonna
claw
its
way
back
to
another
3
months
of
support
that
was
sort
of
a
surprise
to
a
lot
of
people
who
were
making
plans
based
on
like
as
of
this
date.
You
know
this
is
what
the
support
support
of
apos
will
look
like.
A
A
C
A
In
the
event
that
the
release
release
goes
back
to
quarterly
releases
and
the
earliest
time
they
would
do
that
would
be
for
version
120,
no
sorry
version
121
is
there
some
reason
why
we
would
in
support
for
118
after
less
than
a
year,
or
should
we
just
at
this
point?
Consider
hey
were
basically
implementing
the
LTS,
usually
support
proposal
de
facto
starting
with
116.
A
So
the
only
one
that
we
would
be
dropping
from
yearly
support
then
potentially
would
be
118
which
at
that
point
starts
to
look
really
weird
and
exceptional,
and
so
the
way
I'd
like
to
look
at
it
is
is
there
some
reason
why
we
couldn't
keep
patching
118
for
is?
Is
there
any
special
problems
that
would
introduce
for
that
matter?
You
know:
are
there
special
problems
being
introduced
by
116
and
117
that
just
nobody
has
discussed,
because
they
were
too
confused
by
the
release
team
proposal,
which
is
a
distinct
possibility.
B
B
E
D
E
D
A
Think
Jordans
suggestion
was
the
sensible
policy
I,
which
would
allow
us
to
move
forward
and,
and
at
some
in
some
form,
we
should
get
that
out
there
to
make
it
project
policy,
which
is
that
the
idea
of
dependency
support
is
that
we
will.
We
will
port
anything
any
patches
that
come
from
upstream,
but
we're
not
promising
that
we
will
generate
our
own
yeah.
E
E
E
And
I
mean
if
we,
if
you
actually
look
at
the
types
of
security
vulnerabilities
fixed
in,
go
only
a
subset
of
them
even
impact
kubernetes
at
all,
so
just
because
there
is
a
security
release
of
go.
Often
that
is
an
area
of
the
language
of
the
standard
library
that
communities
does
not
use
or
is
not
affected
by
so.
C
E
D
E
No
in
the
entire
square,
so
right
now
a
give-and-go
version
is
supported
for
a
year.
For
us
we
don't
pick
it
up
until
a
couple
months
after
it's
released
because
there's
usually
stuff,
we
have
to
work
through.
It's
not.
We
have
to
soak
so
for
us,
the
effective
lifetime
is
like
ten
months,
but
in
the
one-year
support
time
for
a
go
version,
there's
typically
one
two,
three
security
related
issues
that
are
fixed
and
of
those
typically
one
to
impact
kubernetes.
Okay,.
E
E
If
one
of
our
dependencies
doesn't
provide
a
security
fix,
we
don't
promise
to
fork
the
dependency
and
maintain
our
own
distribution
of
it,
like
so
just
clarifying
that
in
parallel,
I
think
it
makes
sense
to
work
on
some
of
our
major
dependencies
to
try
to
get
them
to
improve
or
lengthen
their
support,
but
I
don't
see
it
as
blocking,
but
yes,
Josh
I
think
we
should
clarify.
What
do
we
mean
by
support?
E
People
here
support,
and
they
don't
know
what
support
means.
They
think
I
found
a
bug
in
this
version
of
kubernetes
and
you
must
fix
it
and
release
a
new
patch
version,
because
I
found
a
bug
and
like
that's
one
extreme
right
and
then
the
other
extreme
is
like
only
this
super
narrow
set
of
things
will
be
fixed
and
like
pretty
much
nothing
else,
and
so
we're
somewhere
in
the
middle,
like
we're
not
going
to
maintain
our
own
distributions
and
things,
but
there's
a
bar
where
it's
like
data
loss,
security
issues
that
can
be
fixed.
E
E
E
I
have
a
12:30
call,
I
have
to
jump
on
to
you,
but
I
I,
remember
of
clarifying
the
dependency
stuff,
especially
because
that
seemed
to
be
a
major
roadblock,
like
the
thought
that
we
have
every
last
thing
that
touches
this
version
of
kubernetes
must
also
sign
on
to
this
extended
policy
that
doesn't
seem
realistic
and
I.
Think
a
lot
of
the
people
are
consuming.
Community's
releases
would
still
benefit
from
us,
maintaining
our
issues
and
making
what
our
dependencies
make
available.
It.
D
E
Would
like
a
list
of
our
dependencies
and
how
their
support
statements
align
with
us
I
had
started
the
dock
a
while
ago.
Just
so,
we
can
call
out
those
gaps
like
this
version
of
communities
depends
on
these
things,
and
just
so
you
know
like
this
thing
falls
out
of
support
here,
so
to
be
transparent
about
like
if
there's
a
go,
if
you
found
it
after
this
date,.
A
A
You
know
including
a
response
from
nearly
from
like
300
end-users,
and
that
was
how
we
picked
the
one-year
turn
it's
referred
to
in
the
cap
there
and
I've
got
some.
We've
got
some
graphs
from
the
survey,
but
it
really
was
showing
us
that
there
was
this
large
cluster,
like
almost
30
percent
of
our
users.
That
was
just
one
to
four
months
out
of
support.
A
Now
our
big
worry
in
the
LTS
that
we
can
only
verify
by
implementing
it
is
if
we
push
the
supported
period
out
for
a
year,
will
that
cluster
of
users
just
move
further
back
right?
To
what
degree
is
a
cluster
of
users
who
needs
an
annual
an
annual
cycle
to
upgrade,
which
we
know
is
some
of
them
by
anecdotal
evidence
versus
how
many
of
them
are?
Are
people
who
simply
don't
look
at
upgrading
until
they
know
they're
already,
EOL
and
I?
A
D
Then
the
thing
that
we're
realizing
just
in
the
last
couple
be
hearing
more
of
is
that
there's
probably
more
so.
Our
survey
was
kind
of
late
2018
early
2019.
We
suspect
there's
more
people
in
that
later
camp
because
just
all
of
the
extra
stresses
and
work
in
life
right
now
around
kovat,
there's
less
resources
less
time.
So
you
you
tend
to
do
the
things
that
you're
forced
to
do
because
everything's
on
fire
well,.
E
C
A
I
mean
for
a
parallel
example:
we
changed
type
coercion
because
we
had
to
because
of
security
holes
rather
substantially
in
post
quiz
8.1,
what
no
in
8.2
from
8.1-
and
we
ended
up
with
a
large
cluster
of
users
who
did
not
upgrade
off
of
8.1
until
it
was
out
of
support
for
like
four
years.
A
A
C
Yeah
I
mean
I,
think
the
other.
The
other
thing
that
is
relevant
the
same
is
that
the
other
new
we
did
find
that
when
we
talk
to
people
about
it
there
was
a
level
of
anecdotal.
Yes,
it
would
be
nice
not
to
you
know
not
to
have
one
of
the
upgrade
windows
over
a
period
of
years
fall
in
our
worst
year,
so
giving
you
giving
you
a
year
period
means
that
retail
businesses
don't
have
to
upgrade
its
one
year
over
the
Christmas,
or
you
know
something
like
that
is
saying
to
say
in
sport,
yeah.
C
D
So
is
we're
chatting
this
I
tried
to
make
a
table
of
kind
of
what
what
the
options
look
like
in
the
minutes
there
we
highlighted
definitely
issues
with
115
the
older
go,
laying
like
we've
already
crossed
that
off
the
issues
around
116
were
the
deprecated
API
is
waiting
their
chance
for
removal
now
seeing
it
a
table
for
him.
That
makes
that
kind
of
highlights
something
interesting
if
we
were
to
actually
suggest
instead
of
116
and
117,
then
that
kind
of
puts
us
on
the
annual
cadence,
because
it's
the
2019
release.
C
D
C
B
B
Cool
yeah
so
I'm
trying
to
take
a
fairly
flexible
view
of
the
LTS
situation
overall,
because
we're
interested
in
what
the
community
does
we
want
to
play
in
that,
but
at
the
same
time
our
customers
are
probably
going
to
need
something
longer
than
what
we've
talked
about
here.
So
we
have
to
figure
out
how
how
to
make
that
work.
B
D
Kind
of
feel
like
in
a
way
I'm
hopeful
that
we're
almost
wrapping
up
on
this,
like
the
working
groups
and
kubernetes
are
time-boxed,
but
one
of
the
things
that
we
did
early
on
was
kind
of
split.
On
two
vectors.
We
realized
that
we
had
two
different
things
that
we
were
talking
about:
the
support
lifetime
and
they
release
cadence.
We
focused
in
on
the
support
lifetime
and
are
pitching
an
improvement
on
that.
The
release.
Cadence
was
something
that
separately.
D
We
thought
deserves
some
discussion
and
maybe
its
own
kept,
but
in
the
meantime,
that's
possibly
also
kind
of
resolved
out
towards
a
longer
cycle
time.
At
that
point,
we
might
even
start
talking
about
winding
this
down
and
long-term
support.
Religious
comes
down
to
the
active
actions
of
support
being
out
in
the
cigs
that
you
care
about
the
ones
that
have
the
risk
of
breaking.
You
help
ensure
that
their
test,
quality
and
coverage
is
meaningful
and
high
and
CI
signal
is
always
green.
That
type
of
stuff
yeah.
C
A
D
That's
I
think
it's
reasonable
and
I
I
think
also
I,
like
the
the
message
that
that
sends
do
not
just
sort
of
be
like
okay,
we're
done
here,
but
I
like
to
to
be
present
and
even
though
I
mean
things
have
notably
quieted
down
compared
to
in
the
past.
It
feels
like
we've
reached
kind
of
a
consensus
on
what
people
are
willing
to
do,
but
then
also
to
have
a
few
people
present
watching
for
issues
and
ready
to
try
and
rally
towards
resolution.
C
Yeah,
okay,
so
that
means
that
that
said
probably
doesn't
miss
we're
here
in
agreement
that
we
should
I,
don't
know
what
we
do
there
about
setting
about
setting
the
Sun
setting
time
for
what
good,
but
yeah
feels
like
something
we
should
communicate
in
a
format.
That's
not
just
you
know
many
minutes.
A
D
So
in
terms
specific
action
items,
I
can
try
and
summarize
this
into
a
email
to
ke
dev
and
get
it
out
there
propose
at
a
minimum.
119
is
implementable
and
that
we
think
summarize
the
reasons
for
why
we
think
116
would
be
better
to
let
go
that
117
and
118
are
probably
viable
to
also
go
ahead
and
shift
over,
in
addition
to
119
to
the
12-month
support
proposed,
lazy
consensus
towards
that,
and
they
kept
being
implementable.
Also
with
that
all
PR,
a
clarification
on
what
we're
declaring
support
means
within
this
to
the
cap.