►
From YouTube: K8s Release Engineering Subproject 2019-08-19
A
A
So,
while
we're
waiting,
I
think
a
few
people
are
already
online
and
I
think
that
I
think
that
in
the
meantime,
well
I'm
getting
back
here.
If,
if
you
haven't
put
your
names
in
the
agenda,
go
ahead
and
put
your
names
in
the
agenda
say
that
you're
here,
that's
there!
Any
topics
that
you
want
to
discuss.
Please
also
put
those
in
the
agenda.
Hannes
is
going
to
kick
us
off
with
a
demo
of
some
stuff
that
he's
been
working
on
so
I'll.
Let
you
I'll,
let
you
take
the
floor.
B
So
the
difference
between
the
branch
FF
as
we
do
it
right
now,
and
this
stuff
is
first,
it
does
not
run
on
anyone's
laptop
where
we
basically
have
no
control
over,
but
it
runs
somewhere
in
the
cloud
which
we
might
control
and,
secondly,
the
most
important
bit
here.
It
actually
runs
the
tests
against
the
branch
FFT
code,
so
basically
I
wanted
to
show
you
off
how
I
did
that
with
the
help
of
Concours,
and
why
or
get
some
feedback
from
you
all?
What
do
you
think
about
this
and.
B
Basically,
what
what
I
can
show?
You
is
two
specific
things:
I
think
that
would
be
helpful
for
the
release
engineering
stuff.
That
Congress
brings
one
of
the
first
things
is
the
thing
you
already
see:
it's
all
based
around
pipelines.
So
basically,
in
contrast
to
the
tools
we
currently
use
mainly
GCB,
is
that
it
does
not
run
only
single
tasks,
but
it
manages
how
the
artifacts
and
stuff
flows
basically
from
left
to
right,
hopefully
decreasing
risk
in
that
process.
B
So
the
main
thing
here
is
it
splits
apart
the
what
what
is
called
resources
which
can
be
used
as
inputs
and
outputs
and
the
actual
tasks
that
run,
which
in
that
case
is
the
branch
of
F
and
then
the
test,
and
if
we
step
into
the
test,
what
we
can
see
here
is
all
the
resources
it
needed
specified
by
the
arrows
you
see
here,
pulled
that
down
then
run
some
tasks
and
that's
it
by
splitting.
Apart
these
tasks
and
resources,
what
I
can
see
here
is
exactly
which
resource.
B
B
What
else
can
I
show
you,
for
example,
if
I
click
on
the
resource
itself,
I
can
inspect.
Where
has
this
has
the
resource?
With
of
this
version
been
used
here,
I
can
see.
Ok,
one
green
output
of
whatever
this
test
run
is
or
sorry
input
of
this
test
run
and
has
been
produced
by
the
output
of
this
branch
of
F.
B
And
yeah,
basically,
that's
it
just
wanted
to
gather
some
feedback.
I
think
this
is
also
important
is
might
help
us
in
in
the
process
of
splitting
apart.
Our
release,
tooling,
because
everything
in
conquest
is,
is
a
container
like
every
task.
Every
resource
is
basically
obtained
image
that
runs,
which
we
could
then
one-by-one
upgrade
or
like
one
by
one
switch
to
refactor
to
whatever
we
want
golang
without
needing
to
care
too
much
about
the
other
bits
and
pieces.
Given
we
use
only
the
described
resources
to
pass
artifacts
around
any
inputs.
C
B
Right
now
this
is
running
on
our
shared
Congress
instance,
which
the
Concours
team
provides
for
us
internally.
It's
running
on
gke
I
believe
but
I
don't
know
much
details
about
that,
but
if
that
is
of
interest,
I
can
get
them,
but
the
short
version
is
Concours
basically
runs
anywhere
on
any
cuba.
Nettie's
can
even
run
locally
on
your
talk
engine
and
yeah.
B
B
This
is,
this
is
one
of
the
main
things
not
knowing
too
much
details,
but
what
I
could
imagine
is
we
get?
We
as
the
release
team
got
a
cheeky
cluster
from
working
group,
infra
and
deploy
I
think
currently
concourse
itself,
ships
as
a
helmet
loyd
there
and
managers
managers
there
ourselves,
but
yet
it
would
be.
Somebody
would
need
to
manage
that
and
keep
it
up
to
date
and
older
all
that
businesses.
A
Thanks
alright,
so
one
awesome,
thank
you
for
the
demo.
I
think
that
I
think
that's
seeing
the
the
things
that
happen
on
branch
fast
word
in
a
that.
Multiple
people
can
view
is
better
than
having
it
on
someone's
local
laptop,
especially
because
we
can
pull
logs
and
do
different
things.
I'm
gonna
be
late,
those
as
we
need
to
so
a
few
concerns.
First,
what
what
Carlos
was
mentioning
this
requires
this
is
going
to
require
additional
infrastructure
right.
A
So
one
of
the
things
I'm
curious
about
was
there
a
particular
reason
to
to
try
to
leverage
concourse,
as
opposed
to
the
fact
that
we
have
prowl
as
well
as
JCB.
There
seems
to
be
a
decent
amount
of
overlap
between
what
priority
does
the
fact
that,
in
addition
to
the
fact
that
we
don't
need
to
maintain
and.
E
A
So
yeah
I,
maybe
missed
that
part
in
the
introduction,
but
I
did
read
through
his
his
write-up
in
Kate's
release.
So
I'm
we're
of
most
this
stuff
I'm
curious
about
why
we
can't
find
a
front
end
or
something
for
GCB
and
build
this
in
GCP
like
this,
the
functionality
of
like
pushing
branch
fast
forward
into
into
somewhere
that
is
not
someone's
local
laptop,
is
valuable.
I'm
trying,
yeah
I'm
curious
about
like
is
this
something
that
we
can
do
with
tools
that
we
are
I
assume.
B
A
docker
or
a
container
image
I
immediately
see
and
have
guarantees
that
this
thing
was
created
at
this
step
at
this
time
was
used
in
the
other
step
and
has
created
yet
another
output
of
another
type
of
resource
of
a
specific
version.
So
I
think
that's
that's
super
nice
to
track
what
what
goes
on
in
our
pipelines
and
secondly,
right
now
as
GCB
works
like
all
the
all.
B
The
gathering
of
all
the
inputs
and
pushing
outputs
is
part
of
the
task
which
makes
it
hard
or
even
impossible
to
drag
it
like
you
can
track
it
in
concourse,
because
conker
separates
those
two
things:
the.
If
you
will
resource
management,
input,
output,
management,
decoupling
from
the
actual
thing
that
runs
the
test,
the
build
whatever
it
is.
E
Yeah,
you
would
need
to
choose
a
a
space
technology
said
that
had
that
native
concept,
so
I
think
there
are
a
couple
of
options.
One
is
Tecton,
one
is
spinnaker
and
others
concourse
right,
Eugene,
some
higher
level
tools.
Not
just
oh
look,
there's
not
if
you
wanted
to
move
all
for
DC
being
you
want
to
stay
within
the
Google
family
of
technology.
These
would
be
tacked
on
that
would
be
your
choice,
right
and
I.
Don't
think
we're
you
couldn't
I,
don't
think!
A
Okay,
that's
fair,
so
just
just
just
to
be
clear
for
the
call
at
least
I'm,
not
necessarily
advocating
that
we
stay
in
any
in
the
Google
suite
of
in
the
Google
family
of
products
on
just
my
main
concern
is
any
additional
resource
management
that
we
would
be
taking
up
right.
I
want
to
make
sure
that,
like
we,
we
already
have
enough
things
in
our
hands.
I
want
to
make
sure
that,
like
any
projects
that
we
start
working
on,
don't
add
things
to
that
list
unnecessarily.
This
I
mean
this
is
I,
think
that
this
is
valuable.
A
C
Also,
if
we
build
something,
that's
gonna
need,
run
and
managed
right,
but
maybe
testing
for
has
some
built
in
existing
biases
as
a
group
toward
things
that
they
would
be
willing
to
run
and
manage,
or
maybe
maybe
over
there,
everybody
loves
Concours
for
all.
We
know
like
that.
I
think
we
should
reach
out
to
them
and
understand
what
sorts
of
things
they
envision
being
easy
to
run
and
manage
for
this
type
of
work.
B
Another
thing
I
just
want
to
mention
is
that
I
I
don't
want
to
move
everything
tomorrow
to
concourse
or
Tecton
or
what-have-you,
but
I
think
it'll.
It
would
align
well
with
the
work.
We
are
doing
right
now,
like
breaking
the
thing
apart,
and
so,
if
you
will,
it
doesn't
interfere
anyway.
What
we
can
do
right
now,
I,
can
just
continue
my
tests
or
POCs
on
on
our
internal
thing
here
and
see
how
it
goes.
E
A
Yes,
that's
what
that's
what
I'm
saying
so,
if
we,
if
we
have
if
people
have
not
needed-
or
this
has
been
consistently
good,
the
runs
have
been
consistently
good
in
people
have
not
needed
to
do.
That,
like
Hannes
was
mentioning
that
he
doesn't
really
need
to
do
or
maintain
anything
any
state
afterwards
after
running
branch
fast
forward,
then
we
don't
necessarily
need
a
human
to
do
it.
Then
that
means
we
can
shove
it
in
it.
We
can
shove
it
in
a
job
there's
a
period
where
that's
valid.
C
Right
now,
once
we
get
to
the
final
couple
of
weeks,
depending
on
how
code
freeze
goes,
but
especially
during
code
freeze
and
potentially
the
leading
up
to
or
or
depending
on
how
far
has
exactly
at
that
point,
the
branch
manager
should
really
be
looking
at
the
branches,
and
my
fear
is
that,
if,
if
we
do
too
much
automation,
it
sends
the
message
that
this
is
just.
This
is
another
one
of
these.
C
These
areas
were
there's
this
perception
that
testing
first
should
just
be
all
automated
away,
but
there's
a
period
where
the
human
needs
to
be
very
much
turned
on
looking
at.
What's
going
on
and
man
it
actively
managing
this
the
flow
of
things
and
the
less
practice
one
gets
at
that,
even
if
one
simply
thinks
oh
I,
don't
need
to
do
it
right
now
doing
it
right
now,
a
little
bit
as
a
isn't
is
a
great
learning
thing.
E
One
of
the
reasons
why
you
would
want
to
not
try
and
each
three
architects
power
figure
out.
How
do
you
build
things
on
top
of
power?
Allows
you
to
trained
individual
tasks
together,
which
is
not
a
concept.
That's
native
in
the
architecture
is
that
this
demo,
as
you
have
today,
how's
the
ability
to
run
tests.
So
not
only
does
it
introduce
the
concept
of
a
pipeline
through
the
introduction
of
the
concept
of
am
I
blind
introduces
the
idea
of
backpressure
such
that
commits
cannot
move
forward
until
they're
qualified
is
good.
E
This
allows
a
human
to
be
aided
by
genes
and
doing
that
qualification,
whereas
today
there
was
actually
nothing
that
did
that
at
all,
and
you
just
had
to
kind
of
hope
and
then
look
at
the
the
tests
afterwards,
after
you've
fast
forwarded
the
branch
to
see
if
you
moved
risk
from
master
to
the
police
branch.
So
you
have
to
look
at
test
grade
and
see
if
you
kind
of
have
to
guess
right
whether
you
wanted
to
move
that
risk
from
master
to
the
release
branch,
and
now
the
you
have
a
computer
that
helps
you
qualify.
A
All
right
so
I
think
I
think
next
steps
was
Hannes
if
you
can
arrange
something
with
cig
testing
test
infra
to
talk
a
little
bit
about,
maybe
have
them
join
our
call
or
us
join
their
call
and
talk
a
little
bit
more
about
what
the
future
of
of
something
like
this
would
would
look
like,
or
if
they've
already
been
working
on.
Something
like
this.
A
D
D
I
have
no
idea
how
we
can
proceed
with
that,
but
as
a
setting
that
github
issue
and
sometimes
I'm,
feel
like
a
little
bit
lost
because
I'm
not
like
working
on
this
my
entire
day,
but
just
like
I,
have
reserved
time
to
do
this
during
the
week
and
I.
Don't
know
how
we
want
to
proceed
for
the
release,
associates,
training
or
delegation
or
whatever.
A
Cool
yeah,
so
so
I
think
that
you
know
this
is
something
that
we
are
still
trying
to
figure
out.
Unfortunately,
the
there's
not
an
easy
answer,
because
it's
not
it
has
less
to
do
with
again.
It
has
less
to
do
with
training
someone
up
to
do
it
and
and
and
more
so
giving
them
access
to
tools
to
really
screw
Burnett
is
right
and
it
like
it's
a
dangerous,
dangerous
thing
to
do
right,
so
so
Carlos,
you
actually
had
an
opportunity
to
to
cut
eight
one
of
the
Alpha
releases.
D
Okay
yeah
the
morning
I
discovered
I
need
to
cut
the
release.
It
was
like
I
wasn't
sleeping,
and
then
you
guys,
you
were
Stefan
and
young,
like
I,
think
you're
talking
in
private
or
I,
don't
know
how
it
was
like
decide
run
though
the
Alpha
cut,
but
then
that
the
next
morning,
when
I
wake
up
I
saw
the
is
like
I
need
to
get
the
Alpha
okay
run
to
live
on
things
because
I
don't
know
what
to
do
and
that
I
start
rereading
all
the
their
handbooks
and
see.
D
D
Oh
and
then
some
people
join
and
just
watch,
and
then
I
tried
to
explain
us
Stefan,
didn't
there
his
YouTube
video,
like
I'm,
doing
these
steps
and
checking
this
occasionally
issue
I'm
lap
dating
the
the
issue
for
the
Alpha
cut,
with
the
desk
reads:
screenshots
and
all
the
informations
and
lots
one
was
like
for
me.
I
was
straightforward.
This
part
I,
don't
know
how
about
the
bridge
forward
and
actually
cutting
their
their
release.
So.
A
So
so
that
is
you,
you
did
cut
a
release
right.
You
you
end
up
cutting.
You
ended
up
cutting
an
alpha
release,
so
the
the
the
branch
fast
forward
is
a
little
different,
because
grant
fast
forward
requires
you
to
be
a
member
of
the
release
managers.
Github
team,
which
gives
you
write
access
to
kubernetes
kubernetes
right.
So
that
again,
is
something
that
we're.
We
can't.
B
A
Give
away
lightly
so
the
so
I
guess
a
note
on
the
video
that
I
did.
That
was
my
first
time
doing
that
as
well
right.
So
so
part
of
the
reason
for
that
video
was
to
say,
like
this
is
someone
who
has
no
idea
how
to
do
this,
recording
it
free
for
the
sake
of
for
the
sake
of
it
being
useful
later
so
so
part
of
part
of
what
we
can
do
to
help
the
release
manager
associates
learn.
A
The
task
is
to
to
engage
and
distributed
mentoring
like
like,
like
doing
videos
like
that
right,
I
I,
recently
added
a
there's:
an
act
of
PR
open
for
a
branch
manager,
handbook
updates,
which
I
linked
in
the
agenda.
You
can
take
a
look
at
that
to
get
some
ideas
of
some
of
the
changes
so
I,
so
I
wanted
to
do
the
alpha
0
to
get
an
idea
of
just
how
the
process
worked.
I
also
did
the
beta
0,
because
that
involves
the
branch
cuts.
The
brant
and
the
branch
cuts
essentially
happened
once
a
cycle
right.
A
There
are
lots
of
things
that
may
or
may
not
have
been
documented.
That
I
wanted
to
try
and
capture
right,
so
that
PR
is
the
work
product
of
that
stuff.
We
have
been.
There
have
been
some
active
conversations
around
how
how
we
can
D
do
power
mailing
lists,
and
so
one
it's
easier
for
people
to
communicate
within
the
team
as
well
as
communicate
with
us.
The
second
part
of
that
is
so
that
we
can
eventually
use
those
mailing
lists
to
issue
permissions
on
GCP
right.
A
So
the
release
manager
release
private
at
kubernetes
at
I/o
is
the
mailing
list
for
internal
communication
between
the
patch
release
managers,
the
sig
chairs
and
some
of
the
security
product
security
committee.
That's
the
current
state.
That
list
will
be
shortened
up
to
be
the
build
admins,
the
the
build
admins,
the
patch
release
team,
the
branch
managers
and
I
think
that's
it
right.
The
release
managers
at
kubernetes
IO
list
will
be
every
one
that
I
just
mentioned,
including
an
in
addition
to
the
release
manager
associates
alright.
A
In
terms
of
you
know,
in
terms
of
learning
and
growing
and
as
a
release
manager
associate,
there
are
things
that
you
just
won't
be
able
to
do
right
and
you
won't
be
able
to
do
until
you
essentially
prove
to
us
that
we
we
can
trust
you
with
the
keys
right.
So
you
know
part
of
for
all
the
release.
Managers
on
the
call
and
listening
later
you
know,
part
of
what
we
want
you
to
be
doing
is
taking
an
active
interest
in
the
things
that
we're
working
on
right.
A
A
What's
popping
up
on
the
cig
release
the
cig
release
repo
watching,
what's
popping
up
on
the
release
reap
being
a
part
of
these
calls
being
active
in
the
sig
release
and
the
release
management
channels
on
slack,
offering
to
take
up
issues
or
review
PRS
right
that
come
into
that
come
into
those
repos
like
that's
how
you
proved
up
like
that's,
so
we
were
essentially
so
you
know
the
reason
that
we
gave
you
the
access
to
do.
That
temporarily
is
because
we're
like
hey
Carlos,
has
been
doing
this
stuff.
A
Carlos
has
been
watching
what's
going
on
he's,
taking
an
active
interest
in
this
raid
and
okay.
Well,
if
we're
going
to
choose
someone
to
to
jump
on
this
like,
let's
have
it
be
Carlos
right,
so
that
was
the
discussion
that
was
happening
the
week
before
and
that's
why
it
was
like
it
was
only
resolved.
As
of
that
as
of
that
night,
which
is
why
you
saw
the
notice
in
the
morning
right,
but
you
know
so
so
sorry
for
the
short
notice
but
I
hope
you
enjoyed
yourself
having
an
opportunity
to
yeah.
D
For
sure
again,
I,
thank
you
and
young,
for
the
trust,
for
me
was
like
a
great
learning.
Experience
like
it
was
the
short
notes,
but
there's
no
problem,
because
the
documentation
is
like
we're
writing
and
it
was
easy
to
to
read
and
follow
all
the
guides.
Even
I
I,
like
I,
set
up
a
new
machine
I
made
the
best
to
say
that
my
environment
was
like
a
straight
forward
as
well.
That's.
A
Awesome,
that's
all
and
I
think
that
you
know
one
of
our
goals
overall
is
to
make
the
documentation
like
so
easy
to
read
that
literally
anyone
can
pick
it
up
and
do
it
right.
You'll
you
saw
from
the
process
a
lot
of
it
really
is
just
waiting
for
Forker
for
the
bills.
To
finish
running
I
have
a
personal
goal
where,
if
I've
written
a
document
from
start
to
finish,
I'm
not
happy.
If
you
come
back
with
questions
great,
that
means
I
haven't
done
my
job
in
writing.
That
document
right.
A
It
should
be
so
clear
that
you
don't
need
to
write.
So
if
you-
and
this
goes
for
literally
any
sig
release
TOC,
if
you
see
a
doc
that
is
not
clear
file,
an
issue
tell
us
great,
because
we
want
that
to
especially
for
people
who
are
not
part
of
or
not
part
of,
sig
release
and
don't
have
the
same
context
that
we
do.
A
We
want
them
to
be
able
to
come
to
the
dock
and
go
oh
I,
get
exactly
what
they're
doing
right
now
right
so
so
think
about
you
know
whenever
you
know,
whenever
you
take
up
a
document
or
whenever
you
take
up
a
PR,
realize
that
every
every
word
you
write,
every
line
of
code
that
you
commit
is
going.
It
is
potentially
going
to
be
viewed
by
someone
right
and
you
have
to
write
it
in
such
a
way
that
someone
without
context
can
still
understand
it.
A
Moving
in
in
terms
of
like
how
we
train
you,
I
I,
don't
I,
don't
know
like
this
is
like
this.
This
quarter
is
our
discovery
period.
Essentially,
this
is
the
first
time
we're
officially
doing
a
team.
This
large
there
are
still
like
unknown
unknowns.
There
they're
pieces
of
the
infrastructure
that
myself,
Caleb
and
Tim
may
not
have
touched
before
right.
A
There
is
an
active
issue
right
now
about
how
we
want
to
handle
how
we
want
to
handle
the
release
tool,
images,
the
container
images
that
we
built
and-
and
you
know,
and
and
this
is
another
example
of
someone
doing
exactly
what
we
kind
of
hope-
that
you'll
you'll
do
in
in
as
a
release
manager
associate-
is
to
so
ace
offered
he's
like
hey.
This
looks
like
this.
This
is
something
that
is
right
up.
My
alley
can
I
take
this
great.
That's
what
we
want
right.
You
know.
A
So
this
is
like
the
you
know:
it's
not
just.
How
do
we
train
you?
It's
also
a
an
expectation
of
like
active
participation
right
so
so
he
saw
that
he
picked
it
up
and
you
know
when
I
you
know
when
I
have
enough,
like
I
try
to
as
much
as
possible
tag
people
a
tag,
release,
engineering
to
which
release
engineering
includes
branch
managers,
the
build
manager
so
CSD.
A
A
You
know
these
are
you
know,
I,
think
I
checked
my
queue
today
and
I
have
maybe
seventy
two
things
assigned
to
me
so
like
they,
you
know
trying
to
trying
to
figure
out,
what's
appropriate
for
someone
to
work
on
in
your
active
queue,
as
opposed
to
as
opposed
to
maybe
doing
something
and
then
handing
something
else
off
to
them.
It's
like
it's!
It's
a
constant
juggling
process,
so
everyone
who
is
here
we
are
working
through
this
we're.
You
know
we're
so
I.
D
A
And
its
yeah-
and
it's
definitely
one
of
those
things
where
we
try
to
leave
bread
crumbs
so
that
you
can
you
can
do
that
kind
of
discovery.
It's
also
helpful
to
us
if
you
like,
sometimes
maybe,
three
weeks
later,
you
look
at
an
issue
you're
like
wait.
What
did
I?
What
did
I
do
here
see
I
do
have
to
do
your
own.
A
You
know
you
have
to
do
your
own
archaeology,
so
it
is
helpful
whenever
you're
you're
putting
up
an
issue
or
a
PR
to
not
just
say
like
hey
I,
did
this
thing
or
I
added.
You
know
added
something
to
blah
right
say
why
you
did
it
like,
say
what
you're
doing
say
why
you
did
it
linked
to
any
active
issues
or
conversations
so
that
someone
who
is
not
part
of
that
conversation
can
follow
along
right
right.
A
C
All
right
have
a
comment
or
both
wanted
to
give
time
specifically
for
the
associates
since
you'd
caught
up
to
them,
so
I'm
a
little
concerned
here
on.
So
we
added
this
big
team
and
the
commit
where
they
went
in.
It
was
sort
of
the
associates
for
1.16,
and
this
has
been
decoupled
from
the
release
cycle,
but
I
want
to
do
sort
of
a
process
checkpoint
because
we're
about
two-thirds
of
the
way
through
the
1/16
release
and
make
sure
that
we're
we're
on
a
the
right
path.
C
I
think
the
discussion
here
around
process
updates
is
good,
but
a
lot
of
it
came
to
associates,
pay
attention
and
and
get
involved
and
I
think
when
this
originally
came
up,
we
sort
of
had
the
question
from
Carlos
like
well.
Would
it?
What
is
the
path
here?
How
does
one
grow
as
an
associate?
How
does
one
move
up
to
branch
manager?
We
talked
a
bit
here
about
the
responsibilities
of
the
associates,
but
I
really
think
we
need
to
flesh
out
more
on
what
the
leaders
responsibilities
are
for
actively
growing.
C
So
we
that
was
sort
of
a
TBD
part
of
the
last
discussion,
but
as
time
goes
by
I,
don't
want
to
get
another
eight
weeks
along
because
it's
been
eight
weeks
since
we
did
the
PR
for
without
that
list
of
names,
basically
and
I
want
to
make
sure
that
we're
not
just
kicking
a
can
down
the
road
that
we
are
having
some
process
points
for
making
sure
that
we
flesh
that
part
out.
I
know:
Steven
you're
you're
focused
right
now
on
doing
discovery,
getting
less
unknown
unknowns,
but
I
don't
know.
C
A
So
future
wise
right
as
a
release
manager
associate
you
kind
of
want
to
go
up
this
contributor
ladder
that
we've
just
created
right.
So
it's
essentially
like
roles
that
have
existed
the
head
of
existed
for
a
while
that
have
been
kind
of
separate
right:
the
branch
manager
and
the
patch
release
manager
roles.
The
patch
release
role
was
pulled
out
of
the
release
team
and
it
became
a
team
itself
right.
A
The
branch
managers
were
essentially
bound
to
a
release
cycle
right,
so
they
would
do
their
work
and
then
kind
of
shift
off
right
where
I
think
that
you
know
if,
after
you've
grown,
someone
won
at
least
one
cycle,
foreshadowing
the
role
and
then
another
cycle
to
actually
do
the
branch
management
activities
right.
You've,
you've,
you
know
you
have
you
have
a
contributor
who
is
learned
a
lot
of
the
context
that
you
need
to
to
work
on
the
patch
release
team
right.
So
that's
like
a
natural,
that's
a
natural
progression.
They've
touched
all
the
tools
right.
A
They
you
know.
They've
they've
opened
the
issues
they've,
you
know,
they've
made
the
announcements
and
all
that
stuff
right.
So
that's
a
natural
progression
and
I
think
that
what
I
see
in
the
release
manager
associate
role
is
I.
Come
in
I'm
super
eager,
I'm
doing
all
the
stuff
I'm
filing
PRS,
hey
I,
don't
understand
this:
hey
can
I
take
a
crack
at
this.
All
right
I
may
be
reviewing
PRS
myself.
We
see
that
you're
interested.
You
see
that
you've
been
interested.
We
promote
you
to
branch
manager
right.
You
continue
to
do
that
work.
A
Some
cycles
go
by
maybe
a
cycle.
Maybe
two
I
don't
know,
and
you
become
a
bachelor
you
get
invited
to
the
batch
release.
Team
right,
Pat
Riley's
team
has
a
few
different
things
going
on.
Where
you
know
they're,
you
know
they're
juggling
the
the
patch
releases
for
all
of
the
active
cycles
right
all
of
the
active
kubernetes
releases,
they're
also
keyed
in
with
the
product
Security
Committee,
about
active
Seavey's
right.
So
this
is
kind
of
like
different
work.
A
Some
of
it
is
secret
work
that
I
see
that
I
would
see
a
branch
manager
growing
into
you
know
afterwards,
right
as
an
example
young,
he
was
on
the
call.
We've
invited
him
to
become
a
patch
release.
Team
member
right
starting
in
117
right
and
then
we
also
have
a
former.
We
also
have
a
former
branch
manager.
Doug,
who
is?
Was
he
branch
or
was
he
patch
might
have
been
patch
right?
Tim,
yeah.
A
Okay
right,
so
we've
also
invited
him
to
remain
on
the
patch
release
team
right.
These
teams,
the
set
of
branch
managers
as
well
the
set
of
people
members
on
the
patch
release
team,
as
well
as
the
set
of
release
manager,
associates,
don't
think
of
them
as
bounded
by
any
one
release
cycle.
If
you
were
doing
the
work,
you
can
stay
on
the
team,
that's
that's
what
I
think
and
I
think
that
you
know
it
gives
us
the
opportunity
for
like
every
every
cycle.
I-
don't
imagine
that's
you
know.
A
Even
you
know,
even
even
this
cycle
right
so
far,
you
know,
Young
is
like
the
the
primary
but
branch
manager
I'm
like
we
don't
have
the
idea
of
primaries,
but
Young
is
the
primary
because
he
was
selected
for
branch
management
for
116
before
we
pulled
the
team
out
right.
So
I
think
that
he
has
had
the
opportunity
to
seed
some
of
those
responsibilities
that
allow
myself
Carlos
chances
to
actually
go
through
the
motions
of
pressing
that
button
right.
A
So
I
so
I
think
that
you
know
just
being
a
patch
release
team,
member
or
a
branch
manager.
You
don't
have
to
do
just
those
actions
right.
It's
now
that
you
have
the
context
from
doing
the
job
from
for
some
time.
You
should
seek
to
do
things
like
improve
it
right.
It's
not
just
executing
the
job.
It's
identifying
flaws
in
the
process
right
so
Honus
presenting
the
demo
on.
How
do
we
start
to?
How
do
we
start
to
look
at
pipelining
right?
A
There
is
a
an
open
issue
on
patch
release
team
processes
that
we
could
that
we
can
probably
work
on
cleaning
up
and
from
my
side,
I'm
working
on
the
branch
management
onboarding
as
well
as
clean
ups,
for
that
handbook,
great
so,
I
think
somewhere
in
the
middle
Tim
and
I
will
meet
and
figure
out,
okay.
Well,
this
is
something
that
happens,
and
so
an
example
of
the
branch
cut
activities
right.
The
branch
cut
activities
don't
need
to
be
done
by
a
patch
release
team
member
right.
A
They
just
need
to
be
explicitly
enough
and
documented,
and
and
and
done
by
someone
who
has
access
to
do
them
right.
That's
something
that
we
can
pull
out
if
the
patch
release
manager,
the
patch
manager,
the
branch,
oh
my
god,
the
first
managers
handbook
write
something
like
doing
the
notifications
for
the
release.
That's
something
else
that
doesn't
necessarily
need
to
be
done
by
the
person
who
pushed
the
button
right.
A
So,
like
an
example
is
you
know
harnesses
in
harnesses
and
n
immediate
time
zone
and
by
the
time
we
cut
the
and
we're
doing
the
builds
for
the
Deb's
and
rpms
today
right,
but
that
won't
be
done
until
someone
from
the
build
admin
team
who
is
on
Pacific
u.s.
Pacific
time
zone
comes
in
and
pushes
that
button
great.
So
the
announcement
for
the
announcements
to
go
out
the
same
day.
Honus
is
not
going
to
be
necessarily
the
one
doing
the
announcements
unless
he
wants
to
stay
up
super
late
right.
A
So
you
know
like
there
are:
there
are
ways
of
distributing
this
work.
There
are
ways
of
distributing
the
documentation
that
we're
still
working
through
and
I
think
that
you
know
part
of
the
reason
I
was
talking
with
him
about
this
and
I
said.
You
know
part
of
the
reason
I
wanted
to
inject
myself
in
this
process.
The
cycle
is
to
figure
out
what
some
of
that
stuff
was
right
question
a
lot
of
the
things
that
are
written
down
already
and
poke
holes
in
it.
A
A
A
C
I
can
the
head
of
test
Kurt
and
project
board
we've
got
so
project
updates
and
I
have
one
question
that
came
up
kind
of
late
last
week
on
a
sub
project
from
a
licensing
perspective,
we
just
did
big
going
updates
on
all
of
the
patch
release
branches,
and
some
of
that
was
bringing
in
a
chunk
of
new
vendor
code
for
dependencies
would
which
something
have
noticed
if
we
brought
in
something
strangely
licensed.
There
is
the
licensing
automation
today,
just
on
master
or.
A
It
is
so
it's
not
just
on
its
it's
everywhere.
It's
watching
everything
and
kubernetes
works.
The
the
real
question
is
whether
people
are
doing
things
about
it
right.
So
the
the
release,
the
the
licensing
sub
project
I,
think
we're
still
waiting
to
I.
Think
josh
had
mentioned
that
it
might
be
a
good
idea
for
licensing
to
give
their
updates
in
cig
release
and
sig
release
meetings,
as
opposed
to
having
their
own
meeting.
A
Simply
because
we
haven't
been
able
to
schedule
one
of
those
things
it
has
so
it's
it's
myself,
Nikita,
Tim's
and
Steve
Wynn
so
from
the
LF
I
have
not
really
had
time
to
work
on
licensing.
My
focus
has
been
on
the
on
the
release,
engineering,
stuff
and
so
Nikita
basically
has
that
ball
in
her
her
palms
right
now,
I'm
I
said
just
run
with
it.
A
So
I
think
that
you
know
we
should
make
a
decision
if
we
want
to
spin
up
that
meeting
or
if
we
want
to
just
have
just
have
announcements
within
the
sig
release
meeting
and
move
there,
but
there
is
something
that
runs
called
fossa
that
is
scanning
all
the
repos
for
stuff
right
for
policy
violations,
all
branches
of
all
repos.
Yes,
what
we
need
to
do
is
for
a
first
step
is
define
some
sort
of
soft
policy
right
that
it
can
it
can.
A
C
Yeah
that
answers
question
okay,
go
I,
knew
that
the
the
action
portion
was
TBD.
Well,
there's
people
who
are
responsible
for
it
and
receive
it,
but
I
feel
like
possibly
the
plurality
of
those
people
is
Tim
Hakan.
So
like
it's,
these
people
who
are
seeing
them
and
acting
on
them
or
in
the
past
it
seem
like
they're,
very
busy
people
and
it's
an
area
where
ideally
we'll
get
to
spread
out
a
little
bit
better
through
a
trusted
set
of
people.
C
A
That
we
have
other
branches,
okay,
so
Tim,
would
you
mind
adding
that
as
an
agenda
topic
for
the
cig
release
meeting
next
week,
I'm
onna
cool
all
right.
So
with
the
final
ten
minutes,
I
want
to
go
through
I
guess:
I
guess
I've
reviewed
mostly,
so
it's
fine
to
go
through
mine
I
want
to
go
through
some
of
the
stuff
that
has
happened
in
the
last
recently
ish.
Let's
do
recently
updated.
A
Okay
and
I'll
just
try
to
pull
out
like
interesting
things,
our
newest,
let's
go
in
newest,
okay,
newest
right,
so
we
made
a
change
to
the
image.
I
won't
bother
opening
this
actually
well
alright,
so
we
made
a
change
to
the
image
that
is
used
to
run
the
kubernetes
release
unit
tests
right
so
right
now
we're
using
cubic
ins,
the
cubic
ins
and
eat
eat
and
to
end
tests,
and
so
that's
I
would
prefer.
A
We
not
use
that
image,
but
the
reason
we're
using
it
is
because
it
has
some
of
the
dependencies
required
to
to
make
those
tests
successful.
Now
that
we're
checking
both
shell
and
go
code
great,
but
I
opened
a
separate
issue
to
discuss
how
we
should
be
handling
images
for
release
tooling.
So
if
you
want
to
check
that
out,
it
is
8/5
on
kubernetes
release,
and
that
is
something
that
alex
is
going
to
be
working
on
our
ace.
You
prefer
a
straight.
A
A
A
Publishing
bot
does
that
are
logging
now
Hannes
added
some
test
helpers
for
some
of
the
Bosch
tooling,
that
we
have
in
case
release
fallbacks
method
to
do
right,
so
the
116
beta
0
was
cut.
There
were
some
associated
branch
cuts
activities
that
happen
there.
What
I
did
was
every
time
I
had
to
do
a
thing
that
was
any
way
shape
or
form
related
to
this
branch.
Cut
I
either
opened
an
issue
or
PR
and
linked
it
back
here.
So
there
are
some
things
that
some
action
items
to
look
at
as
well
as
just
general
history.