►
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).
B
Hello,
hello
today
is
monday
september
28th,
and
this
is
the
release
manager
associates,
intro
and
q
a
session,
a
quick
reminder
that
this
meeting
is
recorded.
So
please
be
mindful
of
code
of
conduct
and
what
is
the
plan
for
today's
meeting?
The
plan
is
that
danielle
is
going
to
do
a
quick
work
through
to
the
release,
manager,
associates
role
and
the
plan
is
to
show
about
what
is
expected
and
what
are
the
responsibilities
along
with
a
bit
of
tips
of
tricks?
C
Awesome
thanks
marco,
and
thanks
for
getting
this
all
organized
and
getting
the
timing
down
and
inviting
everyone.
I
really
appreciate
that,
just
to
kind
of
start
off
today,
I've
got
like
a
general
plan
that
we're
gonna
walk
through
kind
of
just
as
an
introduction
to
some
of
the
responsibilities
that
release
manager
associates
have,
but
it's
definitely
a
very
flexible
agenda,
and
this
is
kind
of
a
trial
run
to
see
how
we
can
maybe
develop
some
smaller
content
as
well.
C
So
any
questions
or
ideas
you
have
along
the
way,
obviously
feel
free
to
you
know,
speak
up
you're
welcome
to
interrupt
me,
while
I'm
talking
and
also
put
those
in
chat
or
write
them
down
for
for
ideas
for
later,
but
in
general,
I'm
gonna
go
ahead
and
share
my
screen
here,
which
it
looks
like
the
host
has
disabled
screen
sharing.
So
I
think
you're
the
host
now.
C
Cool,
thank
you
so
anyway,
we're
gonna,
walk
through
thanks,
looks
like
that
works.
C
We're
going
to
walk
through
a
little
bit
of
the
branch
manager
handbook,
which
is
kind
of
the
canonical
place
that
you
go
and
look
for
the
general
overview
of
the
role.
One
thing
I
want
to
point
out
before
we
get
started,
though,
is
you'll,
see
this
notice
here
that,
as
the
patch
release
team,
which
used
to
be
separate
from
the
branch
manager,
role,
gets
condensed
into
the
release
manager,
role,
which
has
been
happening
over
the
last
cycle
and
and
some
time
a
little
bit
before
that.
C
This
document
is
a
little
bit
in
flux
and
things
are
changing,
so
definitely
feel
free,
as
it
says,
to
reach
out
and
ask
questions
and
we'll
try
and
point
out
some
of
the
places
where
things
are.
There's
some
discrepancies
right
now,
but
you're.
You
know
also
welcome
to
question
everything
and
open
prs
to
fix
things
as
you
find
them
as
well,
but
in
general,
a
release
manager
associate
and
a
release
manager
in
general
is
responsible
for,
as
you
would
guess,
managing
releases
right.
C
So
that
goes
from
everything
to
branch
management.
To
actually
cutting
releases
to
working
on
the
tooling
to
do
all
those
things
and
all
the
things
surrounding
it.
C
So
typically,
at
least
in
my
experience,
two
of
the
easiest
ways
to
start
getting
involved,
especially
as
an
associate,
is
to
work
on
the
tooling,
because
you
know
that
is
a
a
static
binary
that
gets
compiled
so
there's
you
know
tangible
tasks
that
can
be
worked
on
over
time
and
we'll
take
a
look
at
that
in
a
moment
and
then
grow
into
cutting
releases,
which
is
kind
of
like
the
primary
function,
and
everything
else
is
in
service
of
that
so
quickly.
C
I'm
gonna,
you
know,
take
a
a
outlook
that
folks
are
are
new,
although
I
know
there's
a
lot
of
very
experienced
folks
on
this
call
already,
so
some
of
this
might
be
kind
of
elementary
for
you,
but
we'll
kind
of
build
up
to
to
more
quote-unquote
advanced
material.
C
One
other
thing
I
want
to
say
before
I
jump
too
far
into
it
is
we
have
a
number
of
folks
on
this
call
who
have
more
experience
than
me
as
well.
So
obviously,
please
feel
free
to
interrupt
and
say.
Actually,
let
me
clarify
that,
or
you
know
something
like
that
so,
but
without
further
ado,
I'm
going
to
go
ahead
and
take
a
look
at
the
release
repo.
So
this
is
in
the
kubernetes
org.
C
This
is
the
release
repo
different
from
sig
release,
which
kind
of
has
the
information
about
what
release
managers
do
so
the
release
repo
is
where
we
keep
all
of
our
tooling.
C
So
the
important
thing
to
note
is
that
we're
currently
still
in
a
transition
from
a
bunch
of
bash
scripts,
basically
to
a
go
tool
called
krell
and
we're
kind
of
in
between
both
and
how
those
interact
with
each
other.
So
a
number
of
the
commands
here
are
based
on
on
bash
scripts
that
either
still
exist
or
existed
in
the
past.
C
So
if
you
actually
look
through
the
git
history
here,
you'll
actually
see
some
of
these
bash
scripts
kind
of
going
away
as
new
krell
commands
come
in,
but
generally
they're,
pretty
straightforward
in
what
they
do.
So
inaugural
is
kind
of
the
the
core
release
machinery
and
that
was
kind
of
the
the.
I
think
the
impetus
for
moving
towards
a
go-base
tool,
because
it
is
a
rather
unwieldy
script
and
you
can
actually
still
see
it.
C
I
believe
here,
so
you
can
look
through
all
of
the
glory
that
is
a
nago
and,
if
you're
not
as
versed
in
bash
as
you
are
in
go,
which
would
be
the
case.
For
me,
this
can
be
a
little
bit
daunting,
but
as
it
transitions
over
to
go,
I
found
it's
very
easy
to
kind
of
implement
small
little
parts
of
this
as
well
as
implement
testing
for
it,
which
is
something
that's
rather
hard
to
do
with
bash.
C
C
What
happens
so,
if
you're
interested
in
in
contributing
to
krell
there's,
obviously
lots
of
issues
here
that
need
to
be
addressed
and
krell
ones
specifically
are
prefixed
with
this
krell
and
brackets
here
so
you're,
obviously
more
than
welcome
to
help
on
some
of
those,
especially
the
ones
that
say,
help
wanted
so,
for
instance,
this
one
is
sub
command
to
retrieve
the
build
candidate,
and
it
looks
like
we're
still
looking
for
help
on
this,
but
it
looks
like
there's
some
more
discussion
needed
so
obviously
take
a
look
at
those
issues.
C
See
if
there's
anything
you'd
like
to
help
out
with
working
on
corel
commands,
specifically
especially
ones
related
to
inaugo,
are
going
to
help.
You
understand
the
release
process
in
general,
because
you're,
obviously
working
on
the
tooling,
that's
actually
executed
when
releases
happen.
Another
thing
I
want
to
point
out
is
this
release
engineering
project
here,
which
has
a
lot
of
these
issues,
prioritized,
which
I
know
sasha
and
tim
and
steven
and
laurie
have
all
been
working
on
getting
these
in
here
and
marco
as
well.
C
So
this
is
also
useful
to
kind
of
see
things
that
are
in
to
do
things
that
are
120
priority
and
then
things
that
are
more
backlogged.
So
obviously
you
can
kind
of
prioritize
things
you'd
like
to
work
on
there,
but
the
primary
thing
that
you'll,
probably
start
doing
as
an
associate
is
start
to
cut
releases.
C
So
a
release
is,
as
you
would
guess,
the
publishing
of
or
the
the
creating
and
publishing
of
kubernetes
binaries,
so
and
kubernetes
images
etc.
C
If
you
want
to
understand
a
little
bit
more
about
when
releases
are
cut
for
a
specific
release,
you
can
always
look
in
the
sig
release
repo
at
the
releases
directory,
and
we
can
look
at
1.20
here
and
you
can
see
actually
when,
when
we're
cutting
specific
releases
here
so
you'll
see,
we
obviously
start
with
alpha
releases
move
to
beta
and
then
rc,
and
then
we
would
finish
up
with
the
official
official
releases
are
also
done
for
for
previous
branches
for
other
releases
in
the
past,
which
we'll
we'll
get
to
in
a
moment.
C
But
official
releases
are
basically,
you
know
ones
that
have
an
actual
semantic
version
that
is
not
post
fixed
with
alpha
or
beta
or
rc.
C
All
right,
so
what
is
the
process
of
actually
cutting
a
release?
So
when
one
of
those
dates
comes
up
and
it's
time
to
cut
a
release,
what
do
we
do
so?
The
first
thing
that
you
do
when
cutting
a
release
is
open
an
issue
and
if
you
actually
go
to
new
issue
here,
you'll
see
that
cutter
release
is
one
of
the
options.
C
So
we
can
take
a
look
at
this
without
actually
creating
one
right
now.
So
this
is
a
really
useful
template
that
pretty
much
tells
you
how
to
cut
the
release
in
and
of
itself.
So
you
obviously
have
the
date
when
it's
scheduled
to
happen.
You
have
the
general
steps
here,
you're
going
to
want
to
put
in
the
krell
version.
C
So
that's
basically,
you
know
which
version
of
the
release
tool
you're
using
which
helps
with.
If
we
run
into
issues
down
the
line,
and
then
we
have
each
of
the
steps
outlined
here
and
the
general
command
for
what
you'd
want
to
do
to
run
those
one
of
the
things
that
I
found
really
useful
when
I
was
first
starting
getting
into
cutting
releases
and
that
sort
of
thing
was
to
look
at
old
issues
like
this
and
you
know
see
what
other
folks
had
done
and
look
at
the
logs
and
that
sort
of
thing.
C
C
C
So
one
thing
to
do,
after
you
finish,
release
make
sure
to
close
out
the
issue,
but
you
can
see
in
general
here
the
steps
that
are
run
so
basically
you
put
in
the
command
that
you're
running
you
put
a
link
to
the
cloud
build
logs
which
are
going
to
spit
out
when
you,
when
you
run
the
command
and
put
the
start
and
the
duration
and
if
it
succeeded,
etc.
C
So
you'll
see
that
what
you
do
usually
is
you
have
a
stage
and
a
release
process.
Once
again,
this
is
stated
in
the
documentation
here
stage
and
release
and
you
have
a
mock
first,
which
is
basically
a
dry
run,
saying
you
know,
let's
make
sure
everything
works
as
expected,
and
then
you
have
the
actual
stage
release.
C
So
when
you
run
these
with
the
no
mock
flag,
you're
going
to
be
prompted
to
say,
do
you
want
to
actually
run
a
release
essentially
and
you'll
say
yes,
I'd
like
to
actually
do
that
and
the
stage
is
going
to
basically
publish
and
create
the
binaries.
The
release
is
going
to
actually
release
them.
C
This
is
very
annoying
all
right.
Well,
we'll
do
this,
instead,
all
right,
so
looking
at
some
of
these
build
logs
here,
if
you
scroll
through
them,
you'll
kind
of
see
all
the
steps
that
are
happening
for
the
various
different
actions
that
we
take.
So
you
know
first
we're
getting
all
the
modules
here
and
something
I
find
really
nice
is
we
actually
have
these
headers
here
which,
if
you
look
through
a
nago,
again
you're,
going
to
see
these
kind
of
specified?
C
Let
me
scroll
down
a
little
bit
and
see
if
we
can
find
something
a
little
interesting.
So
at
the
end,
there's
lots
of
helpful
things
to
tell
you
what
to
do
next.
C
So,
for
instance,
to
release
the
stage,
build
it's
going
to
give
you
the
the
command,
essentially
to
do
that,
so
that
can
be
really
useful
for
for
going
through
releases
as
well,
but
in
general
this
is
the
the
workflow
you'll
get
a
couple
things
that
I
want
to
point
out
that
aren't
necessarily
documented
in
the
branch
manager
handbook
right
now
is,
since
the
vanity
domain
flip.
C
C
So
this
is
some
really
useful
information
and
we
actually
have
a
krell
tool
that
will
do
this
for
us
now,
which
we
used
for
the
the
last
image
promotion.
I
think
adolfo
worked
on
that.
Maybe
so
shout
out
to
you
for
the
great
work
on
that
and
it
will
basically
create
these
pr's
for
you
and
do
the
image
promotion.
C
Sorry
about
that
folks,
this
would
be
in
between
the
the
stage
and
release
kind
of
steps
here,
and
let
me
see
if
I
can.
C
Where
did
I
put
the
example
pr
here
we
go
so
this
is
an
example
of
image
promotion
for
1.19
rc3,
and
you
can
see
this
is
in
the
kate's
dot.
I
o
repo,
which
kind
of
manages
all
of
the
infrastructure
for
for
kubernetes,
and
what
happens
here
is
we
basically
are
just
updating.
B
C
C
Okay,
good,
so
so
that's
that's!
That's
right!
Correct
everything's,
working
as
expected,
yeah,
cool,
okay,
so
basically,
what's
happening
here
is
we're
updating
the
checksums
for
the
different
versions,
which
will
result
in
the
image
promotion.
When
this
pr
is
merged,
you
do
need
to
watch
and
actually
see
that
the
image
promotion
happens.
So
there
is
a
job
that
runs
where,
where
you
can
see
that
I
want
to
pull
up
the
one
the
most
recent
ones
you
can
see.
C
Let's
see
here
the
image
promotion
for
alpha
one,
so
this
one
was
generated
as
you'll
see
with
krell,
so
it'll
actually
create
these
for
you
and
you
can
go
and
see.
You
know
that
the
images
were
promoted
and
that
sort
of
thing,
let
me
actually
show
you
what
that
looks
like.
C
Then
this
will
run
and
you
should
be
able
to
see
that
the
images
are
actually
present,
which
you
can
use
scopia
or
something
like
that
to
inspect
the
images
and
make
sure
the
correct
versions
are
there
and
then
you're
ready
to
cut
a
release?
C
Another
thing
you'll
notice,
is
cutting
the
packages,
so
this
is
the
debs
and
rpms
and
those
are
only
necessary
for
the
official
releases.
So
if
you
actually
look
at
once
again
creating
an
issue.
C
You
will
see,
let
me
go
to
cutter
release.
That'll
actually
notify
this
right,
not
not
requited
not
required
for
pre-releases,
but
when
it
is
required,
you'll
have
to
get
a
google
build
admin
to
be
around
to
basically
cut
those
packages
for
you.
So
you,
basically
once
you
get
past
the
stage
or
once
you
get
past
the
release.
Sorry
you
say
you
know
at
google
build
admins,
please
cut
the
packages
for
me
and
let
me
know
when
you're
you're
ready
to
do
so
and
then
we
follow
up
after
that.
C
C
Tim's
comment
about
the
hardest
bash
understand
all
right
cool.
It
looks
like
just
general
things
thanks
for
dropping
the
links
in
there,
carlos
all
right.
So
that's
the
general
steps
for
a
release,
like
I
said,
looking
through
old
issues,
can
kind
of
show
you
the
the
general
workflow
and
some
of
the
logs
and
what
you
should
expect
to
see
there.
C
Let
me
jump
back
to
the
handbook
here.
I
want
to
stop
before
we
move
on
to
kind
of
the
the
next
section
and
see
if
anyone
has
any
questions
at
this
point
before
I
continue
on.
D
So
we
decide
who
we're
cutting
off
in
version
more
or
less
on
the
flight,
if,
as
I
seen
it
in
the
release,
manager
channel
right.
C
Yes,
so
so
it
kind
of
depends
on
on
the
release.
Usually
I
I
think
this
is
generally
usually
release
managers
will
do
official
releases
and
then
there's
also
some
interesting
things
around
the
first
rc
in
the
alpha.
But
in
general
you
know
it's
folks
who
are
interested
are
able
to
cut
one.
C
So
we
try
to
kind
of
pass
around
their
responsibilities,
both
to
share
the
workload
and
also
to
give
folks
more
experience,
but
but
yeah
in
general,
that
happens
in
the
release,
management
channel
and
there's
also
an
opportunity
for
folks
to
kind
of
shadow
someone
cutting
a
release
if
they'd
like
to
do
that
for
first
or
if
they'd
like
to
someone
to
kind
of
like
you
know,
watch
over
their
shoulder.
C
Essentially
while
they
could
release
those
are
also
options,
but
generally
there's
a
few
folks
that
are
around
to
kind
of
assist
during
a
release
in
case.
If
anything
comes
up.
C
You
know
any
of
the
steps
to
cutting
or
release
a
lot
of
the
tooling
that
goes
around
this
we're
kind
of
spoiled
at
this
point
makes
this
really
easy,
but
it
does
kind
of,
like
you
know,
take
an
actual
human
in
the
loop
at
this
point
still
so
so
there
is
a
few.
You
know
small
complexities
and
sometimes
we'll
run
into
issues
that
have
to
be
corrected
on
the
fly,
but
in
general
I
think
the
workflow
is
pretty
solid.
At
this
point,.
E
I
have
some
questions
that
go
a
little
bit
deeper
into
the
release
process.
I
don't
know
if
this
is
the
right
time
or
maybe
a
little
bit
at
the
end,
sure
you
can
go
ahead
so
in
in
enable
I
see
lots
of
references
to
jenkins,
but
I
don't
think
it's
actually
used,
or
is
it
at
some
point
used
for
anything.
C
I
think
it
depends
on
the
the
specific
reference,
but
in
the
actual
release
process.
I
don't
believe
that
that
jenkins
is
used.
It's
all
cloud
build,
but
I
think
there
are
some
components
of
a
nago
that
make
use
of
jenkins.
I
would
defer
to
sasha
if
you
have
any
more
sausage
cars,
if
you
have
any
more
insight
on
that,
but
I'm
I'm
fairly
certain.
There's
no
jenkins
involvement
during
the
actual
release
process.
F
E
Actually,
I
think
that
was
religious.
My
next
question
I
see
usually
especially
when
artifacts
get
staged.
E
There
is
an
an
identifier
like
this
thing,
I'm
putting
in
the
chat
like
it
says:
9.11
beta,
then
0.92
plus
and,
like
a
I
think,
it's
a
part
of
a
hush
or
something
that's
the
build
id
or
where
does
that
come
from.
C
Yeah,
that's
the
that's
the
build
version,
so
if
it's
not,
you
know
like
if
you're
not
actually
running
a
release,
that
is,
you
know,
making
it
like
beta
dot,
one
or
beta
dot,
zero.
Basically,
the
the
whole
first
part
of
the
semver.
Before
that
final,
like
dot
82
and
the
reference
there
is
the
the
last
version.
Essentially.
C
So
if
you
look
at,
for
instance,
the
alpha
one
release,
let's
take
a
look
at
the
build
version
here,
so
you'll
see
I'm
running
it
on
basically
using
the
the
latest
build
which
is
alpha.zero
right.
So
I'm
cutting
the
alpha.1
release.
So
it's
alpha.0
1624,
that's
just
incremented
with
the
the
number
of
builds
that
happened
so
basically
with
you
know
the
number
of
merges
to
master
and
then
the
hash
is
related
to
the
commit
hash.
C
C
All
right
cool,
so
I'm
going
to
continue
on
and
once
again
I'll
reiterate.
Please
feel
free
to
interrupt
me
or
or
ask
any
questions
at
any
time.
One
thing
I
want
to
touch
on
next.
C
You
know
we
we
have
kind
of
these
like
scheduled
releases
where
we
do
these
steps
I've
described
here,
but
I
wanted
to
talk
a
little
bit
about
kind
of,
like
the
philosophy
of
you
know,
when
a
release
gets
cut
and
and
kind
of
how
that
relates
to
the
rest
of
sig
release
and
especially
the
release
team
for
each
cycle.
C
So
one
thing
you'll
notice
on
every
issue
for
a
new
release.
That's
cut
is
the
snapshot
of
the
test
grid
dashboards,
which
should
be
in
the
steps
up
here.
Yep
screenshot
unhealthy
release,
branch
test
grid
boards,
so
this
is
actually
an
automated
tool
here
that
will
get
these
screenshots
for
you
and
spit
out.
Basically,
the
exact
content.
You
need
to
post
into
the
comment.
C
So
it's
really
really
nice
tooling,
excuse
me,
and
this
is
actually
a
tool
in
krell
or
in
in
the
release
tooling,
so
you
can
just
run
test
grid
snapshot
and
it
will
show
you
how
to
do
that.
But
you
know
if,
if
you've
been
to
a
release
meeting,
you
obviously
know
that
we
have
ci
signal
updates
and
you
know
like
bug,
triage
updates
and
that
sort
of
thing
and
how
do
those
inform
how
we're
actually
releasing?
Why
are
we
even
doing
that
right?
C
So
we
have
our
dashboards
on
test
grid
which
are
basically
running
all
of
these
tests
and
jobs
that
are
telling
us
the
health
of
of
the
current
release
and
previous
release
versions
right.
So
we
don't
want
to
release
something
that
we
know
to
be.
C
C
So
we
have
the
previous
three
versions
here
and
so,
when
you
run
test
grid
snapshot,
you
want
to
make
sure
that
there's
nothing
failing
on
those
branches
and
you'll
see
here
that
we
have
like
a
number
of
flaking
things
here
and
you
kind
of
have
to
use
context
to
understand
whether
it's
okay
to
move
forward
with
a
release
or
not
so
there's
been
times
in
the
past,
especially
with
like
alpha
and
beta
releases,
where
we've
even
had
a
failing
job
on
master,
but
where
you
know
we
communicated
with
ci
signal
or
some
of
the
different
cigs
and
understood
exactly
what
that
meant
and
felt
comfortable
moving
ahead
with
that.
C
Obviously,
as
we
move
towards
an
official
release
at
the
end
of
a
cycle,
it's
very
troubling.
If
we
have,
you
know
a
failing
job
or
something
like
that.
So
understanding
the
health
of
the
release
informs
whether
we
move
forward
with
it
and
if
you
ever
have
any
questions
I'm
around
that,
because
even
no
matter
how
experienced
you
are,
if
you
don't
have
the
context
around,
why
something
is
flaking
or
failing,
maybe
important
to
reach
out
to
ci
signal,
for
instance,
and
say
hey.
C
I
noticed
that
we
have
a
failing
job
on
on
master
blocking.
Are
we
okay
to
move
forward
with
the
release
like?
What's
the
context
around
that,
and
you
can
also
obviously
ping
release
managers
as
well,
but,
like
I
said,
that's
that's
more
relevant
for
official
releases
when
we're
saying
you
know,
this
is
a
known,
good
release
that
we're
putting
out
there.
We
shouldn't
have
any
any
failing
jobs
in
those
situations
all
right.
So
I
wanted
to
move.
C
C
But
as
you
move
into
a
release
manager,
role,
branch
management
in
general
becomes
important
right.
C
So
if
you
aren't
familiar
with
kind
of
like
the
kubernetes
strategy
of
releases
and
branches
and
that
sort
of
thing,
every
major
release-
or
I
guess
minor
release
in
this
case-
has
its
own
branch
right,
so
you'll
see
release
for
for
every
dot.
C
You
know
miner
here
so,
for
instance,
1.19
is
our
most
recent
release
and
then
master
is
obviously
the
the
most
recent
commits
are
going
into
that
and
during
the
release
cycle
for
a
current
release,
we
will
cut
a
branch
and
keep
it
up
to
date
right.
So,
if
you've
ever
seen
those
messages
in
slack
that
are
like
branch
fast
forward,
complete,
probably
from
carlos
over
the
1.19
release
he
he
was
in
charge
of
doing
that.
C
Basically,
what
that's
saying
is
when
we,
when
we
cut
the
release
branch
during
a
release
cycle,
we
are
going
to
continue
to
keep
that
up
to
date
with
master
until
we
actually
cut
the
official
release
there.
So
1.19.0
in
that
case,
so
essentially
every
time
something's
merged
to
master.
We
want
to
you,
know
fast
forward
with
that
and
keep
those
in
sync
until
the
release
happens.
C
Now,
after
release
happens,
obviously
old
versions,
don't
pick
up
everything,
that's
in
a
new
version.
So
if
you
want
something
to
be,
you
know
included
in
an
old
version.
Then
you're
gonna
have
to
cherry
pick
that
back
right,
so
we
merge
it
to
master,
and
then
cherry
pick
cherry
pick
it
onto
an
older
branch
and
that's
essentially
how
new
content
gets
in
for
for
patch
versions
of
old
releases.
C
So
another
part
of
the
release,
manager's
role,
is
to
manage
cherry
picks.
So
I'm
going
to
see
here
if
we
have
any
explicit
cherry
picks
here.
I
saw
some
tagging
on
some,
but
we
can
look
at
the
cherry
pick
labels
here
and
just
pull
some
out
all
right.
So
we
we
don't
want
cherry
pick
approved
but
I'll
go
ahead
and
take
a
look
at
anyway.
C
So
you'll
see
that
there's
none
open
with
cherry
picker
proof
because
generally
cherry
pick
approve
is
the
last
thing
that
happens,
but
we
can
go
ahead
and
we
can
look
at
1.19
update.
So
this
is
from
stephen.
So
this
is
a
a
good
one
to
look
at
here
all
right,
so
this
was
after
the
1.19
release.
Happens
and
so
updating
to
a
new
go
version,
particularly
if
it
you
know
include
some
security,
security,
vulnerability
fixes
or
something
like
that
could
be
something
that's
a
candidate
for
for
back
porting.
C
So
after
1.19.0
came
out,
there
are
updates
to
master
to
update
to
go
1.15.2
and
you'll
see.
This
is
the
original
pr
to
do
that.
Update
and
this
one
may
not
be
the
best
example,
because
I
don't
think
this
is
actually
generated
with
the
cherry
pick
tooling,
but
it
so
kind
of
illustrates.
So
essentially
what
happens
with
any
sort
of
cherry
pick
to
an
old
branch.
C
It
goes
through
its
normal
review
by
sigs
right.
So
typically,
the
people
who
reviewed
the
first
pr
that
went
into
master
are
going
to
also
be
tagged
for
review
on
something
that
is
going
to
be
merged
into
an
older
branch,
and
so
our
role
really
doesn't
come
in
unless,
if
you're
involved
with
the
sig
or
the
changes
that
are
being
made
until
after
a
a
pr,
that's
a
cherry
pick
already
has
a
proof
and
looks
good
to
me
on
there.
So
essentially,
what
they're
saying
is
all
right.
We
have.
C
You
know,
as
as
domain
experts
here
have
said,
this
is
something
that
is
valid
to
go
in.
This
is
good
code.
I
reviewed
it.
You
know
I'm
an
approver
for
for
this
owner's
file
and
now
they'll
tag
their
release,
managers
on
it.
So,
let's
see
if
steven
this
might
have
had
release
manage
tagged
from
the
beginning
yeah.
So
this
isn't
a
great
example,
but
let
me
go
back
and
see
this
one
here.
If
you
see
it
with
automated
cherry
pick,
let
me
go
back
one
more
time.
C
Automated
cherry
pick,
this
format
generally
indicates
that
it
was
actually
created
by
the
release
tooling.
So
this
is
a
cube.
Ctl,
bug
and
you'll
see
that
eddie
opened
this
and
assigned
sean,
which
he
is
a
an
owner
for
this
code.
C
So
he
added
the
looks
good
to
me
and
approved,
and
then
eddie
gave
the
kubernetes
release
manager
tag
here
and
essentially
what
we
do
is
come
through
here
and
tim
actually
approve
this
one
and
if
you're
knowledgeable
of
you
know
what
what
this
change
is
here,
then
you
go
and
you
can
actually
review
the
code
and
say:
okay,
this
makes
sense
as
something
to
be
cherry-picked
to
a
previous
release
branch.
C
C
So
really
our
job
is
to
say
is
this
something
that
should
be
cherry-picked
right
and
if
it
is
all
you
do
to
actually
allow
this
to
be
merged,
is
go
into
the
labels
and
you'll
see
it's
already
here
and
if
you
put
the
cherry
pick
approve
label
it's
going
to
remove
this,
do
not
merge
cherry
pick
not
approve,
and
essentially
you
know,
tide
is
going
to
say.
Okay,
now
it's
ready
to
go
in
so
generally
for
a
pr
you
have
to
have
a
proven
looks
good
to
me.
C
It's
important
right
to
take
regular
kind
of
passes
through
cherry
picks
that
are
open
because
folks
are
reliant
on
us
for
those
to
be
merged,
and
that's
something
we've
been
talking
about
recently,
because
there
is
some
sort
of
you
know
like
disorganization
sort
of
with
with
merging
cherry
picks,
because
they
are
just
kind
of
pr's
that
they
get
release
managers
tagged
on
them,
so
you
know
who's
in
charge
of
doing
that
can
be
kind
of
fuzzy.
C
But
recently
we've
talked
about
you
know
having
like
periodic
scrubs
like
a
zoom
call
where
we
go
through
and
maybe
discuss
some
of
the
things,
because
there's
sometimes
opportunities
where
a
cherry
pick.
May
you
know
it
may
be
hazy
whether
it
should
be
included
or
not,
but
that
is
the
general
process
for
it.
That's
how
cherry
picks
work.
If
something
is
cherry
picked
back
to
an
old
release
branch,
then
in
the
next
patch
version
it
will
be
included
in
the
release.
C
Obviously,
all
right
does
anyone
have
any
questions
on
the
cherry
pick
process
or
kind
of
the
release,
manager's
role
in
that
before
we
continue
on.
A
I
just
have
a
a
small
comment
like
when
the
they
have,
like
a
cherry
pick
for,
for
example,
for
119.
We
check
if
the
same
cherry
peak
exists
for
the
older
brains,
in
this
case
118
and
117,
and
if
they
have
like,
for
example,
in
the
past
three
releases,
we
only
apply
the
label
if
both
cherry
peaks
have
the
looks
good
to
me
and
the
proof,
because
then
we
want
to
merge
in
the
all
three
branches
at
the
same
time,
to
have
the
same
fix
across
all
the
brains.
A
If,
for
example,
160
or
117,
there
is
no
approval,
looks
good
to
me.
We
try
to
come
talk
to
the
the
approvers
from
their
other
chairpeaks
and
ask
them
to
review
that
one
before
managing
their
waters
as
well.
So
whenever
all
the
cherry
peaks
are
are
good,
then
we
merge
in
this
case
this
in
these
three
release
branches
as
well.
C
That's
a
great
point,
carlos
thanks
for
bringing
that
up
and
one
thing.
A
C
To
that
is
you
know
not
everything
is
going
to
be
cherry,
picked
to
every
active
branch
right,
so
branches.
You
know
rotate.
A
C
Out
of
support,
but
just
because
something
in
support
obviously
doesn't
mean
it's
gonna
receive
a
cherry
pick.
So
a
great
example
of
that
is
a
new
feature
being
added
in
1.19
and
then
you
know,
a
bug
is
discovered
in
it
and
then
we
cherry
pick
back
to
1.19.
Obviously
that
feature
doesn't
exist
in
earlier
branches,
so
there
will
be
no
cherry
pick
there,
but
if
it
does,
cars
is
exactly
right.
You
know
you
don't
want
to
have.
C
You
know
approval
to
go
to
one
branch
and
not
others,
because
that
could
cause
some
conflicts
all
right.
Any
other
questions
on
the
cherry
pick
process.
C
All
right,
so
we
have
about
five
minutes
here
left,
so
I
want
to
quickly
touch
on
branch
management
once
again.
This
is
something
that
moves
more
towards
the
release
manager
rather
than
release
manager,
associate
role.
C
But
obviously
this
is
something
that
you
want
to
learn
about
as
an
associate,
so
you
can
eventually
take
on
these
responsibilities
as
well,
so
I
definitely
want
to
touch
on
it
and
to
be
totally
transparent,
carlos
and
sasha,
and
some
others
have
run
a
lot
more
of
this
more
than
I
have,
but
I
have
general
familiarity
with
it.
You
know
and
have
reviewed
things
related
to
it.
It's
also
related
to
some
of
the
sig
release
roles
on
the
release
team,
so
it's
relevant
in
that
regard
as
well.
C
So
obviously
things
you
need
to
do.
We
talked
about
branch
fast
forwarding
to
be
able
to
branch
test
forward.
You
need
to
be
able
to
create
a
branch,
so
here's
some
information
about
branch
creation,
important
thing
to
note
here
is
we.
We
changed
last
release
when
the
actual
coming
release
branch
gets
created,
which
obviously
affects
how
things
are
fast
forwarded
and
that
sort
of
thing,
but
you
can
imagine
you,
know,
cutting
it
too
early.
C
It's
kind
of
just
extra
work
for
no
reason,
because
if
you're
fast
forwarding
to
keep
up,
then
you
know
you're,
basically
matching
master
exactly
so.
If
you
have
more
questions
about
that
feel
free
to
reach
out
with
those
other
things
that
need
to
happen
which
I'm
particularly
familiar
with
the
test,
infra
configuration.
C
So
we
looked
earlier,
you
know
at
the
master
blocking
branches.
Once
we
have
a
a
new
release
branch,
we
want
to
start
having
jobs
that
run
specifically
on
that
right.
So
for
a
while
or
for
the
you
know,
last
third
or
so
of
a
release
cycle.
You
should
see
that
the
most
recent
branch
boards
are
going
to
match
that
of
master
blocking
in
terms
of
if
something's,
failing
on
master
blocking
we'd
assume
it's
also
failing
on
on
the
coming
release
branch
as
well
once
again,
because
that's
being
fast
forwarded
right.
C
So
it's
testing
the
same
code,
but
in
order
to
actually
create
these
branches
and
these
new
dashboards,
you
have
to
go
into
test
infra,
which
I
assume
most
folks
are
pretty
familiar
with.
But
basically
this
is
where
our
configuration
for
different
jobs
that
run
go
and
also
how
they're
reflected
on
test
grid
dashboards.
C
So
it
always
takes
me
some
time
to
find
exactly
where
these
are
but
jobs.
I
think
it's
kubernetes
and
sig
release
so
release
branch
jobs.
This
is
primary,
primarily
what
you're
going
to
look
at
and
if
we
actually
see
these.
So
these
are
the
different
branches
that
are
in
support
right
now
and
so
you'll
see
that
essentially
they're
just
the
different
job
flavors
for
these
different
branches,
and
I
want
to
note
how
these
actually
get
generated.
C
C
You
can
see
me
messing
around
with
some
stuff,
but
I'm
trying
to
find-
and
I
probably
should
just
look
in
the
actual
yeah
I'll
look
for
the
pr.
But
essentially
what
you
do
is
you
run
the
release
branch
generation
to
be
able
to
cut
these
new
or
generate
these
new
types
right
and
cycle
in
right,
because
once
we
add
a
new
dashboard
for
for
a
new
release
version,
then
we're
going
to
drop
off
an
old
one.
That's
no
longer
in
service.
So,
let's
see
if
we
can
just
find.
C
A
pr
okay,
these
are
actually
all
going
to
be
from
that
okay,
so
I
can
point
you
to
pr
later
on
about
which
actually
updates
these,
but
essentially
these
are
generated
for
each
of
the
different
branch
jobs
and
I
believe
which
I
should
have
that's
earlier.
Reling,
so
config,
forker
and
config
rotator
are
kind
of
the
things
responsible
for
this.
So
you'll
see
that
some
of
the
job
configurations
here
are
going
to
have
fork
per
release
in
them.
C
So
yeah
for
per
release.
True,
so
if
you
look
through
all
the
different
job
configurations
in
test
infra,
if
it
has
the
fort
per
release
annotation,
that
basically
means
that
we
want
to
generate
a
different
flavor
of
this
job
for
each
release,
branch
right
and
run
it.
Against
those
I
mean
we
have
tooling,
obviously
config
forker
to
do
that
and
so
that'll
basically
spit
out
those
files,
those
yaml
files.
C
We
were
looking
at
earlier,
which
have
the
generated
jobs
for
each
release,
branch
that
are
also
on
unmaster
blocking,
so
that's
kind
of
how
we
get
those
and
that's
how
we,
you
know
see
what
our
signal
is
on
on
old
branches,
which
then
inform
you
know
when
we
cut
releases,
as
I
mentioned
earlier,
all
right
trying
to
see
if
there's
anything
else
that
we
could
cover
here
in
the
last
minute
or
so
variants
are
important.
So
you
saw
those
different
cubekins
image
bumps
and
test
infra
as
well.
C
So
if
you
look
at
the
variants
that
we
have
here,
basically,
we
need
to
keep
up
variants
for
each
release
branch.
So
that's
saying
you
know,
have
the
have
the
code
for
this
release
branch,
basically
in
this
cubekins
image
that
we
use
to
run
our
jobs,
so
updating
those
to
be
consistent
with
each
of
these
is
important.
C
One
other
thing
I
want
to
touch
on
which
isn't?
Actually,
I
don't
think
in
the
release?
Manager
handbook
is
version
markers.
So
if
you
see
something
like
stable,
so
this
is
stable.1.18
but
you'll
see
things
like
stable
one,
stable,
two
or
latest.
Basically,
that's
saying
you
know
it's
corresponding
to
the
release
branch.
So
it's
an
agnostic
way
to
talk
about.
You
know
x,
release
releases
back
of
kubernetes,
so
you'll
see
in
some
jobs
that
it
uses.
C
C
See
if
we
can
find
this
real
quick,
so
basically
the
version
markers
tell
you
which
version
to
download
for
different
release
jobs.
So
this
is
is
part
of
the
kate's
extract
or
extract
kate's
script.
That's
in
test
infra
or
it's
not
scripted.
It's
go
code,
but
essentially
here
you
can
see
that
we're
getting
the
latest
version.
So
these
these
different
jobs
they
pull
based
on
kind
of
which
version
it
is,
which
means
you
don't
have
to
update
them
right.
C
Each
time
we
cut
a
new
release,
you
can
just
say
get
stable
one.
Then
it
will
look
for
the
version
marker
for
stable
one
which
you
know
could
be
something
like
1.19.3
rc0
and
those
get
automatically
updated.
So
we're
basically
changing
what
the
url
gives
you
back
when
you
curl
for
it,
rather
than
you
know,
updating
the
job
to
point
at
a
specific
one,
each
time,
which
means
that
we
can
use
the
latest
kubernetes
code
or
the
latest.
C
You
know
stable
one
code
or
latest
of
the
coming
release
or
something
like
that
in
the
different
jobs.
If
you
have
more
questions
about
that,
that
was
kind
of
a
haphazard
way
to
explain
it,
so
please
feel
free
to
reach
out.
So
hopefully
this
was
kind
of
a
fire
hose
of
information
here,
and
I
presented
it
in
that
way
so
that
we
can
kind
of
say,
okay,
those
things
stuck,
those
things
didn't.
We
need
more
clarity
on
them,
so
I
would
definitely
really
appreciate
it
and
I'm
sure
others
would
as
well.
C
If
you
have
questions
that
came
out
of
this
call,
if
you
could,
you
know,
let
me
know
or
let
marco
know
or
just
post
them
in
release
management
so
that
we
can
kind
of
create
smaller,
condensed,
videos
or
even
just
you
know,
write-ups
about
how
different
things
work
so
that
they
can
be
more
consumable
for
new
folks
and
more
consumable
for
folks
like
yourselves,
but
before
I
sign
off.
I
definitely
want
to
see
if
there's
any
questions
I
can
answer
here.
C
Obviously
anyone
feel
free
to
to
drop
off
if
you
have
other
things
to
get
to.
G
Yeah
I've
got
a
quick
question
and
have
some
time
to
stick
around,
so
I
definitely
have
been
involved
with
the
release
manager
associates
for
quite
some
time
now.
I
kind
of
took
a
step
back
for
a
job
transition
and
then
now
I'm
trying
to
get
back
more
involved
and
engage,
and
I
see
all
these
different
areas
but
like
where
am
I
most
effective?
Do
I
just
go
into
the
backlog?
Is
it
in
slack?
Do
I
shadow
people
on
you
know
cutting
branches?
C
Yeah,
that's
a
great
point.
Jim
I'd
say
like
one
of
the
things,
that's
been
really
helpful
for
me
and
kind
of
how
I
I
think
I
you
know
it
accelerated
pretty
fast
through
understanding.
Some
of
the
stuff
is
just
monitoring
a
bunch
of
pr's
and,
seeing
you
know
oh
okay,
like
why
are
we
bumping
this
image
here?
Why
are
we
you
know
changing
how
this
command
works?
So
obviously
the
release
repo
is
relevant
for
that
release.
Managers
get
tagged
on
on
image,
bumps
and
different
things.
C
So
you
know
just
setting
up
notifications,
for
that
can
be
really
useful
things
that
I've
found
are
useful,
especially
when
I'm
time
constrained
is
you
know,
taking
on
some
responsibility
of
a
issue
on
the
release
repo
for
krell
or
something
like
that,
because
those
are
less
time
sensitive,
right,
they're
not
like
scheduled
for
for
a
release
or
something
like
that,
so
those
can
be
a
good
way
to
be
involved.
C
You
know
when
you
are
time
constrained
and
then
the
other
thing
I
mean
just
like
you
mentioned
just
reaching
out
to
folks
and
being
like
hey.
Why
are
you
doing
this?
No
one's
gonna
be
upset
about
you
like
questioning
it
and
there's
definitely
been
times
where
someone
is
like
hey.
Why
are
you
doing
this
and
I'm
like?
I
have
no
idea.
You
know
like
this
is
just
what
we
do
and
that's
obviously
not
a
good
way
to
ever
be
approaching
any
steps
we're
taking
especially
around
the
release.
C
So
please
feel
free
to
just
question
people,
and-
and
you
know
well
me
or
others
will
be
very-
you
know
happy
to
get
those
questions.
A
great
example
of
that
is
that
release
manager
kind
of
document
that
we
went
through
that
that
content
notice
about
things
being
up
out
of
date.
Actually
I
just
updated
something
jim
I
saw
you
have
made
a
a
big
update
through
that
a
few
months
ago,
so
like
stuff
like
that,
obviously
super
helpful
is
clear.
C
E
Yeah,
for
me,
I'm
kind
of
on
the
other
side
of
the
release
of
the
serialized
activities.
I
would
like
to
get
more
familiarized
with
the
testing
side
of
it,
so
I've
never
been
a
part
of
the
ci
signal
team
or
being
near
to
it.
So
I'd
like
to
to
get
more
familiar
with
that.
So
what
would
you
suggest.
C
Yeah,
so
so
that's
probably
the
direction
that
I
most
came
in
to
sig
release
from.
So
I'm
certainly
passionate
about
that
one
of
the
things
that
would
be
really
useful
there
and
one
of
the
things
that
helped
me
actually
understand
what
was
happening
in
all
these
releases
was
seeing
when
jobs
were
failing.
So
when
you
see
a
a
you
know
like
an
issue
open,
it's
like
failing
test
or
something
like
that.
You
know
investigating
those
and
looking
through
the
logs
are
going
to
tell
you
a
lot
about
how
the
releases
work.
C
So
every
job
is
either
you
know
pulling
in
a
release
or
creating
a
release
or
creating
a
build
or
something
like
that.
So
everything
kind
of
touches
the
release
process
right.
We
need
to
inform
jobs
where
to
get
the
latest
code
or
we
need
to
you
know
actually
be
producing
that
code.
C
So
when
we
looked
at
tests
and
furthers
there's
the
build
jobs
there,
which
will
show,
you
know
how
we
build
things
and
push
new
versions
and
where
they
go,
what
bucket
they
live
in
that
sort
of
thing
and
then
other
jobs
like
the
the
one
I
was
just
showing
before
I
stopped
sharing.
My
screen
is
pulling
in
a
specific
release
version,
so
you
know
looking
at
that
and
then
finding
out
where
that
code
came
from
and
then
actually
troubleshooting
the
test.
That's
failing!
C
Those
are
great
ways
to
understand
how
different
testing
works
and
something
that
I
did
as
part
ci
signal
which
this
you
know.
This
may
not
be
something
that
you
know
folks
want
to
do.
Who
aren't
in
that
work
already,
but
writing
like
a
short
paragraph
about
what
a
job
does
like
you
know
the
steps
like.
Oh
it
goes
and
pulls
this
release
down,
and
then
it
runs
these
tests
with
these
annotations
on
them
and
that
sort
of
thing
that
really
helped
me.
C
You
know
understand
like
how
everything
was
working
together
exactly
and
so,
if
that's
something
you're
interested
in
number
one
I'd
say
it's
a
great
like
personal
exercise
and
number
two.
You
know
ci
signal
folks
really
appreciate
that
as
well,
and
so
you
know
any
documentation.
There,
especially
is
I'm
sure,
really
useful
and
I
think
we're
a
little
light
on
kind
of
like
the
documentation
around
testing
in
the
release
manager
handbook.
So
I'm
sure
there's
be
there'd,
be
an
opportunity
to
add
some
documentation.
There
yeah.
E
So
when
we
get
those
emails,
letting
someone,
I
guess
us
know
that
some
of
the
tests
and
ca
and
secret
lists
are
failing.
That's
our
responsibility
or.
C
So
actually
like
fixing
them
is
not
really
our
responsibility.
I
guess
you
know
it
kind
of
goes.
Ci
signal
is
responsible
for
responding
to
those
emails
and
going
seeing
what's
wrong
and
making
sure
someone
addresses
them,
and
the
person
who
addresses
them
is
usually
someone
in
a
cig
as
a
release
manager.
C
Sometimes
the
failure
is
our
responsibility
so
like
if
we're
not
publishing,
builds
or
something
like
that
that
be
something
that
I'd
say
falls
under
sig
release,
but
even
if
you're,
it's
not
like
your
explicit
responsibility
as
a
release,
manager
or
release
manager
associate
obviously
jumping
in
there
is
a
great
way
to
just
understand.
More
so
I
mean
you
can
assign
any
issue
to
yourself
right
on
kubernetes
and
try
and
fix
a
bug,
and
that,
probably
you
know,
will
will
touch
release
in
some
way.
C
One
thing
I
want
to
mention
here:
it's
in
the
the
chat
from
max,
and
I
appreciate
you
bringing
that
up.
Sasha
and
I
gave
two
talks.
This
summer,
slash
fall,
I
guess
one
at
kubecon,
china
and
one
for
kubecon
eu
that
kind
of
touch
on
both
the
sig
release
in
general
and
the
different
roles
in
it
and
then
sasha
especially
led
a
talk
on
release
engineering.
I
think
that
was
the
second
one
we
we
recorded
them.
I
think
out
of
order,
in
which
case
they
were
actually
broadcast.
C
C
Max
cool:
well,
there's
not
too
many
other
questions.
I
I'm
gonna.
Let
marco
kind
of
sign
us
off
here,
but
I
really
do
would
love
to
hear
specific
things
that
you'd
like
to
see
examples
of
there
are
some
some
youtube
videos
actually
of
going
through
an
actual
release,
so
you
can
actually
watch.
I
know
specifically
right
when
I
became
an
associate.
C
I
watched
sasha
do
one,
I
believe,
there's
a
youtube
video
of
that
which
some
of
that
may
be
out
of
date,
but
it
gives
you
a
general
idea,
but
if
you'd
actually
literally
like,
like
curated
videos
or
or
curated
walkthroughs
or
that
sort
of
thing,
that'd
definitely
be
something
I'd
be
interested
in
working
on.
I
know
marco
is
really
leading
the
charge
in
that.
So
I
appreciate
that
marco.
So
please
feel
free
to
give
any
of
us
feedback
on
on
things
that
we
can
do
to
make
the
onboarding
process
better.
B
Okay,
so
we
are
coming
to
the
end.
I
would
first
like
to
thanks
a
lot
to
daniel
for
stepping
up
to
do
this
session,
because
it
was
great-
and
I
hope
that
all
of
you
liked
it-
and
I
want
to
thank
all
of
you
for
joining
us
today.
If
you
have
any
other
questions
or
any
other
feedback
or
is
there
anything
you'd
like
to
see
from
us,
please
let
us
know
in
release
manager's
channel
or
feel
free
to
ping
me
in
direct
messages,
if
you
prefer
that
way.