►
From YouTube: Intro: SIG Release - Tim Pepper, VMware
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: SIG Release - Tim Pepper, VMware
This session on the Release Special Interest Group will give an introductory overview of the process of creating kubernetes releases, the team of community volunteers managing the release process, their roles and responsibilities, and how you can become involved.
To learn more click here: https://sched.co/FuLM
A
A
So
I
am
Tim,
pepper,
I
work
for
VMware
and
as
of
this
last
week,
I'm
now
one
of
the
chairs
of
cig
release
and
prior
to
that
I
guess.
My
my
claim
to
fame
was
I.
Was
the
release
team
lead
for
the
112
release,
also
been
involved
in
prior
releases
and
am
involved
in
the
113
release
now
as
well
so
yeah
with
that
introduction
carry
on
the
agenda.
What
I
want
to
cover
for
you
today
is
go
over
a
highlight
of
what
is
cig
release.
A
It
gets
a
period
of
support
and
lives
beyond
the
few
months
where
that
is
happening
and
then
I'll
go
into
how
we
actually
staff
the
production
of
the
releases
and
talk
about
the
release
team
and
the
individual
roles
and
responsibilities
on
the
team,
and
then
from
that,
give
you
an
idea
of
how
you
can
become
involved.
There's
opportunity
here:
we
are
trying
to
grow
the
size
of
our
cig
and
grow
the
kubernetes
community
and
there's
many
opportunities
here
for
newcomers
to
get
engaged
in
this.
A
So
first,
then,
what
is
Zig
release.
So
these
are
some
some
phrases
I
copied
out
of
the
cig
charter,
like
all
of
the
other.
Six
now
or
increasingly,
the
SIG's
are
putting
charter
documents
in
the
kubernetes
/
community
repository
that
describe
formally
what
it
is
that
the
sig
does.
So
the
the
primary
overarching
goal
in
my
mind
for
sig
release
is
that
we're
generating
the
kubernetes
releases
on
a
reliable
schedule
with
high
quality.
A
We
need
enough
people
to
make
sure
that
we
can
complete
the
releases
on
time
that
we
spot
any
quality
problems
and
get
them
resolved,
and
then
that
this
is
sustainable,
that
from
quarter
to
quarter
as
we
make
releases,
we
always
have
enough
people
to
do
this
and
additionally
then,
to
support
it
for
some
period
after
the
release,
then
a
key
difference
between
the
special
interest
groups
and
the
working
groups
or
the
committees
within
the
kubernetes
organization,
is
that
SIG's
own
code.
So
these
first
couple
bullets
are
sort
of
talking
about
the
process.
A
How
we
produce
some
build
artifacts,
but
we
do
that
with
tooling
and
with
automation
and
there
the
code
is
the
responsibility
of
sig
release
and
finally,
I
kind
of
like
to
say
that
on
the
release
team
are
in
cig
release,
we
we
don't
do
any
real
work,
because
often
people
think
of
real
work
as
writing.
A
whole
bunch
of
code
implementing
features
making
bug
fixes,
but
in
terms
of
the
broader
software
engineering
lifecycle,
what
we
do
is
engineers
writing
code
or
fixing.
A
bug
is
only
a
tiny
part
of
the
bigger
picture
of
engineering.
A
So
all
of
the
process
and
project
management
aspects
that
come
into
the
bigger
picture
fall
to
us
where
the
work
doing
the
features
in
the
bug
fixes
is
that
comes
from
all
of
the
other
SIG's,
so
we
partner
with
those
SIG's.
We
work
to
make
sure
that
they're
empowered
to
get
their
features
and
bug
fixes
done
and
integrated
into
a
release
that
goes
out
to
users,
so
the
process
itself
I've
sort
of
started
to
hint.
A
A
We
start
out
deciding
what
do
we
aspire
to
put
into
this
release,
and
once
we've
decided
that,
then
we
work
on
it
for
a
while,
and
then
we
sort
of
draw
the
line
make
sure
that
we
have
all
the
aspects
of
quality
we
need
through
bug
fixing
and
then
we
put
out
the
release,
but
I
want
to
highlight
one
recent
change
here.
So
I've
talked
a
little
bit
in
terms
of
features
but
features.
The
word
in
English
to
some
people
implies
something
kind
of
narrow
and
we've
wanted
to
use
a
word.
A
That's
a
little
broader
that
talks
about
making
kubernetes
better.
That
could
be
a
bug
fix.
It
could
be
removing
technical
debt
refactoring
code.
Those
are
things
maybe
that
aren't
user
visible
and
aren't
something
that
people
think
of
as
a
new
feature,
but
they
do
make
kubernetes
better.
They
enhance
kubernetes.
So
in
addition
to
adding
some
new
feature,
there's
these
other
things
that
also
constitute
enhancements.
So
we
start
out
and-
and
this
kind
of
looks
like
a
waterfall
sort
of
process,
but
that's
only
here
is
a
way
to
describe
what
we
do.
A
It's
actually
much
more
agile
than
this.
All
of
the
SIG's
are
always
writing
code.
They're,
always
fixing
bugs
they're,
always
talking
about
ideas
on
enhancements,
but
at
the
start
of
the
cycle.
What
the
release
team
really
works
to
do
is
to
talk
to
the
SIG's
and
say
of
all
of
your
great
ideas.
What
can
we
narrow
down
to
as
things
that
we
can
realistically
accomplish
in
the
next
three
months
and
know
that
we
have
good
testing
and
documentation
and
all
the
other
things
in
order
to
make
a
solid
release?
A
So
at
some
point
about
four
weeks
in
we
have
what
we
now
call
the
enhancements,
freeze
or
previously
known
as
feature
freeze
from
this
point
forward.
We
have
a
list
usually
something
like
40
or
60,
things
that
we're
expecting
to
come
in
in
terms
of
larger
changes
to
the
codebase
and
we'll
start
tracking
those
closely
to
ensure
that
they
make
a
solid
progression
towards
quality.
At
this
point,
the
code
base
is
just
sort
of
a
free-for-all.
A
We
ask
the
SIG's
to
be
merging
less
code
and
thinking
deliberately
in
this
period
of
these
many
things
that
were
aspirations
to
complete
for
the
release.
Are
they
realistically
going
to
make
it
or
perhaps
not?
And
it's
okay,
if
not
in
the
agile,
deferred
commitment
way,
if
not
we'll,
just
move
those
forward
to
the
next
release
and
work
can
continue
on
them,
but
we
won't
target
them
for
this
release
branch
around
week
8
we
enter
the
code
freeze
at
this
point,
no
new
feature
work
or
no
new
enhancement.
A
A
Looking
at
the
continuous
integration
tests
and
the
automated
test
results
and
ensure
that
all
of
the
results
are
green
and
we
have
a
we're
on
track
for
a
healthy
release,
as
we
start
having
the
the
clear
signs
of
healthy
code
in
the
release
branch,
we
in
the
code
freeze,
we
call
this
thaw,
so
a
sort
of
springtime
water
melting
term,
and
at
that
point
the
master
branch
carries
on
to
the
next
release.
We
may
have
a
few
more
final
bug
fixes
yet
to
get
into
the
branch
and
some
last
building
and
testing
to
do
before.
A
Now
this
three-month
cycle
is
actually
happening
continually
and
additionally,
we
have
the
idea
of
support,
so
this
is
sort
of
showing
what
the
calendar
year
2018
looked
like
in
the
first
quarter.
We
were
doing
exactly
what
I've
just
described
for
the
1:10
release
and
at
the
point
that
it
released
in
March
it
entered
a
nine
month.
Support
phase
where
one
10.9
or
patch
releases
were
being
made,
things
that
were
in
master
branch
that
are
critical,
fixes,
get
back
ported
to
1:10
for
users
of
that
stable
release.
A
But
in
the
meantime
the
master
branch
is
then
under
development
for
1.11
from
April
to
June,
and
we
actually
have
the
111
release
lead
here
in
the
room
with
us.
Also
Josh
burkas,
who
was
my
mentor
on
the
team.
Helping
me
become
the
the
one
not
12
release
lead,
so
that's
going
on
in
parallel
and
then
the
112
release
and,
as
I
finished,
helping
get
that
release
out
the
door
with
our
team
in
September.
The
1.13
release
is
started
and
is
underway.
A
Now.
A
key
thing
to
understand
here
is
that
right
now,
the
way
we
do
our
support
is
those
critical
back
fixes
in
this
nine-month
period.
We
do
those
four
three
releases
at
a
time,
so
right
now,
1.12
is
available.
So
it's
one
of
the
supported
releases
1.11
is
also
an
1.10.
Is
the
third
one
at
the
point
that
when
that
13
is
released
in
december,
assuming
that
everything
goes
on
schedule,
1.10
will
fall
out
of
support
and
this
cycle
continues
across
the
calendar
from
year
to
year.
A
This
is
done
with
a
git,
cherry-pick
mechanism,
and
we
have
a
basic
expectation
that
the
fix
is
in
the
master
branch,
and
only
at
that
point
will
we
back
port
it.
This
ensures
that
master
is
always
maximally
healthy
going
forward.
We
do
not
back
port
features
and
we
don't
have
something
if
you're
familiar
in
other
software
projects,
the
concept
of
long
term
support
where
you
may
get
multiple
years
of
support
on
something
and
then
be
able
to
upgrade
to
the
next
thing.
We
don't
do
that.
A
You
actually
have
to
upgrade
from
1.10
to
1.11
from
1.11
to
1.12.
So
with
this
cadence
of
a
release,
every
four
months
and
nine
months
of
support
as
you're
operating
a
cluster,
you
have
to
actually
think
about
this
release
life
cycle
and
how
you'll
manage
your
clusters
moving
forward
through
the
upgrade
path.
But
what
you
get
once
you
deploy
a
cluster
is
basically
nine
months
of
support.
A
Now
there
is
friction
that
we
understand
in
the
community.
This
is
very
rapid
and
we
want
to
improve
operators
experience
from
a
support
perspective,
so
we've
just
started
a
working
group
called
working
group,
LTS
long
term
support
where
we're
going
to
initially
do
an
investigation
of
what
types
of
support
people
want
and
what
types
of
problems
they
experience
today
and
brainstorm.
What
we
could
do
to
make
things
better.
A
It's
it
would
be
strange
if
we
say
kubernetes
is
about
deploying
your
apps
fast,
but
we
say
you
can't
deploy
your
cluster
fast
and
efficient,
so
we
want
to
figure
out
a
way
to
bridge
these,
and
this
may
take
some
invention
because
I
don't
know
that
there's
major
system
software
that
advances
as
rapidly
as
kubernetes
does
but
gives
a
solid
user
experience.
Yet
so
we
may
be
the
first
and
tomorrow,
I'll
be
hosting
a
cig
release
deep
dive
on
this
topic.
A
If
you'd
like
to
attend
now,
the
release
team
so
I
was
the
lead
of
the
release
team
for
1.12,
which
was
the
third
quarter
of
this
year,
and
this
is
a
picture
from
the
github
repository
where
we
track
our
releases
and
the
first
column
you
can
see
there
is
the
roll
names,
the
people
that
the
tasks
on
the
team.
The
second
column
is
the
name
of
the
person
who
is
leading
that
particular
role
for
the
release,
and
then
this
third
column
is
what
we
call
shadows
to
make
sure
that
our
community
is
growing
and
sustainable.
A
As
we
move
through
time.
We
try
to
ensure
that
every
lead
on
the
release
team
has
a
few
set
of
shadows
who
their
training
their
mentoring,
and
then
we
hope
that
they
will
eventually
step
up
to
lead
one
of
these
roles
themselves,
so
we're
we're
always
growing
the
team
and
spreading
the
load
bringing
in
new
ideas
and
new
skilled
users,
and
this
actually
happened.
So
my
shadow
on
the
one
twelve
release
eye
sundar
has
stepped
up
to
be
the
lead
of
the
current
one.
A
Thirteen
release
the
others
there,
where
there's
an
arrow,
a
shadow
has
taken
over
the
role
from
the
lead,
and
you
can
see
this
then
for
113
in
the
current
quarter
quarter
four
of
2018.
We
have
a
set
of
leads
again
who
are?
Some
of
them
are
prior
participants
in
a
release
team
and
some
of
them
are
shadows.
Who've
graduated
up
into
a
higher
level
of
responsibility,
so
we're
a
volunteer
set
of
leads
plus
our
shadows,
who
are
sort
of
our
trainees,
and
it's
our
responsibility
to
train
these
leads.
A
So
they
can
eventually
step
up
and
we
meet
regularly,
and
our
job
like
I
said
before,
is
to
not
do
the
actual
work
of
all
of
the
features
in
the
release,
but
to
sort
of
assess
the
status
of
the
velocity
and
trajectory
the
quality
of
the
the
respective
release
as
we're
aiming
towards
our
release
date
and
weigh
the
risks
that
we're.
Having
do.
A
We
have
a
large
feature,
that's
having
lots
of
trouble
and
tests
do
we
need
to
bring
more
focus
to
that
get
more
people
working
on
it
to
solidify
and
fix
it
sooner
and
then
the
way
we
do.
That
is
a
whole
bunch
of
meetings.
We're
constantly
going
out
to
the
other
SIG's
to
talk
to
them
to
say:
hey.
Your
code
is
causing
a
lot
of
test
failures.
How
can
we
get
some
resolution
on
that?
A
Pinging
people
on
slack
following
issues
and
pull
requests
on
github
all
across
the
repositories
and
on
any
release
right
now,
I
think
we
have
about
2,000
commits
that
come
into
the
release.
So
that's
a
lot
of
things
to
watch
and
track,
and
this
is
why
we
need
a
large
team.
You
have
a
lot
of
puzzle
pieces
and
we're
sort
of
there
watching
and
trying
to
bring
it
all
together
to
make
a
coherent
picture.
A
One
of
the
things
that
happens
within
this
is
that
it
can
almost
at
times
be
frustrating
for
things
that
are
working
everything's
great
and
we
don't
have
to
pay
too
much
attention
to
it,
but
for
things
that
are
a
problem
on
the
the
path
to
this
release,
we're
always
looking
at
those
so
to
sort
of
counter
the
focus
that
we
have
to
give
to
things
that
have
problems
and
not
be
drawn
into
negativity.
As
a
team,
we
try
to
have
a
lot
of
fun.
A
A
We
take
it
very
seriously
what
we
do,
but
we
try
to
be
positive
as
we
do
it
so
to
talk,
then,
a
little
bit
about
the
specific
roles
that
were
in
the
chart
there
and
keeping
the
the
cat
analogy
going.
Is
the
release
team
lead?
I
was
the
cat
herder.
In
chief
all
these
other
cats,
I
had
to
hold
in
my
arms
and
help
bring
somewhere
together
and
also
the
warrior
in
chief
I
had
to
watch
for
any
potential
problems
and
try
to
to
take
things
and
put
them
back
on
track.
A
But
it's
relatively
easy
to
do
that
in
the
end,
because
you
have
a
team
of
people
supporting
you
and,
in
addition
to
Josh
of
paths
lead
and
a
current
member
on
the
release
team,
we
also
have
Noah
and
Young
Lee
here
who
are
past
contributors
and
present
contributors
on
release
teams
as
well
and
as
a
release
team.
We
rely
on
the
people
in
each
of
these
roles
to
support
us.
A
The
enhancements
lead
is,
is
basically
a
project
manager
who
goes
out
to
the
cigs
and
understands
all
of
the
work
they
have
in
flight,
tries
to
then
capture
it
as
a
list
and
make
sure
that
all
of
the
things
that
it
needs,
testing
and
documentation
are
sufficiently
planned
out
that
there
are
people
working
on
the
code
so
that
we
know
and
have
confidence.
It
will
be
done
on
time.
Our
CI
signal
lead
currently
Josh
for
the
this
release.
They
watch
our
test
infrastructure,
all
of
our
or
our
the
outputs
of
the
test
infrastructure.
A
All
of
our
automated
tests
that
are
running
thousands
and
thousands
of
times
a
day
and
on
all
of
the
commits
that
come
in
watching
those
to
see,
are
we
healthy
or
do
we
have
failures
and
where
we
have
failures,
bringing
forces
to
bear
to
fix
the
problems.
Our
test
infrastructure
lead
actually
owns
the
underlying
mechanisms,
making
sure
that
our
testing
resources
are
healthy.
We
can
have
the
perception
of
the
codebase
being
unstable
when
it's
actually
the
hosting
of
the
test
platform
being
unstable,
and
that
can
be
a
full-time
job
in
itself.
A
We
have
a
role
for
bug
triage.
The
CI
signal
is
more
focused
on
the
automated
tests,
but
anybody
in
the
world
in
our
community
could
run
kubernetes
or
run
our
pending
release
code
and
discover
a
flaw,
and
they
would
then
open
an
issue
in
github.
We
need
to
see
that
and
get
focus
on
it
to
resolve
it.
So
our
bug
triage
lead,
manages
tracking
new
incoming
bugs
associating
them
to
PRS
and
getting
the
right
people
working
on
fixing.
We
have
a
branch
manager.
A
We
then
also
have
these
documentation,
release,
notes
and
communication
rules,
as
I
alluded
to
earlier.
These
are
a
critical
part
of
software
engineering.
You
can't
just
write
code.
You
also
have
to
write
documentation.
The
documentation
needs
internationalized
for
folks
in
China
to
be
able
to
read
more
easily
the.
When
the
release
comes
out,
there
has
to
be
a
set
of
release,
notes
that
tells
a
prospective
consumer.
What
to
expect?
Are
there
awesome
new
features?
Are
there
maybe
known
bugs
that
will
be
fixed
very
soon,
but
were
part
of
the
release?
A
Still
are
there
features
that
were
deprecated
or
that
graduated
from
alpha
to
beta
or
from
beta
to
stable,
GA
and
then
communications
as
well?
For
each
of
these
major
releases
on
a
project
the
size
and
scale
of
kubernetes,
the
the
newspapers
and
the
the
bloggers
of
the
world
in
the
podcasters,
they
want
to
know
what's
in
the
release
and
it's
actually
a
full-time
job,
with
the
shadows
as
a
sub
team.
Just
to
talk
to
all
of
these
different
media
resources.
A
One
of
the
one
of
my
sort
of
points
of
pride
in
the
112
release
was
to
to
take
these
rolls,
many
of
which
had
very
little
documentation
on
what
the
roller
responsibility
was
and
drive
towards
better
documenting
them.
So
we
now
have
a
set
of
release
team
role
handbooks
out
on
get
and
if
any
of
the
stuff
that
I've
talked
about
today
sounds
at
all
interested,
interesting
or
matches
any
of
your
skills.
A
I'd
encourage
you
to
take
a
look
at
these
read
through
them
and
and
come
to
our
cig
and
ask
questions,
attend
our
release.
Team
meetings
and
our
cig
release
meetings
and
learn
about
these
roles
and
how
we
operationally
make
the
releases
it's
a
great
opportunity
to
get
involved
in
the
project
and
become
a
contributor
one
of
the
the
really
cool
things
about
being
involved
in
the
release
team.
Is
it
spans
everything
if
you're,
just
a
networking
person?
A
Probably
you're
gonna,
go
work
in
cig
networking
if
you're,
just
a
storage
person,
SIG's
storage,
but
for
many
of
us
were
interested
in
a
lot
of
different
things
or
as
a
newcomer
we
don't
know
quite
where
we
fit
and
because
the
release
team
spans
everything
it's
a
great
place
to
start
orienting
to
the
broader
project
and
if
you've
got
general
software
engineering
skills,
project
management
skills,
our
good
at
documentation
are
bilingual.
It's
a
great
opportunity
to
make
a
concrete
contribution
to
the
project
and
start
to
get
yourself
noticed
and
and
maybe
find
your
passion.
A
And
then,
when
you
engage
with
the
cig
that
you're
interested
in
the
people
that
already
know
you
and
welcome
you,
because
they've
seen
your
contributions,
so
some
things
are
coming
soon
out
of
cig
release.
We
we've
struggled
in
the
past
on
having
enough
people
to
do
all
of
the
things
that
we
want
to
do.
A
Mini
SIG's
have
sub-projects
beneath
them
and
realistically
each
release
team,
so
the
112
release
team,
the
113,
the
110
release
team.
Each
of
these
was
a
sub
project
that
existed
basically
for
three
three
months
and
then
there
was
another
one
and
then
there
was
another
one,
but
there's
other
things.
We
need
like
release,
engineering
and
automation
around
build
tooling
in
the
release
team.
There
wasn't
a
role
specifically
for
that
and
it's
an
area
where
our
code
has
actually
languished
a
stomach
stent.
A
We
need
more
people
to
be
involved
in
a
sub
project
that
works
on
better
bettering
those
tools
and
we'd
like
to
have
a
release
engineering
sub
project.
We
also
have
some
ongoing
issues
around
licensing
that
could
use
better
automation
and
there
again
we
need
to
write
down
what
we
needed
to
formalize
it
as
a
sub
project.
Make
it
easy
for
people
to
then
volunteer
get
involved
similar
for
security
and
provenance
within
the
release.
A
We
need
to
have
signed,
build
artifacts
so
that
people
can
download
them
and
know
that
they
have
integrity,
know
where
the
artifacts
came
from
that
they're
trustworthy,
secure,
release.
Engineering
is
a
large
task
in
itself
and
again
we
could
use
skilled
folks
getting
involved
on
that
and
then,
as
mentioned
the
whole
concept
of
support,
how
do
we
do
better
support
than
the
new
working
group
long
term
support
which
sig
release
has
sponsored?
A
So
all
of
this
is
sort
of
my
call
to
you
to
to
consider
getting
involved
in
sig
release,
we're
more
than
just
writing
feature
code
or
bug
fixes
and
go
it's
about
release
engineering,
there's
a
component
of
marketing,
documentation,
testing,
project
management,
communication,
a
lot
of
other
skills
and
I.
Think
I
really
passionately
believe
that
individual
engineers
who
learn
more
of
these
skills
become
better
engineers.
So
these
aren't
just
what
people
sometimes
call
soft
skills.
I
often
get
challenged.
People
say:
oh
you're,
you're
just
doing
the
release
stuff.
Are
you
technical?
A
Well,
yes,
I
am,
and
the
more
you
do
this,
the
more
you
are
able
to
be
a
solid
engineer.
So
I
see
this
as
a
window
of
opportunity
and
I
would
encourage
newcomers
to
think
of
it.
That
way
and
consider
getting
involved
with
us
and
with
that,
that's
my
presentation
and
if
you
have,
if
you
have
questions
and
would
love
to
hear
them,.
B
A
A
that's
a
very
good
observation
there,
so
we
had
one
person
in
the
list
that
is
the
patch
manager,
where
these
other
roles
had
shadows
and
the
the
shadows
are
graduating
to
help.
It
hasn't
exactly
been
a
problem
in
the
past,
but
we
recognize
that
it
has
the
potential
to
become
a
problem
if,
for
no
other
reason,
I
really
believe
that,
as
the
kubernetes
project
grows
gets
more
usage
more
attention,
some
of
that
attention
comes
from
blackhat
security
researchers
trying
to
break
the
system.
They
will
find
bugs
that
are
security
holes.
A
Those
bugs
will
need
backported
and
on
any
other
large
project
like
this.
The
number
of
those
bugs
and
patches
is
just
a
rapidly
increasing
curve.
That
means
a
rapidly
increasing
amount
of
work
for
those
patch
managers
and
for
that
reason,
actually
I
volunteered
to
be
one
of
the
patch
managers
for
the
113
release
and
my
goal
through
the
first
nine
months
of
2019
supporting
113
is
patch
manager
is
to
do
it
as
a
team.
A
We
have
two
leads
instead
of
one
and
we
do
have
a
set
of
shadows
and
what
we're
aiming
to
do
is
make
it
a
collective
team
effort.
So
that's
not
just
on
the
back
of
one
person
and
then
hopefully
that
team
also
starts
to
cover
more
of
the
releases
instead
of
having
one
individual
in
parallel
with
another
individual
for
nine
months,
each
that
we
have
a
team
that
gives
better
continuity
across
the
years
that
we
expect
kubernetes
to
be
successful
again,
a
great
opportunity
for
folks
to
get
involved.
C
B
A
In
kubernetes
we're
all
in
trouble,
we
don't
have
an
answer
to
that,
but
we
can
look
to
other
software
projects
so,
for
example,
both
the
Linux
kernel
and
Mini
Linux
distributions
have
this
model
of
long
term
support.
So
the
Linux
kernel,
for
example,
has
multiple
prior
releases
that
are
designated
long
term
support
and
they
get
multiple
years
of
patches
being
back
ported
now,
from
a
kernel
perspective,
it's
a
little
bit
easier
because
one
aspect
of
support
is,
if
you
stay
here
on
this
one
major
release
with
minor
bug
patches.
A
How
do
you
two
years
later,
move
to
the
next
one?
That
upgrade
path
is
a
key
part
of
support
for
the
Linux
kernel.
It's
so
mature
now
and
there's
a
clear
separation
between
kernel,
space
and
user
space
and
a
set
of
well-known
sis
calls
and
POSIX
has
been
a
set
of
interfaces
for
decades.
Now,
there's
enough
stability
there
that
a
user
can
at
some
point,
install
a
new
kernel
reboot
and
expect
that
everything
just
works
fine.
A
Today,
if
you
wait
two
years
and
just
replace
your
kubernetes
control
plane
with
a
new
kubernetes
control
plane,
things
are
going
to
be
completely
broken.
So
we
as
a
group
as
a
community
somehow
that
need
to
understand
what
the
equivalent
api's
are
and
drive
them
to
higher
quality
and
stability
to
where
you
get
something
like
the
kernel
user,
space,
boundary
and
well-known
sis
calls
and
the
famous
Linux
kernel
mantra
that
we
will
never
break
user
space
and
kubernetes.
A
This
may
be
less
clear:
what
is
user
space
when
you
have
CR
DS
and
can
dynamically
change
the
control
plane.
So
there's
a
lot
of
thinking
and
discussing
to
do
there
and
then
the
other
example
Linux
distributions
the
the
example
I
would
give.
There
would
be
a
bun.
You
have
the
16:04
build
that
was
LTS
and
then
two
years
later,
1804
and
you
can
upgrade
from
one
to
the
next
and
again
you're
relatively
safe
and
doing
that,
perhaps
because
of
the
stability
and
the
maturity
of
the
broader
Linux
ecosystem
in
cloud
native.
A
We
need
to
get
there
there's
a
huge
amount
of
opportunity
to
drive
that
type
of
change
and
stabilizing
and
maturing
all
of
what
we
do.
We're,
certainly
not
there
yet.
So
this
is
an
aspiration
and
again
I
hope
to
spend
most
of
the
the
talk
tomorrow
discussing
this
with
a
set
of
users
and
operators
and
we'll
be
collecting
information,
doing
surveys
discussing
over
the
coming
year
to
try
to
drive
some
concrete
actions
to
improve
where
we
are
in
support
ability
in
the
project.
Okay,.
A
Okay,
well
I!
Thank
you
all
for
coming.
If
you
have
any
additional
questions
in
the
future
are
interested
in
getting
involved.
I
really
encourage
you
to
join
our
slack
channel
cig
release,
join
our
cig
release
meetings
and
the
release
team
meetings.
These
are
all
there's
information
on
how
to
get
connected
to
these
in
the
standard,
kubernetes
community
documentation
places,
and
we
would
love
to
have
your
involvement
in
improving
the
release
engineering
of
the
project.
Thank
you.