►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
SIG Release Intro – Jaice Singer DuMars & Caleb Miles, Google (Any Skill Level)
For those curious about how Kubernetes releases happen, this is the session for you. This introduction will explain what the Release Special Interest Group does, and an overview of how releases are staffed and managed. It will also provide an onramp for anyone interested in volunteering for a release team position in the future.
About Jaice
I am passionate about vibrant, diverse, and inclusive open source communities, all things governance, continuous improvement, and Agile at scale. I have been a Kubernetes release manager, and co-lead various Kubernetes Special Interest Groups.
About Caleb
He is a technical program manager at Google.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
So,
just
like
a
normal
community
meeting,
I'd
say
we're
just
gonna
wait
a
couple
minutes
and
let
people
connect
to
the
the
conference
call
here
and
get
started.
My
partner
in
crime
is
not
here,
Caleb,
so
I'm
hoping
he'll,
show
up
in
a
moment
here,
while
we're
a
while
we're
waiting
for
that
so
of
the
people
in
the
room
and
everybody
hates
it.
When
you
do
this,
but
I'm
gonna
do
it
anyway
and
I'm
really
asking
for
insincere
involvement
here.
A
How
many
people
in
the
room
have
at
least
some
idea
and
don't
extrapolate
based
on
that?
It's
the
really
special
interest
group,
but
what
the
Release
special
interest
group
actually
does
anybody
know
what
it
does?
Okay
about
fifty
percent,
that's
good
and
the
people
who
are
raising
their
hands
are
largely
have
been
on
the
release
team
so
that
I'm
glad
you
actually
know
because
otherwise
you
had
me
very
fooled.
The
whole
three
months
that
we
were
together
or
more
so
I'm
gonna
go
ahead
and
get
started.
A
Caleb
will
probably
make
an
entrance
soon,
but
I'm
gonna
go
ahead
and
get
off.
First
Who
am
I,
I
am
Jace
singer
Dumars
I
work
for
Google
and
I
I
sort
of
feel
like
Google
pays
my
paycheck,
but
in
some
ways
I
work
for
kubernetes
and
probably
there's
a
lot
of
people
who
feel
that
way
in
this
room
and,
as
you
become
more
involved
in
the
community,
that
feeling
definitely
becomes
stronger
and
stronger.
So
really
I
work
for
you.
I
work
for
everybody
in
this
room.
A
A
Well,
just
fundamentally
and
philosophically,
the
release
represents
a
critical
bond
between
the
kubernetes
project
and
the
people
who
use
kubernetes
in
in
the
world
and
at
the
heart
of
that
is
that
that's
really
a
covenant
of
trust
and
on
the
release
team
or
anything
to
do
with
the
release
team.
You
are
actually
the
holder
of
that
trust
because,
for
example,
if
we
put
out
a
release
that
breaks
production
installations
all
over
the
world
chances
are,
people
are
not
going
to
give
us
a
lot
of
second
chances.
A
So
when
we
talk
about
the
covenant
of
trust,
that's
really
at
the
heart
of
a
lot
of
decisions
we
make
and
how
we
actually
manage
the
things
that
we
do
so
well,
we'll
talk
about
that
more
in
detail,
but
another
core
thing
that
we
want
to
do
are.
Why
is
that?
We
want
to
continue
looking
at
the
the
release
process
as
a
holistic
thing
and
look
at
how
we
do
that
over
time
and
that's
your
mic
so
Caleb
do
you
want
to
introduce
yourself
sorry.
A
A
Very
rarely
do
we
have
to
immediately
put
out
a
patch
release
to
repair
some
critical
security
defect
or
other
performance
defects,
just
as
far
as
open-source
projects
go
I
believe
we
have
a
really
really
solid
reputation
in
that,
and
that
is
something
that
is
important
for
us
to
continue.
In
to
maintain
so
and.
B
Consistency
I
mean
the
cooperage
community
is
huge.
There
are
over
a
thousand
contributors,
there
are
a
bunch
of
interested
active
companies
and
making
sure
that
we
are
able
to
have
a
process
that
allows
people
to
depend
on
the
releases
being
high
quality
and
that
they
come
out
as
close
as
we
can
to
when
we
started
the
process
that
were
within
generally
a
week
of
a
date.
That's
picked
three
months
ahead,
I
think
for
a
project.
B
B
And
riffing
on
transparency,
so
kubernetes,
so
as
a
project
that
started
at
Google,
inspired
by
Google
technology,
for
you
know,
running
websites
all
over
the
world
and
it
has
been
and
continues
to
be,
a
challenge
to
move
all
of
our
work
into
the
open.
We
have
really
tried
to
widen
the
community
beyond
just
Google.
We
don't
want
to
be.
You
know
the
elephant
in
the
room,
just
stepping
on
everyone
else
and
making
sure
that
well,
why
we
do
things
and
what
we
do
where
the
roles
are
located
in
a
place.
That's
discoverable
is
ongoing
work.
A
And
so,
in
order
to
keep
doing
all
this
better,
we
have
a
series
of
things
that
we
do
for
continuous
improvement.
The
largest
thing
that
we
do
is
a
release
level
retrospective
and
there
were
some
sort
of
ad
hoc
ones
that
started
around
1
1
1
2,
1
3
was
where
we
really
as
a
community
rallied
around
and
said
hey.
A
This
is
something
as
important
and
meaningful
and
we
need
to
really
drive
this
in
a
way
that
is,
has
a
lot
of
visibility
so
for
the
1/3
retrospective,
we
actually
took
over
the
career
days
community
meeting
and
ended
it
at
that
time.
That
was
one
of
my
first
contributions
to
the
project
was
to
run
that
retrospective,
and,
let
me
tell
you
I
was
scared
out
of
my
mind
to
do
it.
You.
A
Thanks
I
I
survived
and,
and
it's
one
of
those
things
that
is
just
as
a
learning
in
this
in
this
community-
is
that
if
there's
something
you
feel
like
is
missing
and-
and
it
doesn't
necessarily
have
to
be
code,
you
can
walk
into
any
particular
gap
or
thing
that
you
see
that
needs
help
and
just
offer
to
help,
raise
your
hand
and
say
hey,
you
know,
I
know
something
about
this.
I
would
love
to
make
this
better.
This
is
a
community
that
embraces
that
this
is
a
community,
that's
open
to
any
contribution.
A
So
that's
how
we
continuously
improve
having
new
people
come
into
the
process
is
another
way.
We
do
that
so
so
Tim
did
an
Tim
pepper
in
the
back
of
the
room.
Did
a
great
presentation
on
this
yesterday
and
I'm
going
to
touch
on
it
here,
a
little
bit
and
Paris
also
Paris
Pitman
and
her
presentation
talked
about
it
in
terms
of
mentoring,
but
one
of
our
goals.
Our
hopes
for
the
the
release
is
to
provide
opportunities
for
new
contributors.
A
I
I
would
say
that
the
release
process
is
one
of
the
best
ways
to
see
the
entire
gravitas
of
the
project
you're
exposed
to
testing
you're
supposed
to
the
coding.
You
look
at
issues
and
PRS
and
their
governance
and
use
get
to
see
how
SIG's
and
to
relate
with
one
another
and
with
the
release,
and
it
is.
A
It
is
absolutely
astonishing
how
many
pieces
and
people
and
groups,
and
all
these
things
go
into
a
release
and
in
the
release
team
you
get
to
see
all
of
this
unfold
over
a
period
of
time
and
because
the
cadence
is
a
three
month
cadence,
it's
not
like
you're,
just
tossed
into
the
deep
end
right
at
the
beginning.
You
actually
have
time
to
acclimate
to
the
information,
so
it
is
a
tremendous
opportunity
for
new
contributors
to
just
shadow
and
also
take
some
responsibility
and
some
of
the
roles
that
are
available
and
you.
B
Know
we
are
a
very
large
project.
We
just
hosting
kubernetes
routinely
breaks
github
in
terms
of
issues.
You
know
I
think
I'm,
lucky
enough
to
I
said
near
Tim
Hawken
and
there
he's
entirely
unable
to
filter
the
issues
assigned
to
him,
and
so
we're
trying
to
you
know
make
up
a
lot
of
this
ad
hoc
and
we've
also
been
really
lucky
to
interact
with
members
of
the
OpenStack
community
to
try
and
get
some
cross-pollination
going
from
another
very
large
community.
It's
a
hard
job
and
we're
making
it
up
as
we
go.
B
A
So
this
translates
into
policy
we're
trying
to
make
sane
policies
about
how,
when
things
get
cut
off
for
code
phrase
or
when
feature
freezes,
and
what
does
the
future
process
look
like
and
all
that
stuff
so
we're
trying
as
a
sig
to
really
look
not
only
from
the
the
user
perspective
in
terms
of
maintaining
trust,
but
also
maintaining
the
trusted
developers
that
have
to
interrelate
to
the
release
process
to
get
their
code
out
the
door.
So
it's
a
really
fine
balance.
I
mean
this
is
something
that
happens
in
enterprise
and
other
orgs
every
day.
A
Right
you've
got
the
the
velocity
of
delivery
of
code,
but
then
you
also
can't
be
disruptive
to
customers,
because,
if
you're
making
major
changes
in
the
customer
portal
every
day,
that's
going
to
disenfranchise
your
customers.
So
in
some
ways
you
know
we
have.
We
have
people
running
crew,
Nettie's
one-five
in
production
right
now,
and
probably
even
older
versions
than
that,
because
the
the
upgrade
cadence
isn't
necessarily
consistent
across
enterprises.
So
we
just
have
to
manage
all
those
things
and
creates
a
right
balance.
B
And
we
would
not
be
able
to
do
any
of
this
without
the
amazing
work
done
by
our
test.
Automation,
engineers,
the
great
people
in
sick
testing,
the
automation
is,
is
crucial.
So,
if
you're
looking
for
an
opportunity
to
build
tools
that
most
companies
can
only
dream
of,
definitely
cig
releases
is
place
and
suggesting
is
another
great
place
for
for
doing
this
kind
of
work.
Yeah.
A
And
lastly,
what
we
want
to
do
is
set
really
good
examples
for
the
project.
In
some
ways,
sig
release
has
been
a
trendsetter.
We
were
the
first
group
to
really
establish
formalized
roles.
So
essentially,
when
you
step
into
a
release
role,
you
have
a
more
or
less
a
job
description
of
the
things
that
you
are
responsible
for,
and
you
know
what
the
time
commitment
is,
and
you
know
what
the
team
around
you
looks
like
you
can
get
a
shadow.
A
These
things
actually
make
a
difference,
and
so
now,
from
a
governance
perspective,
we're
looking
at
more
and
more
SIG's.
Looking
at
how
do
we
codify
a
technical,
lead
role
or
a
chairperson
role
to
manage
meetings?
So
that's
one
way
that
we
definitely
have
driven
or
pushed
the
policy
forward.
Another
way
is
that
we
have.
We
have
role
successions
so
as
they
release
lead.
You
are
not
supposed
to
do
two
in
a
row
because
one
you
might
suffer
some
sort
of
psychological
harm
that
is
that
goes
on.
A
You
can
hear
that
in
Aaron's
lab
we
have
a
current
release,
lead
here
and
I'm
handling.
So,
but
so
the
role
succession
is
a
big
deal,
because
we
don't
want
this
to
be
somebody
squatting
on
the
role
basically
and
trying
to
be
maintaining
it
a
long
term.
We
want
the
ability
to
replace
the
people
in
leadership
positions
and
that's
really
important,
because
burnout
is
real
and
we
need
to
to
guard
our
time
carefully.
A
No
matter
how
passionate
we
are
about
the
project
and
if
you
want
to
be
able
to
release
lead
one
time,
then
in
you're
not
gonna
be
the
next
time,
and
you
really
really
want
to
do
something.
There
is
no
shortage
of
things
you
can
do
believe
me,
so
there's
always
someplace
for
you
to
step
in
and
make
a
contribution
and
just.
B
One
more
thing
off
of
that
I
mean
we
have:
it's
always
been
a
challenge
for
people
who
have
been
on
the
release
team
to
be
able
to
take
that
experience
and
then
step
into
more
of
a
strategic
long-term
focus
to
help
the
overall
release
process
back
to
the
value
of
continuous
improvement.
So
that
is
something
we
were
really
hoping
that
our
succession
on
the
release
team
will
allow
us
to
do
for
sure
and.
A
Always
diversity
is
really
important
as
well.
I
would
love
to
see
our
our
teams
become
more
diverse,
I
would
love
to
see
different
ideas,
different
experimentation
and
just
see
where
it
goes.
One
thing
too
I
want
to
mention
is
communications,
because
I
feel,
like
the
release.
Team
has
a
very
high
burden
in
terms
of
communicating
status
and
that's
something
that
we've
tried
to
continually
fine-tune
letting
developers
know
when
code
freezes.
What
does
that
mean?
What
is
it?
How
does
it
impact
their
work?
A
So
what
do
we
do
in
essence
its
releases,
it's
retrospectives
and
in
its
coordination
of
work
across
six
and
again
it
seems
self-evident,
but
these
each
of
these
things
have
a
lot
of
nuance
around
them
in
terms
of
the
way
we
try
and
carry
these
out
the
last
one
here
really.
Coordination
of
work
across
SIG's
is
a
really
interesting
thing,
because
we
we
are
the
stopping
point
for
a
lot
of
work
from
different
SIG's.
A
C
B
Up
so
this
is
from
release
1-3
just
summary
of
the
features
and
all
be
about
the
release
schedule
around
1:10
we've
got
official
release.
Low
we've
got
the
archive
of
our
meeting
minutes.
We've
got
the
exceptions
to
the
code,
freeze
that
we've
well
and
what
the
resolution
was
there.
We
have
again
the
the
schedule,
we've
got
draft
or
the
release
notes
and
we've
got
a
directory
for
the
who's
actually
on
the
release
team.
So
you
can
reach
them.
If
you
need
help
a
nice.
A
B
A
So
this
was
something
I
stole
from
Tim.
This
is
a
great
visualization
of
the
release
process,
more
or
less
13
weeks,
depending
on
what
time
of
year,
the
releases
around
the
holiday
season,
the
last
quarter.
It
is
a
little
more
truncated,
but
generally
these
are
the
key
things
that
happen.
So
we
talked
about
defining
the
features
getting
the
work
sort
of
teed
up.
A
Then
you
have
coding,
and
then
you
are
in
this
sort
of
bug-fixing
phase,
where
you're
trying
to
make
sure
that
the
quality
of
the
things
going
in
are
good
and
and
then
basically,
we
there's
a
lot
of
fine-tuning
at
the
end
of
the
the
process
to
make
sure
that
all
the
critical
defects
are
fixed
issues
resolved
and
whatnot.
So.
A
This
is
also
something
I
stole
from
Tim.
Thank
you
in
fact,
I
might
as
well
just
own
the
whole
deck
from
Tim,
because
Tim
did
a
great
job.
So
this
this
is
really
an
interesting
way
of
visualizing
the
overlap
of
releases
and,
obviously
after
we
do
a
major
release,
we
have
the
the
patch
releases
that
come
out
after,
and
so
there
are
these
activities
that
are
always
in
flight
for
three
releases
in
some
cases
will
will
do
something
for
a
release.
A
D
C
A
B
And
just
speaking
about
you
know
the
volunteers
here,
so
we
look
at
sig
release
the
our
repository
under
the
Cabrini's
org.
We
have
a
hundred
and
seventeen
contributors
to
this
one
auditory,
which
is
mostly
policy
information
about
the
release.
So
it
really
is
a
whole
village
getting
together
to
get
the
release
out.
A
B
A
B
Do
rely
on
that
goodwill.
It's
amazing
to
see
when
you
poke
a
cig
lead,
who
is
often
a
technical
lead
at
a
very
large
corporation
who's
got
team
to
help
guide
through
difficult
waters.
Who's
got.
You
know
dozens
of
other
internal
commitments
and
applying
to
trying
to
triage
the
tests
within
an
hour
or
two
of
being
alerted
to
that.
So
it's
just
really
amazing
to
see
how
committed
people
are
to
holy
fountains
and
supporting
everything.
B
So
this
is
a
little
bit
about
the
role
definition.
So
in
the
beginning
we
had
a
wiki,
so
we
no
longer
have
this
wiki,
so
I
had
to
go
back
into
the
Wayback
Machine
yeah,
thanks
to
our
Erin,
for
helping
with
that,
we
had
just
the
one
releases
our
and
the
Czar
was
all-powerful.
Although
trying
to
release
a
project,
this
large,
the
Czar
I
think
almost
always
ended
up
very,
very
sick
by
the
end
of
it.
It
was
a
lot
of
work
for
just
a
single
human
being
to
carry
on
their
shoulders
starting.
B
We
have
you
know
this
better
team
definition.
We
really
expanded
out.
You
can
notice
that
there's
no
czar
there
there's
so
we've
got
well-defined
roles
and
where
people
can
be
reached
and
in
one
tend
the
the
number
of
defined
roles
like
it
barely
fits
on
one
slide
right
below.
We
had
to
cut
off
actually
the
CI
robot.
That
does
a
lot
of
the
heavy
lifting
for
us
now
and
now
we
see
the
shadow
rolls
talking
again
about
that
secession.
B
A
A
B
You
can
notice
with
a
lot
of
these
roles
we
like
to
say
in
this
community,
following
the
sage
advice
from
Sarah
Novotny,
that
all
contributions
are
not
code,
so
we
have
communications
lead.
We
have
a
lead
for
release
notes.
Specifically.
We
have
leads
for
documentation,
CI
signal
and
bug
triage.
It's
all.
There
are
lots
of
ways
you
can
contribute
to
getting
a
high
quality,
Cooper
native
release
out,
and
we
need
people
to
fill
all
of
them.
So
it's
a
great
opportunity.
There.
A
So
when
do
we
do
these
things?
We
do
the
bi-weekly
meetings
for
cig
release.
We
have
specific
release
team
meetings,
the
the
cig,
the
release
team
meetings
are
our
gated,
so
essentially
they
start
out
at
once
a
week,
then
they
progress
to
three
times
a
week
and
then
they
go
five
times
a
week
or
every
weekday
for
the
last
two
weeks
of
the
release.
A
So
this
1.10
release
it
was
a
little
stressful,
and
so
basically
it
was
time
to
break
out
the
big,
the
big
tool
here
and
and
add
a
puppy
to
the
mix,
which
definitely
was
a
morale.
Booster,
cannot
guarantee
that
all
cig
meetings
will
have
a
puppy,
but
you
never
know
and
yeah.
Lastly,
quarterly
releases.
A
So
you
may
be
asking
yourself:
how
do
I
join
this
wonderful
sake?
Well
talk
to
any
of
us
and
feel
free
to
ask
questions
on
slack
or
anything,
we're
all
here
to
serve
you
and
nobody's
asking
these
questions,
but
I
thought
it
was
fun
anyway.
What
skills
are
needed?
I
if
you
are
curious,
if
your
skills
match
best
thing
to
do
is
just
read
the
job
descriptions
in
an
area.
That's
interesting
to
you
and
the
next
thing
find
somebody
who's
done.
The
role
before.
B
B
Think
that
has
been
a
real
challenge
for
quickly
around
staffing.
It's
been
hard
to
find
to
not
have
to
wear
the
two
hats,
both
as
a
sig
release,
member
and
a
member
of
the
release
team
I.
Think
one
of
the
things
that's
probably
or
hopefully
I'm
optimistic.
That's
going
to
help
is
a
lot
of
the
investments
we've
made
in
automation
so
to
not
have
to
have
Google
employees
be
pinned
to
roles.
B
E
E
Suddenly
we
have
a
pool
of
people,
though
sig
release
for
the
first
time
who
are
not
involved
in
the
current
release
and
we
needed
that
because
well,
you
are
on
the
current
release
team,
it's
hard
to
think
beyond
the
release
date,
and
so
you
need
people
who
are
not
on
the
current
cycle
to
be
thinking
beyond
the
current
release
day.
At
that
time
and
and
so
just
recently,
in
the
last
you
know
couple
weeks,
we
actually
had
separate
release
team
meetings
that
were
strictly
about
discussing
long-term
plans
for
things.
C
A
The
the
cloud
provider
split
out
is
probably
not
going
to
be
past
beta
I,
don't
think
for
one
twelve
is
random,
so
there
won't
necessarily
be
a
material
impact
there.
The
the
longer-term
of
that
is
that
there
will
be
a
period
of
time
where
both
the
entry
provider
exists
and
the
out
of
tree
provider
exists.
A
At
the
same
time,
that's
going
to
present
some
relatively
interesting
challenges
for
the
the
cloud
providers
to
manage
that,
but
as
far
as
I
know,
there's
really
no
good
way
to
do
that
and
not
have,
or
you
know,
to
remain
positive,
askew
testing.
So
I
don't
think.
That's
fully
fully
vetted
yet
about
how
it's
gonna
look.
B
Well,
that
teams
that
could
go
either
way.
Oh,
yes,
repeating
the
question
was:
are
we
going
to
continue
doing
quarter
quarterly
releases,
or
will
there
be
some
other
cadence
I?
Think
that
is
hard?
There
is
pressure
on
both
sides
as
a
developer,
I
used
to
be
an
engineer
at
pivotal,
where
we
think
it's
very
important
to
have
short
frequent
releases
in
order
to
de-risk
each
individual
release.
At
the
same
time,
kubernetes
has
seen
incredible
adoption
in
the
enterprise
when
Jace
was
and
Jace
was
mentioning.
The
a
lot
of
enterprises
are
still
trailing
behind.
A
Yeah
my
this
is
my
personal
take
on.
Is
it
I
think
we
need
to
trend
toward
more
releases
than
less
simply
because
there
are
a
lot
of
human
aspects
of
the
release
process
still
and
when
release
stretches
on
that
actually
amplifies
the
the
human
aspects
of
the
of
it
quite
a
bit.
So
it's
one
of
those
things
where
we
have
a
lot
of
discussion
to
have
around
that,
and
probably
that
would
be
a
great
topic
for
a
cig
release
meeting
as
opposed
to
a
release
team
meeting.
A
A
B
Definitely
along
the
LTS
release
side.
This
I
think
it
is
hard
and
certainly
talking
with
folks
from
the
OpenStack
community.
They've
experienced
this
as
well.
The
people
who
need
an
LTS
release
on
the
open
source
side,
so
not
a
non
vendor
provided
support
agreement
are
among
the
least
likely
people
to
be
able
to
devote
time
to
producing
that,
and
so
it's
very
difficult
to
staff
that
kind
of
effort
on
a
volunteer
basis,
and
so
at
least
given
our
current
machinery
IIIi
think
it'll
be
to
the
challenge.
But
we
there's
no
there's
no
clear
resolution
there.
D
A
B
And
there's
specific
deprecation
or
stability
policies
are
governed
by
a
set
architecture,
so
they
set
this
up
the
rules
of
the
road
and
we
treat
all
local
code
submissions
the
same.
In
that
way,
we
there's
you
know
obviously
often
there'll,
be
extra
notifications
and
the
release
notes.
For
example,
when
major
deprecations
happen.