►
From YouTube: K8s SIG Docs Meeting for 20210413
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
Hey
everybody
welcome
to
the
weekly
sig
docs
meeting.
I
am
jim
angel.
One
of
your
co-chairs
today
is
april
13th.
It
is
10
30
pacific
on
tuesday
before
getting
started,
looks
like
all
familiar
faces
from
a
contributor
perspective.
So
welcome
back
everybody
good
to
see
everyone.
A
This
week's
updates
reminders
for
the
pr
wrangler
it
is
zach
arnold.
I
still
need
to
reach
out
to
zach,
I'm
not
sure
if
zack
is
active
or
not
so
I'll
double
check
and
take
that
action
item
right
after
this
call,
and
then
next
week
is
karen
bradshaw
or
kb
hockey
on
github.
A
All
right,
moving
on
to
today's
agenda
ray
brought
up
the
idea
of
having
a
retrospective
for
the
release.
I
thought
that
was
a
great
idea.
I
would
love
to
see
this
for
future
releases
moving
forward.
I
know
we
have
in
the
the
docs
handbook
talking
about
more
of
an
internal
retro
of
what
went
well,
but
I
think
this
is
important
to
the
wider
sig
dax
community
and
very
valuable
use
of
our
time.
So
with
that,
I
will
kick
it
over
to
ray,
and
I
want
to
congratulate
ray
also
on
a
successful
release.
A
It
was
a
fantastic
and
very
well
done.
B
I
want
to
thank
everyone
else
in
sick
docs
as
well.
So
a
lot
of
the
reviews
that
came
in
very
very
quickly
super
helpful.
I
do
want
to
make
a
note
that
having
a
stick
box,
only
a
retro
is
actually
part
of
the
handbook,
so
every
release
cycle
should
be
doing
a
retro
just
first
just
for
sick,
docs
and
stuff
all
right.
So
do
you
want
to
go
over
release?
121
just
went
out
last
week
and
the
retrospective
want
to
review
like
what
went
well,
what?
B
How
can
we
improve
the
process
and
how
we
can
improve
the
the
playbook
or
add
and
remove
stuff
and
from
the
playbook?
So
just
starting
off
with
what
went?
Well,
I
think
so.
121
we
moved
the
docs
placeholder
pr
deadline
after
code
freeze
and
in
120
we
had
it.
B
I
think
before
code
freeze-
and
I
think,
moving
the
docs
placeholder
pr
deadline
after
code
freeze
was
was
very
helpful
because
a
lot
of
contributors
are
still
busy
writing
code,
and
so
the
last
thing,
the
first
thing
on
their
mind
and
their
priority
is
just
getting
getting
their
code
in
or
getting
their
tests
in.
To
make
sure
that
they're
that
their
enhancement
is,
is
tracked
for
what
for
the
release?
B
So
I
think
that's
one
of
the
key
successes
that
went
well
and
funny.
It's
actually
part
of
the
handbook
so
well
that
the
docs
placeholder
pr
is
the
line
is
after
code
freeze,
but
for
120.
For
some
reason
we
had
it
before
code,
freeze
so
yeah.
Any
other
notes
on
what
went
well.
A
A
Work
to
prep
up
the
next
release
is
done
a
little
bit
after
the
release
cycle
and
ray
you
reached
out
to
me
early,
and
we
got
that
stuff
kind
of
hammered
out
either
a
few
hours
before
the
release,
or
I
think
it's
the
day
before
the
release.
I
think
doing
that
early
is
just
helpful
to
get
it
off
your
your
plate.
A
I
I
feel,
like
you,
there's
a
big
crescendo
up
to
the
release
and
afterwards
you
want
nothing
to
do
with
docs
for
the
release
process
and
you
want
to
enjoy
your
successful
release
after
the
case.
So
I
think
getting
that
done
early
was
a
very
big
success
and
I
wouldn't
mind
seeing
that
moving
forward
I'll.
B
I'll
I'll
elaborate
more
on
just
on
the
notes,
so
good
point.
I
also
think
what
well
is
that
all
the
reviews
for
the
docs
prs
were
always
very
quick
from
the
sigdoc
side.
I
think
that
was
awesome.
It's
always
sort
of.
Sometimes
it
can
be
pulling
too
to
get
tech
reviews.
So
that's
always
going
to
be
an
issue.
That's
not
it's
not
just
for
a
specific
release.
That's
just
always
going
to
be
because
contributors
are
busy
with
you
know
other
with
their
jobs.
B
So
so
you
want
to
make
a
note.
I
know
victor's
on
the
call,
so
I'm
sure
he's
already
seen
that
so
all
right
anything
else
for
what
in
one
wall.
B
All
right
moving
on
and
can
we
improve
the
process-
and
I
put
in
some
notes
here
once
is
the
reference
documentation
generation
which,
for
this
release
and
last
release
was,
was
also
an
issue
as
well.
So
we
needed
assistance
from
sigdoc's
members
to
to
help
generate
those
reference
stocks,
and
I
know
for
me
it's
always
been
kind
of
like
I
guess,
there's
some
that
I'm
not
aware
of
of.
B
A
I
do
feel
like
this
is
a
common
pain
and
you
know
I
haven't
personally
been
that
closely
involved.
I
know
tim
and
karen
and
xia,
ming
have
both
been
very.
All
of
them
have
been
very
active
in
the
reference
documentation
generation.
I
know
transitioning
as
well
to
the
new
format
with
what
felipe
was
doing
is
also
a
little
bit
of
a
challenge,
but
this
has
commonly
been
an
issue,
or
at
least
for
from
a
leads
perspective.
C
Tim,
we
actually
have
more
more
reference
documentation
coming
in
it's
a
good
problem
to
have,
because
teaming
has
added
reference
documentation
for
things
like
cubeconfig
and
the
exec
credential
json
format
that
you
get
when
you
run
a
credential
helper
plug-in,
which
is
all
good
to
document,
but
it
means
more
toil
at
the
moment.
C
I
wonder
if
we
have,
I
think
we
should
maybe
put
on
the
next
meetings
agenda.
You
know
which
I
would
I
would
bump
this
to
the
next
meeting
and
have
a
discussion
about
what
we
want
to
do
about
that
toil.
How
does
that
sound
as
a
discussion.
B
I
agree,
I
think
that's
a
good
discussion
to
have
and
there's
more
steps,
not
just
achieving,
but
like
felipe,
has
additional
steps
as
well
that
I
need
to
capture
in
the
doc's
role
handbook
one
of
the
things
I
I
that
concerned
me
was
knowing
what
looks
right
in
the
reference
stock
like
what
what
do
we
expect?
Does
it
look
right?
B
Is
it
ready
to
merge
after
some
reviews
and
that's
what
I
kind
of
had,
I
guess,
lack
of
clarity
on
on
like
what
should
it
look
like.
C
So
if
it
makes
you
feel
like
you're
in
good
company
ray,
I
put
in
a
a
merge
pr
that
got
reviewed
by
at
least
one
tech
lead,
and
I
made
a
mistake
by
not
deleting
some
files
that
I
should
have
deleted
in
the
manual
merge.
C
So
yeah
toil
also
leaves
an
opportunity
for
us
to
make
mistakes
that
we
might
not
want.
B
Yeah,
I
agree
so
all
right,
yeah,
let's
make
this
a
topic.
This
might
be
a
continued
discussion.
I'm
sure
there's
going
to
be
some
other
learning
curves
for
122.
and.
C
Maybe
beyond
server
side
applying
has
similar
problems
as
layla's
put
in
the
chat.
D
Yeah,
I,
it
is
not
related
to
one
so
this
like
release,
but
we
have.
I
got
similar
questions
that
are
coming
to
me
how
we
going
to
document
this
if
you
can
get
more
help
in
having
the
best
documents,
the
best
practices
and
just
look
into
those
documents
and
create
our
own
documents.
D
There
are
questions
that
are
coming
and,
if
I
am
not,
I
just
joined
last
week
to
the
sick
dogs,
but
I
would
be
very
happy
if
we
can
continue
these
conversations
around
how
what
are
the
at
least
best
practices.
So
we
can
point
people
to
here
are
the
documents
that
have
like
multiple
use,
usages
of
in
server
side
applied.
D
There
are
multiple
users
who
might
have
different
scenarios,
and
this
is
not
like
one
simple
document
to
address
everything,
but
the
scenarios
might
be
different
and
if,
in
each
case
they
are
trying
to
address
all
those
cases,
all
the
corner
cases
in
the
documents.
But
it's
not
easy
to
capture
everything
in
one
document
and
they
are
and
yeah
we
are
looking
to.
It
is
not
just
one
pr
that
I
come
here
and
ask
for
a
review
in
that.
D
Pr,
but
we
are
looking
to
examples
of
how
what
is
the
best
way
to
document
those
kind
of
things
and
people
can
easily
find
their
relevant
information
not
going
through
a
long
document
of
like
use
cases
or
scenarios,
but
just
point
to
the
relevant
information
easily
and
access
that
information
yeah.
That
is.
A
Cool,
I
would
suggest,
if
you
don't
mind,
let's
move
that
to
the
discussion
and
we
can
bring
us
back
up
and
have
a
further
discussion
around
some
general
best
practices.
Today
after
we
talk
about
the
release
piece
but
yeah,
I
think
it's
a
great
point.
I
do
have
some
questions
or
some
comments
on
that
area
and
I'm
sure
other
folks
do
as
well.
But
let
me
let
me
move
that
to
the
discussion
area
and
we'll
pick
that
back
up
in
just
a
little
bit.
A
B
Okay,
moving
on
for
localization
team
teams,
so
part
of
the
release
earlier
early
on
the
release
cycle,
we
create
a
github
issue
just
to
gather
who
the
who
is
the
contact
for
each
localization
team
and
for
and
we've
talked
about
this
before,
as
well,
just
moving
it
to
a
github
discussion.
B
So
it's
not
it's
no
longer
an
issue,
but
just
have
a
continued
discussion
to
for
any
any
announcements
as
well
for
this,
for
the
teams
to
like
state
if
there's
a
repo
for
using
in
in
the
timeline
as
well.
So
I
know
that's
a
prior
topic,
we've
discussed
and
so
that's
something
that
we
will
probably
end.
I
will
change
in
the
handbook
to
implement
for
122.
A
Do
you
find
benefit
in
reaching
out
to
the
localization
leads?
I
know
when
we
originally
started
doing
this.
It
was
more
just
general
awareness.
No
one
was
really
sure
if
we
should
or
shouldn't
be
doing
this.
Ideally,
some
of
the
localization
leads
are
plugged
into
sig
docs
as
well.
There's
the
monthly
meeting-
and
I
guess
what
I'm
bringing
up
here
is.
Is
this
a
necessary
step
and
is
it
beneficial
and
are
we
finding
value
in
it.
B
I
think
the
biggest
necessary
step
is
to
is
the
timeline
for
the
repro
freeze,
so
that
they're
aware
and
the
release
dates
as
well,
and
I
bought.
I
took
it
one
more
step,
even
though
I
was
in
the
handbook,
I
actually
pinged
every
localization
team
on
slack
just
to
make
sure
that
they
were
aware
of
the
repro
freeze
and
in
the
timeline
as
well,
even
though
it
is
on
the
github
issue,
but
only
only
the
owners,
but
there's
there's
definitely
a
lot
of
number
of
members
for
each
team.
B
All
right,
one
more
just
like
a
sub
topic
on,
so
we
had
some
con.
We
had
some
concern
and
this
is
from
the
side
channel
that
anna
put
in
so
we
have
some
concern
with
the
noise
of
collecting
primary
contacts
during
the
release,
and
just
we
don't
know
what
we
can
improve
on
with
that.
B
But
that's
always
a
concern
with
with
every
release
of
just
trying
to
find
the
right
contact
for
pr
reviews,
mostly
for
for
docs,
but
on
the
dock
side
of
things.
But
this
is
also
an
issue
for
other
teams
as
well,
but
for
top
for
docs,
primarily
creating
those
prs
and
for
pr
reviews-
and
I
don't
know-
I
don't-
have
the
right
answer
for
that-.
A
Yeah,
I
know
that
we,
this
seems
to
be
something
that
comes
up
each
release
cycle
and,
unfortunately,
I
don't
think
there's
a
great
answer:
you're
going
to
be
stuck
identifying
that
point
person
one
way
or
the
other,
whether
it's
you
know
later
on
in
the
release
or
early.
I
would
love
to
hear
folks
of
any
other
ideas
or
suggestions
around
the
topic
like
this.
This
is
a
challenge
it's
chicken
and
egg.
You
know
you
don't
really
have
a
data
set
or
a
listing.
A
B
B
I
know
for
other
teams
they've
gone
into
like
a
into
a
more
like
an
opt-in
approach,
so
that
there
is
someone
who
is
a
contact
that
opts
in
but
docs
is
once
enhancement
is
opt-in.
B
It
docs
is
pretty
much
either
knee
docks.
You
don't
need
docs
and
there's
no
other
opt-in.
I
guess
there
can
be
an
opt-in,
but
or
that
I
don't
know
I
just
don't
know
what
the
right
answer
is
because
we've,
even
though
what
didn't
with
the
opt-in
process,
sometimes
it
was
still
hard
to
to
contact
the
person
who
did
opt-in
or
the
group
that
did
opt-in
for
the
right
to
make
a
placeholder
pr
or
just
to
or
for
pr
review.
So.
C
B
No,
I
think
this
is
for
just
primary
contacts
of
the
doc
owners
or
doc,
or
the
tech
reviews
on
for
some
of
the
for
some
of
the
doc
prs
just
contact
on
if,
if
the
for
the
enhancement
owner,
this
is
an
odd
one.
So
this
is,
if
just
contact
the
enhanced
builder,
if
they
it
just
to
confirm
they
do
or
do
not
need
docs,
because
the
enhancement.
C
So
maybe
like
well,
I'm
gonna
suggest
something,
and
then
you
can
tell
me
how
far
off
it
is
from
from
addressing
the
right
thing,
whether
it's
the
right
solution
is
it
is.
It
aren't
trying
to
answer
the
right
question
and
the
the
suggestion
is.
Six
could
opt
into
nominating
a
a
point
person
for
dox
liaison
for
release.
B
I
like
that
we
can
make
that's
part
of
the
enhancements
opt-in
process
just
to
there.
There
is
a
change
to
the
enhancements
opt-in
process
for
122..
I
don't
know
what
that
process
is,
but
we'll
I
have
that
as
a
description
topic
on
thursday
for
the
retro
for
the
121
retro.
I
like
that,
just
having
an
additional
you
know,
doc's
liaison.
A
Perfect-
and
I
was
trying
to
break
up
two
looks
like
anna
had
kind
of
like
two
and
one.
We
were
talking
a
little
bit
about
localization
just
now.
We
kind
of
diverged
into
talking
about
the
enhancement
owners
and
the
responsiveness
there
so
try
to
split
it
up,
but
if
I
knew
it
was
followed
along
in
the
agenda,
hopefully
I
didn't
butcher
it
or,
if
anna's
watching
this
on
replay.
Hopefully
I'm
not
missing
the
intent
of
the
question,
but
I've
broken
it
now
into
the
do.
A
We
need
to
collect
a
primary
contact
for
enhancement,
docs,
they're
kind
of
chasing
down
the
the
technical
liaison
or
the
docs
liaison
for
that
specific
enhancement,
and
then
I've
broken
the
one
we
just
talked
about
as
far
as
tagging,
the
localization
owners
and
the
github
groups,
and
that's
where
we
notify
the
localization
teams
of
you
know
some
of
those
important
dates
like
where
I
was
talking
about.
B
All
right,
all
right,
let's
continue
one
more
big
topic
is:
how
can
we
improve
the
playbook
that
the
doxwell
handbook
can
remove,
add
or
remove
stuff
from
the
docs
handbook?
One
thing
I
noticed
in
this
release:
we
had
more
merge
conflicts
when
we
did
branch
sync.
So
during
the
release
cycle
every
week
we
have
a.
B
We
have
a
dev
branch
and
we
would
sync
that
with
the
master
branch,
this
benefits
us
at
the
end,
where
we
don't
have
to
deal
with
all
the
merge
conflicts
that
might
happen
this
wheelie
cycle,
I
noticed
we
did
have
more
merge
conflicts,
but
I
think
a
lot
of
them
would
have
been
solved
if
we
just
had
the
requirement
to
squash,
commits
or
and
also
build
errors,
I'm
sorry
it.
We
had
some
built
more
billet
errors,
but
I
believe
that
they
would
have
been
solved
by
squashing
commits.
B
I
know
it
is
a
sick
kind
of
a
sick
box
thing
to
prefer
to
squash
commits,
but
I
think
I
need
to
state
that
in
the
doc's
role
handbook
is
to
ask
ask
authors
to
squash
your
commits
before
we
emerge
them,
and
also-
and
maybe
after
n
number
of
days
just
and
if
the
author
isn't
responding
to
just
add
that
power
label
to
squash
commits
where
you
guys.
B
900
sure,
but
and
changes
I
think
that's
more
builders
than
merge
conflicts,
I'm
not
100
sure,
but
I
I
know
that
the
additional
commits
in
the
polls
usually
the
same,
pull
requests
you
just.
You
usually
fix
this,
that
those
build
errors.
A
A
I'm
definitely
somewhat
of
a
get
novice
as
well,
but
I
would
say
two
years
ago,
or
so.
The
default
strategy
on
the
k,
slash
website
repository
was
to
squash
automatically.
So
when
you
approved
a
pr
and
you
you
know,
lgtm
slash,
approve
prowl.
The
piece
actually
merges
that
commit
into
the
code
base
would
squash.
It
use
the
title
of
the
pr
and
add
it
to
k,
website
and
ultimately,
what's
happening.
A
Ultimately,
what
happened
was
if
we
stopped
prow
from
automatically
squashing
prs
now
we
could
empower
all
of
the
release,
leads
to
open
up
their
own
separate
pr
to
do
a
synchronization
between
master
branch
or
the
main
branch
and
the
dev
dash.
Whatever
the
current
release
cycle
is,
so
it's
really
a
matter
of
stopping
the
automation
from
automatically
squashing
and
putting
that
pr
as
a
single
commit
unit
into
a
k
website
to
empower
now
the
release
team
to
make
those
changes
in
a
separate
pr.
A
The
trade-off
now
is
that
anybody
who
creates
a
pr
on
k
website
on
the
development
branch
doesn't
matter
where,
if
it
has
multiple
commits
those
commits,
are
all
going
to
be
merged
into
k,
slash
website,
as
is
so,
if
you
have
a
pr
with
two
separate
commits
around
the
same.
You
know,
subject:
area
topic,
those
will
be
merged
into
the
main,
whatever
branch
you're
targeting
as
those
two
exact
commits.
A
So
the
general
rule
of
thumb
is
to
squash
your
commits
it's
kind
of
one
unit
of
work.
It
is
okay
to
have
multiple
commits.
If
you're
doing
multiple
units
of
work,
you
could
have
a
commit
for
activity
a
another
commit
for
activity
b
if
they're
separate
activities,
but
ultimately
it's
a
good
rule
of
thumb
just
to
squash
it
manually,
and
so
we're
talking
about
here
is,
since
the
automation
is
not
going
to
squash.
A
C
So
if
someone's
got
a
branch,
that
is
a
long
way
behind
the
development
branch
or
you
know
yeah
they're
a
long
way
behind
and
they
want
to
make
some
changes,
whether
those
changes
target
a
development
branch
or
the
primary
branch.
C
If
they
make
those
changes,
then
there's
a
big,
a
long
gap
that
git
or
whatever
has
to
automatically
resolve
and
git,
is
greater.
This
git
will
solve
all
manner
of
differences
automatically.
It
tries
really
hard
if
they
take
that
pull
request,
and
then
they
rebase
it
against
the
target
branch.
Where
you
know
so
def-1.22
or
master
or
main
when
we
switch,
then
git
hasn't
got
much
work
to
do
it
can.
In
the
easiest
case
it
says,
that's
a
fast
forward.
C
I
have
nothing
to
do
and
whether
we
then
squash
merge
that
or
use
a
traditional
git
merge.
We
are
giving
git
less
work
to
do,
but
making
less
work
for
git
means
that
the
author
must
rebase
their
changes
themselves.
It's
not
a
thing
that
the
get
hub
web
ui
can
do
you.
The
author
must
know
how
to
rebase.
Not
everyone
does
it's.
A
Yeah,
I
would
completely
agree
with
that,
and
I
I
would
like
to
see
for
the
next
release
cycle
when
we
start
running
into
some
of
these
edge
cases
or
victor.
When
some
of
this
stuff
starts
coming
up,
it'd
be
great
to
bring
up
and
surface
to
sync
docs
and
see
you
know:
do
we
need
to
do
more
squashing?
A
Do
we
need
to
do
more
rebasing
like
let's
bring
these
problems
up
to
the
weekly
meeting
and
then
real
quick
here
just
for
folks,
I'm
sharing
this
more
for
for
my
sake,
but
I
feel
like
it
might
benefit
some
other
folks,
I'm
a
very
visual
learner,
and
so
what
I
wanted
to
share
here
is
a
little
bit
of
what
we're
talking
about
not
spend
a
ton
of
time
here,
but
talking
about
the
difference
of
when
a
feature
is
merged
versus
when
a
feature
is
rebased,
and
this
isn't
a
perfect
example.
A
But
what
is
showing
here
is
if
I
had
a
main
or
master
branch
here.
This
is
this
red
line
and
I
were
to
create
a
new
feature
branch
called
a
b
over
here,
and
I
make
some
changes
to
it.
When
I
want
to
merge
that
in
you
can
see
here
in
a
traditional
merge
since
lgtm
approve
that
feature
branch
is
then
merged
in
to
create
a
brand
new
commit
on
the
overall
main
branch.
A
A
No
and
you're
spot
on
and
this
document
does
not
really
capture.
I
think
tim
you
and
I
are
on
the
same
page.
I
thought
this
was
a
great
visual
to
show
rebasing
starting
at
that
commit
point,
but
you're
spot
on
we're
not
talking
about
the
action
after
the
pr
is
there
whether
it's
merge
versus
rebase
from
the
pr
to
the
branch
we're
talking
mainly
about
when
you've
created
the
pr
some
time
has
passed
by
multiple
changes
have
happened
on
that
branch
and
rebasing
then
starts
that
change.
On
top
of
the
latest
point
in
time,.
C
Unfortunately,
you
know
lots
of
technical
writers
are
not
people
who
use
git
in
detail
and
that's
fine.
I
think
it's
incumbent
on
sig
docs
to
make
a
strong
effort
to
lower
those
barriers
to
entry.
So
the
people
who
are
good
tech
writers
haven't
put
weeks
into
learning
git
in
detail,
can
can
be
good
tech,
writers.
C
Small
branch
tangent,
we
could
build
a
visualization
that
we
could
build
some
metrics
around
how
different
releases
looked
in
terms
of
you
know
how
staleness
this
sounds
like
a
bad
term,
but
how
stale
were
people's
forks
when
we
merged
in
their
changes-
and
you
know,
is
that
important?
Does
the
staleness
metric
correspond
with
the
sort
of
the
pain
that
release
leads,
are
feeling,
for
example,
and
if
it
is,
can
we
surface
that
to
to
make
people
have
informed
choices
about
maybe
nagging
a
rebase
or
whatever.
A
Yeah,
I
think
that'd
be
great
to
look
into
and
sorry
to
go
off
on
a
complete
tangent
there
ray
back
back
over
to
you.
B
All
good
points
all
right,
any
other
questions
with
with
these
more
builders
might
be
squashy
might
be
good.
We
basically
might
be
good.
C
C
C
I
think
we
might
be
and
we're
on
the
enterprise
price
plan.
I
think
so.
I
think
we
might
be
pushing
the
envelope
a
bit
of
what
netlify
can
comfortably
cope
with
for
us.
I
might
be
wrong.
It
might
be
loads
of
resources
and
there's
another
issue,
but
you
know
my
32
core
laptops
strains
a
bit
when
I
build
the
site.
B
All
right
good
point,
all
right
and
moving
on,
so
one
of
the
steps
in
the
release
cycle
is
to
create
the
release
branch,
so
121
was
released,
so
one
of
the
steps
was
to
create
the
release
dash
1.20
branch
to
capture
the
120
docs,
as
as
it
were.
I
did
this
right
before
the
repo
freeze
on
the
same
day,
and
I
did
this
on
purpose
because
on
the
handbook,
it
just
tells
you
to
do
it
during
the
during
the
week.
B
But
if
you
do
do
it
early
in
the
week
and
the
releases
later
in
the
week,
you
would
have
to
sync
this
release
branch.
So
I
purposely
for
two
reasons.
One
is
that
you
need
specific
rights
to
the
to
the
repo
to
create
the
branch.
These
rights
aren't
usually
given
until
the
day
before
the
release
anyway.
B
So
that's
why
I
made
it
so
right.
I
made
it
to
that
when
I
did
have
the
rights
to
create
the
branch.
It's
also
on
the
same
day
that
we
did
the
repro
freeze.
So
I
just
created
that
release
branch
right
before
I
still
suggest
to
always
confirm
to
make
sure
that
the
release
branch
is
still
in
sync,
with
with
the
master
branch
same
with
the
dev
121
or
the
future
branch,
to
make
sure
that
those
are
still
in
sync
and
also
what
I
propose.
B
I
guess
tasks
I
propose
to
change
in
the
release
handbook,
mostly
just
having
a
set
date
for
it
and
the
release
handbook
it's
it's
kind
of
it
just
says
dude,
just
it
just
says
it
and
during
the
release
week,
but
I'll
put
reasons
why
having
the
right
permissions
and
also
also
to
make
sure
that
it's
more
in
line
with
master
branch.
B
Alright,
going
on
to
the
next
one
so
part
of
the
release
cycle,
we
also
modified
the
config.tamil
files,
not
just
for
the
master
branch,
but
also
on
the
on
the
other
branches.
For
previous
versions
for
like
121
120,
118
117.
B
We
we
have,
we
typically
add
in
the
patch
versions
as
well,
but
jim,
and
I
were
talking
about
not
doing
the
patch
versions
because
after
a
month,
those
patch
versions
are
not
in
line
anymore,
and
we
should
do
some
testing
to
see
if
that
actually
affects
anything
so
with
the
config.tamil
files,
because
even
though
we
it's
up
to
date
at
the
day
of
release,
but
after
the
day
out
by
the
time,
the
next
patch
comes,
it's
not
updated,
so
they're
out
of
line
anyway.
A
Yeah
and
just
add
some
more
clarity
around
this.
This
came
up
at
one
of
our
quarterly
reviews
and
potentially
something
worth
carrying
through
to
our
next
quarterly
review
meeting.
If
we
don't
have
some
additional
progress
on
there,
so
there's
a
few
links
in
the
kubernetes
website
that
use
a
short
code
or
basically
a
key
to
value
in
this
config.toml
to
generate
on
the
fly,
a
url
linking
to
a
specific
kubernetes
version.
A
So
I
think,
for
example,
cube
cuddle
is
a
good
example
of
that,
where
you
download
the
latest
using
a
or
you
can
download
a
specific
version
using
a
specific
version
down
to
the
patch
tag
itself.
So
there
are
areas
in
the
documentation
that
leverage
this
this
variable
that
is
set
in
the
config.tamil.
A
However,
as
ray
pointed
out,
it
goes
very
still
very
quickly,
and
so,
if
it's
not
really
representing
the
true
state
of
the
world,
it
might
not
be
worth,
including
and
beyond
that.
I
think
that
this
could
fall
under
there's
some
efforts
going
on
right
now
around
creating
a
release
page
potentially,
whatever
solution
comes
about
to
create
the
release
page
will
involve
the
latest
patch
release
to
some
extent,
whether
that's
a
data
file
in
the
repository
or
an
api
that's
getting
hit.
A
Ultimately,
the
most
latest
patch
will
be
accurate
and
on
this
release
page
and
potentially
we
could
fold
that
into
the
efforts
there.
So
I
think
this
is
a
larger
undertaking
beyond
even
the
release
team
happy
to
have
other
folks
jump
in
and
help
out
with
as
well
any
other
questions
or
comments
around
this
piece.
A
Cool
not
hearing
too
much.
I
I
do
think
that
this
is
a
worthy
effort.
I
I
just
think
that
it
might
even
be
broader
than
the
sig
ducks
release
team
and
I
think
it
might
fold
under
that
release
page
initiative
and
might
be
something
worth
tracking
under
the
quarterly
planning.
If
folks
are
willing
to
do
so,.
C
I
guess
I'll
add
that
the
sort
of
automation
that
I
had
in
mind
to
deal
with
the
toil
of
opera
updating
reference
docs
would
be
the
same
kind
of
automation
that
I
would
use
to
bump
a
minor
sorry,
a
patch
version
automatically.
B
All
right
last
two
sub
topics
are
sublets
part
of
the
release
cycle.
We
we
literally
just
copy
and
paste
what's
in
the
release,
notes
to
a
file
on
the
on
k
website,
so
one
of
them.
So
what
I
propose
is
to
just
linking
to
the
release
notes
instead,
I'll
have
to
see
if
how
that
affects
that
page,
but
that's
one
possibility.
Instead
of
doing
a
copy
and
paste.
A
I'm
a
strong
plus
one,
it's
one
of
those
things
I
think
has
been
done
for
past
releases.
I
even
did
it
you
know
many
moons
ago
and
I
think
no
one's
really
sat
there
and
questioned
it,
but
the
fact
that
we
copy
it
much
like
the
the
minor
release
or
the
patch
version
is
as
soon
as
there's
a
new
minor
patch
release
of
kubernetes.
A
Those
release
notes
are
out
of
date,
so
I
I'm
in
favor
of
immediately
removing
it
and
replacing
it
with
the
url
to
github's
release
notes
at
least
for
right
now
or
whatever
the
appropriate
landing
spot
is.
I
think
a
future
state
potentially
is
even
eliminating
that
page
and
kind
of
consolidating
under
that
releases
page
and
linking
out
the
proper
assets,
but
we
have
strong
plus
one
there.
Does
anyone
have
any
opinions
against,
like?
I
guess,
keeping
that
in
the
k
website
repository
not
linking
the
true
source?
A
C
Release
notes
that
look
like
a
website
long
term,
I'm
very
happy
to
have
things
tidied
up
now,
because
that's
better,
but
if
we,
if
we
can't
make
sort
of
release,
notes
that
look
like
a
website,
I
think
it
damages
people's
impression
of
kubernetes.
Just
at
the
point
they're
considering
trying
it.
A
There's
also,
I
think,
there's
the
I
forget
the
is
it
sprawl
notes
or
there's
the
official
release
notes
sub
project
website.
That
also
could
be
part
of
this
discussion
of
folding,
underneath
into
either
k
website
or
something
similar
to
that,
but
once
again
a
little
bit
larger
of
an
undertaking,
but
at
least
actionable
things
we
can
talk
about
today.
It
sounds
like
we're
all
generally
in
favor
of
not
duplicating
that
effort
or,
at
the
very
least,
linking
to
a
true
source.
B
All
right,
the
last
one
is
more
procedural
is
one
of
we
als.
One
of
the
last
steps
we
do
in
the
release
cycle
is
to
create
some
tags
for
the
last
commit
of
the
release,
branch
of
the
current
release
and
the
initial
commit
of
the
of
the
new
release.
So
I
wanted
just
to
update
the
steps
because,
because
I
think
there
is
a
better
way
to
confirming
what
the
last
commit
hash
of
the
previous
release
is.
So
that's
just
something
more
procedural.
B
I'm
for
it
all
right
and
okay
and
I'll
have
a
pull
request
for
the
updates
for
the
changes
to
handbook
in
a
few
days
for
people
to
review.
A
A
E
No,
not
really.
I
got
pinked
from
the
release
lead
today
and
basically,
what
she
said
was
she's
going
to
update
us,
but
the
start
dates
start
date.
Sorry
week
one
will
begin
on
19th
of
april.
That's
that's
what
I
got
so
far
so
once
that
once
that
starts
I'll,
follow
the
handbook
and
you
know,
collaborate
with
enhancements
and
so
on
and
we'll
take
it
from
there.
I
guess
I'll
keep
you
updated.
If
I,
if
I
hear
anything
else.
C
Yeah
sure
we've
got
a
few
upcoming
articles.
We've
got
a
bunch
of
release
articles
mr
bobby
tables,
and
I
have
really
been
reviewing
these
recently.
I'm
gonna
segue
straight
into
the
next
point.
The
blog
team
is
looking
for
reviewers.
C
Now
we
did
have
rolf
on
the
call
earlier
so
rolf
if
you're,
watching
this
on
on
on
the
class,
one
channel
or
otherwise
yeah
you're
welcome
to
to
step
forward.
Everyone
is
welcome
to
step
forward
and
look
at
joining
the
book
team.
More
formally,
we
could
really
use.
We
have
a
backlog.
People
are
putting
forward
articles
that
are
worth
publishing
and
sig.
Docs
is
not
getting
through
the
backlog
of
reviews
to
get
those
published.
C
I
don't
know
like
the
blog
team
is
so
I
I
I
think,
sparse
that
we
probably
need
to
come
up
with
a
new
process
as
well.
I
know
in
the
past
there
was
a
sort
of
a
a
spreadsheet
of
how
we
do
things,
but
I
don't
know
if
I
need
to
keep
that.
I
think
what
we
need
is
a
really
mostly
more
people,
and
then
we
can
come
up
with
process
and
liaise
with
former
contributors
and
so
on
that
side.
But
people
is
what
we
need
most.
F
No,
I
had
the
the
same
question
that
you
asked
exactly
I'd,
be
happy
to
help
and
was
wondering
how
and
so.
C
Come
and
help
me
figure
out.
You
know
what
we
what
we
need
to
do.
A
Awesome,
I
know
at
the
very
least
there
is
the
sig
docs
blog
channel
on
slack,
and
I
think
that
there's
that
would
be
a
good
starting
point
at
least
making
noise
in
that
channel.
Saying,
hey,
look!
I'm
here,
I'm
ready
to
help.
I
feel
like
that
at
least
is
a
good
p0.
If
you
will.
G
I
just
hope
to
share
that
korean
localization
team
started
the
first
milestone
for
121,
the
friendship,
1
20,
21
ko1,
and
thank
you
for
the
great
job
from
the
release
team
and
we
are
actually
very
scheduled
well,
since
we
are
very
important
for
the
master
wrench,
please
and
release
schedule,
so
we
are
good
to
go.
G
A
Awesome
yeah.
Thank
you
very
much.
It
sounds
like
things
are
on
track
there
and,
as
always,
the
korean
localization
is
absolutely
crushing
it
when
it
comes
to
staying
on
top
of
the
releases.
So
I
really
appreciate
that
and
thank
you.
A
All
right
moving
on
this
is
blank
right
now
I'll,
throw
it
out
there.
Any
issues
or
prs
folks
would
like
to
talk
about
today.
A
All
right
hearing
a
whole
lot
of
nothing.
We
will
move
on
to
the
discussion,
so
we
do
have
about
seven
more
minutes
left
in
the
call
leila.
I
want
to
make
sure
you
get
the
appropriate
amount
of
time
for
your
discussion
point.
So
if
we,
for
whatever
reason,
can't
finish
up
what
we
need
to
finish
up
in
the
next
six
or
seven
minutes
here,
we
can
definitely
bring
this
up
next
week
as
well
to
go
to
go
further
into
it.
A
So
the
question
I
was
brought
up
earlier
and
why
I
pulled
this
down
to
the
discussion
spot
was
talking
about
general
documentation,
best
practices
in
particular
for
this
one
server
side
apply,
and
I
do
have
thoughts
and
opinions
on
you
know
documentation
and
kubernetes
website,
but
I'm
curious
to
hear
other
folks.
First,
I
don't
want
to
be
the
only
one
talking
on
this,
especially
with
the
limited
amount
of
time.
Any
other
thoughts
comments.
Best
practices
folks
would
like
to
share.
A
All
right,
you're,
not
hearing
too
much
I'll
start
kicking
us
off,
at
least
so
I
do
know
that
I'd
say.
Probably
the
number
one
resource
for
contributing
to
kubernetes,
especially
the
documentation,
is
our
own
contributing
docs
themselves,
but
more
specifically,
there's
a
style
guide
within
side
of
the
documentation
outlining
acceptable
and
and
what
is
required
from
a
technical
writing
standpoint,
and
this
isn't
so
much
about
information
architecture
and
organizing
the
discoverability
of
the
documentation.
A
However,
it
does
outline
very
clearly
do's
and
don'ts
of
good
documentation,
and
I
think
you
know
I'm
not
the
the
best
technical
writer.
I
I
didn't
have
a
background.
Technical
writing.
When
I
joined
sig
docs
and
this
style
guide
has
became
a
go-to
handbook
as
well
as
I
continuously
learn
from
it,
and
I
try
to
apply
it
my
day-to-day
writing.
A
D
A
D
How
about
now
that
can
you
hear
perfect?
Thank
you
yeah.
That
is
a
perfect,
like
those
examples
would
help
us
a
lot
so
that
those
are
the
things
that
we
don't
want
to
just
create
a
blog
or
one
feature
with
some
documents
around
it.
But
we
have
the
things
that
might
and
it
is
evolving
so
and
maybe
in
future
we
want
to
add
used
cases,
or
there
are
some
of
the
things
that
are
not
documented
yet,
but
we
will
add
to
the
current
argument,
but
yeah.
A
Yeah
awesome
yeah.
I
would
highly
recommend
going
through
the
contributing
docs,
especially
the
style
guide,
that
I've
added
in
there
and
then
I
think
from
that
point
forward.
If
there's
any
specific
questions
such
as,
how
do
I
do
something
like
x
to
create
y-
or
you
know
some
sort
of
direct
question
potentially
folks
here
could
help
out,
or
maybe
even
on
slack
there's
a
more
pointed
question.
D
Thank
you
yeah.
We
were
thinking
about
like
adding
the
tabs.
It
might
be
easier
to
like
just
writing
a
long
document.
So
if
I
have
those
specific
questions,
I
will
contact
sick
dogs
around
those
specific
things.
Thank
you.
Thank
you.
H
Oh
hi
yeah
I
used
to
I'm
working
on
some
other
open
source
documentation.
I
was
using
master.
Is
it
now
been
superseded
by
control,
plane
or
just
control,
plane,
node.
H
A
C
That
the
control
plane
is
the
bit
of
kubernetes
that
isn't
the
node
essentially
and
runs
the
control
loops
and
so
on
now,
depending
on
how
you're
running
your
cluster,
you
might
run
your
control
plane
on
nodes
or
you
might
not
have
things
like
kubelet
involved
in
running
the
control
plane
software
tool,
you
might
run
it
directly
via
systemd.
C
It's
still
the
control
plane,
no
matter
what,
but,
if
you're,
using
a
cube
atom
to
launch
your
cluster,
then
you
have
nodes
that
have
control
plane,
nodes
and
are
tainted
to
not
take
workload,
pods
and
so
on
so
control
plane.
Node
is
a
completely
valid
term
for
some
clusters.
C
Control
plane
is
always
a
valid
term
and
no
matter
what
tooling
you
use
to
deploy
your
cluster,
you
can
always
talk
about
control,
plane
and
in
terms
of
what's
the
thing
that
the
cubelets
register
with
and
that
you
talk
to
when
you
want
to
use
the
kubernetes
api,
we
do
not
call
that
the
master
we've
moved
away
from
that
terminology.
H
A
So
it
sounds
like
when,
in
doubt,
control
plane
would
be
a
good
de
facto
standard
unless
specifically
referring
to
a
control
plane.
Node
is
that
fair.
C
That's
yeah
and
you
will
also
find
the
word
you
know
master
in
the
documentation,
a
couple
of
places
where
we
need
to
clear
it
up.
It
might
be
talking
about
a
replicated
stateful
set
which
might
previously
been
called
multi-master,
and
we
now
want
to
use
different
terminology.
C
There
is
a
dedicated
working
group,
wg
naming
and
celeste
horgan,
who
is
also
a
sig.
Docs
contributor,
is
a
good
person
who
who
to
ask
if
you've
got
any
thorny
questions.
I
actually
think
that
one
about
is
it
called
the
control
plane.
I
think
that's
a
pretty
straightforward
one
and
I
hope,
that's
covered
in
the
style
guide.
If
not,
I
guess
we
take
pr's.
C
I
Awesome
and
with
that
we
are
one
minute
over
chris
sorry,
you
have
a
question.
You
know.
I
was
just
going
to
make
a
quick
comment
on
that.
I
looked
into
that
same
issue
and
when
I
talked
to
some
people
who
set
these
things
up,
they
said
the
difference
between
like
a
a
worker
like
a
node
and
the
control
plane
is
that
a
worker
node
basically
is
just
always
a
cubelet
and
and
a
run
time.
So
basically,
a
worker
node
is
always
kind
of
the
same
thing.
I
Control
plane
can
be
split
across
a
bunch
of
different
nodes
and
split
up
in
a
bunch
of
different
ways.
That's
why
there
are
some
implementations
that
will
have
specific
worker.
I'm
sorry
master
nodes
that
are
now
basically
control
plane
nodes,
but
then
others
will
have
like
fcd
split
outs
in
separate
ways.
It
will
have
other
services
split
out
in
separate
ways.
So
it's
not
like
necessarily
a
one
for
one
kind
of
thing
like
a
like
a
node
is
a
worker.
The
compute
node
is.
A
A
Yeah,
that's
a
very
good
point.
I
think
it's
very
along
the
same
lines
of
what
tim
was
referring
to
so
context
is
really
important
there.
It
sounds
like
cool
all
right
with
that
we're
a
few
minutes
over
so
being
respectful
of
folks
time.
I
appreciate
y'all
chatting
if
we
want
to
continue
this
conversation.
Let's
pick
it
back
up
next
week
or
in
slack
and
y'all
have
a
good
week
thanks
a
lot
bye.