►
From YouTube: Kubernetes SIG Release - 2019-07-16
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
Ok,
let's
get
rolling,
oh
we're
already,
recording
cool
awesome,
so
hello,
everyone!
This
is
the
July
16th
edition
of
the
cig,
release,
bi-weekly
meeting
or
at
fortnightly
meeting.
This
is
a
meeting
that
is
recorded
and
available
on
the
Internet.
So
please
be
mindful
of
what
you
say:
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct,
and
you
know,
just
in
general,
be
happy,
be
awesome
to
each
other.
A
Ok,
so
we've
got
a
few
agenda
items
and
it
seems
like
we're
filling
up
more
agenda
items
as
we
go,
I
would
say
anyone
who
is
interested
in
dropping
an
agenda
item
I
think
we,
you
know
we're
kind
of
gonna
open.
My
kit
today
so
feel
free
to.
If
there's
something
you
want
to
chat
about
just
pop
that
on
the
agenda,
so
we'll
start
off
with
a
Benjamin
elder
wants
to
talk
about
kind.
A
What
I
have
noticed
is
that
those
jobs
are
on
our
dashboard
that
are,
but
there
are
jobs
that
we
don't
officially
own
and
and
there's
no
one
who
gets
notified
on
them
when
they
fail
outside
of
us.
Looking
at
our
dashboard
right,
so
I've
opened
a
PR,
so
those
jobs
were
GCE
jobs
for
upgrade
downgrade
that
we're
living
in
the
sig
cluster
life
cycle
space
within
test
grid
configs.
They
are
sig.
Cluster
life
cycle
said
like
hey,
that's
not
us.
A
That's
still
way,
so
I
have
moved
them
over
to
the
G
sig
GCP
set
of
jobs
and
also
created
a
new
dashboard
called
sig
release
orphaned
right.
So
that
will
give
people
an
opportunity
to
still
look
at
these
jobs
if
they
want
to
I
will
send
out
once
I
actually
fix
the
broken
thing
in
that
PR
I
will
send
out
and
a
notice
to
release,
release
team,
GCP
and
cholesterol,
I
cycle
and
testing.
A
Regarding
this
change
so
moving
forward,
we
will
start
to
move
jobs
that
are
consistently
failing
or
flaky
that
people
are
not
responding
to
to
orphaned
and
give
them
an
opportunity
to
bring
those
back
into
one
of
the
things
that
we
watch
day
to
day
so
in
forming
our
blocking
or
miscellaneous
are
one
of
the
Associated
release,
number
dashboards,
so
release
1:15
so
on
and
so
forth.
Right.
If
that
does
not
happen,
I
would
like
to
have
some
sort
of
hard
date.
A
So
let's
say
if
we
move
your
thing
in
during
the
1:16
cycle
and
it
has
not
been
attended
to
after
by
the
end
of
the
cycle,
let's
say,
then
it
gets
removed
right.
We
should
not
be
owning
or
displaying
jobs
that
we
don't
personally
own
or
people
are
not
being
responsive
to
write
it.
We
lose
I
mean
seeing
seeing
red
on
our
dashboard
kind
of
like
it
makes
me
nuts.
So,
let's,
let's
not,
let's
stop
doing
that
for
116,
so
that
was
that
blockade
right.
A
Okay,
so
during
the
prior
to
the
one
twelve
ten
cut
wait
hold
on,
has
been
on
first
nope,
okay,
so,
prior
to
the
the
one
twelve
ten
cut
we
merged
in
some
some
changes
to
the
release
tooling,
and
these
were
small
exchange
--is,
but
they
were
a
flood
of
small
changes.
So
essentially,
what
we
did
was
we,
we
added
shell
checking
capabilities
or
scripts
to
do.
A
Shell
checks
for
for
the
kubernetes
release
tools
and
it
broke
some
stuff
broke
some
stuff,
like
they're,
weird
glob
patterns
that
happened
and
and
things
that
weren't
actually
getting
exported
and
so
on
and
so
forth.
Short
version
is
changes
to
our
release.
Tools
have
the
potential
to
break
master,
blocking
tests
and
a
whole
bunch
of
a
whole
slew
of
assorted
tests,
because
some
of
the
tests
depend
on
depend
on
our
tooling
to
actually
cut
a
CI
release,
essentially
later
stage
of
CI
release
right.
A
It's
a
really
long
issue
that
kind
of
analyzes
some
of
the
things
that
happened
and
some
of
the
some
of
the
to
dues,
as
a
result
of
that,
so
one
of
the
things
that
we
did
was
we
added
a
blockade
for
the
files
that
have
a
potential
to
impact
any
any
release.
Thingies
right
or
the
are
a
CI
signal
overall,
so
you
can.
You
can
take
a
look
at
the
the
link
to
that.
A
Will
show
you
exactly
where
the
blockade
is
and
how
its
configured
it's
basically
a
regex
pattern
that
points
at
like
nago,
GCB
manager,
the
stuff.
That's
in
build
the
stuff,
that's
in
Debian
and
rpm
right,
so
essentially
the
new
requirement,
at
least
for
the
time
being,
is
that
only
a
release,
release
repo
admin
can
remove
the
label
for
blocked
paths
and
allow
something
to
merge
right.
So
this
is
a
temporary
situation.
This
is
just
to
make
sure
that
we
put
the
put
the
right
bits
in
place
to
make
sure
that
our
repo
is
safe.
A
So
one
of
the
things
that
we're
doing
is
we're
adding
we're
testing
around
certain
things,
verifying
that
artifacts
land,
where
they're
supposed
to
so
I,
will
quickly
just
share
my
screen
and
show
you
that's
you
know
so
this
is
this
is
an
example
of
a
PR.
That's
open
right
now.
This
PR
touches
what
it's
touching
is
lib
release,
lib
SH,
which
is
one
of
the
release,
libraries
that
we
use
for
an
AA
go
and
GCB
manager,
and
you
can
see
that
it
has
a
do
not
merge
block
paths
great.
A
So
anyone
who
is
not
familiar
may
not
be
familiar
with
the
blockade
plug-in
in
prowl.
The
blockade
plug-in
will
essentially
scan
a
regex
pattern
and
spit
out
a
message
if
you
touched
a
file
that
is
related
to
that
regex
right,
so
so,
quick
messages
changes,
certain
release
tools
will
affect
our
ability
to
test
build
and
release.
Kubernetes
SPR
must
be
explicitly
approved
by
cig
release,
repo
admin.
Right
again,
this
is
a
temporary
state.
We
want
to
make
sure
that
we
have
the
tests
in
place
that
we
need
to
make
sure
it's
safe
to
make
changes.
A
I
think
that
what
we
proved
over
making
all
of
those
changes
was
that
we
cannot
safely
change
things
like
a
Naga
right
and
we
need
to
get
past
that
state.
So
this
is
this
will
be
in
place
for
about
a
month
and
I
believe
we've
also.
We've
also
noted.
We've
also
noted
exactly
when
this
blockade
is
going
to
expire,
but
in
the
meantime,
anyone
who
is
a
repo
admin
which
are
the
sig
release
chairs
will
be
the
ones
lifting
holds
or
removing
this
label.
A
I
can
go
in
and
say
like
okay
pulling
that
label
right
and
and
allow
this
to
merge
that
will
overwrite
the
blockade
right.
This
is
this.
Is
not
like
a
like
the
usual
overrides?
Well,
not
everyone
uses
over
eyes,
but
another
feature
of
prow
is
that
you
can
initiate
an
override
of
some
of
the
contexts
that
exist
here
right.
So,
if
I
wanted
to
override
this
test,
I
could
again.
This
is
something
that
is
reserved
for
repo
admins.
So
it's
something
that
you
should
not
be
doing
outside
of
like
extreme
circumstances
right.
A
You
know
it's
a
test,
that's
consistently
failing
and
it's
a
thing,
that's
critical
for
X
reason.
Maybe
you
consider
doing
the
overwrite,
but
over
all
stay
away
from
overrides
and
stay
away
from
blockades.
We
have
this
in
place
because
this
is
critical,
tooling
right
now,
and
that
was
that
I
think
that
we
should
I
think
that
anyone
who's
on
the
release
team
should,
when
I'll
stop
sharing
my
screen.
A
So
you
know,
namely
adding
the
blockades,
making
sure
that
things
are
properly
tested,
explicitly
examine
all
the
things
that
failed
when
we
broke
those
jobs
and
how
we
can
make
sure
that
doesn't
happen
again.
One
of
the
reasons
that
we
also
failed
in
those
jobs
is
that
is
that
every
every
job
that
we
use
every
a
lot
of
the
CI
jobs
that
utilize
kubernetes
release,
make
the
assumption.
Well,
they
use
master
right.
So
the
assumption
is
that
master
is
always
good.
A
We
should
be
using
a
known
good
tag
of
kubernetes
release
instead,
so
one
of
the
things
to
do
is
start
tagging
kubernetes
release
which
I've
started
to
do
I
will
I
will
do
another
tag
soon,
probably
a
tag
that
is
like
post,
1,
12,
10,
1,
1,
13,
8,
1,
14
4,
which
we
released
last
week.
So
that's
a
known
good
state
of
the
repo
as
well
and
probably-
or
maybe
we'll
just
do
a
tag
for
one
15
one.
So
one
15
one
is
coming
out
on
Thursday.
A
If
everything
is
successful
during
that
release,
we'll
cut
a
tag
to
say
that
we
know
this
repos
in
a
known,
good
state
here,
right,
backfill,
each
of
the
CI
jobs
to
point
to
that
known,
good
tag.
What
that
allows
us
to
do,
then
is
we
can
now
more
safely
make
changes
to
the
repo,
because
we
know
that
all
of
the
jobs
that
could
potentially
fail
are
using
a
known,
good
tag
right
and
we
can.
We
can
vet
those
changes
that
are
happening
on
master,
add
tests
as
necessary.
A
A
Potentially
I
think
so,
as
I
was
looking
at
some
of
the
stuff.
The
way
I
felt
was
anything
that
we're
doing
at
anything
that
we're
doing
for
kubernetes
kubernetes.
We
should
probably
be
doing
for
kubernetes
release
right
if
we
say
like
here's
code
freeze
like
maybe
we
decided
that,
like
at
code
freeze,
we
cut
a
tag
or
something
right
and
we
cut
a
tag
and
we
set
up
the
same
blocks
that
we
do.
A
We
I
have
a
task
on
my
list
to
mirror
any
of
the
plugins
that
we're
using
kübra
Nettie's
kubernetes
first,
so
that
we
can
instantiate
like
the
same
type
of
test
and
for
our
checks
against
it.
But
yes,
I
I,
think
you're
you're
right
when
we
freeze,
we
should
freeze
all
the
way,
including
the
release,
tooling
yeah,.
D
E
A
So
so
Ben
is
mentioning
push
build
as
well
push
build
is
a
potentially
one
that
we
could
do
to
what
I
want
before
we
we
start
doing.
This
stuff
is
like.
We
need
to
I
think
we're
starting
to
tease
all
the
information
out
of
multiple
people's
heads
about
how
all
of
these
things
work,
the
artifacts
that
we
produce
and
stuff
like
that,
Tim
and
I.
Have
we
sat
down
at
some
point?
I
mentioned
this
in
the
previous
meeting.
A
If
you
were
you
were
there
I'm
doing,
we
just
did
part
of
the
116
alpha
dot,
one
release
where
I
mentioned
some
of
this.
That
is
recorded,
and
you
can
see
that
later.
But
you
know
we
kind
of
had
a
brainstorm
and,
if
you're
curious
about
some
of
the
things
that
we're
talking
about,
because
this
I
mean
the
same
questions
were
getting
asked,
essentially
check
out
that
brainstorm.
A
So
you
know
we
need
an
understanding
of
the
things
that
we
host,
how
to
how
do
those
things
your
artifacts,
that
we're
producing
the
tooling
that
we're
using
currently
I
think
that
that
should
happen
before
we
make
any
moves.
I
know
that
you
know.
There's
some
people
who
were
saying
like
KK:
you
should
be
the
canonical
place
where
everything
you
know
where
everything
is
defined
to
do
builds,
and,
yes,
that's
probably
eventually
true,
but
we
also
have
some
spaghetti
right
now
that
I
think
we
should.
We
should
manage
first
before
moving
anything
out.
I.
E
Will
say,
though,
if
you
move
push
build-out,
you
unbreak,
almost
all
of
the
like
things
needing
to
check
out
release
that
had
for
no
real
reason.
The
main
reason
they're
checking
out
kubernetes
released.
Is
you
get
push
push
build
if
you
move
that
I,
don't
think
they're
depending
on
anything
else
and
will
be
a
lot
more
free
to
actually
develop
their
okay.
A
Can
you
would
you
mind
ping,
an
issue
for
that
sure
yeah
like
I
haven't
forgotten
yet,
but
I
might.
A
A
A
So
this
is
talking
about
the
docker
images
talking
about
the
binaries
that
we
produce
the
the
debs
that
we
put
the
Deb's
and
rpms
that
we
package
all
of
the
little
extra
files
that
are
involved
in
in
in
this
rights
of
configurations
for,
like
so
the
tarballs
the
configurations
for
like
windows
and
extra
files
for
GCE.
So
all
of
that
stuff
he
did
like
I
think
he
spent
quite
a
bit
of
time
on
doing
that.
So
we
merged
that
earlier
today,
there
may
be
some
cleanup
of
it
that
I
want
to
do.
A
So
like
alright.
Well,
if
we're
going
to
release
kubernetes,
we
need
to
post
certain
things.
What
are
those
things
right?
Having
an
artifacts
list
that
we
can
reference
is
valuable
because
it
says
now
we
know
we're
we're
kicking
out
we're
kicking
out
docker
images.
We
have
tar
balls,
we
have
configurations
for
GCE,
we
have
configurations
for
windows,
we
have
Deb's
and
rpms,
and
and
so
on
and
so
forth,
right,
so
understanding
all
the
things
that
we
we
need
and
are
the
things
that
we
be
naturally
output
and
then
figuring
out
where
those
things
go.
Okay.
A
A
To
actually
do
it
release
right
so
figuring
out
how
to
build
it,
release
end-to-end
and
working
with
the
case
in
for
a
group
to
get
some
of
this
done
so
I
think
that
a
lot
of
us
are
a
lot
of
us
by
us.
I
mean
sig.
Release
shares
have
the
appropriate
access
to
do
some
of
the
stuff
we
should
all
be
like
writers
or
owners,
or
editors
or
some
sort
of
of
the
the
requisite
GCP
projects.
A
Well,
we
have
a
ton
of
work
to
do.
We've
started
to
write
it
down
on
the
release
engineering
project
board,
as
well
as
a
cig
release
project
board.
We've
also
got
issues
that
have
been
open
since
2017
right
so,
like
you
know,
we've
we've
we've
got
stuff
to
do
so.
Anyone
who's
on
the
call
or
anyone
who's
listening
to
this
call
afterwards
interested
in
getting
involved
in
the
release
engineering
stuff.
Please
let
us
know.
E
Sorry
I
was
gonna,
say:
I
did
totally
miss
my
slot.
Sorry
about
that,
and
we
still
have
Josh's
topic
as
well,
but
I'm
good
to
go.
I
didn't
have
a
lot
to
say
there.
Basically,
we've
been
running
continuous
testing
against
all
the
branches
for
a
while.
Now
we
have
a
dashboard
that
I'm
going
to
link
to.
A
So
finally,
that
dovetails
with
Josh's
topic
about
implementing
blocking
criteria
and
so
I
think
I.
Think
first,
good
step
is
outside
of
this
discussion
to
open
just
open
an
issue.
I
would
I
would
say,
open
an
issue
list
the
kind
kind
and
to
end
for
blah
right
and
say
that
you
want
to
move
it
in
to
release
blocking,
and
we
can
have
part
of
the
discussion
there,
which
issued
tracker
a
great
question:
a
sig
release.
A
A
C
E
E
C
C
Test
job
failure
issues
all
it's
not
they're,
not
really
job
failure
issues
the
jobs
were
failing,
because
there
was
a
problem
with
performance,
which
is
what
they
should
do,
but
there
was
an
issue
about
whether
that
should
be
blocking
or
not,
etc,
and
we
decided
that
we
would
move
the
blocking
when
we
look
back
to
where
it
was
so
pretty
much.
This
is
gone
from
a
proposal
to
accepted
policy,
except
that
it's
not
exactly
clear
what
we
need
to
do
to
turn
it
into
accepted
policy.
C
Aside
from
closing
that
issue,
there
I
mean
presumably
needs
some
additional
I
know
the
lead,
some
additional
documentation
in
the
see,
a
signal
handbook
which
I
have
given
myself
a
to
do
to
write,
but
I
think
that
there
needs
to
be
a
communication
somewhere
other
than
the
C.
In
addition
to
the
see
a
signal
handbook
because
for
one
thing,
wouldn't
necessarily
want
to
be
directing
everybody
who
contributes
to
kubernetes
to
the
see
a
signal
handbook
I
for
a
general
understanding
of
test
criteria.
So
where
should
that
go.
A
Yes,
a
my
thought
was
that
it
should
live
in
urban
areas.
Community
contributors,
devel,
sig,
release
blah
right
and
we
described
the
because
I
mean
that's
that's
kind
of
how
it's
broken
up
by
sake
right
now
and
and
develop,
but
that
includes
information
on
cherry-picks
and
so
on
and
so
forth.
So
I
think
that
that
is
the
right
place
to
to
to
put
it
and
anything
that
we
talked
about
that
references.
Job
criteria
should
reference
just
link
out
to
that.
Instead,.
C
C
C
A
I
think
that
we
can
put
it
up
for
a
vote
once
we
have
the
documentation.
That's
probably
sounds
right,
I'm
generally
fine,
with
most
of
the
things
that
I
read
over
there,
but
I
will
be
honest.
That
I
did
a
quick
skim
of
it.
What
I
would
say
is
that
we
definitely
need
you
know,
and
this
is
something
that's
a
skill
ability
pointed
out
to
you
that
we
need
a
more
well-defined
definition
of
what
a
defined
definition
of
what.
C
A
A
So
I
probably
have
a
few
things:
I
could
riff
on,
but
I
want
to.
Since
we
have
no
more
agenda
topics,
I
want
to
open
it
up
to
open
mic
anyone
new
on
the
call
anyone
want
to
introduce
themselves.
Anyone
have
a
topic
for
a
discussion
that
is
not
currently
here.
So
I
see
Paul,
you
raised
your
hand,
so
go
for
it.
F
I'm
new
I'm
on
the
release,
notes
shadow
one
of
the
shadows
for
the
release,
notes,
yeah,
so
hi.
Everyone-
and
this
is
my
first
release-
release
call
I'm
in
Australia.
So
time
zones
always
an
issue
yeah,
but
at
least
this
this
one
was
at
an
acceptable
time,
which
is
cool
so
hi.
Everyone
looking
forward
to
contributing
welcome.
A
A
All
right
so
I
think
I've.
You
know,
I've
mentioned
it
in
a
few
calls,
and
I
will
mention
it
here
again,
just
to
make
sure
we
are
consistently
recording
this.
We
made
the
decision
last
cycle
are
in
between
last
cycle
in
this
cycle
to
remove
the
branch
manager,
the
branch
manager
role
from
the
release
team
right.
A
Part
of
the
reason
for
that
is
that
we
want
to
more
closely
align
the
branch
management
duties
to
other
release
engineering
e-type
duties
right,
so
the
change
there
is
the
branch
manager
is
still
the
branch
manager
but
lives
in
this
release.
Managers
group,
which
is
under
the
release
engineering
sub-project
of
cig
release
I,
was
trying
to
see
how
many
times
I
could
say,
release
in
one
sentence,
so
the
and
then
the
branch
manager
shadows
have
become
release
manager
associates
right.
A
So
the
idea
here
is
that
what
we
you
know,
I
I,
don't
know
all
of
the
all
of
the
parameters
of
this
just
yet,
but
we
want
to
build
a
team
that
essentially
is
kind
of
like
a
sister
team
to
the
product
security
committee
right
so
at
the
top
level
of
of
the
patch
release
of
the
patch
release
or
of
release
managers.
This
release
managers
group
is
the
patch
release
team
right.
A
The
patch
release
team
is
is
subject
to
the
security
embargo
for
kubernetes
right,
so
notifications
on
Seavey's,
an
execution
of
because
they
are
the
ones
who
execute
on
building
a
release
for
this
right.
So
I
think
it
makes
sense
and
and
I
think
Tim
had
mentioned
this
at
some
point
too.
It
makes
sense
to
align
on
the
way
we
build
a
team.
So
there
was
an
issue
somewhere
that
I
can
track
down,
but
it
makes
sense
to
align
on
the
way
we
build.
A
So
what
we
did
this
cycle
is
we
had
so
in
the
process
of
doing
all
of
the
shadow
applications
and
reviewing
those
candidates
and
deciding
who
goes
where
they
were
also
a
set
of
candidates.
I'm
sorry,
there's
like
a
creaking
door
in
the
back
and
if
that's
getting
caught
on
video
I'm
sorry,
so
there
are
set
of
set
of
candidates
for
the
branch
branch
manager,
shadows,
I,
believe
for
each
role.
Just
as
like
release
team
stats,
we
had
about
80
people
volunteer
for
the
116
release.
A
A
Communications
was
fairly
easy
because
we
had
about
three
or
so
people
volunteer
for
communications.
So
we're
like
cool
I,
really
like
your
all
communication
shadows
now,
but
for
every
other
role
at
least
17
people
applied
to
each
of
those
roles,
so
I
think
with
branch
management
it
might
have
been
22
to
28
people,
it's
a
kind
of
look
at
and
and
that's
hard
because
like
this
is
the
shirt
version
like
that.
That
was
super
hard.
A
So
what
we
did
instead
of
selecting
three
to
four
people,
as
we
kind
of
went
crazy
and
we
said,
let's,
let's
take
a
bunch
right.
Let's
say
we
have
a
lot
of
release
engineering
debt
to
pay
down.
So
let's
take
a
bunch
of
people
and
see
what
we
can
do
with
this
team.
So
we
selected
13
people
this
time
and
I
think
I
think
Josh.
This
first
first
thought
was
like
13.
A
B
C
B
A
A
A
So
you
know
in
in
selection,
I
kind
of
I
kind
of
looked
at
like
what
I
would
like
to
see
are
people
who
have
had
either
have
release
engineering
chops
by
way
of
their
job
or
by
way
of
things
that
they've
done
in
say,
test
infraorder,
release,
team
or
people
that
I
know
I've
seen
before
right,
and
this
is
not
to
say
this
is
a
popularity
contest,
but
this
is
a.
This
is
something
that's
built
on
trust
of
the
community
right.
A
So
if
you're
coming
around,
you
know
if
you
were
coming
around
cig
release,
if
you
were
part
of
the
release
team,
you're
more
likely
to
get
selected
here
right,
so
I
think
that
we've
built
the
the
makings
of
a
right
all
told
between
the
you
know
between
everyone,
who's
involved
in
this
release.
Managers
group,
you
know,
we've
got
the
patch
release
team.
A
The
branch
managers,
the
associates,
the
build
admins
the
build
admins
are
the
people
who
have
the
requisite
permissions
in
behind
the
Google
curtain
to
push
the
button
to
generate
Deb's
and
rpms
for
kubernetes
right.
So
they
are
part
of
the
process,
as
well
as
the
cig
release
shares
which
essentially
end
up
owning
all
of
the
mailing
lists
and
all
of
the
little
doodads
that
involve
doing
the
release.
So
it's
an
important
that
they're
included
in
that
in
that
page,
just
for
reference,
so
you
know
moving
forward.
A
I
am
going
to
be
D
duping
some
of
the
information
that
is
on
the
branch
management
handbook,
as
well
as
the
patch
release
team
handbook
and
I'm
D
duping
it
by
running
through
it
myself
right.
So
in
immediately
before
this
call,
we
did
a
call
for
cutting
the
116
alpha
one
right,
so
we
staged
it
on
that
call.
Probably
later
I
will
do
the
release
portion
of
it,
and
that
is
recorded
that
will
be
up
later
on
the
playlist.
So
I
talked
about
there's
lots
of
overlap.
A
Here,
I
talked
about
some
of
the
release,
engineering
problems
that
we
have
and
some
of
the
things
that
we
can
immediately
fix
in
the
Docs
and
so
yeah.
The
kind
of
the
idea
is
just
to
exercise
the
tooling
exercise,
the
docs
through
a
bunch
of
people
at
this.
This
problem,
and
and
kind
of
enable
us
to
pay
down
this
technical
debt
that
we've
been
building
since
essentially
the
project
started.
So
I'll
start
I'll,
stop
yapping
and
ask
if
anyone
has
questions
about
any
of
that.
A
So
I
think
you
know
I
think
it's
a
it's
appropriate
as
you
move
through
this
ladder
that
doesn't
exist
yet
I
I
think
that
it
makes
sense
for
the
associates
and
the
branch
managers
to
still
align
around
the
release
cycle,
because
they'll
be
doing
things
that
are
related
to
the
release
cycle
right,
so
whether
it's
cutting
branches
managing
ci-4,
that
a
lot
of
the
stuff
that
has
moved
out
of
the
destined
for
playbook,
has
moved
into
the
branch
management
playbook
right.
So
there
are,
there
are
branch,
management,
tasks
or
testing
for
tasks.
A
There
are
some
CI
signal
associated
tasks
that
are
part
of
the
branch
manager
role,
and
you
know,
thereby
something
that
associates
should
be
learning
so
I
think
that
it
still
makes
sense
for
like
associates
and
and
and
branch
managers
to
attend
the
release
meetings.
When
you
know
when
possible,
they
are
also
on
the
release
team
mailing
list
so
that
they
get
all
of
those
communications
and
all
the
the
right
events,
and
so
is
yeah.
A
C
A
Yeah,
so
this
is
yeah.
This
is
something
I
had
mentioned
and
on
the
I
think
the
first
release
team
call
the
did
something
new
kind
of
like
we
just
went
around
the
room
and
I
and
I
asked
each
of
the
each
of
the
roll
leads
like
what
are
your
goals
like?
Well,
it's
like,
if
there's
a
thing
that
you
could
name
like
your
one
thing
for
the
cycle
like.
What's
that?
What
do
you
want
to
get
done
right?
So
I?
You
know,
I,
think
that
part
of
it
is
I
want
to
see.
A
Hopefully
you
become
the
release
team
lead
right,
so
four
cycles
you're
you're
here
for
a
year
we
got
you
for
a
year.
So,
like
that's
one
path
right,
the
second
one
I
think
is
more
unspoken
and
because,
like
that,
you
know
that's
kind
of
obvious
we've
written
that
that
down
in
our
in
our
documentation
around
release
team
selection.
The
second
one
is
a
little
less
obvious
and
it's
I
have
gotten
to
that
crossroads.
Where
I
have
been
a
lead
or
maybe
I've
just
shadowed.
A
A
few
rolls
for
a
while
right
and
I've
identified
some
big
problem,
a
process
problem
or
something
like
that
and
I'm
going
to
I'm
gonna
go
fix
it
right.
I'm
gonna
go
fix
it,
but
for
me
to
take
the
time
that
I
need
to
go
fix
it
I
can't
do
it
on
the
release
team
right
and
that's
kind
of
like
what
I
did
for
features
right,
so
features
got
rebranded
to
enhancements.
A
We
wrote
the
we
wrote
the
first
handbooks
right
starting
that
cycle
and
then
I
said
we
have
a
bigger
problem
and
the
problem
is
like
how
we
pull
things
into
the
cycle
in
the
first
place
right
so
started.
Focusing
on
the
PM
stuff.
I
would
like
to
see
more
people
say:
ok
right.
There
is
a
huge
test
in
for
problem
that
we
want,
like
that.
A
Look
for
the
call
like
I'm,
not
saying,
there's
a
test
in
for
problem
right
right,
but
you
know
as
an
example
like
there's
there's
this
thing
that
I
want
to
fix
like
we
want
to
write
a
release
notes.
We
want
to
write
a
release,
notes
website,
because
the
way
people
are
consuming
release
notes
now
are
not
great
right.
So
that
is
a
tangible
improvement
that
people
were
able
to
get
done
during
the
release
cycle.
But
it's
something
that
it
likes.
A
A
A
But
it's
it's
something
that
more
people
need
to
consider,
and
it's
definitely
I'm.
Also
seeing
a
pattern
of
maybe
lifers
is
the
wrong
word,
but
people
who
will
rotate
back
into
the
release
team,
not
saying
that
that's
a
bad
thing
right,
but
you
know
having
the
opportunity
to
work
outside
of
the
release
team
and
get
these
things
done.
It's
entirely
possible
and
you
in
fact
have
more
time
because
you
are
not
bound
to
attending
the
release
team
meetings
or
the
burndown
meetings.
Stuff
like
that
right.
A
E
A
C
A
But
yeah
I
mean
I.
Think
that
you
know
it's
all
jokes
aside,
the
you
know
I
still
see
the
release.
Team
is
like
one
of
the
scene,
best
ways
of
like
trial
by
fire
for
the
project
right
being
able
to
come
in
and
like
you
were,
forced
to
interact
on
so
many
so
many
different
levels,
with
different
SIG's
and
and
and
the
kind
of
work
that
you
do
like
it's.
It's
super
valuable
right,
so
I
love
being
around
the
release.
A
But
yes,
there
are,
there
are
more
places
to
contribute
right
and
and
I
think
that
you
know
we
have
the
release
team.
You
know
a
lot
of
the
roles
in
the
release
team.
They
map,
you
know
somewhat
two
different
SIG's
right.
So
if
I
said,
if
we
find
that
you
know
your
interests
lie
is
in
a
different
cig,
you
know
whether
it's
like
CI
signal
has,
you
know
strong
ties
to
testing
and
you
know
and
test
in
for
a
did
to
and
enhancements
in,
communications
have
ties
to
p.m.
A
and,
let's
so
on
and
so
forth
right.
You
know
so
like
if
we
find
that
your
interest
is
lies
outside
of
the
release
team.
That's
okay,
right
or
you
have
gained
the
reputation
where
you're
able
to
do
the
thing
like
schedule,
kubernetes
webinar
or
are
you
know,
published
to
the
blog
or
have
like
rights
to
publish
to
the
blog
or
have
you
know,
reviewer
or
approver
rights
in
some
test
in
for
filter
right?
A
We
want
to
enable
you
to
do
that,
but
we
want
to
make
sure
that
we're
looking
at
the
path
for
you
and
like
the
path
is
not
necessarily
staying
in
the
release
team.
So
again
it's
kind
of
a
fuzzier
thing
too,
and
and
I
think
it
will
take
mentorship
of
the
people
who
who
are
on
the
release,
team
or
even
deeper
mentorship
than
we're
doing
right
now.
A
C
C
C
A
B
A
You
know-
and
this
is
one
of
the
reasons
that
we
anytime
I
mentioned
the
handbooks
and
you
know
and
shadows,
are
on
the
call,
I
say
question
the
handbook
question
every
time
you
look
at
a
handbook
if
it's
something
that
doesn't
make
sense
like
realize
that
it
may
have
been
written
a
few
cycles
ago,
maybe
entirely
stale-
and
you
know
this
is
not.
This
is
not
wall,
I,
think
every
every
release
cycle.
We
tweak
the
release
team
selection
process
just
a
little
bit
right.
We've
figure
out
how
we
do
that
differently.
A
A
You
know
in
terms
of
of
more
like
graduation,
you
know
in
two
different
roles,
one
of
the
things
that
we've
been
doing
or
started
to
do,
I.
Think
it's
one
cycle
now
or
something
or
the
release
team
leads
graduate
into
in
as
sub
project
owners.
For
the
release
team
sub-project
right,
so
we
initially
seeded
the
sub
project
owners
with
the
release
team
leads
from
n
minus
three,
maybe
cycles
so
I
think
Josh,
Josh,
iishe,
Erin
and
I
got
a
missing.
I'm
missing
one
and
then
Claire
was
was
was
one
fourteen?
Yes,
wait.
A
No,
oh
my
god.
One
15
too
many
release
cycles,
but
every
you
know
every
time
the
release
cycles
done
well
we'll
go
in,
will
suite
the
sweep
the
owners
and
make
sure
that
the
people
who
have
been
doing
that
work
are
allowed
to.
You
know
have
approval
rights
on
the
things
that
affect
the
way
we
do
releases.
A
So
that's
you
know,
that's
one
path
to
sub-project
ownership
right
and
not
everyone's
gonna
go
down
that
path,
but
you
know
if
you're
interested
in
being
a
sub-project
owner,
you
care
about
release
engineering
or
you
care
about
the
the
licensing
project
that
were
sub
project
that
we're
kicking
up
and
you
know
like.
Let
us
know
let
us
know
so
we
can
figure
out
how
to
put
you
in
those
places
right.