►
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
Deep Dive: Kubernetes (Release) SIG - Tim Pepper & Stephen Augustus, VMware
Kubernetes is built through a motley collection of tools used in parallel and redundant ways on different cadences by a decentralized, global developer community. This runs counter to the established quality software engineering practice of a constantly exercised single build/test/release workflow. Our Release Engineering subproject aspires to a unified, deterministic, reproducible, verifiable build system used continually for dev/test as well as periodic official releases. In this SIG Release Deep Dive session we will briefly discuss the history of release engineering in Kubernetes and the build tooling and workflows present today, and then move on to our plans and progress towards commonizing build tooling and workflows, the positive benefits we expect will come in the next few release cycles from this effort, and how you can engage to better the future of Kubernetes.
https://sched.co/MPjf
A
Okay,
so
we
will
get
started.
This
is
a
cig
release,
deep
dive.
We
are
gonna
talk
about
our
sub
projects
and
also
a
working
group
that
we
were
partially
sponsoring
and
then
hopefully
have
a
bit
of
a
call
to
action.
We
need
more
people
involved
in
our
sig
Oh
introductions
back
first,
so
I'm,
Tim,
pepper,
I
am
a
software
engineer
and
the
open
source
technology
Center
at
VMware,
I'm
active
in
cig
release
and
also
said
contributor
experience
among
us,
mattering
of
other
things,
and
this
is.
B
A
B
Part
of
the
whole
plan
around
stick
releases.
We
want
to
be
able
to
generate
kubernetes
releases.
That's
the
big
thing
right,
so
this
so
cig
release
is
often
conflated
as
just
the
release
you
I
think,
but
there
are
a
variety
of
sub
projects
that
live
within
cig
release
that
we're
going
to
talk
about
today.
So
one
of
them
is
the
release
team.
The
stick
release
overall
is
is
responsible
for
generating
consistent
kubernetes
releases
on
a
reliable
schedule.
B
We
also
want
to
make
sure
that
there's
a
consistent,
consistent
body
of
members
dedicated
to
these
roles
right,
so
whether
it
be
release
engineering,
whether
it
be
handling
whether
it
be
handling
the
the
communications
around
the
release
team,
the
the
CI
signal
making
short
test
in
for
us
in
place.
So
these
are
some
of
the
roles
that
we're
going
to
go
into
as
well
as
handling
licensing.
A
On
the
tooling
aspect,
we'll
talk
a
lot
about
that
more,
but
one
of
the
things
I
call
out
here,
like
the
the
highlighted
stuff,
is
things
that
we
were
focused
on.
But
I
didn't
highlight
the
D
and
automated
releases
because
that's
fairly
aspirational
still,
we
need
to
put
in
some
work
towards
automating
the
releases
more
so
and
ultimately
automating
a
lot
of
human
tasks
away
and
then
also
we
in
many
ways.
We
don't
do
a
lot
of
the
work
that
people
maybe
presume
that
we
do.
B
Going
into
the
release
team,
the
really
seam
has
broken
into
a
set
of
roles
and
I.
Think
that
as
Tim
was
mentioning,
the
the
roles
are
kind
of
there
kind
of
liaisons
into
other
sakes
right
so
going
down
the
list,
we
kind
of
have
the
enhancements,
so
I'll
do
the
PM
ones
right
so
enhancements
and
communications
are
kind
of
arms.
B
Of
the
the
cig
PM
group,
where
the
enhancements
the
enhancements,
lead
or
enhancement
shadows,
are
responsible
for
essentially
collating
a
list
of
collating
lists
of
the
open
features
within
kubernetes
and
deciding
which
ones
are
going
to
land
in
the
release.
So
there
is
a
set
of
I
believe
142,
open
enhancement
issues,
so
enhancement
issues
enhancements
are
changes
in
the
project
that
would
take
multiple
release
cycles
to
complete
right,
different
from
features
which
are
changes
in
the
project
would
which
would
only
take
a
cycle
to
complete
right.
B
A
One
of
the
cool
things
that
we've
done
over
the
last
year,
I
think
is
turn
this
from
sort
of
anecdote
and
lore,
especially
held
within
the
minds
of
a
large
set
of
Googlers
into
something
that's
really
being
run
by
the
community,
and
these
roles
have
documented
responsibilities.
So
all
of
that,
if
you
follow
that
link
there
you'll
see
all
of
the
role
handbooks
that
describe
what
the
roles
are
and
it's
a
volunteer
process.
We're
constantly
looking
for
new
people
to
step
up
depending
on
the
role.
A
B
I
think,
what's
what's
kind
of
interesting.
There
is
that,
within
the
last
few
release
cycles,
we've
had
the
opportunity
to
do
exactly
as
Tim
said,
try
to
automate
some
of
these
roles
away
and
we
haven't
gotten
all
the
way
there
yet.
But
I
think
that
you
know
from
the
pax
release,
manager,
role
and
as
well
as
I
think
we're
gonna.
B
Do
the
branch
manager
for
the
next
cycle
we're
starting
to
pull
like
those
roles
out
of
the
release
team,
because
their
goals
that
kind
of
exists
over
the
you
know
over
the
lifecycle
of
kubernetes
and
not
just
a
single
release?
And
then
we
got
some
good
news
on
the
test
in
four
side
to
that.
Essentially,
we
had
automated
enough
of
the
test
in
for
all
away
that
it
didn't
need
to
be
a
role
on
the
release
team
any
anymore,
so
starting
in
1/16
we're
gonna
chop
that
and.
A
The
key
here
is
that
this
has
a
quarterly
focus.
Kubernetes
we
release
on
basically
a
quarterly
basis,
so
a
team
is
coalesced
to
focus
on
getting
a
release
out
and
then
we're
repeating
that
and
we'll
talk
more
about
that.
The
next
sub
project
to
talk
about
is
the
licensing
one
and
so
I'll
kind
of
set
it
up
a
little
bit.
And
then
you
can
talk
about
where
we're
going.
So
you
might
kind
of
trivially
a
naively
look
at
kubernetes,
look
on
github
and
see
that
it's
a
patchy
2.0
license
right,
but
but
is
it?
A
This
is
open
source
if
I
go
into
the
code
base.
I
just
did
this
this
morning
during
the
keynotes
to
check
the
numbers
on
master,
there's
226
licensed
files
and
trivially,
knowing
that
it's
a
patchy
license
right,
but
I
grew
up
for
apache
license.
I
get
11
or
almost
12,000
hits
on
Apache
license
and
what
that
is
is
license
headers
in
individual
files
and
then
it's
a
go
based
project
right.
A
So,
if
you're,
looking
goat
ups
in
the
license
file,
there's
a
set
of
concatenated
licenses
and
looking
at
the
delimiter
and
just
doing
a
simple,
grep
and
word
count-
I
got
the
impression,
there's
2,000,
distinct
licenses
in
that
file,
which
scares
me.
But
the
point
here
is:
this
is
open
source.
We
have
to
do
the
right
things
right.
We
need
to
make
sure
that
we're
in
compliance
with
whatever
all
these
other
licenses
are
and
that
you
don't
want
at
the
scale
you
don't
want
to
do
manually
across
all
of
these
vendor
code
ups.
So
the.
B
Future,
yes,
so
I
think
that
you
know
there.
There
are
two
problems
to
handle
simultaneously
right.
So
one
is
the
requirement
around
the
scenes.
You
have
to
use
certain
licenses
right,
so
there's
a
set
of
excepted
licenses
for
scene
CF,
projects
which
are
Apache
primarily
and
and
the
CC
v4
404
Creative
Commons
right
for
documentation,
so
the
the
second
problem
is
that
you
know
everything
that
you
use
within
kubernetes.
B
It's
you
know
your
vendor
in
directories
or
you
know,
you've
got
you've,
got
dependencies
that
have
deep
deeper
dependencies
and
like
how
do
we
do
the
scans?
At
what
point
do
we
say
that,
like
we've
done
enough
checking
for
licenses
right
and
we're
happy
with
we're
happy
that
we're
conforming
with
our
license
policies,
so
we're
gonna
be
doing
that
via
automation,
right
I,
think
that
you
know
previously,
we
kind
of
did
it
in
two
ways.
We
did
these
these
fine
commands
and
these
grep
commands
across
all
of
the
directories.
B
We
also
have
Steve
Winslow,
who
is
on
the
LS
side,
who
uses
a
tool
called
follow,
G
which
ends
up
coming
out
into
spreadsheet,
and
then
he
co
leads
to
spreadsheet
and
then
sends
it
to
us,
and
then
we
D
do,
but
between
the
you
know,
between
the
two.
So
it's
that
can't
continue
to
happen
right,
especially
with
you
know
more
than
150
projects
within
the
kubernetes
works
right.
So
we
have
a
tool
called
fossa
that
we're
gonna
be
using
moving
forward
and
we've
spun
up
a
licensing
sub
project.
B
So
it's
myself
steve
on
on
the
yellow
side,
dims
and
nikita
right.
So
the
idea
is
to
build
automation
around
each
of
these
processes
in
each
of
these
repos,
so
that
we
can
move
to
a
point
where
we
can
turn
on,
like
pre,
submit
checks
right
for
for
kubernetes
and
being
able
to
say,
like
hey
you're
in
license
violation
right.
You
can't
even
merge
this
because
you're
in
license
violation
right.
So
that's
that's
the
future,
but
there's
so
many
things
right
get
to
first.
B
A
Call
to
action
if
you're
a
licensing
nerd
get
involved
with
this
I
know,
there's
probably
one
in
the
room,
so
the
the
next
one
to
talk
about
a
little
bit
briefly.
Is
the
working
group
long-term
support,
so
the
little
link
there
will
jump
you
off
to
the
details,
but
to
kind
of
describe
what's
going
on
here.
I
want
to
make
sure
that
people
are
clear
on
the
release
life
cycle.
A
So
we
have
these
quarter
quarterly
releases
that
I
mentioned,
but
then
there's
nine
months
of
support
that
follow
it
and
you
have
a
set
of
overlapping
releases.
So
114
came
out
in
the
spring.
115
is
going
on
right
now
and
116
117
will
follow,
but
each
of
those
get
nine
months
of
patch
support.
So
there's
been
a
question
we
hear
rumbles
of
discomfort,
I
guess
around
this
people
find
it
awkward
or
difficult
to
upgrade
across
releases
on
this
cadence.
A
That
doesn't
necessarily
mean,
though,
that
we
need
a
dramatically
longer-term
support
like
what
people
think
of
as
traditional
LTS.
When
you
hear
LTS
like
a
bun
LTS
many
years
of
support,
so
in
kubernetes
working
groups,
don't
own
code
they're,
trying
to
figure
out
and
propose
a
solution
to
a
problem.
So
this
working
group
is
trying
to
drive
conversations
around
what
are
the
actual
end
user
needs
and
then
with
those
catalogued.
What
are
our
options
to
match
them?
So
if,
if
we
really
find
the
people
are
wanting
longer
support
than
this,
nine
months
span?
A
Okay,
what
what
is
that
gonna
mean
and
come
up
with
proposals
for
the
project
on
how
to
iterate
on
that
and-
and
maybe
the
answer
ends
up
being?
No,
we,
we
are
more
or
less
okay
with
this
and
it's
a
smaller
set
of
users
who
are
struggling,
and
maybe
then
there
are
still
things
that
we
can
propose
to
the
project
around
tooling
or
improvements
to
stay
stable
api's,
for
example,
that
make
it
easier
for
people
to
upgrade
on
this
cadence.
A
Each
of
us
involved
in
this
workgroup
has
some
very
strongly
held
opinions
that
are
relatively
divergent.
It's
almost
in
a
way
sig
raw
tomatoes.
Like
you
got
a
you
got
to
have
your
flame
suit
on,
but
there
will
be
more
discussion
of
this
specifically
tomorrow.
There's
a
deep
dive
session
in
the
afternoon,
if
you're
still
around
just
at
the
end
of
the
conference
and
the
link
is,
are
so.
B
B
A
The
the
big
area
of
work
that
we
have
to
do
is
release
engineering.
So,
like
we
talked
about
the
releases
team,
it's
got
a
time
span.
That's
quarterly.
Its
focus
is
delivering
the
next
kubernetes
minor
release,
but
there's
more
to
life
than
that
all
of
the
the
tooling.
That
is
the
crank
that
we
turn
on
a
quarterly
basis
to
generate
the
release,
needs
improvement
both
in
terms
of
the
mechanism
but
also
the
the
human
processes
and
and
the
the
rationale
for
how
why,
when
we
do
things,
so
what
all
are
we
talking
about?
A
Improving
there
I
want
to
kind
of
go
through
a
set
of
slides,
it
kind
of
describes
where
we
are
so
right
now,
if
you're
looking
at
Kay
Kay
the
kubernetes
master
branch,
we
have
a
set
of
great
automation,
really
that
does
build
and
give
CI
feedback.
But
in
parallel
to
that
we
have
a
set
of
code
in
the
kubernetes
org
under
the
release,
repo,
and
that
does
releases
that
are
targeted
for
the
that
quarterly
minor
release
right
the
official
releases.
A
So
you
end
up
with
a
distinct
they're
between
Devin
prod,
and
it
is
most
of
you
all
know.
Probably
this
is
a
poor
practice
to
have
you
want
these
two
environments
to
nearly
exactly
mirror
each
other
or
you
you
run
into
potential
issues.
You
have
test
escapes
because
that
thing
that
you
shipped
is
official
prod,
isn't
what
you
tested
on
a
day-to-day
basis
and
we
have
a
really
good
CI.
A
B
A
You
get
two
distinct
things
here:
the
on
the
dev
side.
Right
now
you
could
argue
that
that's
mostly
consumed
by
automation
and
and
that's
the
point
created
by
automation,
testings
the
point
you
get
automated
feedback
that
shows
up
on
a
dashboard
somewhere,
but
for
prod
the
consumers
are
the
users,
the
end
users
of
kubernetes.
People
are
downloading
the
things
the
creation
is
manual
and
the
testing
is
kind
of
spotty.
A
You
could
almost
round
it
to
zero
if
you're
cynical
compared
to
what's
on
dev
continuously
right,
so
we
have
a
quality
feedback
loop
on
dev,
but
not
so
much
on
prod,
so
pretty
clear
problem
right,
it's
a
little
worse
than
that,
though,
because
on
dev
we
we
build
a
set
of
things
and
they
they
go
out
to
a
cloud
bucket,
that's
again
consumed
by
automation,
but
users
don't
consume
things
in
that
way.
We
we
have
people
who
go
to
our
kubernetes
website.
A
So
you
sort
of
have
a
what
is
a
normal
staging
here.
You
have
some
some
build
and
staging
and
publication
right.
What
we
want
to
do
for
the
future
is
still
have
that
normal
build
staging
prod
or
build
staging
publications
set
of
flows,
but
have
it
be
a
continuum
once
for
dev
and
have
testing
at
each
of
those
points?
So,
instead
of
prod.
A
Of
prod
largely
untested,
we
have
that
same
testing
going
on
for
dev
and
we
have
it
not
just
for
the
the
automation
consumed
artifacts,
but
also
for
all
of
the
artifacts
that
are
intended
for
humans,
so
that
you
as
a
human,
if
you
download
an
RPM,
you
know
that
something
has
actually
previously
consumed
successfully,
that
rpm
and
right
now.
That
is
a.
B
Bit
spotty
so
I
think
what's
cool
about
this,
you
know
this
kind
of
shift
into
the
futures
that
you
know
be
one
we're
opening
an
opportunity
for
contribution.
So
if
there
are
release
engineering,
people
in
the
room
are
listening
to
the
recording
later
and
are
interested
in
working
on
the
sub
project.
Let
us
know
I
think
it
builds
the.
It
starts
to
build
the
confidence
that
we
have
in
you
know.
B
I
I
know
personally
like
when
I
was
an
SRE
or
PE
the
the
idea
of
consuming
a
dot
zero
release
for
something
it
was
a
little
sketchy
the
same
with
like
consuming
a
beta
or
an
alpha
right
so
like
what
we
want
to
be
able
to
do
is
over
time
build
this
confidence
in
kubernetes,
like
I.
Think
that
you
know
I,
think
that
you
know
from
a
community
standpoint
and
from
an
end-user
perspective
like
kubernetes.
B
Is
the
thing
right
and
that's
really
great,
but
you
know
once
you
start
to
dig
into
some
of
the
internals
you
you,
you
know
you
you
look
at
the
alpha
this.
You
look
at
the
betas
and
you're
like
how
can
we
drive?
You
know
how
can
we
drive
consumption
or
around
around
these
things
and
I
think
building
a
workflow
and
and
being
really
open
about
the
way
that
we
construct
that
workflow
is
going
to
be
one
of
the
keys
to
doing
that.
If.
A
You
think
of
that
problem
slide,
or
you
kind
of
imagine
why
our
dot
zero
releases
might
have
some
trouble
in
terms
of
that
final
staging
of
of
the
artifacts
that
humans
consume.
So
we
want
to
get
to
something
where
creation
is
entirely
automated,
consistent
across
the
flow
and
as
we
have
things
that
are
validated
they
get
promoted
to
the
next
level
of
publication
or
stable
usage
and
testing
everywhere,
and
then
that
this
is
all
consistent.
So.
B
Working
groups
are
our
multi-sig
events
essentially
to
drive
down
some
effort
and
then
kind
of
turn
themselves
down
right
so
between
the
the
k10
for
group
release
engineering
sub
project,
the
the
kind
of
the
goal
of
the
k10
for
group
right
now
is
to
you
or
the
Katyn
for
team
is
to
build
infrastructure
that
lives
outside
of
that
a
CNC
F
owned
infrastructure
right.
So
the
the
means
of
production
for
for
some
of
these
artifacts
are
kind
of
dependent
on
certain
companies,
and
this
is
a
community
effort
right.
We
want
to.
B
C
A
You
go
back
quite
a
few
years.
You
would
see
kubernetes
by
Google
TM
trademarked
like
it
was
Google.
This
project
started
as
a
Google
thing
right,
but
it's
now
under
the
auspices
of
CN
CF,
it's
community
run,
but
some
portion
of
this
release-
engineering
stuff
happened
on
Google
machinery,
with
Google
people
doing
things
that
required
Google
proof.
A
So
we're
we're
trying
to
finish
off
the
decoupling
there
and
last
year
in
August,
Google
made
a
large
announcement
committing
9
million
dollars
to
the
CNC
F,
to
enable
the
CNC
F
to
stand
up
their
own
hosting
for
this
stuff
and
move
the
last
portion
of
things
off.
One
thing,
though,
in
addition
to
having
Devon
prod
separate,
you
also
sometimes
see
in
poor
groups,
security
being
an
afterthought,
and
that's
also
a
thing
here.
You
need
to
have
security
in
this
mix
and
not
have
it
be
an
afterthought.
A
So
how
to
get
involved
we
have
been
so
I
may
be
to
put
these
slides
or
these
bullets
in
slightly
different
order.
The
release
engineering
like
like
Steven
was
mentioning,
has
been
slightly
mixed
up
in
that
working
group,
Cates
infra
effort,
where
Google's
working
to
move
the
the
test
infrastructure
out
from
under
them
into
the
community.
Cnc
Efron
we've
sort
of
been
waiting
on
that
because
it
was
like
it
was
almost
ready
and
we
figure
if
we're
gonna
stand
up
a
new
flow.
A
Let's
just
do
it
on
the
new
infra,
instead
of
doing
it
on
the
old
and
migrating
it
also
and
being
mixed
up
in
there,
but
that's
been
a
bit
slow
and
then
now
we've
had
sort
of
the
spring
and
conference
season
where
all
of
the
people
involved
have
had
their
internal
dev
conferences
and
we're
all
now
here
at
coop
con.
So
that
slowed
things
down
a
little
bit,
but
right
after
cube
con
we're
all
planning
on
getting
a
much
more
concrete
issue
backlog.
B
Yeah
so
I
think
overall
I
mean
these
conferences
are
always
a
good
opportunity
to
be
able
to
sync
up
with
people
in
person.
We've
had
some
good
conversations,
even
yesterday,
with
some
of
the
Google
release
engineers
to
kind
of
move.
This
effort
forward
so
definitely
look
out
for
it
in
the
next.
The
next
quarter.
It's
a.
B
So,
additionally,
prior
to
cube
con,
this
is
release
released
wide.
If
you're
interested
in
getting
involved.
We
did
a
kind
of
did
a
backlog,
grooming
or
initial
vac
log
grooming
and
I
found
199
issues
on
our
cig,
release,
backlog
right
and
then
I
was
like
okay.
Well,
let
me
create
some
new
project
boards
and
broke
them
up
into
sub
projects,
and
we
were
still
at
like
99th
at
our
top
level.
Stick
release.
So
all
of
that
to
say
that
help
is
welcome
and
feel
free
to
talk
to
Tim,
myself
or
afterwards.
If.
A
You're
passionate
about
DevOps
get
ops
if
you're
an
SRE.
If
you
have
an
interest
in
securing
release
flows,
things
like
that,
we
would
love
to
have
your
involvement
and
with
that
I
think
that
is
our
last
slide.
We've
got
a
little
under
10
minutes,
I
think
for
QA.
Well,
since
this
is
being
recorded,
we'll
ask
that
you
raise
your
hand
and
run
the
mic.
Even
we'll
run
the
microphone
around
and
we'll
try
and
answer
questions.
D
A
First,
past
meetings
come
to
the
cig
release
meeting
it's
bi-weekly.
If
you
go
to
the
kubernetes
community,
org
you'll
see
there
a
set
of
subdirectories
per
cig
and
cig
release
has
a
directory.
The
readme
MD
there
has
links
to
the
google
group
join.
Our
google
group
and
you'll
get
automatically
invited
to
the
bi-weekly
zoom
meeting.
There's
also
a
link
there
to
the
agenda
and
minutes
talks,
so
you
could
catch
up
on
things.
So
that's
that's
how
to
get
connected
specific
skills
involved.
A
A
So
if
we
wrote
it
to
a
like
that
and
go
there'd,
be
some
go,
but
currently
most
of
the
scripting
is
bash,
but
having
some
awareness
of
how
Deb
packages
are
built
using
Honus
here
in
the
front,
a
fair
amount
for
that
I'm
super
familiar
with
the
RPM
side,
so
we
sort
of
bounce
things
off
each
other
there
so
that
type
of
stuff
container
building
there
is
a
new
tool.
That's
been
created
for
doing
the
the
idea
of
promotion
for
container
images
and
that's
written
and
go
so
a
variety
of
scripting
languages.
A
Some
go
familiarity,
some
familiarity
with
packaging
across
the
scheme
of
things
and
then
a
little
bit.
Also
it's
this
admin
type
of
skills
around
understanding
how
to
to
manage
publication
flows
and
shuffling
artifacts
around
right.
Now,
a
portion
of
the
building
happens
in
GCB
the
Google
cloud,
build
tool.
I
am
open
to
seeing
us
change
that
will
I
think
we
should
have
an
open
mind
as
we
envision
this
better
workflow
to
pick
the
correct
tools
for
the
job
in
a
community-based
way,
we're
very
naturally,
and
it
is
totally
fine
not
to
ding
them
for
it.
A
B
On
the
more
simplistic
side,
anything
in
the
kubernetes
community
kind
of
requires
some
time
and
dedication,
so
willingness
to
really
dive
in
and
be
comfortable
with
feeling
uncomfortable,
occasionally,
I
think
that
we
have
amazing
resources
to
help
people
get
spun
up.
So,
even
if
you
don't
know
some
of
these
tools,
you're
not
familiar
with
go
like
we
have
people
to
point
you
in
the
right
direction,
but
the
willingness
to
stick
with
it
for
a
while
is
is
kind
of
key
to
the
game
as.
A
We
brainstorm
it
I
think
having
an
opinion
but
also
being
willing
to
change
that
opinion
and
being
a
willing
and
able
to
read
there's
a
number
of
keps
and
Google
Docs
that
describe
in
very
large
detail
a
set
of
possibilities
of
tooling
and
workflows
here.
So,
if
you
have
experience
in
these
areas,
coming
in
being
able
to
constructively
collaboratively,
share
ideas
and
opinions
and
but
also
being
willing
to
to
merge
with
others
and
collectively
find
the
right
path
forward
for
this
stuff
can.
B
B
What
has
what
we've
done
over
the
last
few
cycles
is:
go
from
a
first-come,
first-serve
process
to
a
we've
created
a
questionnaire
like
so
all
the
things
that
you
all
the
different
skills
that
you
may
or
may
not
have
like
what
roles
are
you
interested
in?
What
is
the
time
commitment?
Where
are
you
located
just
kind
of
trying
to
gather
a
profile
on
this
shadow
candidate
right
and
then
from
there?
B
The
the
the
people
who
are
selected
as
release
team
role
leads
for
the
next
cycle,
which
are
usually
the
shadows
that
were
from
the
previous
cycle.
Have
the
opportunity
to
then
interview
the
the
shadows
right
and
get
an
idea
of
what's
going
there
I
think
what's
kind
of
interesting
about
the
release
team
is
that
we
have
you
have
this
problem
that
you're
trying
to
solve,
while
so
you're
trying
to
do
the
thing
while
learning
the
thing
while
teaching
it
to
someone
else,
and
so
it's
it's
always
like
an
interesting
ride.
B
I
think
that
we,
what
I
love
about
Zig
release
specifically,
is
that
we
wear
a
lot
of
our
processes
are
pretty
well
documented
and
I
think
that
we
constantly
empower
people
every
release
cycle
to
rewrite
that
documentation
to
redefine
what
that
policy
is
right.
So
it's
it's,
never
the
same.
Every
every
release
cycle
right,
so
that's
kind
of
on
the
release
team
side,
one.
A
Other
thing
there
in
terms
of
a
skill
so
that
I'd
mentioned
sort
of
being
able
to
read
the
docs
and
Steven
talked
about
read
and
help
refine
the
docs.
But
if
you
go
back
a
year,
most
of
these
Doc's
didn't
exist
or
were
very
old
and
spotty.
So
we've
put
an
effort
into
making
sure
that
they're
much
more
documented,
but
the
next
step
is
to
bring
a
mind
for
automation.
So,
as
your
is
you're
not
just
exercising
the
role
teaching
the
role,
learning
the
role
you're,
looking
to
replace
anything
within
that
with
automation,.
B
B
So
we
it's
not
it's
not
that
we're
unwilling
to
onboard
peoples
that
process,
but
we
have
to
be
careful
with
the
types
of
people
on
board
to
that
process
and
make
sure
that
they're
committed
and
willing
to
uphold
the
the
disclosures
process,
as
well
as
the
you
know,
kind
of
the
values
of
the
community.
Most.
A
Of
these
roles
are
areas
where
individuals
who
are
even
earlier
career
or
younger
or
less
experienced
engineers
could
engage
and
start
learning
and
contributing
as
well,
but
especially
the
patch
release
team,
because
we
have
to
do
fairly
active
risk
management.
Looking
at
what
patches
we
choose
to
backport
and
limiting
and
constraining
those,
we
need
a
little
bit
more
senior
people
who
are
are
able
to
understand
that
and
then
interact
with
the
security
team
on
inbound
CVEs
and
line
things
up
so
that
we
get
a
release
out
the
day
that
we're
announcing
the
CVE.
E
A
A
As
a
project
like
running
running
cluster,
we
don't
yet
have
a
threat
model,
it's
in
the
works,
but
then
the
scope
of
that
initial
threat
modeling
doesn't
include
the
release
process,
but
if
we're
releasing
official
binaries
that
are
signed,
that
people
are
downloading,
I
don't
know
that
they
want
to
or
should
run
those
in
production
at
this
point
if
they
should
trust
us,
if
they
haven't
seen
our
threat
modeling
or
our
test
proof
of
the
implementation
versus
that.
So
that's
my
base
start
starting
point.
B
B
There
are
a
lot
of
things
that
we
haven't
figured
out
and
you
know
getting
everyone
into
the
room
at
the
same
time
is
incredibly
difficult,
so
there
you
know
there
are
lots
of
expertise
across
like
I
mean
in
a
pack
time
zones
that
we
don't
always
get
to
liaised
with.
Also
if
anyone
is
in
the
european
time
zones
and
interested
in
running
cig
release,
meetings
talk
to
us
our
cig.
A
Release
meetings
are
Tuesday
afternoons,
Pacific
time,
which
is
bad
for
everybody
else
in
the
world,
and
we
we
need
to
change
that
and
I,
don't
know
to
capture
everybody
and
there's
so
many
meetings
already
in
the
morning.
We
may
need
to
split
and
have
sort
of
bounce
back
and
forth
a
little
bit
but
enable
all
of
you
Europeans
and
people
from
other
continents
to
get
involved
more
easily.
We
know
we
need
to
do
that
and
and
hound
us
force
us
to
do
that.
Don't
let
us
not
say.