►
From YouTube: WG LTS biweekly 20200204
Description
WG LTS biweekly Feb 4, 2020
A
A
Well,
we
have
a
couple
things:
we're
gonna
talk
about
today.
I
guess,
I'll
go
ahead
and
formally
say
this
is
a
kubernetes
community
meeting.
It
is
following
the
code
of
conduct,
that's
being
recorded,
we'll
upload
it
to
the
web.
Afterwards,
our
agenda
doc.
For
today
we
had
three
things
in
it.
At
this
point.
The
first
is
to
kind
of
go
over.
Some
of
the
feedback
so
far
on
the
cap.
Second,
is
to
talk
about
whether
we
want
to
do
a
buffett,
contributor
summit,
and
then
the
third
is
the
topic
of
the
survey.
D
B
D
A
We
chose
to
not
change
that
aspect
versus
the
support
aspect
and
we
had.
We
had
two
modes
of
discussion
back
then
there
was,
let's
do
releases
slower
and
let's
do
releases
faster
yeah
at
the
time
Tim
was
saying:
Tim
Sinclair
was
saying:
let's
do
them
faster,
so
I'm
confused
by
a
comment
that
would
say:
let's
do
them
slower.
D
D
Yeah
I
mean
I,
guess
my
feeling
is
like
we
actually
don't
you
still
the
most
about
one
of
the
most
valuable
things
we've
actually
done.
Is
that
actually
sitting
down
and
thinking
about
where,
where
the
extra
work
might
come
from
is
has
been
one
of
the
most
valuable
things
about
this
whole
project.
Yeah.
A
D
Yeah
exactly
yeah,
so
I
think
yes,
I'd
like
to
remind
this,
be
like
yeah.
We
could
do
that.
We
do
discuss
slowing
down
the
release
cadence,
but
there
was
a
lot
of
tension
between
you.
There
was
a
lot
of
some
people
who
wanted,
and
the
data
showed
that
there
was
that
it
was
very
you
know.
Some
people
wanted
things
to
be
faster
and
some
one
of
the
things
to
be
slower
and
so
changing
the
release
can
seems
like
it
would
require
even
more
coordination
than
this.
Does
you
need
that's
fair.
D
A
D
A
E
D
A
So,
as
so
Tim
said,
simpler
is
more
good,
or
can
we
keep
all
policies
the
same
and
just
do
three
releases
a
year
and
split
the
difference
and
I've
drafted?
That
certainly
is
a
possibility.
We
discussed
both
speeding
up
the
released
cadence,
eg
monthly
question
mark
twelve
releases
a
year,
a
question
mark
and
slowing
down
the
cadence
eg
three
Lee
releases
a
year
space
four
months
apart,
question
mark
annual
releases
I
guess
we
also
talked
about
twice
yearly
releases.
A
A
D
A
A
We
run
our
testing
so
like
right
now
we're
supporting
the
release
branches
for
115,
116
117.
Those
are
all
running
with
the
head
of
the
test.
Infrared,
oh
so
I
would
have
thought
that
was
running
with
the
current
basal,
but
maybe
there
if
there's
Basil's,
if
or
where,
there's
basal
isms
within
existing
container
images
that
are
pinned
in
the
old
branches.
We
have
some
bifurcation
there.
B
A
We
I
don't
feel
like
we've
I
guess
not
have
to
go.
Look
at
the
history
of
images.
It
doesn't
so
I
think
that
my
general
thinking
on
this
problem
is
it's
one
that
exists
and
that
we
have
not
managed
well
thus,
far
like
we
on
those
trailing
images,
we
don't
do
a
lot
of
updates
and
I'd
be
curious
to
see
basil
fixes
that
we've
had
to
back
part,
for
example,
or
other
ones
like
I
know
we
do
go
updates
and
that
those
have
been
painful
at
times.
A
A
B
A
And
and
there
there
are
also
some
voices
who
are
ready
for
it
to
move
on.
So
it's
yeah
if
I
feel
like
Basel,
is
one
of
those
things
where
it
has
a
lot
of
promise,
but
once
it's
been
used
for
a
while,
you
may
decide
that
that
promise
isn't
what
you
see
day-to-day
in
effect
on
your
project,
and
then
you
start
to
maybe
decide
to
go
with
something
simpler
and
the
people
who
use
it.
The
most
are
the
ones
who
are
coming
around
to
that.
A
D
Yeah,
that's
the
that's!
The
problem
we
had
on
contours
that
envoy
is
right.
Now
we
don't
do
back
boards
Emma
full
stop.
If
you
want
a
security
fix,
then
you
moved
to
the
latest
version
so
yeah,
which
means
a
lot
and
they're
really
aggressive
on
their
own
as
well
so
yeah.
It
means
that
you've
got
a
you.
Gotta
keep
up
a
lot.
A
B
If
you
look
at
the
boot
files
in
kk,
basel
has
a
set
of
dependency
itself,
so
it's
like
a
dependency
tree
pretty
much.
It
has
gazelle,
which
is
the
tool
responsible
for
all
the
build
files
in
sub
directories.
It
has
dependencies
for
creating
images
dependencies
for
pulling
stuff
from
the
internet.
It's
like
a
whole
build
system.
It's
like
maven,
pretty
much
is
like
something
like
that.
I've.
B
B
I
set
the
problem.
We
have
right
now
that
we
still
me
and
Steven
Augustus.
We
decided
to
send
some
pears
for
KK
to
see
the
reaction
of
some
buzzer
changes
and
people
went
in
there
commented.
Then
they
said
that
we
shouldn't
change
it
like
that,
and
because
me
and
Steven
we
don't
understand
very
well
how
buzzer
works.
B
D
A
And
it's
I
think
it's
fair
for
the
community
to
say,
understand
your
high-level
desire,
here's
a
list
of
things
that
yes
we're
not
managing
today
and
yes,
you
chose
to
not
try
to
manage
them,
but
as
we
elongate
support,
we're
gonna
have
to
draw
the
line
now
and
choose
come
up
with
a
plan
on
how
we
manage
them.
I
I
could
see
that
being
a
possibility
here.
A
D
A
A
G
B
B
F
E
D
Yeah
yeah,
that's
true:
it's
unlikely
that
this
will
be
LG
TMD
concern,
so
yeah
I
think
it
probably
makes
sense
to
do
the
additional
commits
for
now
and
then,
when
it
gets
close
when
people
are
actually
starting
to
be
like
yeah
I
think
this
looks
pretty
good
to
me.
Then
then
I'll
squash,
Sherman
and
move
to
that
and
then
move
back
to
push
push
I.
Think
I
know
you
I
agree
with
you,
the
mere
that
that
I
like
that
too,
and
that's
one
of
the
reasons
that
I'm
used
to
doing
force,
push
but
yeah.
A
D
B
E
E
A
D
A
Well,
okay,
but
then,
and
then
I
went
compared
to
doubled,
like
kind
of
sanity
check
myself
and
I
realized.
Oh,
that
message
doesn't
show
up
in
any
of
the
newer
branches,
but
it's
because
it's
like
it's
hidden,
a
layer
deeper,
it's
not
that
it
went
away.
You
can
now
usually
get
the
impression
that
it's
only
and
it
was
only
in
the
114
branch
like
it
had
been
deprecated
and
it
went
out
of
support,
but
it
is
actually
still
there
and
all
of
the
new
ones.
It's
all
over
the
place
so
like
we.
A
We
have
this
weird
overlapping
state
of
things
where,
like
there
is
no
test
plan
for
the
kubernetes
project,
for
example,
cig
test
sick
testing
is
more
arguably
sig
test
infrastructure.
They
explicitly
stayed
in
their
charter
that
they
don't
do
the
that
test
plan
level
type
of
stuff.
It's
whatever
the
project
wants
to
do,
for
its
testing
they'll
make
sure
that
there's
a
way
to
run
it,
but
they
don't
get
involved
in
talking
about
what
should
run
or
should
not.
A
But
at
the
same
time,
when
all
of
the
tests
are
implemented
in
a
test
infrastructure
sort
of
way-
and
they
start
to
say
that
that's
not
supported
that
that
sends
a
message
and
it
can't
be
both.
Like
you
can't
say
it's
out
of
support
is
a
scary
message,
but
just
kidding
wink-wink
nudge-nudge,
we
yeah.
H
A
H
D
H
A
A
So
bootstrap
dot
pie
I
mean
one
of
the
questions
I
had
in
my
mind
after
he
typed
in
that
comment
was
well
like
so
can
I
PR
a
change
that
removes
that
message,
a
guy
that,
like
not
int
in
you
to
be
passive-aggressive
but
like
okay.
So
let's
have
a
conversation
like.
Why
is
it
there?
Where
do
we
move
forward?
If
it's,
if
it's
meant
to
be
moving
out
of
support
like
how
do
we
actually
deprecated
it?
How
do
we?
A
B
It
shouldn't
be
I,
think
it
just
the
sheer
volume
of
jobs
that
already
existed,
that
consumers
are
possible,
pay
everything
coverage,
these
branches
tested
using
the
script,
I
think
the
future
potential
extension
that
this
caps
proposes
can
also
consume
boast
about
pie,
and
eventually
we
can
start
duplicating
everything
when
somebody
has
bandwidth
for
that.
The
problem
is
the
sheer
volume
and
the
bandwidth
of
people,
but
the
replacement
is
to
my
knowledge,
is
the
so-called
Pinocchio's,
which
is
a
simplification
of
how
you
write
the
job
for
prom
I.
F
B
A
B
A
Test
infer
stuff
could
need
deprecated
at
a
slower
schedule
or
have
more
backwards.
Compatibility
maintenance
is
is
undeniable,
but
we
we
don't.
I
don't
know
how
they
manage
that
themselves
now
and
yes,
bootstrapped
up
high
is
a
example
of
something
intending
to
change,
but
without
a
plan
it's
hard
to
quantify
costs
there.
D
But
yeah,
but
maybe
we're
not
testing
the
change
in
the
cap
per
se.
Is
that
like
it's?
It's
that
there
Ruben
there
will
be
stuff
that
needs
to
change
it
and
test
infra
and
other
testing
things,
but
it's
not
specifically
about
testing
this
cap.
If
you
know
that
if
I
said
I'm
saying
like
it's
not
like
you're
adding
a
feature-
and
you
need-
and
this
is
the
test
plan
for
how
you're
going
to
test
that
feature-
it's
like
you
know-
there
will
be
changes
needing
to
the
broader
testing.
But
it's
not
like
the
quiet.
D
It's
not
part
of
it's,
not
the
the
thing.
That's
actually
required
to
do
this
care
P.
She
said
I'm,
saying
like
it's
that
to
do
this
camp,
it
will
have
big
costs
unless
we
do
changes
to
the
tests
to
the
testing,
but
the.
But
it's
not
like
it's
not
like.
It's
like
this
specific.
Like
future
test
you
can
add,
or
something
like
that
for
this
cap
goes
to
be.
D
B
Yeah
heard
of
the
comment,
I
think
the
testing
section
of
the
kit
just
needs
to
explain
that
the
changes
in
density
of
are
the
following.
We
need
to
test
another
branch,
which
means
that
we
have
to
build
another,
or
rather,
we
have
to
maintain
another
built,
a
scene
image
for
one
motorcycle
first,
one
for
team.
We
have
to
maintain
it
for
one
cycle,
more
yeah
and
the
other
changes
that
we
have
to
maintain
another
set
of
branch
jobs
which
have
a
schema
files.
We
have
to
keep
them.
B
B
A
A
B
B
Buzzer
has
a
tree
of
dependencies
and
they
should
less
than,
but
they
should
explain
the
consequences
of
maintaining
disaster
buzzing
for
one
more
cycle
like
I,
wanted
to
bring
something
related
to
this
meeting,
almost
daily
basis,
I'm
saying
to
people
reporting
issues
in
KK
that
114
is
no
longer
supported
and
people
continue
to
like
every
day
they
post
issues
about
114
bugs
and
it's
not
clear
to
whether
they
wire
they're,
not
updating
1215,
but
I.
Tell
them
like
hey.
B
B
D
Yeah
I
think
that
yeah,
it's
definitely
I,
think
114
is
the
first
one
that
I've
seen
where
it's
taken
a
long
time
for
the
cloud
providers
to
sort
of
move
people
like
you
to
make
it
will
it
took
a
long
time
for
the
glam
advisors
to
make
115
available,
obviously,
and
they
were
kind
of
pretty
close,
and
then
you
and
now
a
lot
of
people
are
you.
It
seems
like.
Maybe
a
lot
of
people
are
starting
to
keep
more
the.
Why
do
I
need
to
upgrade
I've
got
everything?
I
need
counterpoint.
B
G
D
D
H
D
B
D
D
D
It
does
come
up,
there's
a
couple
of
ones
where
there's
one
wave,
it
was
like
you,
hey,
there's
gonna,
be
a
cost
in
dollars
for
infrastructure
resources
kept
online
and
he's
like,
and
there's
engineering
costs
how'd.
She
critical
bug
did
more
virgins.
So
that's
by
the
fair
I
think
I'll
just
put
that
footage
in
pretty
much
related.
D
D
Don't
think
that
it
feels
like,
maybe
that
one
of
these
camp
is
to
get
your
broad
agreement,
that
you
know
that
this
is
something
we
want
to
do
and
then
one
of
the
actions
from
that
after
we
get
that
broad
agreement
is
then
building
a
test
plan
for
how
like
for
building
a
plan
for
how
we
would
change
that,
how
we
would
change
the
bra
testing
to
support.
That
is
that
does
that?
Take
fair
yeah,
okay,
okay,.
A
D
I
mean
I,
wouldn't
want
proposing
something
because
yeah
so
as
the
person
who
it
would
be
nice
to
be
able
to
have
a
room
where
I
can
guarantee
that
yeah
I
can
say
hey
you
know,
I
was
in
a
room
ready
to
talk
to
you,
people
about
changes.
They
wanted
to
the
kept.
You
know
and
you
if
you
didn't
wanna,
come
yeah,
that's
fair
enough,
but,
like
you
know,
this
is
the
time
when,
if
lots
of
people
around,
let's
talk
about
it
and
try
and
get
a
bit
a
bit
more
high-bandwidth
work
done.
A
D
A
D
I'll
probably
need
to
help
with
that
today,
my
time
Tim,
so
you
want
to
just
give
you
to
do
this
or
give
me
put
me
in
the
right
direction.
Then
I
can
do
some
work
today.
I'm
I'm
out
I'm,
actually
offline
tomorrow
on
Fridays
anytime,
so
yeah
I
won't.
Oh
and
I
know
no.
It
closes
at
the
end
of
the
week,
so
yeah
I
can
sort
of
get
the
process
started,
but
I
won't
go
to
finish.
It.
A
Well,
let's
see,
maybe
we
fit
just
finish
her
today.
There's
it's
not
a
it's,
not
a
complex
one
and
then
so.
I
just
got
a
slack
message
from
Tim
st.
Clair,
suggesting
that
we
we
mentioned
this
cap
on
ke
dev
and
start
a
broader
discussion
around
it.
Try
and
bring
more
eyes
to
it
and
I
think
that's
worthwhile
and
if
we
we
can
also,
if
we've
just
if
today
we
submit
something
to
the
contribs
emmab
off.
We
can
also
mention
that
their
feedback
on
lists
also
come
to
the
debuff
at
contribs
summit.
A
So
survey,
then,
next
up,
so
we've
done
one
last
year
as
we
start
discussing
it
in
the
fall,
we
decided
we
wanted
to
do
one
again
to
try
and
see
what
improvements
we're
getting
and
what
people
think
may
be
of
proposals
for
changes,
see
closer
life
cycles
got
they've
been
doing
an
annual
one
and
they're
drafting
there's.
Currently
we
talked
about
maybe
trying
to
align
with
what
sig
arch
was
doing
and
their
production
readiness
sub
project,
but
in
the
meantime,
they've
gone
ahead
and
gone,
live
and
there's
a
link
there.
A
B
D
B
I
personally
wanted
to
have
the
mapping
between
sacristan
API
and
the
upgrade
question.
So
if
the
production
readiness
folks
wanted
to
wait
for
us,
we
kind
of
combined
this,
but
our
server
is
going
to
be
done
late
March.
So
it
wasn't
clear
to
me
why
they
went
and
released
it.
So
soon
me
and
Tim
discussed
on
privates
that
I
don't
think
we
should
combine
the
service
at
the
same
time.
I
do
see
the
major.
H
And
I'm
not
I'm,
not
all
that
clear
on
what
sort
of
additional
information
we
would
get
that
we
actually
needed.
I
mean
what
I
like
to.
If
the
production
writing
this
thing
actually
had
a
slightly
clearer
version,
skew
question
that
we
had
that
had
which
version
are
you
running
in
you
know
dev
versus
production,
yeah
I
felt
like
that
was
a
nice.
It
was
certainly
useful
from
a
data
analysis
perspective
in
our
own
question.
Yeah.
It.
A
H
D
A
Are
they
succeeding
at
getting
to
being
on
fresher
releases,
so
some
of
those
types
of
questions
or
what
we
were
hoping
to
get
but
we're
trying
to
decide?
How
do
we?
How
do
we
do
a
better
job
of
getting
that
data
specifically,
how
do
what
should
we
craft
for
questions
and
then
get
something
ready
for
a
draft
survey
before
we
put
out
without
it's
an
exact
timeline,
but
with
the
the
arch
one
out
and
cluster
lifecycle?
I
personally
am
starting
a
question
whether
we
should
do
a
distinct
one
at
all.
At
this
point,
I.
B
Where,
potentially,
the
sequence
of
a
cycle
said,
we
can
adopt
some
of
the
questions
that
this
group
once
thought
before.
Click
on
yeah
I
mean
there
is
time
until
then
we
can
decide
further
if
you
guys
want
to
say
that
it's
Jeremy
or
not,
but
yeah,
we
can
afford
the
questions
in
the
sequester
cycle
survey
and
we
are
going
to
want
to
have
a
mapping
between
the
porcelain
rates
frequency
things
like
that.
So
we
didn't
have
a
LTS
question
in
our
previous
survey
for
cubanÃa.
B
A
One
thing
we
didn't
ask
or
the
that
I'm
not
seeing
I'm
sorry,
one
thing
that
we
did
ask
an
hour.
Lts
survey
that
I'm
not
seeing
is
clearly
in
the
production.
Readiness
one
is
the
source
of
the
kubernetes
that
is
in
use.
Is
it
self
built
as
a
upstream?
Is
it
vendor
a
mix
of
those
and
I'd
be
curious
from
the
cube
ATM
one?
If
you're
thinking
of
asking
that
type
of
question
the
extent
to
which
people
use
upstream
artifacts
or
vendor
artifacts
I,
don't.
B
B
A
H
Commit
I
almost
feel
like.
We
just
need
to
have
one-on-one
interviews
with
a
lot
of
the
vendors
again,
some
of
which
are
represented
in
our
committee
and
say:
hey
you
know:
do
you
actually
care
about
the
upstream
patches,
or
are
you
basically
doing
your
own
backporting
anyway,
and
that's
actually
kind
of
been
an
open
question?
Yeah.
B
I
think
we,
the
question,
is
targeting
vendors,
and
maybe
we
should
be
asking
the
vendors.
If
you
are
a
vendor,
do
you
have
patches
on
top
of
upstream?
Do
you
maintain
a
patch
on
top
forcing
I'm
pretty
sure
all
the
vendors
out
there
were
doing
that
already
great
in
terms
of
the
users
using
a
vendor
solution
like
I,
don't
know
Jiki,
for
instance,
I'm
sure
that
some
of
the
users
don't
even
know
what
patches
are
on
top
of
the
114
version,
so
it's
kind
of
hidden.
The
same
goes
for
any
other
vendor
I.
Think.
H
Well,
the
users
won't
have
that
the
vendors
will,
though,
because
I
mean
like
one
of
these,
so
we
did
we,
we
did.
We
asked
our
question
about
lender
belts
and
stuff,
and
then,
when
we
were
processing
the
data,
somebody
pointed
out
there's
a
big
variance
right
because
for
OpenShift,
even
if
we
look
at
the
upstream
patches,
we
still
rebuild
them
for
open
chests,
and
so
the
value
of
having
patches
for
further
back
versions
is
a
lot
less
broken
shift.
H
A
B
H
Also
so
the
problem
is
there's
several
different
because
like
if
we
only
had
from
user
perspective,
there's
several
different
scenarios
in
which
users
care
directly
about
the
upstream
patches,
one
is
if
they're
building
from
source
another
one
is,
if
they're
installing
any
of
the
official
containers
like
say,
if
you
do,
the
coop
admit,
install
you're,
not
building
from
source.
But
you
are
you
very
much
care
about
patch
support
from
upstream,
because
that's
where
those
containers
come
from
the
and
there's
a
few
other
distribution
mechanisms
that
are
are
like
that,
then.
A
We
did
have
feedback
for
you.
For
example,
in
Barcelona
we
had
quite
a
number
of
existing
distributors
present,
who
agreed
that
there
is
toil.
That's
not
differentiated,
toil
in
terms
of
managing
backported
patches
and
an
interest
in
doing
some
more
of
that
in
a
common
way
in
the
upstream,
instead
of
redundantly
at
each
vendor.
Since
it's
not
something
that
particularly
differentiate.