►
From YouTube: Kubernetes Release Engineering 20200901
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
Hello,
hello
today
is
september
1st.
This
is
the
bi-weekly
release
engineering
sub-project
meeting
for
sig
release.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people
all
right.
So
we've
got
a
few
things
on
the
agenda,
I'm
going
to
sort
of
speed
through,
so
we
have
time
to
discuss
some
other
stuff
towards
the
bottom
of
the
agenda.
A
But
if
you
have
questions
comments
and
concerns,
let
me
know
so:
we've
got
a
few
things
in
flight,
our
things
that
are
coming
up,
slash,
inflight,
the
first
of
which
is
the
final
116
release,
which
is
scheduled
for
this
wednesday
or
tomorrow
september.
2Nd
again
it
will
be
the
final
released
for
116,
at
which
point
we
will
start
soon
afterwards,
decommissioning
jobs
and
and
whatnot.
A
A
Okay,
sasha:
are
you
fine
to
take
that
one?
Do
you
want
to
hand
it
to
someone
yeah
call
us
and
myself
will
take,
take
it
tomorrow.
Okay,.
A
A
Okay,
next
up
is
the
second
120
alpha.
It's
120
alpha
1..
We
need
a
date
for
this.
This
is
something
new
to
the
process
or
recent
to
the
process
where
we
tried
to
cut
a
new
alpha
for
the
for
the
primary
branch
soon
after
the
previous
release.
So
119.0
went
out
last
last
week
and
we
want
to
make
sure
that
we
refresh
some
of
the
content
that
is
on
120,
especially
given
that
the
branch
reopening
policy,
the
branch
reopening
plan
is,
is
currently
being
executed.
A
A
So
the
tldr
of
the
plan
is
the
we're
going
to
handle
failing
test
fixes
first,
followed
by
a
second
step
of
dock
and
cleanup
work,
followed
by
low
risk
bug,
fixes
followed
by
bug,
fixes
that
may
be
higher
impact
and,
finally,
the
features
or
deprecations
for
for
the
for
the
120
release,
which
would
be
considered
to
be
resuming
regular
development.
A
So
right
now,
over
the
last
over
the
release.
So
thursday,
through
the
weekend
and
monday,
the
failing
tests
have
all
the
failing
test:
prs
have
all
merged
the
dock,
and
cleanup
prs
have
merged
the
low
risk,
bug
fixes
have
merged,
and
I
forklifted
some
of
the
open
bug
fixes
into
the
milestone
as
of
yesterday.
A
A
At
this
point,
we're
going
to
be
requesting
that
the
sigs
area
component
leads
start
to
triage.
That
queue
make
sure
that
everything
is
reviewed
and
approved
appropriately,
and
I
think
that
we're
going
to
we
should
discuss
what
we
want
to
do
with
the
120
milestone.
I
have
I.
I
feel
that
we
should
leave
the
milestone
restriction
on
for
a
little
bit
just
ensure
things
settle
out,
but
I
want
to
take
some
opinions
on
that
as.
A
B
A
B
Historically,
the
disadvantage
has
been
called
out
as
it
hinders
velocity,
but
having
velocity
without
quality
isn't
necessarily
a
good
thing
exactly.
I
think
we
could
even
ask
the
the
other
side
of
that
question.
Why
remove
it?
Having
ci
signal
be
good
for
two
days
or
so,
as
steven
mentioned,
isn't
as
good
as
keeping
it
for
the
cycle.
A
So
yeah
that
was
so
yeah
so
towards
the
end
of
last
cycle.
That's
kind
of
what
I
was
suggesting
and
I
didn't
know
if
that
was
being
too
heavy-handed
or
not.
I.
B
Am
just
starting
hearing,
it
say
what
I
would
guess
that
people
just
aren't
hearing
it
the
we
always
have
communication
issues
on
these
things
and
the
desire
to
keep
ci
clean
and
how
we
would
go
about
doing
that
and
the
trade-off
versus
velocity
being
what
we
think
of
as
a
positive
thing.
B
I
can
agree
with
keeping
it
in
place
and
having
so
the
milestone,
maintainers,
there's
like
what
is
it
200
or
300
versus
two
or
three
thousand
people
who
can
simply
commit
so
that
that
changes
the
velocity,
but
it
whittles
things
down
the
audience
of
people
to
whom
we
need
to
talk
about
ensuring
quality
and
and
reacting
to
quality,
going
down
versus
things
just
continually
streaming
in.
I
think
it
kind
of
it
does
a
better
job
of
federating,
the
ownership
of
quality
to
people
who
are
entrusted
to
actively
do
that.
B
B
And
there
the
question
is:
how
do
we
actually
communicate
with
them?
I
mean
we've
got
the
emails
that
say:
action
required
decay,
dev
we've
got,
we've
got
things
out
to
the
the
chairs
and
tech
leads
list
through
contributes,
but
I
I
do
see
hints
of
signs
that
people
haven't
read
or
seen
or
understood
those.
D
A
A
note
taker
for
this
great
sorry,
lori.
C
No
worries
no
raise
it's
a
good
point
to
make,
so
you
know
it
might
just
be
like.
Maybe
we
need
to
let
this
idea
simmer
for
a
bit,
what
we'd
like
to
have
these
milestone,
maintainers
do
or
being
thinking
about.
C
You
know
if
the
problem
has
been
historically
that
we
have
framed
plans
around
velocity
and
we
we
want
to
see
a
slightly
different
approach
going
forward
and
think
then
what
is
the
message
basically
and
then
just
as
an
aside,
I'm
reaching
out
to
the
sig
chairs
right
now,
just
to
have
them
look
at
their
kept,
so
this
is
sort
of
sort
of
tangentially
related,
but
it's
just
like
to
say
that
I'm
doing
some
outreach
already
to
the
chairs
and
tech
leads,
and
so,
if
we
want
to
actually
have
them
look
at
milestone,
maintainer
work.
C
C
A
Let's,
let's
maybe
segment
it
out,
so
the
the
message
isn't
buried,
horrible,
not
to
say
yeah,.
D
A
To
say
that
it
would
be,
but
just
to
make
sure
that
it's
it's
crystal
like
we.
A
We
have
two
levers
here
and
one
is
in
place
right
now,
which
is
the
the
milestone
restriction.
The
second
arm
of
that
is
that
the
milestone
maintainers
group
is
a
sig
release
owned
github
team
right.
So
I
I
think
it's
definitely
worthwhile
and
and
should
be
required
of
us
to
look
back
over
what
we
consider
a
milestone
maintainer
to
be-
and
I
think
it's
absolutely
within
our
right,
given
where
the
group
is,
is
housed
to
consider
removing
or
adding
more
people
to
to
milestone
maintainers.
A
I
think
something
to
note
about
milestone.
Maintainers
is,
I
think,
classically
people
have
added
sig
chairs
and
tech.
Tech
leads
as
milestone
maintainers.
Those
are
not
the
only
people
who
can
maintain
milestones
right,
so
so
people
who
are
reviewers
approvers
in
those
areas
based
on
you
know,
based
on
what
a
sig's
requirement
for
becoming
a
milestone,
maintainer
and
their
sig
is,
should
be
added
right.
A
I've
seen
you
know
in
some
of
the
messages
about
draining
the
queue
I've
seen
prs
fly
by
with
people
updating
their
milestone,
maintainers,
but
I've,
probably
I've
primarily
seen
those
updates
to
be
adding
chairs
or
technical
leads
that
were
not
there
before,
as
opposed
to
adding
people
who
are
not
chairs
or
technical
leads.
A
So
I
think
we
could
put
a
finer
point
on
that
and
overall
this
sounds
like
an
entirely
other
topic
that
we
probably
should
discuss
in
sig
release.
A
A
Okay,
any
other
thoughts
before
we
move
on.
A
Okay,
all
right
so
dependency
updates.
A
We've
got
a
few
recently,
the
first
of
which
or
not
the
first,
but
the
the
most
imminent
one
coming
is
the
go
115
one
is
a
security
fix
that
is
supposed
to
land
for
today.
So
I'm
going
to
be
watching
the
the
golang
list
for
that
once
that
starts
up
I'll
get
started
with
the
cube
cross
images
and
all
that
good
stuff
start
rolling
that
over.
A
That's,
I
don't
given
that
it's
primarily
security
release.
I
don't
see
too
many
problems
cropping
up
from
that,
but
I'm
gonna
just
knock
on
wood,
so
that
should
be
coming
soon
into
the
120
branch.
The
next
up
is
cri
tools.
Sasha.
Do
you
want
to
talk
a
little
bit
about
that.
E
D
Yeah
so
last
week
we
cut
the
new
version
of
cry
tools
and
they
are
already
merged
into
cube
kk
as
well.
So
marco
did
that
and
caller
supported.
So
we
used
the
github
2
gcs
tool
from
k,
release
just
link
it
here,
which
is
a
little
utility
to
put
binary
artifacts
from
github
to
gcs,
and
the
main
intention
is
to
not
hit
api
rate
limiting
limiting
when
testing
in
our
infrastructure.
D
So
that
way
we
have
all
of
the
binary
artifacts
also
available
in
gcs,
which
is
pretty
cool
and
yeah.
It
requires
some
manual
copying
around
from
github
to
gcs,
and
I
think
we
would
like
to
compile
a
list
or
some
documentation
around
it,
which
projects
are
actually
handled
in
that
way.
So
we
have
cri
tools
and
we
also,
I
think
we
also
have
cni
plugins
right,
but
we
could
think
about
probably
other
tools
and
binaries
which
have
to
be
put
into
google
cloud
buckets.
A
Right
so
a
few
notes
on
that
first
off.
Thank
you
for
jumping
on
that
and
thank
you,
marco,
for
working
on
the
pr
I
did
notice.
As
I
was
doing,
the
cni
updates
that
there
may
be
some
references
that
are
not
updated
in
kubernetes
kubernetes
for
cri
tools
so,
and
I
think
primarily
they
got
missed
because
they're
not
in
the
dependencies.yaml.
A
So
it's
possible
that
a
new
reference
to
cri
tools
was
added
and
it
wasn't
added
to
the
dependencies.yaml
as
well.
So
I
would
do
a
search
for
117.0.
I
think
in
the
code
base
cri
and
117
0.
I
think
that's
it
might
be
in
cluster
if
you
do
a
hound
search
or
if
I,
if
I
have
time
to
find
it
later
I'll
I'll
ping
you
on
it,
but
there's
one
or
two
more
references
and
you
need
to
be
updated
for
for
github
to
gcs.
A
That
tool
was
created
exactly
for
the
reason
that
sasha
mentioned.
Basically,
we
have
a
few
projects
to
wrangle.
It's
really
only
two,
the
the
big
ones
that
we
care
about
are
the
ones
that
eventually
end
up
as
as
as
parts
of
the
the
deb
and
rpm
that
we
push
for
the
release
cycle.
A
So
those
are
cri
tools
are
the
cri
ctl
and
and
the
cni
plug-ins
right
so
container.
Networking
slash
plugins
is
that
repo
the
so
we
ran
into
api
rate
limiting
issues,
but
there's
also
the
question
of
like
provenance
for
the
artifacts
that
we
then
package.
So
the
request
was
that
we
have
gcs
buckets
for
that
the
so
all
the
references
and
kubernetes
kubernetes
have
been
changed
to
point
to
those
new
gcs
buckets,
which
means
when
these
projects
come
out
with
new
releases.
We
need
to
make
sure
that
we
update.
A
We
update
the
the
buckets
to
include
the
new
releases
that
is
currently
a
gap.
The
I
did
not
want
to
enable
any
automation
until
the
tool
was
a
little
cleaner.
Thanks
to
carlos.
You
did
a
bunch
of
work
on
cleaning
up
that
tool.
A
I
kind
of
landed
the
the
mvp
and
opened
an
issue
for
some
bugs
and
features
that
I
wanted
and
carlos
totally
ran
with
it.
So
thank
you
for
that.
I
think
it
is
close
to
the
place
where
I
would
be
okay
with
putting
it
in
ci.
The
plan
would
be
to
create
some
sort
of
config
directory
in
k,
release
config,
I
don't
know
gh
to
gcs.yaml
or
something
like
that
right.
A
That
was
kind
of
the
reason
for
having
it
be
able
to
support
yaml
configs
right,
so
we
land
a
yaml
config
within
our
repo
configure
a
ci
job
to
to
grab
both
the
cri
tools,
repo,
as
well
as
the
cni
plugins
repo,
and
we
provide
no
config
there
right.
We
basically
point
it
at
the
repo
and
no
no
configs
that
are
specific
to
releases
so
that
it
just
grabs
everything
right
that
way.
A
Those
buckets
are
always
up
to
date
and
there's
less
of
kind
of
like
a
back
and
forth
mechanical
process
as
we're
trying
to
do
updates
throughout
the
release
cycle
right.
But
yes,
another
gap
is
documentation
not
so
much
for
jesus
the
github
to
gcs
tool.
That
is
reasonably
documented.
What
we
need
to
include
are
what's
the
process
right.
I
think
we
have
a
bunch
of
open
issues
that
have
been
open
for
some
time,
because
the
we
were
not
aware
of
like
ownership
for
for
certain
tools.
A
I
for
the
cri
tools,
stuff
sasha's,
on
top
of
that
for
cni,
I've
been
working
on
wrangling,
some
of
that
stuff
and
we're.
Finally,
in
a
place
where
we
can
like
sit
down
and
document
it
for
real
right.
There
are
lots
of
pieces
that
we
didn't
understand
that
over
the
past
two
cycles,
or
so
we
do
now
so
yeah
so
cri
tools
update
to
119.0
cni
plugins,
just
released
a
087.
A
I've
already
merged
the
pr
for
that
to
kubernetes
kubernetes,
which
means
that
we
have
to
follow
up
with
updates
to
the
package
specs
for
the
debs
and
rpms,
as
well
as
an
update
to
the
debian
hypercube
base
image
and
I'm
so
that
leads
into
the
base
image
updates
and
I
am
working
on
a
base
image
update
right
now
for
for
the
hypercube
stuff,
as
well
as
some
niceties.
I
guess
that
will
eventually
allow
us
to
support
multiple
buildings
for
multiple
architectures
across
all
of
our
images.
A
If
we
want
to
so
marco,
that
was
the
pr
that
you
reviewed
it's
basically
a
hack
script
that
enables
enables
docker
build
x,
the
docker
build
x
command,
which
is
currently
an
experimental
feature
or
perma
experimental.
I
guess
that
is
we
the
way
we
build
multi-arc
images
across
the
various
images
that
we
have.
A
Each
of
them
is
a
little
different
and
I'd
like
to
I'd
like
to
standardize
on
using
that
tool,
as
well
as
the
the
multi-arch
key
mu
user,
static
image
that
automatically
sets
up
all
the
stuff
for
you
so
more
to
come
soon.
I'll
have
some
prs
flying
within
the
next
day
or
so
on
that
stuff,
and
then
we
should
probably
step
back
and
do
write-ups.
For
that
too,
120
is
going
to
be
a
lot
of
writing
stuff
up.
A
So
any
questions
on
this
stuff.
E
Yeah,
I
just
want
to
add
the
regarding
cri
tools.
Sorry,
if
I
miss
it
to
update
any
reference,
I
have
followed
the
pr
link
by
sasha
and
I
was
warned
that
there
might
be
something
else.
I
tried
to
search
with
hound,
but
I
was
not
able
to
find
anything
if
you
find
somewhere
else
free
fail
to
point
me
just
that.
I
know
what
have
I
missed
and
where
was
that
tell
us?
I
can
also
take
a
look
into
that
as
well.
A
Yeah
yeah
yeah,
no
problem,
it's
it's
more!
So
it's
it's
a
documentation
thing
honestly,
because
they're,
like
our
flow,
has
evolved
over
the
last
few
cycles,
and
it
continues
to
to
the
point
where,
where
any
documentation
that
was
created
is
maybe
no
longer
accurate,
the
dependencies.yaml
piece
is
the
big
piece,
because
if
a
reference
is
not
included
in
dependencies.yaml,
it
doesn't
get
picked
up
by
the
pre-submit
the
pull
kubernetes
dependencies
pre-submit.
So
it's
not
your
fault
for
missing
it
at
all,
but
we'll
work
together
and
fix
it.
A
Last
one
is
fcd3413
that
was
recently
released
before
the
I
believe
before
the
119
release
cycle
went
out.
We
updated
the
client
side
to
the
new
version
and
there's
a
pr
and
flight
that
is
currently
being
caught
by.
I
think
a
few
kind
failures
to
update
the
server
side,
so
that
should
happen
soon.
I
think
the
kind
failures
are
related
to
resources,
so
that
should
be
resolved
as
well.
I
see
a
few
pr's
in
flight
dan.
I
don't
know.
If
do
you
know
more
about
that?.
G
F
So
if
they're
racing
with
something
that
you
know
has
a
smaller
cpu
request,
then
they're
going
to
lose
that
pretty
much
every
time.
So
last
night
or
yesterday
evening
we
bumped
down
the
cpu
request.
I
wasn't
sure
ben
had
originally
set
that
so
I'm
not
sure
if
that's
going
to
cause
issues
with
the
test,
but
at
least
it
should,
you
know,
get
them
running,
and
then
we
can
see
what
the
issue
is
as
opposed
to
them
not
being
able
to
be
scheduled.
F
So
I
should
also
think
that
the
cluster
should
auto
scale
in
that
situation.
So
not
exactly
sure
what
the
issue
is,
but
we
should
have
more
clarity
on
it
today.
A
All
right
on
to
marco
to
chat
about
release
manager
and
release
manager,
associate
responsibilities.
E
Yeah
lori:
do
you
want
me
to
get
started,
or
do
you
want
to
do
this
short
introduction.
E
Okay,
so
the
thing
I
want
to
talk
about
is
to
discuss
a
little
bit
of
responsibilities,
for
release
manager
and
for
release
manager,
associates
roles
for
some
context.
How
this
started.
We
had
a
bunch
of
discussions
with
rory
and
a
few
falsehood
meetings.
If
I
remember
correctly,
it
was
veronica,
sasha,
lori
and
me,
and
we
got
her
at
some
points.
E
What
could
be
improved
regarding
release
engineering
and
one
of
the
dominant
topic
was
that
we
wanted
to
enable
more
folks
to
do
the
more
things
and
to
make
sure
that
they
can
do
those
things,
and
one
of
the
things
that
came
up
is
the
knowledge
exchange,
so
that
folks
learn
how
to
do
the
things
they
need
to
do
and
the
some
point
that
comes
follow-up
to
that
is
to
be
able
to
successful
come
up
with
some
technologies
change.
E
We
should
probably
decide
what
the
roles
of
release
manager
and
release
manager
associate,
and
what
should
we
even
do
right
now?
There
is
a
lot
of
things
and,
like
updates
releases,
so
on
many
tools
that
we
use,
but
I
think
that
it
will
be
helpful
to
have
a
list
somewhere
or
some
documentation
that
will
describe
what
should
we
do
and
what
are
our
responsibilities?
E
E
Let's
say
knowledge,
research
getting
started,
so
we
can
start
learning
and
collaborating
on
what
we
are
doing
every
day
and
so
on.
So
I
have
looked
a
little
bit
into
role
books.
I
can
send
the
link
to
the
zoom
right
now.
Probably
someone
can
share
it
in
the
document
as
well.
We
have
two
role,
books
and
they're
a
little
bit
out
of
date,
because
the
branch
manager
perpetually
steamrolls
got
now
merged
into
one
role.
E
But
what
I
have
wanted
to
ask
folks:
I
wanted
first
to
raise
the
borders
for
this
and
for
these
sections
that
we
will
be
trying
to
do,
and
I
wanted
to
try
to
discuss
a
little
bit
and
want
to
hear
about
falx
things
that
should
be
responsibilities
of
release,
managers
and
release
manager
associates.
So
if
you
have
anything
to
add
now,
then
I
guess
we
can
discuss
a
little
bit
about.
E
C
G
So
I've
been
trying
to
figure
out
what
the
all
of
the
branch
manager
and
other
people
do
from
for
the
last.
I
don't
know
six
seven
months
and
I've
been
trying
to
everything
I
I
by
by
this
time.
I
think
I
understand
what
the
release
process
does,
but
everything
I
have
to
learn.
I
have
to
learn
it
from
reading
the
bash
code,
which
is
not
the
not
the
best
of
of
ways
to
learn.
G
So
at
many
many
points
in
the
past,
I've
been
watching
the
releases
from
the
sidelines
so
to
speak,
and
I've
been
ready
to
jump
in
and
help
to
do
things,
but
it
is
a
really
opaque
process,
and
I
don't
know
if
this
is
intentional,
but,
for
example,
outside
people
cannot
read
the
logs
and
since
I
cannot
read
the
logs
whenever
something
fails
or
is
failing,
I
might
have
been
able
to
keep
some
time
to
help
that.
G
But
since
I
cannot
look
at
the
logs
or
the
output
of
the
processes,
I
cannot
but
it's
a
really
slow
process
to
to
be
able
to
help.
And
at
one
point
I
found
that
I
know
log
that
someone
left
in
a
bucket
somewhere
and
that
really
helped
me
understand
the
process
a
lot
more.
G
A
So,
just
to
comment
really
quickly
on
the
logs,
the
logs
are
explicitly
hidden
because
there
have
been
security
issues
in
the
past
where
api
keys
have
been
leaked.
A
It's
it's
bash,
so
things
are
things
can
be
unsafe
if,
if
you
know
if
things
aren't
properly
quoted
and
whatnot,
so
those
that's
not
currently
an
issue,
but
we
do
try
to
guard
against
that
right.
So
the
release
manager's
associate's
role,
one
of
the
intentions
there
is
to
provide
people
access
to
vlogs
right
so
that
they
can
do
this
kind
of
debugging
and
the
actually
I'm
gonna
keep
shutting
up
and
let
you
and
let
others
talk
so.
H
Okay,
I
can
try
to
add
my
two
cents.
This
past
cycle,
I
tried
to
to
help
the
some
associates,
for
example
marquee
and
veronica,
like
when
they
cut
the
the
the
alpha
and
beta
releases.
I
like
we
had
like
some
call
and
they
did
all
the
work
like
was
like
trying
to
teach
say
you
need
to
do
this.
You
need
to
do
that
and
like
following
the
the
existing
documentation
as
well,
but
I
think
we
need
to
do
this.
H
Maybe
going
back
again
like
from
the
beginning,
like
stephen
did
like
several
times
like
open,
a
zoo
call,
and
then
everybody
can
jump
in
and
see
what's
going
on.
I
think
maybe
we
need
to
do
that
again
like
and
make
this
maybe
a
common
practice.
H
Every
time
when
we
cut
a
release,
we
maybe
open
a
zoom
call
and
then
everybody
can
see.
The
problem
is
like
there
is
some
like
the
the
stage
part
takes
like
one
hour
two
hours
and
like
there's
nothing
much
to
do
like
while
waiting
and
then
I'm
not
a
good
speaker
like
like
steven
I
can
talking
for
one
hour,
but
I
think
maybe
we
can
like
do
in
a
session
and
jumping
and
explaining.
C
Some
of
us
have
given
presentations
in
the
past,
probably
in
our
work
for
our
conferences,
and
I
think
you
have
there's
a
lot
of
help
here
at
the
ready
for
just
structuring
that
kind
of
discussion.
So
please
don't
hesitate
in
asking
for
that
help.
Many
of
us
will
jump
in
and
you
might
have
that
experience
as
well,
but
you
know
you
shouldn't
have
to
do
it
all
yourself.
C
I
just
want
to
make
sure
I
was
clear
like
if
what
I
just
said
like
if
we
need
to
do
trainings
and
sessions
like
just
doing
the
formatting
is
sometimes
like
the
key
in
making
all
of
it.
Go
a
lot
better
like
it's
just
you
just
get
it
out
of
the
way.
It's
a
big
hurdle.
E
Yeah,
so
I
wanted
first
to
thank
you
for
the
feedback,
and
I
actually
agree
with
this,
because
I
think
these
sessions
are
very
useful
and
they're
a
nice
way
to
learn
about
and
see
how
it
actually
works,
especially
if
you
are
associated
and
never
have
done
it
before.
I
actually
like
watching
someone
who
has
experienced
or
done
it
before
to
see.
Okay.
This
is
how
it's
done,
and
maybe
even
if
it
is
recorded
as
long
as
it
is
possible,
then
I
can
go
also
later.
E
If,
if
I
have
to
do
it
myself
someday,
it
might
be
useful
to
have
it
as
a
reference.
The
problem
here
is
yes,
carlos
said
the
release
is
a
little
bit
harder
because
there
are
a
bunch
of
commands
said
now
bit
corel.
It
got,
I
hope,
a
little
bit
easier.
I
haven't
done
it
personally,
but
I
see
that
it
is
very
quite
improved
to
what
it
was
before
with
tanago
and
all
other
stuff,
but
I
I'd
that
it
would
be
also
useful
with
all
other
stuff.
Like
I
don't
know,
updating
the
dependencies
or
updating
go.
E
It
might
be
useful
to
have
some
session
and
see
personally.
This
is
some
stuff
that
I'd
like
to
see.
How
is
it
done
because
it
is
coming
up
very
frequently
and
it
will
be
nice
to
just
see
okay.
This
is
what
are
the
challenges
and
how
it
all
works,
and
I
guess
it
might
be
a
little
bit
easier.
Hopefully
they
are
not
stuff
to
wait
for
like
in
the
early
stage
and
yeah.
I
think
from
that
side
that
would
be
nice
addition.
A
So
to
to
add
on
to
carlos's
point,
I
I
do
believe
that
I
do
believe
that
maybe
an
initial
look
into
the
release
process
is
useful,
but
I
don't
believe
that
those
sessions
are
exciting
are
especially
given
that
our
release
process
takes
the
day
right
between
the
mock
stage,
release
and
and
official
stage,
and
release
and
image
promotion,
and
all
that
stuff
it
takes
four
hours
or
so
right
and
it's
duplication
of
work
that
we
have
sessions
recorded.
A
I
think
that
we
could
do
another
one
if
people
really
really
really
want
that,
but
I
think
that
the
sessions
that
we
have
recorded
give
some
sufficient
detail
into
the
process
for
release
manager
associates
you
have
access
to
the
logs,
so
you
do
have
that
opportunity
to
look
into
the
logs
on
the.
A
Console.Buildsgoogle.Something
we
can
get
you
links
if
you
don't
have
them
already,
but
every
release
that
is
happening
when
we
do
the
release.
We
start
a
thread
and
within
the
thread,
are
links
to
all
of
the
logs,
so
anyone
who
has
access
should
be
able
to
view
them.
So
that's
the
first
part.
What
I
think
is
more
interesting,
then
the
the
release
process
itself.
A
The
release
process
is
such
a
small
part
of
what
we
do
overall
right.
There
there's
a
lot
more
within
the
the
dependency
updates
working
on
the
tooling.
Having
those
conversations
the
go
updates,
I
recorded
three
hours
of
content
for
that.
If
you're
interested
in
watching,
I
think
it's
also
on
the
playlists.
It's
both
on
the
release.
Playlists
as
well
as
I
think
the
controvex
code,
walkthrough
playlists.
A
We
can
do
another
one
of
of
those
if,
if
you're
interested,
we
can
tackle
other
dependencies,
I
think
what
I
would
be
curious
about
is
for
associates
been
hearing
would
like
to
get
a
better
idea
of
what
you
want
right.
If
there
is
a
topic
that
you
want
to
cover,
I
want
to
explicitly
know
about
it
right.
There
is
a
lot
of
stuff
that
we,
if
we're,
not
providing
adequate
mentorship.
A
I
think
one
of
the
primary
responsibilities
of
release
managers
is
to
mentor
the
people
that
are
coming
up
right
before
the
tooling
people
process
tools
right.
We
handle
the
people
first
right.
So,
if
you're
not
getting
adequate
mentorship,
please
let
us
know,
let
us
know
what
we
can
do.
Let
us
know
about
specific
topics
that
you
want
to
to
know
about.
A
A
Please
be
explicit
if
you
are,
if
there
is
a
specific
request
that
you
are
not
getting
feedback
on,
whether
it
be
a
pr
issue,
I
know
there
have
been
a
lot
that
come
through.
I
have
a
pretty
large
stack.
Tim
has
a
pretty
large
stack,
I
think
in
in
general.
The
the
chairs
and
technical
leads
have
decent
chunk
of
stuff
to
work
through.
A
If
we
miss
one
of
your
requests,
it's
not
because
we're
trying
to
ignore
you
or
anything
like
that-
I
not
not
to
say
that
anyone
is
is-
is
suggesting
that,
but
we
miss
things
so
so
don't
feel
like
you're
bugging
us
to.
Let
us
know
again
that
there's
something
that
you'd
like
us
to
take
a
look
at
if
you're
not
getting
feedback
on
something,
and
you
really
need
it.
A
We
recently
created
the
sig
release,
leads
at
kubernetes.io
list.
That
is
a
list
that
tim
myself,
sasha,
jorge
and
laurie
are
on
send
a
note
to
that
list.
If
you're
really
not
getting
anything
from
us
moving
into
the
moving
into
future
cycles,
I've
had
the
discussion
with
release
managers
that
I
want
to
make
sure
that
they
are
spending
time
doing
mentorship
activities
with
you
all
right.
A
A
Maybe
there
is
some
synchronous
time
where
we
talk
through
an
agenda
and
we
talk
through
what
you
want
to
learn.
We
record
a
session.
People
can
view
it
offline
because
that
session
will
not
always
work
for
schedules
adolfo.
I
will
speak
to
you
offline,
because
I
know
you
have
interest
in
becoming
a
release.
Manager
associate
and
we've
discussed
that
in
the
past.
So
I
hear
you,
I
know
you're
working
on
krell
and
you're
doing
a
phenomenal
job.
So
we'll
talk
about
that
moving
into
120..
A
I
don't
know
if
I
missed
anything
but
keep
going.
Marco.
E
Okay,
so
I
want
to
thank
everyone
for
the
feedback
and
one
final
question,
so
I'm
planning
to
help
a
little
bit
with
this.
I
will,
I
might
spend
some
time
taking
and
probably
let's
try
will
be
useful
if
I
go
ahead
and
try
to
collect
the
things
we
are
working
on
the
dependencies
that
we
are
maintaining
the
tools
that
we
are
doing
and
compiling
a
list
of
them
so
that
we
know
what
are
the
responsibilities?
E
C
C
So
it's
like,
there
are
certain
security
things
that
you
wanted
to
know
or
have
exposure
to.
E
E
C
Yeah,
I
mean
here's,
here's
just
one
thing
like
maybe
taking
a
look
at
the
project
board,
release
engineering
items
and
being
like.
I
could
do
that,
but
I
don't
have
knowledge
of
x
or
I
could
do
that.
But
this
is
like
a
lot
of
steps
and
maybe
we
break
this
down
and-
and
that
might
be
just
a
helpful
triggering
mechanism
so
like
getting
that
list
together.
B
A
couple
comments:
the
as
we
started
this.
We
started
with
the
discussion
of
the
role
handbooks,
but
I
didn't
really
feel
like
we
closed
on
action.
There
we've
had
an
open
item
for
consolidating
those
for
a
while.
I
know
it's
on
your
place.
Even
I
don't
know
if
you'd
be
comfortable
delegating
that
to
marco
and
others
or
if
you
think,
you'll
get
around
to
that.
This
cycle.
A
So
yeah,
so
the
primary
reason
for
it
not
getting
done
is:
we've
had
updates
to
the
handbook
throughout
that.
Have
that
would
cause
a
massive
diff
in
in
the
update
that
I'm
doing
so,
I
have
to
basically
scrap
it
and
start
over
if
anyone
is
looking
at
the
handbooks-
and
you
have
comments
updates
that
you
want
to
make
like-
let
me
know
as
well,
so
I
can
make
sure
that
those
are
integrated
in
the
consolidation.
A
The
reason
I
would
prefer
to
do
it
personally
is
because
I
have
context
on
all
of
the
things
that
need
done,
and
it
is
harder
slower
to
do
a
review
as
opposed
to
writing
the
content
myself.
So
that's
for
the
handbooks
at
least.
Basically,
what's
going
to
happen,
all
of
the
tasks
that
are
release
management
related
will
be
pulled
out
into
their
its
own
file,
the
carlos
the
update
that
you
did
recently.
A
I
had
requested
that
you
pull
the
image
promotion
stuff
out
into
a
separate
location
too,
and
that's
kind
of
part
of
the
consolidation.
I
didn't
want
to
put
new
content
into
those
those
handbooks
one
of
the
the
you
know.
One
of
the
things
that
would
you
know
is
under
purview
for
the
the
release
managers
is
doing,
reviews
on
cherry
picks,
sharon
doing
cherry
pick.
Approvals
do
not
be
afraid
to
do
that.
A
A
So
as
a
release
manager,
you
have
the
power
and
you
should
exercise
that
power
for
for
approving
these
things.
If
you
do
not
feel
comfortable
with
approving
a
certain
pr
reach
out
to
the
team,
we
have
a
private.
We
have
a
private
slack
channel
for
exactly
that
kind
of
thing.
So,
but
if
you
are
sweeping
the
content
because,
like
I
usually
end
up
running
through
like
quick
iterative,
dependency
updates
and
tim
does
a
lot
of
like
the
background
making
sure
the
cherry
picks
merge.
A
H
I'm,
like
my
I
did
like
last
week.
I
was
updating
the
spreadsheet
and
didn't
like
approve
because
I
was
afraid
to
do
the
wrong
stuff
in
codes
and
also
because,
like
we
don't
like,
I
have
an
explicit
process,
I'd
like
to
see
like
if
we
can
have
like
in
the
future
some
documentation
regarding
cherry
picks
process.
H
E
A
You
have
recorded
blessing.
There
is
so
we
have
some
documentation
tim.
I
think,
since
you
spend
a
decent
chunk
of
time,
doing
that,
would
you
like
to
look
over
the
documentation
and
think
about
opportunities
for
improvement.
B
Yeah,
I
can
do
that
and
carlos
if
there
are
things
where
you
feel
that
the
criteria
is
unclear
for
when
you
choose
to
merge
something
those
can
be
added
to
the
document
or
start
as
a
question.
I'm
unsure
of
this,
because
I
don't
understand
this
whatever
that
this
is
is
something
that
should
be
in
the
document
and
then
we
can.
Basically,
we
can
write
up
a
paragraph
and
give
it
to
stephen
to
put
in
the
document
when
he
updates
it.
Cool
sounds
good.
C
Yeah,
I
mean,
I
think,
what
we're
talking
about
right
now
is
generally
empowerment,
empowerment
of
this
group,
and
so
there's
a
lot
of
knowledge
and
information
that
this
group
is
seeking
to
be
able
to
do
to
do
the
work,
and
so
I
mean
perhaps
part
of
marco's.
Listing
of
these
different
items
is
that
we
just
highlight
the
documentation
needs.
C
We
know
we
have
quite
a
few
of
them,
and
so,
if
we
have
a
body
of
work
that
we
know
we
need
to
achieve
to
make
everyone
feel
like
they
can
contribute
in
the
ways
that
they
want
to.
Then
that
will
be
one
huge
hurdle
that
will
pass
over.
I
think
it's
just
a
matter
of
organizing
that
data
in
a
single
place
and
we
look
at
it
together,
we're
making
strides
toward
that.
We
have
our
project
board,
it's
updated.
We.
C
A
Yeah
to
be
super
clear,
I
want
to
work
on
less
stuff.
I
want
tim
to
work
on
less
stuff.
I
want
I
want
sasha,
I
want
jorge
to
work
on
less
stuff,
so
that
requires
that
requires
good
documentation
that
requires
understanding
of
the
process
across
the
board.
That
requires,
I
think,
the
flip
side
of
of
this
of
the
associates
discussion
is
that-
and
this
is
just
a
general
note
for
for
everyone-
it's,
I
think
I
think
they're,
I
think
in
previous
cycles.
I've
said
tenacity
right.
A
There
needs
to
be
a
an
genuine,
a
genuine
interest
in
working
on
stuff
and
tackling
things,
even
when
the
boundaries
of
what
you
have
to
work
on
are
a
little
fuzzy.
A
That
is,
I
know,
that's
not
an
easy
thing
to
say
or
do,
but
it
is
most
of
how
I
learned
the
stuff
that
I'm
working
on
right
now,
so
the
I
think,
a
really
good
example
and
I'm
curious
dan.
Would
you
be
interested
in
giving
a
chat
or
something
dan
is
a
really
excellent
example
of
someone
who
is
not
a
release,
manager
associate
and
dove
in
absolutely
dove
in
right
and
and
hit
a
bunch
of
things
that
he
was
not
sure
about
asked
the
right
questions?
A
Did
the
thing
became
a
release,
manager
associate
and
very
soon
afterwards
became
a
release
manager
because
it
was
almost
detrimental
for
us
to
not
have
him
have
that
access
to
do
the
work
dan?
I
would
be.
I
I'd
be
interested.
If
you
would.
You
would
be
curious
if
you'd
be
interested
in
like
giving
a
chat
to
the
associates
or
something
about
some
of
the
techniques
that
you
or
things
that
you
think
about
when
you're
working
through
issues.
F
Yeah,
I'd
definitely
be
more
than
happy
to
do
that.
I
think
that
coming
from
some
of
the
ci
signal,
side
of
things
definitely
helps
right
because
you're,
basically
looking
for
things
that
are
breaking
and
so
yeah
I'd,
be
happy
to
put
together
a
youtube
video
or
something
like
that
for
folks
that
are
looking
to
take
on
some
more
work.
A
Cool
dan,
can
you
work
with
lori
and
think
about
it.
Let's.
C
Set
that
up
like
no
one
was
going
to
yell
at
you.
If
you
do
something
wrong
we're
all
here
to
help-
and
this
is
a
really
great
environment
for
for
learning
like
because
I
think
we're
all
aligned
and
just
trying
to
help
each
other
so
the
need.
You
don't
need
to
worry
about
making
any
sort
of
mistake
or
error.
But
of
course
that
part
means
ask
for
the
help
when
you're,
when
you're,
not
sure
or
something
you
do,
that
you're
golden.
A
Yeah,
I
think
you'll
you'll
you'll,
find
that
the
the
pro
tip
a
lot
of
the
things
that
have
been
like
massive
outages
are
things
that
we
didn't
know
before
right
things
that
we
didn't
know
little
hurdles
that
we've
run
into
in
an
inaugural
that
we
that
we
figured
out,
we
figured
out
as
a
group
right
so
really
don't
be
afraid
to
ask
questions
to
to
feel
like
it's
okay
to
fail.
A
It
really
is
that's
how
you
learn.
So
if
you
have
the
questions
like
dive
in,
if
you
have
the
questions,
just
just
ask
seriously.
A
So,
with
two
minutes
left,
I'm
going
to
try
to
jump
through
this
stuff
really
quickly.
The
first
is
a
really
cool
tool.
Download
kubernetes.com,
I
chuck
recently,
did
an
update
to
it
and
mentioned
it
on
twitter,
and
it's
like
hey
man,
it'd,
be
cool.
If,
if
we
could
use
that
and
he's
like,
you
totally
can't,
and
so
we
had
that
donated
into
kubernetes
sigs,
so
check
out
that
website,
that's
something
that
release
engineering,
so
this
is
an
opportunity
for
contribution
here
right.
A
This
is
something
that
release
engineering
will
be
maintaining
moving
forward.
There
is
an
open
issue
around
switching
the
site
to
netlify.
I
believe
that
sasha
opened
jeff
is
going
to
be
working
on
that,
but
if
people
are
interested
in
working
together
with
jeff,
let
us
know
and
we'll
get
you
connected.
A
E
I
personally
had
some
other
problems,
but
that
were
that
were
not
reported
by
fox,
so
I'm
not
sure
have
I
done
something
wrong,
but
I
think
the
original
issue
that
was
in
the
progress
or
in
the
backlog,
wherever
can
be
closed,
then,
if
there's
need,
we
can
replace
it
with
another
one.
If
folks
still
have
problems,
but
so
far,
I
think
it
got.
A
Improved
a
bit
so
marco,
would
you
mind
spinning
up
a
thread
on
the
release
managers
at
kubernetes,
io
mailing
list
to
chat
about
that
a
little
bit
the
I
have
to
hop
for
another
meeting,
but
the
my
feeling
is
that
there
is
a
fix
and
the
fix
would
be
to
use
stretch
for
hypercube,
but
that
makes
it
tricky
because
then
stretch
and
buster
are
being
used
simultaneously
on
the
same
branch,
and
I
don't
like
that,
but
it
the
the
overarching
issue
is
managing
hypercube
is
difficult
and
it
continues
to
be
difficult
and
that's
the
reason
we
deprecated
it,
but
it's
still
causing
problems
for
previous
branches.
A
So
we
need
to
discuss
a
resolution
for
that,
not
just
for
the
current
issue,
but
for
hypercube
issues
that
will
crop
up
throughout
the
cycle
that
we
need
to
maintain
it.
For
so,
thank
you.
Everyone
for
having
this
awesome
chat.
We
will
catch
you
at
the
next
one
later.
Thank
you.
Bye.