►
From YouTube: WG LTS biweekly 20200218
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
A
A
A
A
Well,
we
may
as
well
get
started,
can
can
the
two
of
you
hear
me
I'm,
not
hearing
any
audio.
Okay
Lumiere
says
yes
in
the
chat
all
right,
so
the
recording
is
automatically
going.
This
is
the
February
18th
meeting
of
the
working
group
LTS
for
kubernetes.
The
meeting
is
recorded.
We
follow
the
kubernetes
code
of
conduct
and
the
video
will
get
uploaded
to
YouTube
after
we're
done
here.
I.
A
A
B
Okay,
better
okay,.
A
I
hear
you
too
all
right
cool
well
with
that
out
of
the
way,
so
I
was
just
starting
to
paste
a
few
things
in
the
agenda
which
I
had
not
done
previously,
so
there's
kept
stuff
to
talk
about,
contributes
and
survey.
I
believe
would
be
the
things
for
the
week
anything
that
you
want
to
talk
about
Josh
outside
of
those
three
nope.
A
Okay.
So,
first
of
all,
you
see
if
I
paste,
a
link.
I
can't
tell
if
scheduling
me
things
on
this
link
for
the
contributor
summit
or
if
it's
actually
public,
now
I
thought,
like
kind
of
today
tomorrow
and
we're
supposed
to
be
going
public
but
I
forget
the
specific
date
can
either
of
you
see
that
we
get
the
actual
schedule.
A
Yeah,
okay,
so
then
I
guess
I'm
not
blowing.
Anything
I
wasn't
sure
if
this
was
public
yet,
but
the
schedule
is
up
and
we
are
on
the
schedule
so
1:30
in
the
afternoon
on
Monday
March
30th
during
contributor
summit,
we've
got
a
time
slot
to
talk
about
things,
in
particular
the
the
kept
proposals.
So
with
a
little
luck,
we'll
have
conversation
a
little
bit
more
down
the
lane,
I
guess.
In
our
prior
meeting
two
weeks
ago
we
talked
about
starting
to
drive
for
the
last
bit
of
feedback.
A
B
A
A
One
of
the
annoying
things
about
how
github
does
its
conversations
is
that
you
get
sort
of
a
new
thread
ish
in
time
order,
but
within
each
thread
since
their
threads.
It's
really
hard
to
look
and
see
like
what
is
the
most
recent
comment.
I've
been
trying
to
look
at
this
periodically
and
see
like
how
many
of
these
sub
points
of
conversation
gotten
new
comments,
but
like
scrolling
back
through
months
worth
of
comments
is
tedious
and
lossy.
So
I
feel
like
the
the
main
set
of
additional
feedback
we
got
two
weeks
ago.
A
B
B
A
A
A
B
A
A
A
Right
we
in
the
cost
section
and
I
think
that
was
part
of
what
what
Ben
was
calling
out
like
we're
saying
that
there's
no
additional
cost,
but
it
is
an
additional
cost
by
not
removing
yeah.
B
A
We
have
this
an
accounting
world
double
ledger
book
entry
like
it.
Maybe
it
would
make
more
sense,
I,
don't
know
we
don't
have
numbers
around
any
of
this
anyway.
No
I
think
it's
it's
down
at
the
end
test
plan
where
he
says
it:
we're
increasing
the
skew
and
expanded
test
matrix,
so
yeah,
probably
both
could
be
yeah.
B
B
Yeah
I'm
gonna
have
to
put
in
there
as
a
note
that
you
know
some
SIG's
may
decide
to
increase
their
conversion
test
coverage
as
well,
which
would
obviously
be
an
additional
cost,
but
that
would
be
up
to
them
look.
I'm
pretty
sure
said.
Cluster
lifecycle
would,
for
example,
increase
the
scope
of
their
tests.
Oh.
C
B
A
A
A
A
C
B
B
B
C
C
B
A
B
A
A
B
A
A
So
I
started
joining
as
I
was
looking
through,
as
we
were
talking
about
that
I
started
jotting.
One
other
thing
I
saw
in
the
recent
github
comments,
and
that
is
the
temp
st.
Clair
had
asked
why?
Why
go
about
it?
This
way,
instead
of
changing
the
release
cadence,
so
going
back
a
number
of
months,
we
decided
that
between
the
two
changing
the
released
cadence,
making
the
releases
more
often
or
less
often
was
a
harder
change
to
realize
than
just
changing
the
support
statement
and
testing
and
documentation
just
changing
that.
A
So
we
did
a
lot
of
discussion
around
that
Tim
had
been
one
of
the
Tim
st.
Clair
had
been
one
of
the
act.
Active
voices
on
making
the
release
cadence
faster,
like
monthly.
So
I
was
a
little
surprised
by
his
comment
to
make
it
slower,
but
I
also
think
like
that
demonstrates
that
that's
a
whole
realm
of
complexity
and
to
shift
that
off
to
the
side
means
that
it
can
be
addressed
on
its
own
conflating.
B
A
B
A
C
A
A
B
B
The
main
reason
why
we
decided
not
to
pursue
that
route
was
because
well
we
have
people
in
the
community
who
would
like
to
do
releases
less
frequently.
We
also
people
the
community
would
like
to
do
releases
more
frequently
and
the
more
frequently
in
camp
includes
Tim,
which
is
why
you
know
the
suggestion
from
him.
You
know
who
attended
our
meetings,
so
this
suggestion
from
him
is
a
little
strange,
so
I
think
we
actually
need
to
particular
comment
on
that.
B
A
That
well
monthly
development
branches
and
annual
release
branches
or
out
of
state
branches
I
forget
what
the
nomenclature
was.
He
was
using
their
stable
I
think
so
then
I
mean
he
he
may.
He
may
be
arguing
both
sides
of
it.
Yes,
we
need
to
make
smaller
releases,
but
from
a
support
perspective
we
should
make
larger
releases.
A
B
B
B
Well,
I
mean
obviously
a
cap
is
the
place
to
discuss
alternative
plans,
or
at
least
discussion
on
the
cap
right,
because
if
anybody
has
a
proposal
for
we're
gonna
do
acts,
then
somebody
can
say
hey:
why
would
fulfill
the
same
goals
and
it
would
be
easier
because
acts?
You
know
the
and
that's
a
perfectly
reasonable
thing
to
do.
The
problem
is
that
you
know
we're
gonna
have
to
bring
that
back
to
community
discussion
and
say
hey.
C
A
I
feel
like,
if
yeah
as
a
working
group,
we
collated
a
set
of
experiences
and
opinions
together
and
found
this
as
a
common
path
that
provides
an
improvement.
There
has
been
a
common
refrain
there,
though,
of
people
saying
well,
it's
such
a
small
improvement.
Is
it
really
worthwhile
and
I
do
see
that
in
Tim's
comments
like
three
versus
four
or
three
months
versus
four
three
releases
versus
four
releases
or
four
months
versus
three
months
like
either
way
they're
both
minor
increments
yeah.
B
B
A
A
A
In
particular
and
related
to
Tim
st.
Clair's
proposal
around
moving
faster,
we
say
this
maybe
compatible
and
complementary,
with
the
change
proposed
in
this
cap.
Additional
changes
in
this
direction
remain
a
possibility
in
the
future.
So
we're
not
saying
we
don't
want
it,
but
unless
there's
somebody
championing
that
direction,
it's.
C
A
A
If
you
ask
customers
would
you
prefer
to
never
have
to
upgrade
for
the
next
seven
years
and
everything
works
perfectly
for
that
time
without
ever
upgrading,
like
everybody's
gonna,
say
yes,
people
don't
like
to
have
to
change
things
for
no
reason,
so
the
longer
support
you
offer
people
are
gonna,
probably
choose
four
less
releases
more
support,
but
for
somebody,
who's
looking
for
a
new
feature
today
and
isn't
getting
it
or
finding
it
slow.
Those
people
are
gonna
say
that
they,
they
probably
want
to
get
features
faster
and
then
on
the
other
side
of
the
equation.
A
B
B
I
mean
I.
Think
at
this
point,
I,
don't
I
don't
feel
like
I
need.
We
need
feedback
from
the
general
user
base
on
those
two
alternatives.
Are
we
gonna
feedback?
The
feedback
I
care
about
is
test
infra,
the
release
team
and
the
sort
of
collective
sig
leadership
the
because
the
people
who
it
really
affects
are
the
people
who
need
to
support
our
release
infrastructure.
You
know
who
it
obviously
affects
from
a
cost
perspective.
B
C
C
B
I
mean
from
that
perspective,
I
would
expect,
based
on
a
previous
survey.
Data
I
would
expect
a
slight
tendency
towards
an
approval
of
less
frequent
releases,
because
if
you
look
at
that
curve
of
which
version
people
are
using
in
production,
you
see
that
that
curve
Peaks
like
two
releases
ago,
so
you
know
clearly,
people
who
are
using
releases
that
are
two
three
releases
old
and
production
would
be
happy
to
have
us
have
less
frequent
releases.
They
might
even
be
happy
if
we
went
to
semiannual
releases.
B
Potential
costs,
one
is:
do
less
frequent
releases,
make
the
release
process,
notably
harder
right,
because
less
frequently
uses
means
bigger
releases
for
some
definition
to
bigger
and
since
I
have
ample
experience.
With
the
end
point
of
this,
with
a
project
doing
annual
releases,
I
will
tell
you
that
that
cost
is
substantial
and
notable.
B
B
The
other
you
know,
and
obviously
we
wouldn't
get
there
with
four
months
releases,
but
you
know
how
much
longer
would
code
freeze
need
to
be
etc.
So
it's
gonna
affect
the
release.
People
and
then
second,
you
know
for
people
who
are
writing
features
does
effectively
possibly
needing
to
wait
an
extra
two
months,
I
mean
if
they
missed
the
boat.
B
You
know
how
bad
is
that
from
their
perspective,
you
know
cuz
like
right
now
with
quarterly
releases.
If
your
feature
doesn't
make
it
in
this
quarter,
then
you
can
probably
get
it
in
in
the
next
release
and
therefore
I'm
gonna
probably
get
into
the
next
release
and
therefore
you're
only
waiting,
you
know
say
about,
for
you
know
a
little
over
three
months.
B
A
A
Say
I've
become
increasingly
worried
about
the
type
of
stuff
you
just
articulated.
Over
the
last
year,
I've
seen
an
increase
in
proposals
of
cherry
picks
to
patch
branches,
which
feel
feature
like
and
which
are
they're
partly
related
to
the
fact
that
we
don't
have
the
split
out
monolith
entirely
yet,
but
yeah.
B
A
A
particular
cloud
provider
is
is
trying
to
get
a
feature
into
a
particular
reso
that
they
can
get
it
out
to
their
customers
and
they're,
even
trying
to
do
that
in
patch
releases.
Much,
but
then
also
in
the
current
pending
release,
seeing
a
little
bit
more
things
that
almost
feel
like
enhancements
enhancement,
proposals
that
are
graduating
early
or
being
pushed
forward
to
to
get
them
somewhere
and
a
vague
sense
behind
that
that
a
vendor
is
is
looking
to
get
something
declared
as
GA,
so
that
they
can
convince
their
customers
to
use
it.
A
And
that
explicitly
in
comments
like
we
need
to
have
this
GA,
because
nobody
will
use
it.
If
it's
not
GA
and
that's
that's
the
opposite
of
how
we
want
to
work
as
a
open-source
project.
I
would
assert
that
we
should
be
merging
things
that
are
ready
and
demonstrable
viable
high
quality
versus
vendors
wanting
them
in.
B
Yeah
anyway,
I
mean
this
is
so
if
we're
going
to
talk
about
this
is
an
alternative.
I
think
it
is
an
entire
separate
gap
that
will
also
require
discussion,
because
for
that
matter
we
have
a
stability
working
group
and
I
would
say
you
know
hey
for
the
reasons
you
just
mentioned.
The
stability
working
group
needs
to
weigh
in
underneath
change
to
release
cadence
you
know:
does
this
make
their
job
easier
or
harder.
B
The
so
you
know,
and
there
would
be
a
all
set
of
falun
changes
right
if
our
releases
were
less
frequent,
we
would
need
to
change
our
deprecation
policy
and
you
know
a
whole
bunch
of
other
things,
but
actually
probably
or
we
didn't
change.
The
deprecation
policy
would
effectively
mean
that
deprecated
features
would
still
exist
for
a
longer
calendar
time,
which.
B
B
B
The
only
reason
why
you
know
I
still
play
around
with
the
idea
is
there
are
ways
that
it
would
make
the
actual
release
cycle
a
little
bit
easier,
because,
right
now,
with
a
three-month
release
cycle,
the
release
team
keeps
running
into
timing
issues
around
both
coupe
cons
and
international
holidays
and
having
a
four
month.
Release
cycle
would
make
it
easier
to
dodge
those
kinds
of
things.
A
A
B
C
A
C
C
A
Cube
con
in
San
Diego
fall
of
2019
for
the
recording
Brian
grant
was
in
the
contribs
summer
session
and
I
would
summarize
as
being
supportive
of
what
we're
proposing
here.
I
see
that
late
last
week,
Tim
Hawke
and
marked
himself
on
the
tempest
intending
to
review
so
we'll
see
what
feedback
we
get
there
yeah.
B
B
A
C
B
I
would
say
we
don't
have
the
ability
to
get
thousands
of
people
to
respond
to
a
a
survey
like
we
pulled
out
all
of
the
stops
to
push
our
last
survey,
which,
admittedly,
was
relatively
long
and
for
that
reason
it
limited
who
felt
that
out.
But
our
last
survey
we've
got
a
tree
broadcast
by
like
multiple
key
people
in
kubernetes
and
by
the
CN
CF,
and
we
got
six
hundred
people
who
even
started
the
survey.
I
think.
B
B
And,
like
I
said,
you
know
from
my
perspective,
I
care
about.
You
know
I
care
about
how
contributors
feel
about
the
tool
turn.
It
is
my
caring
for
how
the
public
feels
you
know
my
hierarchy
of
who
I
care
about
is
contributors
number
one
then
vendors
say
number
two,
because
the
vendors
are
gonna
have
feedback
about
what
they
would
prefer,
that
we
do
pretty
sure.
B
A
Yeah
I
think
the
contributor
like
we,
we
definitely
we
started
with
trying
to
understand
the
end
user
in
the
vendor
set
to
see
what
is
there
actually
a
gap
there
are
we,
as
a
community
under
delivering
verses
desires,
so
I
think
we
started
with
their
perspective
with
intention
and
we're
really
off
into
the
space
where
we're
trying
to
figure
out
with
some
things
discussed
and
some
desires
there
as
a
concrete
cap,
what
is
a
community?
Are
we
capable
of
delivering
in
there?
A
It
really
gets
into
even
beyond
the
thousand
or
so
people
in
the
org
I
think
the
the
cig
leads,
because
they
understand
what
the
specific
costs
are
within
their
domain
and
their
ability
to
organize
people
around
doing
the
work
and
if
it's
not
viable,
even
if
there
is
a
desire
from
the
user
base,
it's
not
something
as
it
can.
We
would
be
able
to
tackle.
We'd
have
believed
it
to
vendors
to
provide
that
differentiated
support.
The.
B
A
A
Other
thing
was
just
to
talk
about
the
survey,
so
we
were
discussing
not
doing
a
survey
and
I
just
wanted
to
just
like
reiterate
that
work.
We've
we
decided
not
to
do
a
specific
survey
ourselves.
The
production
readiness
one
so
again,
just
like
remind
people
to
put
some
shoutouts
out
there
on
that
try
and
get
more
people
to
respond.
Okay,
last
year's
work
group
LTS
survey
was
had
really
high
response
rate,
because
people
were
saying:
hey
we're
trying
to
get
your
feedback.
We
want
to
get
feedback,
so
just
that
okay
is.
A
C
C
Hawkins
responded
four
minutes
ago
to
the
Cape
Oh,
perfect,
perfect
timing,
yeah,
so
I
just
want
to
say
something
about
the
the
survey
we
do
in
food
sequester
lifecycle.
If
you
think
that
we
can
inject
some
LDS
related
questions
in
there
just
I
guess
you
have
to
formulate
them,
probably
during
a
call
here,
I'm,
not
sure
if
it
makes
sense,
but
like
last
year
we
had
a
generic
audience
question
like
do
you
want
the
OGS
in
kubernetes
I
think
you
may
observe
it,
but
it's
a
it's
a
silly
question.
C
B
B
A
B
And
then
it's
it's
already
in
the
kept
as
risks.
Yeah
we've
already
put
that
in
the
café's
risk,
because
that,
yes,
that
very
well
could
happen.
You
know
right
now
we're
making
the
assumption
that
we're
getting
this
11-month
problem,
because
a
lot
of
people
are
on
sort
of
annual
upgrade
cycles,
but
that
goes
wrong.
We.
A
Did
hear
that
from
some
that
they
have
business
processes
that
are
around
the
calendar
and
we
know
like
from
our
own
experiences
that
yeah.
That
is
something
that
happens.
That
is
real,
whether
it's
the
primary
factor,
it's.
It
is
hard
to
say
if
we
shifted
from
a
nine
plus
three
to
a
six
plus
two
and
we
shortened
our
support
either
people
would
start
upgrading
faster
or
not
right,
if
that
is
the
the
main
motivator
I,
don't
see
them
upgrading
faster
and
just
my
experience,
what
I've
seen
in
my
time
in
the
industry,
yeah.
B
The
question
is
how
many
right
I
mean
the
dirt
I
guarantee
you
that
there
are
users
out
there
that
their
process
is.
Oh,
my
god,
the
kubernetes
version
that
we're
using
is
eol
I'd,
better
talk
to
my
boss
about
upgrading
and
those
people
will
backslide
to
whatever
our
window.
Support
is
the
question:
is
you
know,
out
of
the
25,
to
30%
of
our
users,
who
are
on
currently
in
the
eleven
month
window?
B
What
portion
that
is
we're
assuming
that
that's
a
minority,
but
we
won't
actually
know
until
we
do
something
we're
also
up
against
another.
You
know
sort
of
fact
that
makes
things
a
little
bit
unpredictable,
which
is
that
in
the
last
year
and
a
half
kubernetes
has
gotten
substantially
more
usable
in
production
and
therefore
a
lot
of
people's.
What
is
your
production
version
is
based
on
what
was
the
first
version
you
could
use
in
production,
rather
than
anything
based
on
our
release
cycles.
B
You
know
this
is
the
first
version
here
and
this
matches
the
first
version
of
OpenShift
that
was,
production
warning.
This
matches
the
first
release
of
VMware
scoober,
on-prem,
kubernetes
and
we'll
see
these
sort
of
benchmark
versions
that
never
get
upgraded
and
right
now
that's
going
to
be
kind
of
lost
in
our
data,
because
really
we're
looking
at
maybe
about
two
years
of
production
worthiness
and
it's
not
possible
for
us
to
tell
the
difference
between
that
and
people's
frequency
of
upgrading.
B
Would
need
people
to
be
willing
to
fill
out
a
survey
we'd
honestly
need
to
do
a
follow-up
survey
that
involved
doing
interviews
with
actual
users.
You
get
to
a
point
where
you
can't
really
answer
questions
by
multiple
guests
without
leaving
things
out
so
the
way
this
is
generally
dealt
with.
If
you're
saying
industry
analyst.
Is
you
schedule
meetings
with
like
C,
you
know
CIOs
at
users
and
organizations
and
do
an
interview
with
them
and
do
a
whole
narrative
interview.
B
A
B
B
B
The
and,
and
also
to
a
certain
extent,
I
think
that
only
matters
to
the
extent
that
if,
if
we
actually
believed
that
it
was
possible
that
out
of
that,
you
know
twenty
eight
percent
of
our
users,
who
are
slightly
AOL,
that
are
slightly
expired.
If
we
believe
that
it
was
possible
that
you
know
a
substantial
portion
say
you
know,
half
of
those
twenty
eight
percent
were
people
who
were
actually
on
benchmark
versions
and
that
it
was
not
based
on
an
upgrade
cycle
at
all.
I.
B
C
A
A
No
they're
not
interviewing
end
users,
but
people
are
showing
up
as
representatives
of
and
talking
about
what
global
changes
we
should
do
for
the
project,
but
whether
they're
arguing,
maybe
primarily
from
their
employer
perspective
or
from
the
customers
of
their
employers.
It's
it's.
We
have
a
funnel
of
representation.
Yeah.
B
B
B
B
That
that
particular
interview
is
actually
part
of
my
reason.
Why
I
think
if
we
brought
up
questions
or
four
months
versus
three
months
on
cetera
to
the
actual
end
users,
we
would
not
get
any
determinative
answer.
I
think
we'd
say
something
that
said
it
was
good.
Something
said
it
was
bad
and
a
whole
lot.
That
said,
don't
care!
That's.