►
From YouTube: Kubernetes 1.20 Release Team Meeting 20201002
Description
Release Notes team onboarding
C
C
Okay,
I've
dropped
a
document,
a
link
to
some
agenda
and
some
notes
for
this
meeting
in
there
in
the
chat
for
the
zoom
just
to
find
my
notes
so
hello
and
welcome.
My
name
is
james
lavrock,
I'm
the
release,
notes
and
the
lead
for
kubernetes
120.,
and
this
is
an
onboarding
meeting
designed
primarily
for
shadows,
but
also
ready
for
anyone
who's
interested.
C
This
is
second
october
2020
or
I
believe
it
is
the
third
of
october
for
some
people-
and
this
is
a
kubernetes
meeting.
So
please
abide
by
the
kubernetes
code
of
conduct.
Thank
you,
everyone
for
making
this
work.
I
know
we've
had
some
some
interesting
difficulties
trying
to
fit
this
around
time
zones.
I
know
sonia
in
particular,
I
believe
it's
2
30
3
30
in
the
morning
for
you
right
now
or
something
like
that.
C
B
Yeah
hi,
so
let
me
start
by
introducing
myself,
so
this
is
sonia.
Currently
I
am
a
student
and
studying
my
bachelor's
so
yeah,
I
am
open
source
contributor
in
mozilla
and
in
the
partners
project,
and
this
will
be
my
first
time
contributing
in
kubernetes
and
yeah.
I
am
excited
and
nervous
at
the
same
time
meeting
with
the
people
with
so
much
experience
so
yeah.
This
is
about
me.
E
G
D
D
A
A
Introduce
myself
just
for
the
recording
too
my
name's
jeremy.
I
also
work
at
vmware,
hey
wilson,
I
am
the
120
release.
Lead
I've
been
on
a
few
release
teams
before
so
as
we
go
through
things.
If
you
have
questions
about,
I
can
answer
questions
about
bug
triage,
because
I
did
that
a
long
time
ago
and
I
did
enhancements
a
couple
times.
So
if
you
have
questions
about
either
of
those,
let
me
know
just
general
questions
about
the
release
stuff
feel
free
to
reach
out
anytime,
I'm
in
colorado.
C
H
C
C
C
Our
ultimate
output
will
be
this
document
to
one
extent,
some
extent
to
another.
There's
a
couple
of
major
parts:
there's
a
major
themes
section
and
towards
the
end
of
the
release
cycle,
we'll
be
going
around
and
speaking
to
individual
sigs,
to
ask
what
they
think
has
been
a
major,
a
major
improvement
for
them
during
this
release
and
kind
of
collating
that
and
putting
into
this
into
this
big
list.
C
But
of
course
we
will
be
doing
that
until
the
end
during
the
most
part
of
the
release,
we
will
be
generating
this,
so
this
is
a
giant
list
of
everything
that
changed
you
see.
These
are
all
actually
related
to
individual
pull
requests
against
kubernetes
kubernetes.
So
it's
loading
here
we
go
so
I
just
picked
one
at
random.
C
C
Of
course,
we
have
tooling
to
help
us
do
that,
because
just
copying
and
pasting
this
would
take
a
very
long
time
and
be
extremely
boring,
so
we
primarily
have
a
tool
called
k-rel
which
will
do
it,
so
some
people
call
it
krell,
I'm
not
sure
if
there's
a
canonical
pronunciation,
but
I'm
not
gonna
get
into
that.
But
I
I
go
with
k-rail,
so
I'm
going
to
say
that
krell's
source
code
is
over
in
the
kubernetes
release
repository.
C
You
can
find
it
in
here
if
you're
particularly
interested
in
that,
but
there's
also
its
documentation
under
which
explains
how
it
works
and
what
it
does
and
the
it
actually
does
a
whole
load
of
stuff
relating
to
the
release
process.
But
the
part
we
care
about
is
the
release
notes
sub
command,
which
is
what
we're
going
to
spend
a
fair
bit
of
time.
C
Talking
about,
oh
by
the
way,
if
anyone
had
any
questions
feel
free
to
just
interrupt
at
any
time
so
right
now,
our
primary
thing
we
will
need
to
do,
especially
for
the
early
part
of
release
is
effectively
run
this
tool
whenever
there's
a
release.
So
there
was
a
release
done
a
couple
of
weeks
ago,
which
gave
us
alpha
one
and
alpha
two
is
scheduled
for
in
a
couple
of
weeks
and
then
we'll
get
some
more
alphas,
then
some
betas
and
release
candidate
releases
and
every
time
one
of
those
comes
out.
C
C
I
can't
ahead
of
this,
for
example,
so
I
would
need
to
ask
either
someone
with
a
significant
amount
of
privilege
and
permissions
on
the
system
or
the
original
committee
to
go
and
change
it.
So
this
lets
us
do
that
editing
for
the
tooling
itself,
there's
a
whole
lot
of
documentation
for
krell
and
how
to
build
and
compile
these,
but
the
which
I
won't
go
through
in
particular
detail
here.
C
But
the
broad
idea
is
that
you
can
clone
this
repository
kubernetes
release,
and
then
you
can
go
like
compile
these
tools
kl
and
as
long
as
you've
got
your
system
set
up
in
a
reasonable
way,
so
you've
got
go
installed
and
all
the
rest
of
it
it
will.
It
will
produce
the
tooling
and
put
it
in
in
in
the
place
that
you
can
execute
it
from
so
yeah.
So
it
was
really
lightning
fast,
because
I
did
it
like
half
an
hour
ago,
but
you
get
the
idea
and
then
we
can
do
it.
C
C
So
there's
we
instruct
k
rolls
it
generates,
release
notes.
We
tell
it
to
create
a
draft
pr.
We
have
this
dax
fix
flag,
and
this
is
the
new
one
for
120
that
has
the
interactive
mode,
and
then
we
give
it
a
few
other
pieces
of
information.
We
need
to
tell
it
what
the
fork
is
so
where
these
release
notes
actually
go
during
the
release
is
not
into
like
the
main
kubernetes
website,
they're
published
into
a
git
repos,
specifically
into
k-stick
release.
C
So
this
is
where
that
document
outlining
the
release
team
in
order
to
release
these
handbooks
is
also
in
here
under
releases
release.
120,
there
will
be
a
document
called
draft
release
notes
and
if
you
go
look
at
one
of
your
other
releases
when
you
send
strategy.md,
this
is
where
it
ends
up.
So
what
this
tool
will
do
is
generate
this
file
and
it
will
actually,
it
will
generate
the
file.
It
will
upload
it
to
your
fork
on
github
and
it
will
create
a
pull
request
for
you,
so
it
automates
that
entire
part.
C
In
order
for
this
to
work,
you
need
to
have
a
fork
of
this
repository
already
existing.
So
I've
already
forked
this,
but
all
you
need
to
do
is
just
go.
Click
the
button
default
again.
This
is
all
documented,
but
it's
part
of
the
process.
So
you
don't
need
particularly
worried
about
this.
The
tools
will
mostly
take
care
of
this
for
you
so,
but
I
need
to
tell
it
with
the
four
kids,
so
I
just
give
it
my
github
username.
C
C
If
I
run
this,
it's
actually
going
to
take
a
little
bit
of
time,
because
what
this
is
going
to
do
is
it's
going
to
clone
kubernetes
all
of
it
and
then
it's
going
to
start
scanning
through
git
commits,
and
it's
going
to
go
and
query
the
github
api
and
ask
github
for
a
bunch
of
information
and
then
it's
going
to
start
doing
it.
It's
actually
running
much
faster
here
than
it
normally
would
because
it's
already
cached
a
bunch
of
stuff.
C
E
C
C
C
Oh,
it's
pole,
of
course
yeah.
So
what
the
committer
did
is
they
did
none.
So
this
is
a
special,
a
special
piece
of
information
to
say
that
says,
you
definitely
do
not
want
to
release
note
and
the
release.
Note
robot
will
actually
pick
that
up
and
say:
oh
release,
note
none
and
it
won't.
Let
you
open
it
won't
let
that
you
merge
a
pr
without
either
saying
explicitly.
There
is
no
release
note
or
without
having
one
there.
I
think,
there's
like
maybe
a
special
command.
You
can
do
it
to
override
that.
C
But
there's
effectively
saying
there's
no
release
note
so
in
terms
of
how
well
trained
they
are.
I
don't
have
any
stats
on
how
many
non
and
whether
things
get
missed
in
that
respect
or
not.
So
one
of
the
things
I
don't
actually
do
is
contribute
to
upstream
kubernetes
in
the
code
capacity.
So
I
don't.
I
don't
do
it.
I
don't
know.
That's.
C
B
C
Okay,
where
was
I
right,
so
this
is
probably
actually
run
by
now,
as
I
say,
if
it
hadn't
cached
it
it
probably,
this
can
take.
This
can
take
a
little
while
we
do
actually
some
errors
here.
So
maybe
these
are
good
examples,
no
matching
founds
on
texting.
So
if
I
pull
up
this
one,
for
example,
I
need
to
change
it
to
pole.
C
Is
this
what
you
mean
at
alpha
by
errors
coming
out
from
not
parsing,
oh
yeah,
so
in
this
one
the
committer
has
put
no,
but
because
the
tool
expects
a
code
block
with
non-capitals
written
in
it.
It
hasn't
understood
what
and
see
the
the
robot
said.
Release
note
is
is
is
needed
and
I
think
someone
yeah
someone
came
along
and
said,
release
note
numb
to
tell
tell
the
toolig
specifically
that
that
there
is
no
release.
Note
and
just
just
do
it
anyway,
but
I
don't
think
our
tool.
C
The
kval
is
smart
enough
to
realize
that
so
yeah,
but
it's
it's
a.
They
just
wrote
the
wrong
thing,
and
you
know
it
doesn't
necessarily
tell
you
exactly
what
to
write
well,
I
think
it
does,
but
you
know
it's
easy
to
get
that
wrong,
because
you
might
not
realize
that
this
is
being
parsed
by
a
machine.
If
you
didn't
know
anything
about
this
tooling.
C
Cool,
so
we
have
a
the
new
part.
Is
this
so
normally
what
have
happened
is
if
you
ran
this
tool
back
in
queueing
119,
then
this
would
go
and
open
some
pull
requests,
and
that
would
be
it
now.
We
have
the
new
bit
adolfo.
I
know,
did
you
want
to
talk
through
this
and
we
can
use
this
as
a
demo
or
I'm
not
sure
how
you.
D
C
D
So
the
idea
behind
this
when
we
first
started
working
on
this
during
118,
the
the
the
idea
that
we
had
was
to
completely
eliminate
the
release.
So
the
release
notes
team
just
simply
automate
everything,
but
I
was
having
some
discussions
with
sasha
and
he's
very
he's,
like
very
meticulous
on
the
on
the
quality
of
the
notes,
and
he
convinced
me
that
we
had
to
have
some
review
process
some
human
review
process,
and
that
became
even
more
important
now
that
we're
caring
about
the
naming
stuff
right.
D
So
we
this
process
is
the
idea
behind
this
is
that
is
to
have
the
opportunity
to
automate
everything
on
one
side,
but
still
have
a
chance
to
review
and
improve
the
quality
of
the
text
that
people
ride,
and
so
this
is
what
we
came
up,
and
this
is
the
first
time
we're
using
it.
So,
let's
see
how
it
goes.
C
So
it's
giving
me
a
prompt.
There
is
a
there's,
a
pull
request
in
flight
for
the
well
in
flight
being
open
and
ready
to
be
reviewed.
Sorry,
four
changes
to
that
handbook
which
I've
linked
in
the
meeting
notes
for
this,
which
adolfo
wrote
and
hopefully
we'll
get
emerge
at
some
point,
but
because
the
tools
have
already
merged
effectively
we're
already
using
that.
C
So
I
encourage
people
to
read
that
but
effectively
you
can
see
it's
now
asking
me
to
press
enter
to
start,
and
it
gives
me
a
little
bit
of
information
about
what
this
tool
is
and
what
it
does
and
continue
on.
It
will
show
me
in
this
case
we
have
10
changes
that
have
release
notes
in
birth
in
alpha
one,
and
it
will
one
by
one
show
me
the
text
and
the
information
about
those
requests.
Basically,
the
information
that's
going
to
go
into
that
document
is
is
shown,
and
I
can
edit
this.
C
C
C
Okay,
so
there's
some
valley,
the
animal
that
looks
kind
of
like
that,
so
we're
leaving
the
rest
of
it
alone
and
I'm
going
to
add
a
full
stop,
which
is
an
entirely
superfluous
change
at
this
point,
but
you
can
imagine
we
could
do
anything.
We
could
correct
typos
or
spelling
mistakes
or
really
anything,
I'm
gonna
save
this
out,
and
then
it's
just
move
straight
on
to
the
next.
C
The
next
pull
request.
The
next
release
note
to
be
to
be
looked
at,
so
if
I
just
go
through
most
of
these,
I
think
that
I
suspect
these
I
mean
I
haven't
checked.
I
said
most
of
these
are
probably
fine,
so
I
can
say
you
know.
Yes,
that's
cool.
I
said
I
guess
I
want
to
edit
that
I
can
just
quit
out
of
this
after
saying.
Yes,
without
doing
anything,
and
it's
fine
right.
D
D
D
C
C
So
I
hit
yes,
oh
one,
important
thing
for
this:
you
need
to
generate
a
github
token
and
set
it
as
an
environment
variable
in
your
shell.
Again,
the
documentation
tells
you
how
to
do
this,
I'm
not
going
to
cap
mine
out,
so
I
don't
have
to
like
revoke
it
when
this
video
goes
up,
but
that's
how
this
thing
is
able
to
to
act
on
github
is
using
that
token,
so
it
has
created
the
pull
request
for
me
just
now.
I
don't
know
if
that's
like
shouted
in
sig
release,
no,
it
hasn't.
Okay.
C
I
can't
hopefully
get
automation
turned
on
to
this,
so
this
has
generated
this
thing
just
now
and
you
can
take
a
look
and
see
what
it's
done
and
we
can
see
that
it's
created
this
release,
notes,
draft
file
and
all
of
these
pull
requests
all
of
these
pieces
of
information
that
were
put
in
here.
So
if
we
find
the
one
that
I
edited,
do
you
remember
what
it
was?
I
added
a
full
stop,
but
I
don't
I
don't
remember
which
one
it
was.
C
C
D
D
C
C
But
in
this
case,
because
I
aborted
the
editing
flow
by
accident,
it's
not
done
any
of
that.
So
we've
just
got
this
file,
but
this
is
for
the
purpose
of
alpha
one.
This
is
probably
sufficient.
We
probably
do
need
to
go
through
and
review
all
of
these,
because
otherwise
we're
gonna
have
thousands
of
these,
where
we
get
everything
and
it's
gonna
take
ages,
but
it
has
generated
this
this
this
file,
and
this
is
kind
of
the
primary
output
ahead
of
the
next
release,
for
which
is
alpha
2.
C
D
Yeah,
the
idea
is
that
you
can
send
as
many
as
you
like
you.
The
tool
is
supposed
to
continue
where
you
and
then
continue
editing
the
all
the
unchecked
vrs
at
the
so
far.
So
if
you
leave
this
version
of
the
notes-
and
someone
can
pick
it
pick
it
up
like
next
next
week
and
verify
some
more
and
it
will,
it
should
upload
all
the
all
the
map
files
and
session
files
and
to
be
able
to
continue
where
you
left
off.
C
D
C
C
So
if
people
wanna,
you
know
just
post,
I
guess
in
the
channel
to
say:
oh
well,
I'm
going
to
start
reviewing
some
stuff
and
then
we
can
go
through
the
process
of
getting
that
pr
and
approved,
and
then
someone
else
could
pick
it
up,
which
might
be
a
little
bit
slow
to
begin
with.
But
we
have,
I
think
enough
time,
especially
at
this
stage
later
on
in
the
release.
C
When
the
releases
are
a
bit
faster,
we
might
need
to
do
something
else
like
do
it
as
I
could
have
a
live
exercise
or
some
description,
but
I
think,
certainly
for
now
my
main
focus
or
main
desire
would
be
to
get
everyone
the
chance
to
kind
of
run.
This
tool
get
used
to
it
start
editing.
Things
start
looking
at
reading
through
the
release,
notes
and
and
looking
at
stuff
in
reporting
any
books
that
you
found
and
reporting
delightful.
B
C
Which
we
will
find
there's
nothing
like
users
to
find
bugs
at
all
fo,
and
we
are
your
users
or
a
live
demo
or
a
live
demo
exactly
so
one
more
thing
which
we
need
to
do
is
there
is
the
release
notes
websites
yeah?
So
this
is
real
notes
case
I
o.
So
this
has
much
of
the
same
information,
but
it
is
a
nice
kind
of
like
javascript
searchable
searchable
file
and
you
can
like
narrow
down
by
sig
and
all
that
sort
of
stuff.
It's
great.
C
C
C
It
will
do
much
the
same
thing,
but
it
won't
ask
me
any
questions.
It
will
just
go
and
create
that
pr
during
the
release
we'll
create
a
file
in
in
here
for
each
sub
release
so
we'll
this
will
create
our
120
alpha
1
and
then
we'll
create
a
second
file
for
alpha,
2
and
so
on
and
so
forth
and
at
the
end,
we'll
collapse
all
of
those
down
into
release,
notes
1,
20,
zero
json
file,
which
is
a
fun
experience.
C
That
by
hand
yeah
that's
by
hand,
but
that's
gonna,
be
that's
gonna
be
fun,
but
again
we
only
do
that
once
at
the
end
of
the
end
of
a
release
cycle,
I
think
that's
largely
it
from
our
what
we
need
to
do
during
this
for
this
cycle.
Does
anyone
have
any
questions
about
kind
of
our
goals
or
our
duties
or
what
we
need
to
be
doing.
C
C
D
Well,
I
actually
think
that
we're
going
to
automate
the
actual
run
of
the
of
the
tools,
so
you
the
someone-
I
I
don't
know
in
the
future.
If
it's
going
to
be
the
release,
notes,
team
or
maybe
somebody
else
like
like
celesta-
was
suggesting
folding
it
into
dogs
still
we'll
have
to
do
the
review
and
maybe
correct
some
of
the
notes
and
also
do
the
gathering
of
the
of
the
major
themes
and
but
I
the
actual
run
of
the
of
the
tools
that
feed
the
website
and
the
and
then
and
create
the
draft.
D
I
think
that
will
be
automated
really
soon,
but
we'll
see
and
also
there
was
well
actually
for
now.
I
think
that's
the
only
note,
because
there's
also
some
discussion
on
where
the
actual
point
where
the
release
notes
should
start
generating,
but
maybe
we
should
discuss
that
offline
because
to
leave
this
video
in
a
more
general
show.
C
So
you
can
see
here
that
I'm
hitting
rate
limits
on
github,
which
is
just
the
part
of
using
these
tools,
so
but
it
is
almost
done
with
92,
which
is
nice
once
these
two
pull
requests
are
open.
They'll
go
through
the
normal
pull
request,
approval
mechanism,
so
it
should
be
relatively
fast
to
get
someone
to
come
up
with
them.
I
mean
possibly
not
this
late
in
the
day,
but
someone
will
come
along
necessarily
and
we
should
get
those
merged
and
actually
seems.
D
C
Oh
yeah,
and
it
has
to
pretty
far
in
order
to
satisfy
the
pre-commit
or
the
post,
commit
checks
for
that
repository
because
it's
a
website,
all
of
the
json,
has
to
be
pretty
printed.
So
this
is
then
going
to
go
and
install
npm
to
do
3d,
printing
and
a
bunch
of
other
stuff
which
is
a
bit
takes
a
while,
but
it
it
the
tool
is
automated.
C
I
think
when
I
started
in
one
we
started
when
it's
18
at
alpha
that
wasn't
automated
was
I
had
to
run
that
yourself,
that
was,
that
was
fun,
yeah
cool,
so
that
pull
request
is
open.
This
one
is
going
to
be
open
in
a
minute
and
then
we
can
start
to
start
the
review
process
on
that.
I
suppose
at
some
point
once
this
is
the
one
the
first
one
that
I
already
opened
has
merged.
C
We
can
talk
about
who
we
want
to
have
for
stab
at
running
the
fix
tool
in
order
to
go
and
go
and
start
editing
these
things
and
approving
them
and
kind
of
that
manual
introspection,
but
yeah.
I
think
that
is
the
broad
strokes
of
what
we
need
to
do.
Was
there
anything
else?
Did
anyone
have
any
any
other
general
questions?
Anything
I've.
G
Missed
so
I
guess
this
is
something
new
in
this
cycle
where
we
are
actually
editing
the
release.
Notes
right.
Do
we
want
to
have
those
discussions
over
in
slack
as
we
coordinate
the
work
of
generating,
or
should
we
have
it
on
the
pr
and
have
the
discussions
over
there
on
the
things
that
we
would
like
to
fix
and
amend
and
then
pretty
much
rerun
the
tool
again
with
those
fixes
push
another
commit
to
the
same
branch.
C
That's
a
good
question.
I
don't
think
we
have
a
process
for
this
right
now.
So
largely
we
are
going
to
be
helping
to
shape
that
my
kind
of
immediate
opinion-
and
this
could
well
be
wrong.
Please
do
correct
me,
jeremy.
Adolfo
think
this
is
silly
is
that
if
it's
kind
of
a
non
change
by
which
I
mean
so
spelling
corrections,
grammar
editing
that
sort
of
thing,
I
would
be
pretty
happy
for
us
to
just
do
that
and
kind
of
decide
among
ourselves.
But
you
know
this
is
this
is
fine?
C
You
know
we
added
a
full
start.
We
corrected
something
like
that.
If
it's
like
a
change
in
meaning,
so
we
feel
the
release.
Note
simply
doesn't
explain
enough
or
doesn't
give
enough
background
or
is
perhaps
technically
incorrect,
although
it
may
be
quite
difficult
for
us
to
identify
if
a
release
note
is
technically
incorrect
without
because
we're
not
expected
to
go
and
read
the
code
of
every
single
change
that
goes
into
kubernetes,
it's
it's
impossible.
C
C
Typically,
we
in
the
relations
team
haven't
gone
back
to
original
authors
to
ping
them
about
things
very
often,
but
I
know
that
other
teams,
obviously
releasing
particularly
enhancements,
find
that
to
be
a
challenging
experience
at
it
can
be
a
challenging
experience,
so
we
might
have
to
cross
the
bridge
of
you
know.
We
we
think
of
release.
Note
isn't
good
enough
and
we
speak
to
someone
and
they
just
don't
go
back
to
us
because
of
course
it's
a
volunteer
project.
C
No
one
has
any
requirements
to
get
back
to
us
so
that
we
might
have
to
to
address
as
we
go
along,
but
hopefully
we
should
be
able
to
say.
Oh
maybe
this
would
be
better
and
they
would
say
yes,
but
I
I
think
this
is
going
to
be
an
evolving
process
and
I
think
that's
part
of
the
the
interesting
part
of
this
release
is
good
to
be
evolving,
that
process
and
deciding
what
it
should
look
like.
A
A
They
can
also
weigh
in
on
the
wording
of
the
the
release
note
and
and
make
some
of
those
changes
and
weigh
in
on
that
I
mean
in
the
end
they
have
responsibility
for
the
pr
itself
and
the
changes
coming
in.
So
I
think
this
should
be
a
good
resource
for
also
making
sure
that
the
release
note
is
valid
and
correct.
E
E
E
D
D
C
I'm
yeah,
I'm
I'm
very
supportive
of
that.
I
know
that
you
have
a
wealth
of
experience.
Actually
writing
release
notes,
whereas,
like
my
experience
is
like
fighting
krell
release,
notes
and
hitting
enter
well,
I
said
my
only
comment
would
be
we're.
Gonna
have
to
figure
out
synchronous
meetings
versus
asynchronous
changes
here,
because
I,
like
this
team,
is
distributed
over
a
timezo
difference
of
like
13
14
hours
or
something
so
while
for
one-off
meetings
like
this,
it's
possible
to
get
everyone
in
the
same
room.
C
I
think
that
it's
probably
unreasonable
to
ask
us
to
do
this
every
week
or
every
release
or
something
to
get
everyone
in
one
room.
It's
just
not
going
to
be
fair
on
on
on
the
team,
and
I
think
that
if
I
said
I
was
going
to
have
a
meeting
at
10
o'clock
p.m.
Every
friday
my
wife
would
be
unhappy
with
me,
but
but
I
think,
certainly
for
a
first
stab
during
a
meeting
I
mean
again.
C
If
we
record
it,
then
people
who
can't
make
it
can
watch
the
recording,
especially
if
knowledge
transfer
is
the
ideal
and
we
can
look
at
doing
async
ones
as
well.
So,
like
I
said,
I'd
like
everyone
to
pick
these
up
and
I
don't
necessarily
expect
everyone
to
do
it
live
with
people
watching
so
yeah.
I
think
a
mixture
is
probably
good
to
work,
but
yes,
I'd
say.
Definitely
if
you
want
to
pick
up
the
first
one.
That's
that's
great.
C
We
should
do
that
in
that
case,
shall
we
get
the
first
draft
file
merged
with
no
no
map
changes
at
all
and
then,
as
soon
as
that's
merged,
you're
you're,
free
to
kind
of
start
that
it
usually
doesn't
take
too
long
to
get
these
things
merged?
We
can
probably
prioritize
that
we're
talking
to
adolfo
our
friendly
reviewer.
I
think.
C
If
you
were
wanting
for
things
kind
of
more
of
a
technical
side
to
do
it
isn't
really
part
of
our
remit
on
the
release
team
at
all,
but
I'm
sure
that
dolfo
would
love
to
have
some
help
on
on
writing.
Golang.
If
that's,
if
that's
your
thing,
but
again,
that's
not
really
part
of
our
team.
That's
just
another
thing
you
could
do
in
kubernetes
related
to
this.
If
you
were
interested
it's,
I
did
something
like.
C
Any
help
is
always
welcome,
yeah,
but
yeah.
I
think
I,
as
adopter
said,
our
teams
job
is
going
to
change
to
be
much
more
writing
and
editorial
than
it
is
technical
from
this
release
forwards.
Basically,
so
it's
yeah
okay,
so
I
guess
an
action
from
this
is
we
will
get
this
merged
when
it's
merged
I'll,
give
you
a
ping,
and
you
can
set
up
a
meeting
and
we'll
go
from
there.
A
D
There's
one
one
last
aspect
of
this:
we
were
discussing
on
whether
we
should
edit
the
major
themes
in
public
in
in
a
more
collaboratively
way.
So
during
the
last
cycle
we
were
going
and
on
and
on
if
we
should
open
the
major
themes
document
on
so
there
was
some
discussion
on
whether
we
should
lift
the
information
embargo.
For
that
I
don't
know,
jeremy.
If,
if
something
on
that
front
has
changed
or.
A
Anyway,
if
anybody's
reading
the
github
issues,
if
they're
reading
the
enhancements
tracking
spreadsheet,
all
of
those
things
are
really
like
discernible
and
you
it's
not
like
a
top
secret.
So
I
think
that
we
had
decided
in
the
retro
that
the
embargo
didn't
really
apply
to
this
and
that
we
could
work
on
the
major
themes
and
stuff
in
the
open.
H
A
A
Yeah,
so
the
recording
will
go
to
the
the
zoom
account
and
then
tim
pepper
has
been
going
through
and
manually
copying
these
things
over
to
the
you
to
youtube
so
that
they
get
added
to
the
sig
release
playlist.
So
there's
usually
like
a
like
a
week
or
so
lag,
because
I
don't
think
he
does
it
every
day
he's
doing
it
like
once
a
week
or
so,
and
those
things
get
copied
over
to
to
youtube
and
then
he
just
adds
them
to
the
the
sig
release.