►
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: Kubernetes (Release) SIG - Tim Pepper, VMware & Claire Laurence, Pivotal
SIG Release and the Release Team are looking for volunteers! This session will feature past and current release team members describing what the Release Team does: We will discuss how Kubernetes project volunteers manage the quarterly release cadence of the project, give an overview of the release process, release team roles, and how these support the SIG Release goal of producing high quality Kubernetes releases on a reliable schedule. We will highlight the opportunities for both new and experienced community members (like you, including especially folks in Europe!) to get involved, across a broad range of specialties and technical work.
https://sched.co/MPhy
A
I
am
welcome,
congratulations
on
finding
us
thank
you
for
making
the
trek
all
the
way
over
here
and
we'll
see
if
more
people
trickle
in
as
we
go.
So
this
is
the
cig
release
intro
session
for
the
day
of
our
first
session
and
I
am
Tim
pepper,
I'm,
a
software
engineer
in
the
open-source
program
office
at
VMware,
and
this
is
Claire
hi.
A
A
A
So,
first
of
all,
cig
release.
Our
Charter
says
that
it's
our
job
to
kind
of
foster
and
ensure
the
there
are
reliable
quality
releases
on
a
schedule.
So
you
all
can
look
at
the
words
there.
But
the
highlights
are
that
reliable
schedule.
So
we
put
out
a
fixed
number
of
releases
each
year
and
then
we
try
to
ensure
that
there's
a
consistent
group
of
people
doing
this.
So
it's
volunteers,
but
you
you
need
to
have
that
be
a
sustainable
process.
A
You
can't
have
20
people
volunteer
this
quarter
and
then
the
115
release
finishes
and
they
all
go
away
and
you
have
20
new
people
who
have
to
figure
out
how
to
turn
this
crank.
So
we
try
to
make
sure
that
it's
a
sustainable
process
and
we'll
go
into
that
in
more
detail.
We
also
are
in
charge
of
or
responsible
for
the
tooling
around
the
release
process,
and
this
is
a
big
area
where
we
need
to
do
some
work
in
improving
things.
We're
trying
to
make
it
more
automated,
so
the
D
is
not
bolded
there.
A
So
this
is
kind
of
what
a
release
looks
like.
We
have
four
releases
a
year,
so
you
end
up
with
sort
of
12
or
13
week
process,
depending
on
the
specifics
of
things
or
as
little
as
a
10
week
cycle,
depending
on
like
us,
Thanksgiving
and
Christmas.
It
can
kind
of
get
collapsed
in
because
of
that,
this
is
open
source.
So
the
idea
of
what
is
going
to
be
in
a
release
is
kind
of
agile
or
deferred
commitment.
A
There's
ideas
that
people
in
the
community
are
having
constantly
all
the
time
there's
discussion
ongoing,
but
during
the
first
month
of
the
cycle
we
really
try
to
get
the
community
and
all
of
the
stick
leaders
to
nail
down
formally
what
they
intend
to
deliver
at
the
end
of
the
cycle
and
that's
important
because
at
some
point
we
need
to
know
that
we're
shipping
with
quality-
that's
one
of
our
our
is
a
part
of
our
sig
Carter.
So
we
need
to
know
what
we're
aspiring
to
do
and
have
some
risk
management
there.
A
A
Week
we
have
what's
called
the
enhancements
freeze
where,
at
that
point
we
we
have
a
listing
of
all
the
major
intended
work
for
that
release.
That's
coming
and
these
take
the
forms
of
what
are
called
kubernetes
enhancement
proposals.
It's
a
formalized
document.
So
each
of
those
enhancements
that
are
targeting
the
release
should
have
a
cap.
It
should
be
in
the
implementable
state-
and
that
includes
not
just
having
a
design
and
architecture
for
code-
that's
implementable,
but
having,
for
example,
a
documented
upgrade
strategy.
A
How
this
feature
is
going
to
be
version
across
kubernetes
releases
in
the
future.
A
documented
test
plan
for
the
feature
test
cases
will
be
delivered
in
time
for
this
and
documentation
as
well.
So
then,
there's
work.
That's
going
on
all
the
time
code
is
streaming
into
the
head
of
the
master
branch
and
around
week
7
or
so
we
create
a
branch.
That's
gonna
be
the
the
stable
support
point
for
this
release
and
that's
a
actual
git
branch.
A
So
get
this
behind
all
of
this
and
our
branch
manager
and
our
tools
people
go
ahead
and
create
that
branch
and
then
start
moving
content
from
master
branch
over
to
the
release
branch,
as
we
move
through
a
few
weeks
of
final
bug,
fixing
up
to
the
release
point
and
then
that
repeats
across
the
year.
So
in
the
spring
we're
doing
the
the
115
release.
But
before
that
we
had
one
four.
So
each
of
these
sort
of
cycles
through
you
have
that
enhancements
definition
and
work.
A
The
the
code
freeze
period
for
stabilization
in
the
release
point,
but
we
did
that
for
114,
we're
doing
it
for
115
now
to
finish
at
the
end
of
June,
we'll
follow
that
with
116
and
then
117
as
well,
and
it's
important
to
note
that
once
we
make
a
release,
the
release
isn't
done.
Each
of
these
branches
has
stable
support
for
a
period
of
nine
months
or
three
subsequent
releases.
A
But
it's
the
same
patch.
We
don't
need
three
different
people
doing
that
in
parallel.
So
that's
what
we've
been
doing
then
to
to
go
into
just
a
little
bit
more
detail.
Every
project
has
different
methods
of
branching
and
forking
their
code,
so
we
basically
have
our
master
branch
for
kubernetes.
That's
just
running
along
all
the
time,
but
towards
the
end
of
the
release,
we
make
a
release,
branch
and
periodically.
A
A
We
have
the
ability
to
deliberately
pick
and
say:
okay,
I'm
gonna,
fast
forward
this
this
point
and
we
should
see
the
corresponding
CI
failures,
improve
on
the
release
branch
and
we
can
track
the
progress
that
we're
making
as
we
stabilize
things
at
the
very
end
of
the
process,
we
may
be
much
more
deliberate
than
at
some
point.
We
stop
doing
that
basic
fast-forwarding
and
we
start
cherry-picking
individual
patches.
Just
at
the
last
couple
days
of
most
of
the
release,
typically
and
and
during
that
final
phase,
the
master
branch
is
frozen.
A
We
call
it
the
the
leads
of
the
broader
organization
aren't
merging
encode
arbitrarily,
even
if
it
meets
merge
requirements,
because
we
want
to
ensure
that
for
the
features
we
care
about,
we
have
solid
positive,
passing
tests
there
once
we've
released,
we
we
put
a
tag
on
the
release
branch
for
the
1.12
dot
o
and
subsequently
from
there,
as
we
have
critical
fixes
and
master
and
masters
continued
on.
So
in
this
example,
Claire
is
working
on
the
115
release.
A
Once
it
goes,
master
branch
will
effectively
be
116
alpha,
but
critical
bug
fixes
that
land
there
will
individually
cherry-pick
those
down.
So
across
the
course
of
a
release,
there
might
be
2,000
commits
that
come
in
on
master
and
those
all
flow
into
the
release,
but
then
the
cherry-picked
patches
dial
down
and
we
start
having
two
or
three
dozen
patches,
perhaps
per
release
on
that
order
in
it
that
slowly
goes
down
as
during
the
nine
months
of
support.
A
So
in
words,
we
backport
critical
fixes
to
the
release
branch
and
that's
a
selective
process
cherry-picking
and
get
we
support
three
releases
at
a
time
so
right
now,
the
current
stable
is
112,
sorry
113
and
update
that
yeah.
Those
are
all
off
one.
So,
as
you
can
tell
we're
constantly
moving
forward,
it's
it's
a
little
tricky
to
keep
up
with
all
these
things,
because
it's
it's
always
moving.
So
114,
113
and
112
are
the
current
supported
ones.
Those
all
need
shifted
forward.
A
What
that
amounts
to
is
about
nine
months
of
support
on
a
given
patch,
really
given
minor
release.
So
if
you're
doing
semantic,
versioning,
X,
dot,
y
dot,
z,
kubernetes,
1.13,
dot,
six,
those
were
the
x
y&z
for
a
1.13,
that's
considered
a
minor
release
and
semantic
versioning.
Here
we
give
nine
months
of
naturally
support
for
that.
A
B
Ten,
so,
as
Tim
mentioned,
we
have
a
bunch
of
volunteers,
as
you
can
see
tons
of
different
folks
who
get
involved
in
the
release.
Oftentimes
a
lot
of
the
shadows.
Will
progress
on
and
become
lead,
so
you
can
see
for
112.
Those
are
all
the
folks
who
ended
up
in
a
shadow
role
who
moved
on
to
lead
and
it
continues
you
go
into
113
and
then
114
and
then,
when
15
is
the
release
we're
currently
on
and
that's
the
release
I'm
the
lead
for
just
some
context
for
folks
who
might
be
like.
B
B
Someone
within
my
company
was
part
of
the
release
team
and
they
mentioned
wanting
to
get
more
folks
involved
and
I
said.
Oh,
this
sounds
interesting.
I
do
a
lot
of
release
management
in
my
day,
job
I,
wonder
what
it
looks
like
for
the
open
source,
so
starting
around
August
or
September
I.
Think
of
2018
I
started
joining
the
release
team
calls
since
they're
all
public
anyone
can
join.
We
encourage
folks
who
are
interested
in
the
release
to
join
the
calls
to
learn
more
I
saw
it
and
I
said.
B
B
Each
of
these
releases
is
about
a
quarter
so,
as
Tim
mentioned
10
to
12
weeks,
not
a
huge
time
commitment
to
try
something
out
and
see
if
you
like
it
so
I
did
turned
out.
I
actually
really
enjoyed
working
as
an
enhancement
shadow,
and
so
when
my
lead,
Kendrick
asked
if
I
wanted
to
take
on
the
role
of
lead.
I
said
sure
why
not?
B
Let's
try
it
so
I
was
the
enhancements
lead
for
114
and
doing
that
was
again
super
fun,
very
rewarding
to
learn
more
about
what
the
inhale
processes
like
for
an
open-source
release
and
then,
when
the
outgoing
lead
Aaron
asked
if
I
wanted
to
be
released,
lead
for
115.
Honestly,
it
was
a
little
kind
of
like
oh
man.
B
What
am
I
about
to
get
myself
into,
but
I
was
super
excited
to
again
contribute
to
this
open-source
community
and
try
leading
a
release,
and
so
far
were
at
about
week
7
of
the
115
release
and
it's
been
very
rewarding.
So
basically,
it's
super
easy
for
folks
to
volunteer
and
get
involved
and
try
test
out
the
water
see
what
their
interest
is
in
I
know.
B
We've
had
a
lot
of
leads
who
have
tried
one
lead
role,
and
then
they
go
on
to
shadow
a
different
role
because
they
want
to
learn
more
about
what
that's
like
I
know.
We
have
quiet.
We
have
a
couple
of
release
team
members
in
the
room,
so
if
you've
ever
participated
in
a
release
team-
and
you
want
to
just
sort
of
raise
your
hand
or
stand
up
to-
let
folks
know
lots
of
folks.
B
So
yeah,
as
we
mentioned,
it
is
all
volunteer
for
the
most
part.
Granted
some
companies
do
have
a
vested
interest
in
the
open
source
so,
though,
encourage
employees
to
join,
but
for
the
most
part,
this
is
all
volunteer
time
for
many
people,
a
lot
of
folks
in
Amaya
donate
their
evenings.
A
lot
of
folks
in
the
West
Coast
sometimes
donate
their
morning's
to
help
we
meet
regularly
to
talk
about
the
release,
so
on
a
release
team
you
can
expect
to
have
at
least
one
one-hour
meeting
at
the
start
of
the
cycle.
B
As
we
get
closer
to
the
end.
Those
meetings
increases.
We
need
to
keep
a
better
pulse
on
the
release,
so
you
meet
regularly.
It's
also
really
cool
because
you
get
to
meet
a
lot
of
different
SIG's
throughout
the
release.
Process
will
have
to
work
with
many
different
SIG's
to
check
up
on
enhancements
to
talk
about
scalability
or
testing.
B
All
these
different
aspects
so
I
think
the
realities
team
is
a
really
cool
place
to
sort
of
get
your
feet
wet
within
kubernetes,
because
you
learn
a
lot
about
the
project
with
again
not
having
to
give
a
massive
time
commitment
up
front
again.
Each
release
is
about
a
quarter,
so
you
can
try
it
out
one
quarter
and
see
if
it's
something
you
want
to
continue
with.
And
lastly,
we
do
have
a
lot
of
fun
on
the
release
team,
at
least
I
like
to
think
it's
a
lot
of
fun.
B
So
again,
we
have
a
bunch
of
different
roles
depending
on
what
you're
interested
in
so
lead
enhancement,
CI,
signal
test,
infra
bug,
triage
branch
management,
Docs
release,
notes,
comms
and
patch
release
management.
I.
Think
most
of
these
are
relatively
straightforward
as
what
they
do
again.
All
of
the
roles
are
on
the
github
for
kubernetes,
so
you
can
learn
more
about
them
and
see
what
interests
you
the
most,
where
you
might
want
to
get
started
talking
about
selection,
so
you
might
be
asking
oh,
this
is
so
cool.
B
So
how
does
one
actually
get
on
to
a
release
team
so
for
a
lot
of
the
leads,
as
we
showed?
Typically,
the
leads
will
pick
a
shadow
that
they
think
would
be
interested.
Who
has
the
time,
commitment
ability
to
get
involved
and
the
leads
will
nominate
those
shadows
to
join
the
release
team
and
they
do
it
again
all
in
github,
it's
all
public
for
the
community
and
those
leads
if
they
choose
to
accept,
then
get
to
move
on
and
pick
their
shadows.
B
The
shadows
selection
process
has
changed
a
bit
over
the
past
few
release
cycles,
starting
in
114,
because
we
had
tons
of
interest.
We
opened
up
a
survey
for
folks
to
express
interest
in
shadowing
on
the
release,
team
and
I
think
the
first
survey
had
like
a
hundred
and
twenty
eight
responses,
tons
of
interest,
and
so
from
there
the
leads
will
look
over
all
the
folks
who
filled
out
the
survey
and
decide.
B
Oh
who
of
this
looks
like
it
would
be
a
good
fit
given
the
time
commitment,
given
the
interest
given
what
they
want
to
get
out
of
the
release
team
and
then
they'll
pick
a
selection
of
folks
to
be
their
shadows.
Some
roles
have
left
shadows
than
others
just
based
on
what
the
role
calls
for
and
how
much
the
lead
feels
they
can
mentor.
At
that
point,
in
the
release,
yeah
and
so
good,
showing
all
the
nominations
process
lots
of
github
reacts.
Everyone
gets
really
excited
about
really
seen
HR
yeah.
A
So
we
want
people
to
understand
that
this
is
approachable
and
you
can
get
involved
and
it's
a
great
way
to
learn
about
the
project.
There's
lots
of
information
out
there,
but
it's
not
the
only
thing
that
we
do
so.
I'd
mentioned
the
kubernetes
enhancement
proposal
process.
The
and
Claire
had
started
out
on
the
enhancements
process,
so
tracking
sort
of
project
managing
all
of
these
potential
enhancements
or
features
major
changes
to
the
project.
So
this
is
something
that's
newer
in
the
project
prior
to
the
spring,
it
wasn't
mandatory.
A
It
was
a
kind
of
an
optional
thing
if
you
felt
like
formalizing
your
enhancement
to
this
degree,
but
we've
shifted
now
to
I
feel
like
we're
kind
of
growing
up
as
a
project.
A
lot
of
what
sig
release
is
aiming
to
do
is
is
growing
up
an
improving
quality
processes,
quality
software
engineering
and
the
keps
are
a
part
of
that.
So,
if
you're
familiar
with
Python,
peps
or
OpenStack
blueprints,
it's
a
similar
sort
of
idea.
A
You
write
a
design
document
and
you
gather
consensus
around
it
that
open
source
community
consensus
forming
can
be
a
slow
process,
though
so
we're
experiencing
a
little
bit
of
friction.
Maybe
right
now
where
people
are
like
EPS
I
have
to
have
to
write
all
of
this
stuff.
I
have
to
get
all
of
it
approved
and
on
a
timeline,
and
it's
it's
pressure
and
open
source.
Wasn't
it
just
fun
and
easy,
but
sig
release.
Part
of
our
duty,
I
feel
like
is
to
make
sure
that
people
aspire
to
that
higher
level
of
quality.
A
Software
engineering
and
keps
are
a
key
part
of
that
they're.
Also,
not
the
only
thing
that
we
do.
We
have
a
number
of
sub
projects
that
we're
looking
to
start
up,
so
the
release
team
is
formally
a
sub
project
of
sig
release
and
it's
happening
on
a
quarterly
basis,
and
you
see
this
turnover
and
people
and
it
can
be
a
lot
of
work.
A
Claire
mentioned
like
at
the
beginning,
there's
an
hour
meeting
a
week,
but
people
are
preparing
in
advance
of
that
meeting
and
at
the
end
and
the
final
weeks
there's
a
daily
meeting
for
an
hour
and
you
might
spend
quite
a
few
hours
on
the
release
team
ahead
of
that
meeting
and
after
the
meeting
getting
ready
for
collecting
status,
discussing
status
and
then
following
up
on
things
that
need
to
be
changed.
I
don't
feel
like
the
release.
A
Team
is
exactly
getting
burned
out
at
any
given
phase,
but
it's
a
lot
of
work
and
it's
a
major
time
commitment
and
for
the
people
on
the
team
who
are
strictly
volunteers
or
professionally
volunteering
a
portion
of
their
time.
It's
a
it's
a
very
large
commitment
to
do
on
an
ongoing
basis,
so
we
do
have
turnover,
but
that
leaves
us
with
sort
of
a
gap
in
the
community.
There's
bigger
picture
things
that
need
longer-term,
ongoing
engagement
and
for
that
reason
we've
started
these
other
sub
projects.
A
So
the
first
is
release
engineering
and
I
mentioned
that
we're
responsible
is
a
sig
for
the
tooling
around
the
release
process.
That
tooling,
is
getting
a
little
long
in
the
tooth.
It's
getting
a
little
old
and
crufty
and
the
more
those
of
us
who
operate
it
spend
time
operating
it.
The
more
we're
starting
to
long
for
something
better.
So
this
sub
project
is
really
just
kicking
off
tomorrow
and
the
sig
release
deep-dive
session,
we'll
be
talking
in
more
detail
about
this,
but
we're
looking
to
formulate
a
plan
to
really
modernize
the
release.
A
A
So
when
I
was
a
project,
that's
working
on
some
things
like,
for
example,
black
duck
if
you're
familiar
with
that,
getting
tools
like
that
automated
into
our
flow
to
be
scanning
and
watching
to
ensure
that
we're
fully
compliant
with
all
of
the
licenses
of
other
projects
upon
which
we
depend
or
interact
with
and
then
finally,
I
talked
earlier
about
the
lifecycle,
how
we
do
nine
months
of
support
that
isn't
exactly
popular
with
everybody,
especially
enterprise
users.
They
say
nine
months
or
even
even
if
I
upgrade
every
nine
months.
A
Well,
then,
only
three
months
later
that
thing
that
I
upgraded
to
potentially
has
gone
out
of
support
if
I
just
went
sequentially,
so
we're
hearing
pretty
loudly
from
our
user
base
that
what
we
do
for
community
support
of
the
project
is
not
sufficient.
But
what
we're
not
hearing
clearly
is
what
the
answer
is.
A
So
we've
started
up
a
working
group
and
we're
calling
it
long-term
support,
even
though
that
LTS
acronym,
when
people
see
LTS,
they
think
something
more
like
a
bun
LTS
and
they
envision
multiple
years
of
support,
we're
an
agile
project
and
as
much
as
we
hear
people
saying
they
want
longer
support
for
the
things
we
release.
We're
also
hearing
that
the
release
process
is
too
heavy
and
takes
too
long.
A
lot
of
people
would
like
to
see
a
shorter
release
cycle
so
figuring
out.
A
path
between
this
is
the
the
responsibility
of
this
working
group.
A
We're
trying
to
be
open,
minded
and
not
prescriptive
where,
even
though
it's
called
LTS
we're
not
saying
that
we
will
necessarily
do
LTS.
As
you
know,
it
today
we're
trying
to
figure
out
what
the
actual
user's
needs
are
and
meet
them,
while
also
keeping
the
developer
community
happy
and
making
sure
that
we
reduce
friction
there
as
well,
possibly
increasing
the
cadence
of
releases
and
on
Thursday.
There
will
be
a
deep
dive
session,
a
sort
of
a
buff
of
the
the
LTS
working
group.
If
you're
interested
in
learning
more
about
that.
A
Especially
within
the
release
team,
it's
it's
sort
of
I'm
passionate
about
trying
to
convey
that
kubernetes
is
not
just
about
some
features
and
go
and
writing
code
and
and
being
a
container
Orchestrator
that
there's
a
lot
bigger
picture
to
kubernetes
than
that
and
kind
of
echoing
the
keynotes.
Earlier
in
the
day
that
kubernetes
is
about
the
people,
and
all
of
these
are
areas
where
we
need
people
involved
and
working
and
doing
things
beyond
just
code.
These
are
highly
valuable
things
to
be
working
on
in
enhancing.
A
So
all
of
that
release
engineering
I
talked
about
the
automation
there,
but
other
things
like
marketing.
When
kubernetes
1.15
goes
out,
there
will
be
a
whole
series
of
blog
posts
prepared
and
PR,
and
things
like
that
that
Claire
and
her
Elyse
team
have
worked
with
professionals
and
marketing
to
put
out
there
so
that
everybody
who's
curious
about
the
new
release,
gets
professionally
prepared,
readable,
consumable
content
that
describes
the
caps
that
were
implemented
and
claire
will
be
doing
interviews-
and
I
know
for
me
that
was
a
very
weird
thing
to
I'm
I'm
an
engineer.
A
I
write
code,
but
as
a
release
team
lead.
People
wanted
to
interview
me
for
like
the
news,
it's
very
strange,
but
there
are
people
who
are
professionals
at
that
and
we
rely
on
them
to
help
teach
us
how
to
do
that
dwell.
So
we
need
more
people
like
that
involved
documentation.
Obviously,
when
one
15
releases,
one
of
the
members
of
the
release
team
will
flip
a
switch
and
documentation
specific
to
the
one
15
release
will
go,
live
on
the
website.
A
Again,
that's
preceded
by
at
least
three
months
of
people
who
are
specialized
in
documentation,
making
sure
that
we
have
quality
Doc's
on
all
of
our
key
enhancements
similar
for
testing.
All
of
those
things
need
to
come
with
the
appropriate
amount
of
initial
quality.
Alpha
features,
maybe
are
a
little
less
stable,
but
we
we
try
as
much
as
we
can
there,
but
certainly
things
that
we're
gonna
declare
is
stable
GA.
A
We
want
really
solid
test
plans
and
that
backs
up
at
least
three
months,
if
not
for
a
stable
gega
feature
9
to
12
months
beforehand,
all
sorts
of
work
going
into
test
cases
and
test
infrastructure
improvements.
If
you
are
passionate
about
testing
and
test
Engineering,
we
need
people
like
you
on
the
project
project
management.
Obviously
all
of
this
is
a
lot
of
cat
herding
to
make
sure
all
of
this
stuff
comes
together
on
a
time
schedule
and
then
communication
sharing
that
information
out
at
the
end
of
the
cycle.
A
So
if
these
are
things
that
you're
interested
in,
we
would
love
to
have
you
involved
in
kubernetes
broadly,
but
especially
in
release
teams,
and
that
is
basically
our
talk.
We
tried
to
leave
some
time
for
Q&A
that
I
think
we've
got
a
good
chunk
of
time
still.
So,
if
you
have
questions
about
any
of
this,
raise
your
hand
and
I'll
run
the
mic
out,
so
everybody
in
the
room
can
hear
you
and
it
gets
on
the
recording
as
well.
C
B
Because
that's
when
I
was
going
out
to
SIG's
understanding
like
what
their
plans
were
for
different
enhancements,
they
were
hoping
to
land
in
a
release
cycle
and
then,
after
code,
freeze,
I
basically
had
very
little
to
do
because,
once
code
free
passes,
enhancement
is
done.
On
the
flip
side,
a
group
like
CI
signal
has
a
lot
of
work
that
builds
consistently
over
the
release
because
they
care
a
lot
about
the
test
grids
and
like
what
tests
are
passing.
B
A
The
CI
signal
shadow
when
I
first
joined
the
project
and
I
spent
almost
no
time
the
first
two
months,
because
hardly
anybody
tests
alpha
releases
go
figure,
but
in
the
final
month
it
started
round.
Ramping
up
and
I
was
helping
the
shadow
going
through
all
the
incoming
issues
as
the
lead
for
CI
signal.
In
the
final
weeks,
I
spent
a
couple
hours
every
morning,
prepping
for
the
meeting
to
collect
status
and
then
a
couple
hours
after
the
meeting,
probably
pushing
so
for
a
week
or
so
that
roll
became
almost
a
full-time
job
as
a
release.
A
Lead
I
feel,
like
you're
running
a
meeting
once
a
week
for
an
hour,
but
you're
peeing,
all
sorts
of
people
all
across
the
cycle,
so
that
role
is
much
more
nearing
a
full
time
job
for
much
of
the
cycle.
So
it's
important.
We
we
want
volunteers
who
are
on
the
team
who
are
seriously
committed,
but
also
you
want
to
be
successful.
You
want
to
learn
and
contribute.
So
it's
important
for
people
to
be
able
to
understand
that
time.
Commitment
and
we've
been
working.
A
All
of
those
oh
and
we'll
post,
the
slides
after
but
the
slides,
have
links
in
them
in
the
Earle,
the
URLs
that
you
saw
up
there.
If
you
click
on
those
on
github,
we
have
multi-page
documents
for
each
of
these
roles,
describing
that
and
part
of
that
is
a
bit
on
the
time
commitments
and
the
phasing
of
time
commitment
across
it.
B
B
B
Yeah,
so
if
I'm
understanding
the
question,
what
is
our
approach
in
terms
of
pushing
documentation
if
we're
continuously
building
off
of
Master
my
understanding
for
the
main
release?
So
for
miners
like
115
114,
we
don't
we'll
slowly
build
up
all
the
docs
PRS
throughout
the
cycle,
and
then
we
will.
The
docs
team
will
check
them
like
be
working
on
writing
Docs
throughout
and
then
they
will
push
them
live
for
patches.
I,
believe
that
is
done
as
each
patch
is
ready
to
be
released.
Yeah.
A
Unlike
the
code,
I
believe
that
they
don't
used
fork
branches
like
what
I
described
for
the
code
because
they
have
to
have
all
of
the
Doc's
live,
but
they
use
a
content
management
system
and
they
can
stage
and
prepare
things
so
that,
if
you
go
to
the
kubernetes
Doc's
website
in
the
top
right
corner,
there's
a
little
drop-down
and
you
can
toggle
release
114,
113,
112
and
I.
Don't
know
the
specifics
of
the
CMS
that
they
use
or
their
process.
But
there
are
a
really
good
example
of
basically
everything
on
the
release
team.
A
Even
though
there's
a
Doc's
lead
and
they're
not
here
to
describe
the
details
of
the
process.
Almost
everything
is
delegated,
so
there's
a
special
SiC,
that's
dedicated
to
Doc's.
They
manage
translation,
their
version
control,
all
of
that
and
I
sort
of
joked,
sometimes
on
the
release
team.
We
don't
do
anything.
You
asked
like
how
much
time
it
takes
and
we
describe
a
lot
of
time
doing
stuff,
but
we're
not
doing
the
work
so
much
as
tracking
and
making
sure
that
we
understand
what's
committed
and
commitments
are
delivered.
C
A
Yes
to
all
of
that,
that's
why
we
have
a
sub-project
to
work
on
cleaning
it
up.
There's
manual,
stuff,
there's
some
crude
tools.
There's
some
been
some
looking
at
using
commercial
tools.
We
have
access
to
some
commercial
tools
through
licenses
that
the
CNC
F
has
paid
for
so
it's
a
it's
a
mishmash
and
it
it's
something
that
it's
important
to
do,
the
right
things
right
and
open-source
and
license
compliance
is
one
of
those
that
you
really
need
to
do
so,
tightening
that
up
and
making
sure
that
we
don't
have
any
gaps
or
questions.