►
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: Release SIG - Tim Pepper, VMware & Aishwarya Sundar, Google
You could be a member of the Release Team. Yes, you! This interactive session will feature discussion with members of SIG Release's subproject release teams for 1.13 and 1.12. We will describe how Kubernetes project volunteers manage the quarterly release cadence of the project. We will give an overview of the release process and release team and how these combine across all of the kubernetes SIGs with the goal of producing high quality Kubernetes releases on a reliable schedule. And we will highlight the opportunities for both new and experienced community members (like you!) to get involved.
To Learn More: https://sched.co/Grbb
A
B
A
So
what
we're
going
to
talk
about
today,
we're
gonna,
give
you
a
sort
of
an
overview
of
what
cig
release
is
and
what
it
does
and
that's
going
to
kind
of
be
talking
about
the
release
process,
how
communities
is
released
and
then
a
little
bit
about
the
release
life
cycle
cuz
each
release
exists
for
a
period
of
time
and
then
give
into
some
of
the
details
around
the
release
team.
How
do
we
actually
make
this
work?
A
Come
into
the
details
of
the
roles
and
responsibilities
there
and
then
hopefully
leave
you
a
sort
of
a
message
on
how
you
can
become
involved?
There's
one
two,
three
four
five
I
think
there's
five
other
people
in
the
audience
who
are
people
who've,
gotten
sucked
into
these
roles
and
there's
somebody
sitting
quietly
in
the
back
who's.
A
Sig
release
so
backing
up
one
step:
SIG's
special
interest
groups,
they're
part
of
the
governance
model
of
communities,
how
things
are
delegated
and
split
out
and
there's
a
little
bunch
of
there's
ones
that
are
focused
on
certain
technology,
verticals,
like
storage
networking
and
there
were
cross-cutting
ones
like
release
or
documentation
or
testing.
So
the
part
of
the
overall
project
that's
delegated
to
our
sig,
is
releasing,
but
specifically
on
a
reliable
schedule.
We'll
talk
about
that.
A
A
We
see
that
we're
trying
to
ensure
that
there's
a
consistent
group
of
community
members,
that's
the
sort
of
outreach
portion
like
trying
to
suck
you
all
into
getting
involved,
because
we
have
to
support
these
releases
over
a
period
of
time,
and
that
takes
few
minutes
to
do
and
we
don't
want
people
to
get
burned,
outing
anything
to
go
wrong
there.
So
we're
constantly
trying
to
bring
in
the
paper
people
mentor
and
build
and
grow
the
team
we
also
don't
like.
A
Sometimes
we
say
we
don't
do
anything
because
the
other
SIG's
are
making
kubernetes
in
terms
of
the
features
but
we're
trying
to
pull
all
that
together
and
figure
out
how
to
better
enable
the
tooling
that
does
that
integration
and
I
get
called
out
on
the
side.
People
have
said
like:
oh,
you
have
a
typo,
it
says
automated,
but
you
didn't
highlight
you
know
bold,
the
D,
it's
not
done
yet
the
D
doesn't
quite
apply.
A
We
have
a
whole
lot
to
do
here,
so
we
have
we,
if
you're
interested
in
automation,
it's
a
potentially
good
place
to
get
involved
to
help
improve
the
state
of
the
art
on
all
of
this.
So
as
we're
doing
this,
we're
partnering
with
all
the
other
things
and
we're
empowering
them
to
get
their
code
integrated
in
a
coherent
way,
so
the
release
process
itself.
So
we
have
a
three
month
cycle
roughly
and
we
aim
to
do
four
releases
a
year
and
we're
pretty
good
at
this.
A
We
as
much
as
this
picture,
you
might
look
at
it
and
think
across
three
months,
feature
definition,
feature
work,
bug
fix
mean
release,
sounds
like
a
waterfall
process,
we're
much
more
agile
than
that.
What
goes
into
the
release
is
what's
ready
so
because
of
that,
we're
able
to
hit
our
release
dates
fairly.
Well,
knows
that
it's
coming
and
knows
the
the
criteria
and
the
risks,
and
we
have
a
small
period
at
the
end
where
we
try
to
narrow
things
down,
but
we
start
out
upfront
with
feature
definition,
and
actually
it's
just
changed.
A
This
is
the
last
number
of
months
is
now
at
enhancements.
So
if
you
see
that
fermentation
that's
on
spell
features,
you
hear
us
talking
about
features
or
enhancements
and
you're
confused
on
the
naming,
there's
justin
catchments
a
broader
term
that
can
mean
more
to
people,
so
naming
is
hard
and
against
myths.
This
is
open.
Source
is
going
on
all
the
time.
It's
not
like
people
sit
down.
Okay,
it's
the
first
week
of
the
1:14
release
cycle.
A
A
What
are
you
willing
to
commit
to
having
at
readiness
at
the
end
of
the
cycle
and
documented
tested,
and
do
you
have
the
manpower,
the
the
human
resources
and
then
would
the
power
to
accomplish
what
you're
aspiring
to
and
then
we
we
have
an
actual
feature:
freezer
enhancements.
Freeze
now,
where
we
say:
okay,
here's
our
list
of
things
that
we're
tracking
for
this
release
and
that's
that's
it
major
stuff.
A
You've
missed
the
date
think
about
it
for
the
next
release,
so
that
helps
us
narrow
things
down
and
then
there's
this
big
period
of
feature
work,
enhancements
work,
but
on
the
slide,
we're
moving
forward
in
that
open
source
way
works
just
stuffs,
just
merging
in
if
it's
ready
and
done
as
good
as
merging
into
the
master
branch.
But
that
can't
go
on
forever
because
we
do
need
to
kind
of
narrow
down
again
and
stabilize
the
things
that
have
been
coming
in
so
about
week.
A
7
we
create
a
release
branch
as
forked
off
McMaster
and
things
are
moving
from
master
over
to
that
release,
branch
and
a
regular
cadence.
And
then
we
have
what
we
call
a
code
slush
where
we're
trying
to
it's
not
kind
of
quite
a
code
freeze,
but
we're
trying
to
sell
things
down
and
we'll
have
a
conversation
with
the
Stig
saying,
like
hey,
remember,
to
start
thinking
about
it
something's
coming
in.
Is
this
really
done
or
should
we
push
it
to
the
next
release?
A
So
we
slowly
transition
to
the
point
where
we
do
a
hard
freeze
and
at
that
point
the
only
things
coming
into
the
release
are
supposed
to
be
critical,
bug,
fixes
and
then
have
a
period
by
pest
bug,
test,
bug,
test
and
trying
to
really
earn
out
everything
and
then
around
the
twelfth
week,
or
so
we
lift
the
freeze
master
continues
on
to
whatever
the
next
release
is
gonna,
be
so
on
14.
Right
now,
that's
happened.
A
A
Now,
each
of
these
things
lives
for
a
while,
so
going
back
to
your
coupon
December
of
last
year,
one
and
nine-
and
this
is
slightly
off
to
another
side,
any
defense.
So
imagine
this
is
one
night,
not
one
10,
December
lecture
cube
comes
around
what
9
is
released
and
it
carries
on
for
nine
months
and
then
as
soon
as
that's
happening
in
December,
1
10
comes
out
and
has
worked
on
it
through
March
March.
It
made
us
release
the
next
nine
months.
A
It's
supported,
I
kind
of
do
air
quotes
was
supported
because
this
is
a
open
source.
Community
things
are
a
little
fast
and
loose
in
some
regards
we're
working
on
better,
defining
what
support
means,
but
it's
a
conversation
and
an
open
source
sort
of
way.
So
somebody
is
managing
bringing
patches
back
to
that
branch
and
then,
when
11
started
in
and
ran
from
April
to
June,
1
12
from
the
June
or
July,
rather
to
September
and
1
13
September
through
December.
So
each
of
these
is
always
in
flight.
A
There's
always
a
new
one
coming
and
we
have
three
prior
release:
branches
that
are
getting
patches
brought
back
to
them
for
a
stable
support
branch
and
the
way
this
looks
I've
kind
of
described
this.
You
have
the
master
branch
as
a
horizontal
there
and
it's
point
or
release
branches
pulled
off
to
the
side.
We
have
a
thing:
we
call
branch
fast
forward
or
branch
FF.
It's
sinking
content
from
the
master
branch
to
that
release;
branch
during
our
complete
development
phase.
At
the
point
that
we've
kind
of
released
in
the
root.
That
branch
is
final.
A
We
just
do
very
selective
cherry
picks
into
the
branch
so
I'm,
the
one
of
the
co
patch
managers
for
the
113
release
and
we're
working
on
putting
113
one
out
the
day
after
tomorrow
and
I.
Think
we've
cherry
picked
plates
20,
ish
patches
back,
so
we're
already.
We've
gone
from
thousands
of
patches
in
their
lease
to
20
critical
fixes
this
week
and
it's
it'll
be
sort
of
that
cadence
where
there's
fewer
and
fewer
things
across
time.
Hopefully,.
A
So
the
release
life
cycle
in
words,
so
support,
amounts
to
a
pretty
critical
fixes
to
these
release
branches
and
ensuring
an
upgrade
path.
We
have
continuous
integration
tests
that
it's
really
from
the
latest
110
you
can
upgrade
to
the
latest
111
so
that
you're
not
somehow
stranded
on
one
of
these
branches.
Three
of
those
branches
get
support,
so
latest
stable
was
112,
but
it's
now
113,
so
13,
12
and
11
are
the
three
that
have
support
right
now
and
you
get
approximately
nine
months
of
support
for
something
that
you've
deployed
for
a
new
release.
B
So
Tim,
can
you
describe
a
little
bit
about
how
the
sausage
is
made,
so
I
want
to
take
some
time
to
describe
the
composition
of
the
lease
team
and
for
the
folks
behind
making
sure
this
gets
done
on
time
and
live
quality.
So
what
you
see
here
is
a
snapshot
of
or
120
steam
from
the
Sega
released,
github
repo,
the
first
column.
B
There
lists
all
the
sections
and
the
leads
that
build
the
release,
team
itself
and
the
second
column,
or
all
the
folks
who
led
the
section
for
that
particular
release,
and
then
the
third
column
is
the
set
of
shadows,
who
were
mental
for
that
particular
section
in
that
release?
So
Tim
alluded
to
this
before
one
unit
thing
that
we
started
and
continued
in
theory.
Steam
is
during
every
release.
B
When
we
draft
the
sections
we
also
draft
a
set
of
individuals
who
get
trained
and
mentor
for
each
of
these
sections
by
the
release
leads
by
the
section
needs
in
an
effort
to
sustain
our
community
and
grow
a
group
of
individuals
to
ensure
that
they
are
able
to
pick
up
and
run
the
future
releases.
We
have
this
kind
of
air
programming
or
fair
working
model
where
these
folks
get
trained
and
eventually
the
hope
is
for
them
to
step
up
and
lead
the
sections
to
the
eventual
ease,
and
this
actually
happened.
B
If
you
see
in
113
all
most
of
the
shadows
who
were
mourned
coming
shadowing
each
of
these
yeah
shadowing,
the
different
section
is
graduated
to
take
up
the
lead
roles
in
113
and
that's
the
113
team
there,
where
I
was
a
pretty
shallow
for
Tim
and
he
mentored
me
and
I
was
able
to
get
into
the
lead
role
and
so
on.
For
the
other
sections
as
well,
and
now
we
have
a
new
set
of
shadows.
Who
then
sign
up
one
interesting
thing
to
notice.
We
have
a
good
mix
of
folks
who
shine.
B
I
will
sign
up
to
be
shadows.
We
have
folks
who
are
new
to
humanities
itself,
and
this
is
a
great
place
to
get
oriented
with
the
project.
While
you
learn
and
still
contribute
something
impactful.
So
it's
a
great
place
to
start
your
Cuban
in
his
journey.
We
have
folks
who
are
already
active
contributors
and
other
six,
but
now
want
to
learn
about
the
operational
aspects
of
how
do
we
get
a
release
done?
B
So
we
have
in
folks
interested
from
that
aspect
as
well,
and
we
do
have
also
release
people
who
have
been
on
the
release
team
earlier,
who
are
reprise
their
role
or
they
try
wanna
try
new
things
around,
so
we
have
new
open
to
meet
peoples
with
different
skill
and
experience
levels
and
then
right
now
the
113
release
got
done
and
almost
every
rule.
We,
the
folks
in
the
shadow
roll
graduated,
to
become
the
leads,
and
this
is
our
current
one
for
Katie
and
we
are
currently
looking
to
film
share
with
oceans.
B
The
release
team
in
particular
is
set
of
volunteers
in
both
the
lead,
and
the
one
thing
to
note
is:
we
are
actually
not
before
so
get
do
the
actual
work.
We
don't
like
code,
the
enhancements
we
don't
fix
tests
or
bugs
ours
is
more
of
like
a
coordinating
and
a
tracking
room.
We
track
the
trajectory
and
velocity
of.
B
We
have
three
things
which
they
progress,
to
become
almost
alternate
day
meetings
and
eventually
daily
burn
downs,
where
we
assess
the
risk,
the
status
of
each
of
these
commitments
or
enhancements
at
coining
the
knees
and,
from
my
experience
in
like
three
release
things
I've
noticed
each
release
brings
its
own
set
of
challenges.
Some
areas
are
like
super
good
and
in
cruise
control,
and
they
make
it
on
time.
Well,
the
some
areas
need
more
focus.
B
There
are
surprises,
so
we
collaborate
a
lot
with
the
sig
leads
and
enhancement
owners
to
assess
the
risk,
collaborate
and
brainstorm
on
what
we
can
do.
What's
the
plot
forward
to
deepest
release
and
still
land
it
on
time
in
a
reliable
way,
we
are
done
a
lot
of
signaling.
We
invite
the
same
representatives
to
come
to
our
moon
downs,
where
we
want
to
discuss
issues,
and
we
also
do
a
lot
of
one-on-one
coordination
via
slack
our
CI
team
and
Burke
triage
team,
and
our
enhancements
team
can
talk
to
this.
B
So
we
also
follow
a
lot
of
issue
sailors
in
the
PR
status
via
github.
This
is
a
standalone
from
Tim.
We
kind
of
attract
lows
to
like
thousands
of
be
ours,
2000
every
release,
or
so
so
it's
a
lot
of
busy
work
which
could
get
sometimes
frustrating
a
little
bit
a
little
bit
negative
and
especially
when
there
are
a
lot
of
risks
that
you're
trying
to
work
through.
B
So
we
come
to
that
by
having
a
lot
of
fun
so
on
the
release,
team
and
under-seat
release
channel,
we
keep
up
organizations
like
we
try
to
have
a
more
warm
environment
for
new
contributors
who
want
to
join
the
release
team
and
we
are
one
of
the
top
channels
in
terms
of
in
to
use.
So
we
do
a
lot
of
hard
work,
but
we
try
to
have
fun
while
we
are
at
it
and
quick
rundown
on
the
walk.
So
if
any
of
you
are
thinking
like
ok,
what
are
the
skill
set?
C
B
One
to
bail,
so
basically
the
release
League
is
keeping
up
with
a
cat
analogy.
Is
the
person
herding
all
the
kittens
not
just
within
the
release
team
and
also
within
I,
mean
within
the
community
across
the
6,
making
sure
everything
is
on
track
and
proceeding
in
the
right
direction
pouring
from
Tim?
We
are
also
the
warrior.
In
chief,
we
are
always
trained
to
look
for
the
red
flag.
B
It
seems
super
daunting
and
a
high-pressure
role,
but
with
a
little
bit
of
luck
and
a
lot
of
support
from
there
really
section
leaves
itself,
I
would
like
to
say
that
it's
fairly
doable
talking
about
the
section
leads,
the
enhancement
lead,
is
basically
the
project
manager
for
the
valleys,
so
enrings
sitting
here
was
our
113
enhancement
key.
So
he
or
she
is
the
person
who
goes
to
the
really
of
the
different
sakes
and
understands
what
they
are
planning
for
in
the
release.
Do
they
have
just
coverage?
B
They
have
documentation,
planned
and
kind
of,
collects
all
this
and
puts
it
in
a
spreadsheet.
So
we
can
track
it
across
the
release
cycle.
The
scenes
signally
Josh
who's
sitting
there
and
his
team
of
shadows
Maria.
They
are
kind
of
the
gatekeepers
for
quality
for
release.
They
are
the
ones
who
are
monitoring
the
output
of
hundreds
and
hundreds
of
tests
that
run
across
PRS
and
in
our
release,
logging
jobs
identified,
see
if
their
fleets
are
the
systemic
failures,
open,
github
issues
for
open
things,
make
sure
they're
resolved
and
the
test
get
clean
again.
B
So
the
order
busy
welfare
as
well
and
then
we
have
a
whole
bunch
of
tests
and
flow.
We
have
the
customer
read
and
read,
and
you
saw
her
shadows
who
actually
builds
the
base
on
which
all
of
her
tests
run,
given
the
nature
of
how
rapidly
humanities
is
growing
and
being
contributed
to
having
a
robust
and
stable
infra
is
critical
to
scale
this
project.
B
So
the
bug
triage
lead
is
the
one
responsible
for
seeing
which
of
these
are
critical
and
shipping
chair
effect
or
should
be
worked
on
in
a
particular
release
and
branch
manager,
Doug
and
his
shadow
Venus,
and
all
of
them
sitting
here,
they're
the
ones
who
actually
builds
the
artifacts,
which
we
eventually
they're
responsible
for
cutting
the
branches
fast
forwarding
fixes
in
there
and
cherry-picking
fixes
later
in
the
game
and
the
passion
lease
manager
kind
of
does
the
same,
similar
and
stuff.
But
it's
after
the
release
as
to
worsening
and
the
next
three
role
there.
B
They
are,
in
general,
considered
to
be
soft
skills,
but
they're
super
super
critical
for
the
release
as
much
as
the
other
ones.
Are
it's
not
just
sufficient
to
write
code
and
test
that
you
need
folks
to
take
all
the
hard
work
to
the
consumers
to
tell
them
how
to
use
it,
and
that's
where
these
three
roles
come
in
the
documentation
lead
make
sure
that
every
enhancement
that
Cozens
the
release
has
documentation
talks
about
what
it
is
and
how
to
use
it,
and
each
release
goes
with
the
release.
Notes
talking
about
the
manger.
B
Teens,
which
are
the
features
that
are
new,
which
are
the
ones
that
are
Danita
and
DGA
were
the
known
issues.
How
do
you
upgrade
from
this
release
to
the
next
and
all
that
sort
of
critical
information,
and
then
we
have
a
whole
comms
team
and
as
Ana's
cabinet
his
grows?
There's
a
lot
of
excitement
and
there's
bloggers
and
social
media
and
print
media
who
want
to
know
what's
new
in
the
release
and
our
constant
kind
of
managers.
They
have
the
PR
for
the
Ruiz.
B
They
set
up
all
the
key
messages
and
make
sure
that
we
get
all
the
release
and
for
sooner
and
to
a
wider
audience
and
that
same
thing.
How
can
any
of
you
who
are
interested
here
get
in
on
the
action?
What's
the
process
around
drafting
the
team,
we
keep
the
process
really
light
and
open
around
I
would
say
the
third
part
of
the
current
release
like
there
are
only
ten
or
so
we
create
a
github
issue.
B
Steve
and
a
guest
is
here
I
kind
of
made
a
tradition
of
opening
this
issue
to
draft
folks
into
the
upcoming
releasing,
and
that
says
the
ball
rolling
and
from
there
it's
open
for
anybody
to
you
know.
There
are
folks
who
self
nominate
themselves
new
contributors,
and
there
are
folks
who
have
already
been
on
the
team,
but
they
may
now
want
to
shadow
or
need
different
roles
and
there's
always
the
current
outgoing
Lee,
who
nominates
an
incoming
shadow
to
eat
their
own.
Once
we
have.
B
If
any
of
what
I
spoke
seems
interesting
to
you.
So
we
have
all
of
that
documented
in
our
role.
Handbooks
in
github
feel
free
to
read
and
read
through
join
our
release,
meetings
and
ask
questions.
We
are
always
excited
to
have
new
contributors
who
we
can
work
with
along
the
way
in
closing
I'd
just
say
one
thing,
something
that's
super
unique
do
the
release
team
is
that
it
spans
a
very,
very
large
spectrum.
B
If
you
are
a
part
of
a
particular
sake,
you
get
to
work
just
on
that,
sixth
or
eighth,
you
work
installing
self
networking
stuff
you
Signet
work,
but
a
few
folks
like
me.
We
really
like
to
see
the
big
picture
what's
going
on
across
and
if
that
seems
something
that
you
would
like
to
have
a
cross-cutting
impact
on
the
sick.
The
release
team
is
a
great
place
to
go,
and
also
as
a
new
contributor,
as
I
said
before.
B
A
So
I
focused
on
the
release
team,
said
aspect
of
cig
release,
and
this
is
technically
the
state
release
intro,
not
the
release
team
intro.
So
we
wanted
to
touch
on
a
few
other
things
that
cig
release
does
obviously
release
team,
but
that's
been
sort
of
an
implied
part
of
what
sig
release
does
and
we've
just
got
really
to
the
point
where
we
have
this
sustainability
in
the
team
and
it's
growing
and
we're
mentoring
and
all
of
that.
But
then
we
want
to
formalize
that
the
release
team
is
just
part
of.
A
What's
a
release
aspires
to
do
so
broader
release
engineering.
Making
this
much
more
of
a
discipline
is
something
that
we
want
to
have
as
a
additional
sub
project
focus.
There's
been
a
lot
of
discussion
around
licensing
and
license
compliance
as
something
that
takes
somewhat
specialized
skills
and
we've
got
some
people
starting
to
look
at
that.
That
might
become
its
own
sub
project
could
use
additional
hands
and
then
we've
just
started
a
working
group
initially
sponsored
by
sake
release,
but
the
the
SIG's
were
their
special
interest
groups.
A
Working
groups
are
a
governance
entity,
a
kubernetes
that
span
multiple
SIG's
and
then
they
have
a
time
limit
where
the
stakes
are
something
that's
terrible
is
going
to
be
around
like
we're
not
going
to
stop
doing
storage
right,
but
a
workgroup
is
established
to
tackle
some
of
the
specific
problem.
Find
some
change,
affect
the
change
and
then
disband.
So
there's
been
a
lot
of
discussion
about
what
is
support
and
is
this
model
of
nine
months
worth
of
support
on
three
branches,
sufficient
for
the
user
base
and
there's
some
contentious
discussions
that
are
happening
around
that.
A
The
patch
release
rule
is
one
so
for
the
first
time
and
113
myself
and
Alexandra
Malinowski,
she
and
I
are
working
as
a
team
where
previously
the
patch
management
role
has
always
been
on
one
and
shoulders
for
the
entirety
of
nine
months.
So
we
worried
that
that
was
maybe
a
place
where
we
can
have
some
burnout.
A
Let's,
let's
try
not
to
let's
define
something
for
a
teaming
process
and
then,
let's
start
bringing
in
more
people,
maybe
for
114
and
make
it
a
pat
release
management
team,
and
that
starts
to
dovetail
with
some
efforts
going
on
with
the
kubernetes
project
security
team,
they're
growing,
a
set
of
associate
members
where
there
is
a
core
set
trying
to
get
more
people
involved
in
security
maintenance.
There's
an
overlap
there,
because
that
stable
patch
management
is
largely
about
backporting
security
fixes.
A
So,
finally,
just
to
reiterate
it
involved,
a
large
open
source
project
like
this
is
about
more
than
just
writing
feature
code
in
go
lean,
I
think
a
lot
of
what
we
talked
about
there
in
terms
of
the
release
roles,
if
you're
coming
from
sort
of
a
corporate
product
environment.
All
of
that
all
of
those
aspects
should
seem
familiar,
there
is
people
who
do
release
engineering
and
marketing
and
documentation
test
project
management
communications.
A
These
aren't
soft
skills
they're
at
the
critical
part
of
delivering
a
quality
product
and
kubernetes
is
a
big
deal
that
we
can't
just
be
some
sort
of
open
source
thing.
Somebody
presses
a
button
on
github
and
there's
a
release.
Now
that
big
companies
are
depending
on
this,
we
have
to
do
the
whole
of
what
it
means
to
release
with
a
high
level
of
professionalism.
So
if
you
have
those
types
of
skills,
we'd
love
to
have
you
join
us,
it's
a
great
opportunity
to
contribute
back
to
the
community.
A
Learn
new
skills,
meet
fun
people
and
use
emotions.
If
you're
MOT
game
is
slacking.
Maybe
this
is
your
way
to
bring
it
up
to
a
next
level.
Yeah.
We
try
to
have
fun
because,
like
I
said,
we
can
focus
on
the
problems,
it's
all
about
getting
the
release
out
and
us
managing
risk
fixing
problems.
That
focus
can
get
you
down.
So
we
we
make
sure
that
we
we
keep
it
professional
what
we
have
fun.
So
with
that
we
have
a
few
minutes
for
any
questions
we
have.
Mike
will
run
around.
D
A
For
me
yeah,
this
is
a
very
real
challenge
of
the
kubernetes
project.
It's
if
you
go
back
in
the
history,
it
was
literally
kubernetes
by
google
TM,
like
it
had
a
google
focus
that
had
a
pacific
time
to
unfocus.
We've
been
trying
to
change
that.
A
lot
of
the
things
increasingly
are
adding
a
secondary
time
slot
that
is
more
amenable
to
people
in
other
places
in
the
world.
I
traveled
this
for
the
first
time
on
the
released
him
in
112
not
a
morning
person
but
I
had
a
meeting
and
I
think
it
was
6:00
a.m.
A
Pacific.
Every
Tuesday
is
the
alternate
meeting
each
week
and
it
was
a
different
subset
of
the
shadows
on
the
team
or
in
other
places,
and
that
started
bringing
folks
in
we
have
Hannes
and
Maria
now
in
London,
who
are
contributing
to
the
team.
Alexandra
is
in
Poland,
Jung
Lee
is
in
China,
so
we
are
we're
making
a
concerted
effort
to
bring
more
folks
in
from
around
the
world
and
not
have
it
be
kubernetes
by
the
Pacific
time
zone.
B
Only
thing
in
that
is,
it
really
helps
the
project
to
have
representation
from
everywhere,
because
they're
their
contributors
all
around
the
world,
and
sometimes
we
want
follow-ups
on
the
issues
when
we
are
sleeping
and
I
know,
Maria
and
Hal
else
and
yang
have
helped
us
cover
and
keep
up
the
24
hour
cycle
so
yeah.
We
are
really
looking
forward
to
all
your
contributions.
B
Theories
from
depending
on
the
rules
that
you
would
like
to
shadow,
there
are
some
rules
that
are
more
front-loaded
versus
more
lateral
or
delay,
enhancements,
you're
kind
of
busy
more
during
the
first
part
of
the
release
and
documentation
or
release
notes,
you're
more
busy
towards
the
end
of
the
release
and
there's
things
like
see
a
signal
failure
busy
throughout.
But
that's
exactly
what
we
are
trying
to
define
as
part
of
the
question
at
the
staccato
selection
process,
because
we'd
like
to
list
that
we
like
to
define
that
rule
and
have
that
description.
B
A
To
be
a
little
specific
on
time,
commitment
is
a
shadow
you
could
probably
get
by
with
an
hour
to
a
week,
potentially,
depending
on
how
engaged
you
are
leads,
especially
at
the
end
enhancements
at
the
beginning.
It's
there's
a
lot
of
work,
but
the
the
leads
and
CI
signal
T.
In
the
final
few
weeks
it
becomes
a
full-time
job
for
them.
So
a
shadow
in
support
of
those
roles,
the
more
you're
able
or
willing
to
fight
off
the
more
of
a
contribution
it
is
to
the
lead.
A
A
This
one
maybe
had
a
little
bit
more
people
switching
over,
but
we
try
to
have
some
continuity
as
well,
but
within
that
we're
we're
trying
to
bring
in
shadows,
who
think
that
they
might
be
able
to
have
for
kind
of
a
career
arc
there
for
more
than
just
three
months
and
contribute
longer
terms.
So
the
more
time
you
do
give
to
the
shadow
roll,
the
more
likely
you
are
to
get
voluntold
if
you're
gonna
be
the
next
one
or
suggested
politely
that
you're
doing
an
awesome
job.
A
And
maybe
it's
your
turn
to
do
it
full-time
so
yeah.
It's
really
what
you
want
to
make
of
it
and
we
are
trying
to
do.
Try
out
some
of
these
spreading
the
load
more.
To
have
a
couple
of
people,
perhaps
instead
of
just
singular,
leads
to
make
it
more
viable
because
weight
on
everybody
and
some
of
us
were
lucky
enough
to
get
paid
full
time
to
do
open
source.
But
that's
not
the
case
for
everybody.
E
Yep
had
a
couple
questions
in
the
previous
slide
that
you
have
so
one
was
on
licensing
and
there's
another
on
the
long
term,
support
I,
wonder
if
you
could
expand
on
the
licensing
topic,
because
I
see
it's
apache
license,
but
there's
some
GPL
in
there
and
everything
like
that
and
some
concerns
that
users
have
brought
up
and
then
with
support
as
well.
I'm
curious
where
that
is
at.
As
far
as
like
the
conversation,
where
is
it
at
today?
Okay,.
A
So
licensing
first
is
a
goaling
project.
Go
if
you're
not
familiar
with.
It,
has
a
unique
system
of
package
management,
partly
relating
to
the
fact
that
it's
statically
compiled
language
and
from
a
little
bit
more
modern
language
as
well,
where
it's
being
used
and
workflows
where
people
are
thinking
about,
reproducible
builds,
so
you
have
all
of
your
dependencies
there
in
your
source
tree.
That
means
that
is,
you
version
dependencies
into
your
source,
tree
you're,
pulling
in
their
source
cavity,
and
you
have
to
comply
with
their
licenses.
A
So
there's
a
whole
spectrum
of
concerns
that
you
have
to
manage
there
and
the
first
and
foremost
I
guess
making
sure
that
you
can
clock
with
those
licenses.
So
you
can't
just
be
an
open
source
project.
Thinking
you're,
it's
all
just
open
source
and
you're
complying
the
source
is
there.
There
are
specific
obligations
and
there
are
licenses
that
conflict
with
each
other.
So
this
this
effort,
the
operation
here
to
build
more
tooling,
build
more
processes,
have
more
people,
because,
right
now
the
way
code
is
managed
in
the
tree.
A
A
So
we
need
to
spread
this
out
and
do
something
more
robust
that
ensures
that
we
don't
incur
legal
liabilities
that
we
have
the
proper
best
intent
of
open
source
in
mind
and
we're
not
overwhelming
people
long
term
support
it's
early.
There
are
80,
plus
certified
vendors
of
kubernetes
out
their
vendors
distributors,
hosted
platforms,
they're
all
supporting
product
and
they're
doing
that
in
parallel.
One
of
the
reasons
I
was
pushing
to
start.
A
This
conversation
was,
in
my
past
I've
done
a
bunch
of
work,
supporting
Linux
distributions
and
I've
come
to
believe
that
we
have
a
better
outcome
when
we
do
as
much
of
that
as
possible
income.
Sure
everybody's
got
their
value
add,
but
we
don't
all
need
to
back
port
the
same
patch
80
times
in
parallel
and
potentially
I'll
do
a
slightly
wrong.
Have
a
new,
we
thought
we
were
fixing
one
boat,
but
now
I
have
80
new
bucks.
That's
not
a
good
outcome
for
the
project
or
its
users.
A
So
I
would
like
to
see
us
move
in
a
better
direction
in
that
regard,
and
there
are
a
bunch
of
others
who
would
like
to
as
well
there's
it's
very
early
conversations
and
there's
kind
of
two
mindsets.
One
like
hey,
you
call
it
you
call
it
working
group,
LTS,
I
know
what
else?
Yes
is
that's
a
gun
to
1604
and
1404,
so
you're
gonna
give
me
two
years
of
kubernetes
support.
Yeh,
that's
one
thing
that
could
be
an
outcome,
possibly
I.
A
Most
recently
before
I
moved
to
work
at
VMware,
I
worked
at
Intel
on
a
Linux
distribution
called
their
Linux
and
we
had
a
rolling
release.
We
built
the
entire
West
twice
a
day.
It
was
constantly
shipping.
There's
these
two
mites
as
one
you
slow
down
and
stabilize,
or
you
move
faster
and
able
people
to
upgrade
better,
and
you
see
the
same
set
of
asks.
I
think
in
a
covered.
Any
seizure
base
and
within
the
engineering
community
is
really
hard
to
do.
A
Long-Term
support
and
nobody
wants
to
work
on
two-year-old
code
when
all
the
cool
new
stuff
happening
in
1:14
this
week.
So
somehow
we
have
to
balance
those
sets
of
end
user
requirements
and
it's
early
conversations
toward
to
figuring
out
to
pass
their
defining
better
processes
and
automation
that
ensure
consistency
from
release
to
release
a
solid,
upgrade
path.
Better
testing,
a
better
test
average
there's
a
whole
bunch
of
aspects
of
engineering
around
that
that
we
as
a
community.
All
of
us
together
need
to
improve.
F
F
Just
want
to
add
up
on
the
licensing,
so
we
are
also
working
with
the
CNCs
lawyer
to
do
a
licensing,
coordinate
of
kubernetes
and
CNC
also
has
a
licensing
policy
and
on
which
repos
can
be
used.
Original
tendencies
can
be
used
so,
for
instance,
as
I,
don't
quote
me
on
it,
but
I
think
that's
like
the
rule
around.
If
a
dependency
is
hosted
on
github
and
it
has
like
more
than
10
stars
or
something
and
it
has
a
non
apache
license-
we
can
still
use
it,
but
then
there
are
certain
guidelines
on
it.
A
A
If
I
should
put
container
I
have
to
comply
with
the
licenses
of
everything
in
that
it's
not
just
my
binary,
that's
stuck
on
whatever
iOS
a
was
and
where
we
are.
We
as
a
community
CN
CF
we're
an
entity,
and
we
could,
if
you
look
at
the
eighteen
thousand,
people
who
are
here
in
that
expo
floor.
If
we're
doing
it
wrong,
somebody's
gonna
come
out
to
us
and
it's
gonna
we're
gonna,
look
really
bad.
So
don't
want
to
do
that.