►
From YouTube: Kubernetes Sig Docs 20180327
Description
Meeting notes: https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/
The Kubernetes special interest group for documentation (SIG Docs) meets weekly to discuss improving Kubernetes documentation. This video is the meeting for 27 March 2018.
https://github.com/kubernetes/kubernetes.github.io
A
B
A
C
B
A
D
With
the
help
of
an
able-bodied
crew,
we
got
don't
1.10
ducks
posted
yesterday
and
there's
a
list
of
outstanding
items.
Steve
is
taking
care
of
a
couple
of
issues
with
two
of
the
sets
of
generated
Docs
and
which
one
of
which
came
over
with
some
odd
material
in
front
matter
and
the
other
which
had
some
troubling
dips.
That
made
me
want
to
look
at
it
more
carefully.
Steve
is
now
doing
the
more
careful
looking
at
and
then
there's
a
couple
of
other
smaller
things
that
need
taken
care
of.
D
Well,
one
of
them
is
smaller,
the
other
one
I'm,
not
too
sure
about
Andrew
I,
don't
know
whether
you
saw
on
what
I
posted
in
the
the
group
chat
about
getting
a
release
notes
imported,
but
that
and
getting
the
1.9
dogs
are
now
deprecated
notice
up
are
the
other
two
outstanding
items,
and
the
big
thing
I'd
like
to
pull
out
here
is
that,
while
everybody
has
been
has
done
their
best
document
the
process,
it's
getting
next
release
Docs
out
the
door,
the
documentation
still
used,
some
more
loves
and
I
am
hoping
to
make
that
a
priority
in
the
next
three
weeks
round.
D
A
E
D
I
didn't
see
Nick
on
this
call
and
and
I
one
of
the
things
I
just
like
to
say
it
to
this
group
and
I'm
gonna
call
it
out
in
the
released
retrospective
also,
and
we
need
to
explore
the
reason
why
release
notes
came
in
even
hotter
than
they
have
for
the
last
two
releases
when
they
were
in
fact
in
better
shape
when
I
say
they
came
in
Hunter
I
mean
they
got
a
lot
more
last-minute
attention.
We
had
people
submitting
PRS
against
the
changelog
this
morning.
D
That
did
not
happen
in
one
day
or
one
dot
night,
and
I
did
not.
I
do
not
attribute
that
to
the
quality
of
their
release.
Notes,
because
I
was
monitoring
what
Nick
and
Noah
were
doing
throughout
the
course
of
the
release
and
the
process
was
better
and
the
work
that
they
did
to
make
sure
that
appropriate,
PRS
were
documented
and
that
the
content
was
thorough
and
technically
accurate
was
over-the-top.
D
Excellent,
so
I
want
at
least
this
group
to
know
this
and
I'm
going
to
say
it
again
on
Thursday
and
say
what
were
y'all
thinking.
You
do
not
do
this
cuz.
It
was
a
superb
job,
they
did
and
I
don't
know
how
the
slippage
and
the
noise
happened.
Maybe
it's
because
we're
giving
them
more
notice,
and
so
so
is
everybody
else.
If
that's
the
case
great,
but
we,
if
that's
the
case,
we
also
need
to
improve
the
process
so
that
folks
understand
like
people
are
willing
to
say.
D
D
Mostly
that
I
was
shocked
and
dismayed
at
how
much
noise
there
was
it.
The
last
at
the
very
last
minute
and
I
think
we
need
to
discuss
that
in
the
retrospective
I.
A
A
A
So
let's
talk
about
migrating
the
website
from
jekyll
to
hugo,
to
give
you
all
an
update,
we
are
on
track.
We
have
a
meeting
set
up
for
sick
docs
maintained
errs
tomorrow
at
9:00
a.m.
Pacific
with
urinary
pettersen,
the
the
developer,
who
is
we've
contracted
to
actually
perform
the
migrations
I
think
we
will
know
a
lot
more
and
be
able
to
say
and
talk
a
lot
more
about
specifics
and
specific
aspects,
specific
specific
details
and
specific
milestones
for
the
migration
process.
After
that
meeting
tomorrow,.
A
A
D
D
I
may
be
thinking
pinging
a
few
of
you
I'm,
seeing
quite
a
few
PRS
that
look
like
they're
reasonably
safe
to
just
get
done,
and
we
talked
about
this
before
and
but
I
don't
always
feel
super
confident,
but
I
will
DM
those
of
you
who
have
helped
with
this
kind
of
thing
in
the
past.
If
I've
got
questions.
A
C
D
I'm
sorry
Andrew
to
interrupt,
but
I
just
realized.
I
know
perfectly
well
that
it
goes
through
the
Sunday,
not
Saturday,
but
Sunday
is
Easter
and
I
am
singing
and
eating
all
day.
So
if
someone
else
could
take,
Sunday
I'd
appreciate
it.
I,
don't
think
a
whole
lot
comes
in
over
the
weekend,
but
I
know
I
was
shadowing
monitoring
all
of
last
week
because
of
the
release
and
because
people
were
doing
interesting,
things
with
PRS
for
1:10
and
so
I
wanted.
A
A
lot
of
our
East
Asian
contributors,
what
we
experienced
this
Sunday
is,
you
know
already:
yeah
I
could
take
Easter
Thank.
A
E
I
A
A
C
Historically,
we
would
create
another
branch
for
the
for
the
farm
bird
and
so,
for
example,
right
now
like
1.10
is
live,
so
we
would
create
a
release
1.11
for
the
next
version,
but
this
kind
of
goes
against
the
commence
other
repost
and
so
typically
engineering
to
confuse
when
they're
trying
to
submit
PRS
in
our
repo.
So
one
thought
is
to
try
to
align
ourselves
with
the
way
they
do
it
and,
although
I'm
not
a
big
fan
of
using
master,
this
way
like
this
is
how
we
can
do
it.
C
So
currently
we
actually
juggle
three
branches
right,
so
master
like
I
said
like
right
now
is
like
well
in
this
slide
this
one,
because
I
made
this
before
the
release.
Yesterday
master
was
1.9
right
and
then
we
Sobrante
at
it
came
from
like
was
released
1-9,
so
we
would
always
use
as
a
snapshot
and
periodically.
C
The
next
version
is
I
think
this
slide
does
work
for
us
after
the
now
that
we're
on
the
one
at
10
release.
So
we
can
set
the
release
1.10
branch
to
be
the
default
branch
in
the
repo
so
that
when
people
open
up
PRS
and
stuff
that
will
be,
that
will
be
the
current
one
and
then
I
can
set
necklace.I,
which
is
our
hosting
platform.
C
C
Does
anyone
have
any
questions,
oh
right
and
then
here
are
the
three
places
that
need
the
changes
need
to
be
made.
So
there's
that
config
file
and
we
referenced
like
the
doc
branch
which
currently
is
does
master.
So
we
need
to
change
that
and
every
release,
and
also
the
github
setting
and
the
nesaf
I
think.
D
Andrew
there's
a
piece
of
this
that
I
am
either
missing
or
is
missing,
I'm,
not
sure
which,
and
so
a
is
the
idea
that
by
default
we'd
said
github
up
to
default
to
the
current
release
branch.
So
yeah
would
presumably
ignore
that.
How
well
does
this
map
to
kubernetes
kubernetes,
because
my
understanding
there
is
that
they
cherry
pick
everything
from
master
I,
understand
they're,
not
involved
with
continuous
publishing.
We
have
that
that
part
of
what
we
do
is
completely
different
and
we
can't
map
it,
and
so
it
seems
like
I,
mean
I
like
this.
B
G
G
D
Thanks
Jared
I
wasn't
sure
I'll
try
again
and
how
burdensome
would
it
be?
How
complicated
would
it
be?
How
how
much
of
a
terrible
idea
would
it
be
to
stick
with
master
only
and
with
appropriate
labels,
which
I
realize
we
still
need
to
get
compliance
with,
so
that
might
be
a
deal
breaker
right
there,
but
do
a
daily
cherry-pick
instead
of
requiring
people
to
check
in,
like
current
changes
to
a
current
branch,
that's
not
master.
D
B
E
E
Asked
myself
that
same
question,
it
seems
like
a
lot
of
work,
but
what
I've
wondered
is
if
that
could
be,
if
we
could
have
some
system
where
any
time
someone
checks
in
to
say
right
right
now,
one
1.10
is
life.
That's
where
we're
going
to
do
continuous
improvement
master
now
would
be
continuing
on
as
things
that
will
go
into
111,
and
so
what
we
want
is
anytime.
Somebody
does
a
continuous
improvement
and
checks
into
110.
That's
going
to
have
to
get
I
I'd
like
to
see
that
automatically
get
also
checked
into
master.
E
E
E
D
C
Like
is
our
goal
to
really
mimic
exactly
how
they
do
it,
or
are
we
just
sort
of
creating
sort
of
an
interface
so
that
they
can
still
operate
kind
of
the
way
that
they're
thinking,
but
is
you
know
it's
just
on
top
of
what
we
actually
do,
because
I
also
agree
that,
like
the
daily
cherry
pink
thing
would
be
a
lot
of
overhead
and
I'm
not
sure
what
it
would
actually
give
us?
You
know
like
we
need
to
get
anything
more
by
doing
that.
Yeah.
E
D
A
A
Jennifer
and
I
have
both
had
the
unpleasant
element
of
surprise,
discovering
that
we
have
not
been
merging
master
into
the
release
branch
the
entire
time.
So,
if
I,
if
I,
understand
this
diagram
correctly,
we're
still
going
to
need
to
do
that.
We're
still
going
to
have
to
move
commits
from
the
working
branch
back
into
master.
Now,
we'll
just
reverse
direction
on
how
those
goals
will
go
rather
than
merging
from
master
into
a
release.
Branch
will
be
merging
from
that
release.
Branch
into
master,
alright,.
C
G
D
This
could
ease
some
of
that
pain
Zac
if
I'm
understanding
it
correctly
for
folks,
with
less
than
absolutely
complete
permissions
on
a
repository,
is
you're
not
gonna
have
to
deal
with
master
overwriting
changes.
You
want
to
keep
in
a
branch
that
you're
merging
I
spent
a
stupid
amount
of
time
yesterday
locally
testing
this,
and
there
was
no
way
that
I
could
persuade
my
local
get
to
let
to
merge,
wanted
to
have
one
to
ten
override
master
Android's.
D
You
and
I
I
mean
at
this
point:
I
didn't
have
the
same
permissions
that
Steve
and
Andrew
do,
because
that
happened
at
the
last
minute
for
Anila
fight,
but
they
didn't
before
and
I.
Don't
think
we
want
to
go
handing
out
admin
permissions
to
absolutely
everybody
right
and
left
to
solve
this
problem,
so
that
is
so.
This
is
what
I
alluded
to
before.
That
is
the
other
issue
that
this
solves,
so
that
more
more
sorts
of
get
workflows
that
potential
maintainer
x'
might
be
accustomed
to.
I
think,
would
be
better
accommodated
by
this
approach.
D
D
I'm
not
completely
sure
about
all
my
data
here:
I
need
to
do
more
research
and
they
need
to
talk
to
Steve
and
Andrew,
and
you
to
Zack
I
think
we
need
to
discuss
a
lot
of
this
as
the
maintainer
population
expands
and
as
people
come
into
the
project
with
different
expectations
about
git,
workflows,
I
think
it
behooves
us
now
that
we're
in
this
state
to
take
a
look
again
at
what
we
expect
about
workflows
and
workflows
that
we
can
accommodate
there
being
so
many
possible
variations.
But
I
do
think
this
will
help
yeah.
B
E
Is
whoever
whoever
is
designated
as
the
person
to
do?
The
periodic
merges
from
one
tanning
to
master
will
need
to
be
in
the
admin
group
so
that
they
can
do
those
without
going
through
a
github
pull
request
and
instead,
just
through
a
local,
merge
and
push,
and
that
way
there
is
as
many
commit
numbers
as
possible
will
stay
the
same.
We
won't
have
this
situation
where
you
have
the
same
changes
made
in
the
two
branches,
but
all
the
commit
numbers
are
different.
That's
that's!
What's
been
driving
as
bad
yeah.
A
My
other
question
is
less
of
a
question
and
more
of
an
observation
that
Andrew
I
looked
ahead
in
your
slide
deck
and
you
point
out
the
three
places
that
need
to
change.
I
would
point
out
that
there's
a
fourth
and
that's
our
contributor
guidelines,
where
well:
okay,
technically
five,
our
contributor
guidelines
and
our
release
maestro
guidelines
for
what
needs
to
happen
in
the
course
of
a
release
and
what
we
expect
the
contributors
to
do
so.
Just
raising
mindfulness
to
the
the
extent
of
the
changes
that
we'll
need
to
make.
A
D
Agree
more
and
that
I
tossed
a
note
I
just
tossed
a
note
in
chat
on
I,
think
we
can
decide
about
Andrews
proposal
very
quickly.
I
think
the
larger
discussion
about
workflows
that
we
support
and
who
has
what
kinds
of
permissions
for
managing
the
Docs
during
the
release
cycle
I,
think
that
can
be
a
separate
discussion.
That's.
A
Anything
that
we
can
do
to
standardize
the
contribution
process
across
across
SIG's
and
to
eliminate
some
of
the
issues
that
we're
experiencing
in
every
release,
with
with
contributor
difficulty
and
with
release
Meister
difficulty
anything
that
we
can
do
to
minimize
those
difficulties.
I
think
is
a
good
thing,
so
I
was
going
to
say
my
vote
is
for
it,
but
I
don't
know
that
we're
a
democracy
and
I
don't
know
that
we're
please
please
I.
A
E
Have
one
suggestion
for
this
slide
that
we're
looking
at
so
today
tomorrow
and
you
know
in
the
next
few
weeks
continuous
improvement
in
this
new
new
way
of
doing
things.
Continuous
improvement
would
happen
on
your
gray
branch
there,
but
that's
its
marked
release
one
can
at
the
bottom,
and
it's
gray,
is
that
correct,
yeah.
D
G
So
I
think
I,
don't
think.
There's
a
fire
here.
I
think
we
already
have
the
hugo
plan
in
motion,
so
I
would
hate
to
do
it
here,
go
and
and
then
revamp.
How
we
do
publishing
is
the
name
I'm
not
in
the
change
all
the
variables
all
at
once
camp.
Let's
do
a
break
so
I
think
maybe
after
the
next
release,
we
should
switch
to
this
model
to
give
us
enough
time
to
actually
look
at
it,
but
we're
gonna
happen.
That's
cool
about
it!
K
That
could
mean
that
could
actually
be
a
benefit,
because
if
we
look
at
it
that
way,
we
can
look
at
it
as
taking
this
release
to
really
refine
the
process,
make
sure
all
the
documentation
is
in
place
make
sure
we
really
know
what
we're
doing
and
then
not
be
fumbling
around,
so
it
kind
of
takes
it
out
of
the
hey
we're
on
a
quarterly
release
cycle.
We
don't
have
time
to
deliberate.
G
K
E
I
I
want
to
comment
on
that,
but
first
Andrew
I
want
to
suggest
that
you
move
your
continuous
improvement
happens
up
to
the
most
recent
commit
in
that
branch.
I,
don't
know
if
the
rest
of
you
were,
you
know
are
feeling
this
way
about
it,
but
this
is
what
I
was
really
crave.
Yes,
that
I
was
really
craving
that,
as
you
know,
to
to
build
my
understanding
of
where
does
continue.
You
know
if
I
want
to
submit
something,
that's
a
little
piece
of
continuous
improvement.
Where
does
it
get
added
on
it'll
get
added
on
right?
E
There
does
that
seem
right
to
everybody,
okay
and
then
I
think
what
I
was
hearing
in
the
conversation
that
we
were
just
having?
Is
that
we're
gonna?
Stick
with
the
old?
You
know
the
current
system
for
1.11
and
then
try
to
put
this
new
thing
in
place
for
1.12.
Is
that
what
that
discussion
was
saying?
Oh.
D
Actually
had
a
different
way
of
thinking
about
the
relationship
between
this
proposal
and
the
Hyuga
migration
Jared,
which
is
we're
gonna,
freeze,
Doc's
PRS,
for
a
space
of
how
long
for
the
migration,
it's
not
insignificant.
It's
more
than
the
day
that
we
freeze
per
release.
It
seems
to
me
that
relatively
little
is
going
to
change
as
for
contributors,
not
part
of
this
group
when
they
come
back
to
working
on
ducks
after
the
Hugo
migration-
and
that
might
be
the
ideal
time
to
say.
Oh
we're
also
managing
the
branches
differently.
D
J
G
G
Think.
If
we
are
going
to
do
this
in
the
next
few
weeks,
then
we
really
need
to
put
a
team
together
that
looks
at
this
and
I
see
if
make
sure
that
we've
covered
covered
our
asses
and
and
and
can
actually
sort
of
present,
because
the
guy
on
the
surface
looks
good.
So
I
can
pick
up
some
corner
cases
that
this
might
really
hurt
us
so
and
I'm
a
big
fan
about
trying
to
change
everything
all
that
one.
G
A
A
With
the
proposal
to
to
implement
a
branching
strategy,
while
we're
also
doing
a
platform
migration
I
I
can
there
are,
there
is
some
isolation
of
concerns.
How
do
we
in
the
in
the
case
of
something
that
appears
undiagnosable
it
or
in
the
interest
of
or
when,
if
we
were,
if
we
were
experiencing
problems,
how
do
we
achieve
isolation
of
concerns
or
isolation
of
cause?
I
can
I
can
see.
A
You
know
I
agree
with
Jared
I
think
that
we
can
create
the
window
to
make
this
change
when
we
want
to
when
we're
ready.
But
I
too
would
like
to
to
to
make
this
change
with
more
deliberation,
and
with
with
that
being
the
only
thing
that
we're
focusing
on
at
the
time
as
we
do.
It
I
think
it's
a
significant
enough
change
to
the
workflow
that
it
deserves
its
own,
its
own
staging
yeah.
C
When
I,
when
I
made
this
I,
think
it
just
happened
to
coincide
with
the
one
at
ten
release,
but
it
was
mostly
just
because
people
were
have
been
talking
about
it
and
I
just
want
to
give
us
a
tactical
option
to
implement
it
whenever
we
want
so
I,
don't
I
personally
I'm
not
wishing
for
it
to
get
done
immediately.
I
just
happen
to
present
it
now,
which
happened
to
be
at
a
really
time.
E
So
here's
my
suggestion
for
what
we
do
right
away,
because,
regardless
of
whether
we
make
this
change
or
not,
we
can
we
can
help
with
the
big
octopus
github
or
get
get
branches.
If,
if
we
change
our
strategy
for
this
daily
merge
that
we
do
so
eventually
we
will
have
to
do
a
daily
or
you
know,
almost
daily
merge
of
master
in
the
release,
111
or
the
other
way,
depending
on
what
we
do
and
as
we
go
along
now,
we
need
to
do
a
may
think
what
this
is
going
to
be.
As
we
go
forward.
E
People
check
he
was
proven
into
master
that
will
need
to
have
some
sort
of
almost
a
daily
merge
into
release
1.10,
and
so,
if
we
can
get
that
process
working
better
and
done
by
someone
who
has
who's
in
the
admin
group,
who
can
do
that
with
a
local
merge
and
push
without
squashed
commits
I?
Think
that
that
in
itself
will
do
a
lot
to
alleviate
the
the
troubles
we've
had
keep
getting
these
branches
merged
when
it's
time
for
a
release.
E
Rick
I'd
say:
let's
not
do
this,
this
new
plan
right
away,
but
some,
but
let's
really
look
at
how
we're
doing
our
daily
merge
because
going
forward,
we
have
to
do
a
daily
merge
from
1-10
into
master.
Let's
look
carefully
at
who's
going
to
do
that
and
how
it's
going
to
be
done
so
that
it
doesn't
end
up
with
different
commit
numbers
in
the
two
branches
and
causing
this
kind
of
a
spaghetti.
Octopus
kind
of
you
know:
branch
branch
structure.
C
E
C
B
Just
to
clarify
what,
when
you
said,
merge
is
the
same
as
cold.
That
is
not
always
the
case,
and
people
who
work
in
other
projects
may
have
their
get.
Clients
set
up
to
do
a
rebase
on
pull
it's
actually
fairly
normal
and
it's
much
a
lot
of
people,
including
me,
consider
it
much
tidier
because
you
avoid
having
extra
merge
commits.
D
More
about
it
than
I
do,
but
this
is
what
I
was
alluding
to
earlier.
I
am
at
least
familiar
with
more
get.
Workflows
then
seem
to
be
accommodated
by
current
expectations
of
this
group,
and
that's
tripped
me
up.
It's
tripped
up
other
fall,
and
so
especially
with
you
know,
even
more
folks,
coming
on
board
who
know
more
about
other
workflows,
I
think
that
times
come
for
us
to
get
this
stuff
better
sorted.
Well,.
B
B
B
K
I
mean
what
I'm
I'm
coming
at
this
from
I.
Don't
know
very
much
about
it
and
you
guys
are
coming
in
from
people
know
too
much
about
it.
For
the
workflow
that
we're
proposing
so
I
mean
I
would
like
to
propose
that
we
really
treat
this
like
a
real
project
and
you
know
analyze
what
we
should
be
doing.
Let's
spend
this
release
analyzing
what
we're
doing
and
what
we
should
be
doing
in
a
really
deliberate
way.
Yeah.
G
G
B
Just
gonna
ask
if
we
we
have
people
in
the
room
who
have
experiences
with
different,
get
wear
clothes
I,
wonder
if
it
might
be
worth
having
a
way
for
us
to
each
sort
of
present
workflows
that
we
like,
and
why
in
an
open-minded
way,
because
it
may
be
that
we
don't
know
all
the
possibilities.
Or
some
of
us
may
have
lessons
learned
from
workflows
that
we've
considered
terrible
in
the
past.
B
G
C
A
Everything
that
Andrew
said
what
we're
doing
is
trying
to
move
ourselves
into
alignment
and
consistency
with
the
rest
of
the
kubernetes
development
community.
We
receive
complaints
every
release
about.
Why
aren't
we
doing
it
the
right
way
we
receive
regular
there?
There
are
at
least
a
handful
of
PRS
in
every
release
that
we
have
to
go
in
either
revert
or
manually
change
the
branch
because
developers
aren't
sure
is
they
are
very
accustomed
to
doing
it.
The
rest
of
the
way,
the
way
that
the
rest
of
kubernetes
works.
A
G
Miss
this
point,
though,
I
think
it's,
you
know,
I
think
some
further
research
in
this
and
I
also
think
it's
worthwhile
together
to
reach
out
to
Paris
Pittman
and
get
a
slot
of
the
next
contribute
meeting.
You
can
actually
present
this
as
an
option
and
see
if
people
like
yeah.
This
is
great
boy
like
yeah.
G
Please
don't
do
this
so
I
and
I
think
that's
also
a
good
place
to
get
other
people's
feedback
on
workflows
and
what
they
expect,
because
I
I
would
like
to
have
that
feedback
as
well
just
to
verify
with
the
community
that
like
hey.
This
is
what
you
want.
We
built
this
for
you,
as
opposed
to
like
we
made
everything
consistent
and
then
getting
feedback
that
we're
still
having
the
same
issues
that
you
mentioned
back,
where
people
still
aren't
volunteer
so
I
spot
things
like
that.
So
I.
G
E
I
I
agree
with
all
that
that,
for
whether
we
want
to
switch
to
this
new
paradigm,
let's
go
slowly.
For
the
other
thing,
though,
we
need,
we
need
to
make
a
decision
right
away
because
that
gray
branch
there
that,
with
that
one
got
ten
branch
starting
today,
needs
to
be
merged
into
master
on
an
almost
daily
basis.
So
for
that,
I'd
like
to
have
a
discussion
with
the
interested
parties,
not
right
here,
but
you
know
sometime
very
soon,
so
we
can
get
that
started
in
a
in
the
way
that
we
think
is
best.
D
E
C
So
here's
the
diagram
prefer
kind
of
how
we
currently
do
it,
although
the
release
numbers
are
kind
of
off
by
one,
but
so
the
great
brands
right
is
like
it's
kind
of
our
snapshot
branch
like
where
we
want
to
capture
like
all
the
changes
for
in
this
case.
Here,
though
intended
this
would
be
release
one
at
ten,
and
this
would
be
1.11
right.
So
so,
whenever,
like
in
a
continuous
improvement,
has
been
made,
some
master
right
we
want
to
we
want
to.
A
So
I'm
so
sorry
to
interrupt
I'm
just
looking
at
the
time
and
I
want
to
be
mindful
of
the
time
that
we
have
left
so
Chris
I
know
you've
been
very
patient
to
wait
to
talk
about
new
provider
hosting.
Do
you
have
enough
time
to
talk
in
five
minutes
about
about
the
follow
up
er?
Or
would
you
like
to
be
first
on
next
week's
agenda?
I.
L
Can
just
we
can
talk
more
about
it
next
week?
Briefly,
the
we've
migrated
all
of
the
current
cloud
providers
into
new
repositories,
and
so,
if
you
go
into
the
github
kubernetes
slash
cloud
provider
in
the
name
of
the
provider,
so
say,
OpenStack
or
or
Azure
or
AWS,
that
will
bring
up
their
repository.
We
are
we're
still
waiting
for
the
final
merge
of
of
the
proposed
layout
for
repositories,
but
but
the
cloud
provider
working
group
is,
you
know
we
pretty
much
agreed
that
you
want
documentation.
L
We
want
the
cloud
providers
want
certain
things
to
live
in
predictable
locations,
so
we
should
be
able
to
build
the
documentation
for
those
you
know
off
of
off
of
that
pull
request,
and
if
you
that
the
pull
request
is
still
active,
you
know
the
final
one
hasn't
been
merged
yet.
So,
if
you
want
to
see
that,
let
me
see
if
I
can
bring
that
up
for
you
and
drop
it
into
chat.
A
A
Right
I
had
two
more
topics
this
week
that
they
can
wait
until
next
week.
So
it
sounds
to
return
to
the
discussion
about
branching
strategy.
It
sounds
like
there's
a
lot
more
discussion
to
be
had
here.
So
do
we
need
to
continue?
Do
we
need
to
have
a
do?
We
need
to
meet
before
next
week
or
do
you
can
we?
Can
we
wait
till
next
week
and
carry
out
what
did
what
do
folks
want
to
do?
I.
C
Mean
it
seems,
like
the
consensus
was
to
hold
off
on
implementing
this,
because
I
wasn't
even
my
original
intent
to
try
to
implement
this
soon.
I
just
want
to
start
talking
about
it.
So
if
everyone
is
in
agreement,
I
think
yeah.
We
should
you
know,
take
more
time,
and
you
know
think
about
this
more
yeah.
E
D
E
E
B
B
E
E
E
And
we
don't
that
we
don't
have
to
rush
into
that,
given
that
Andrews
gonna
look
after
it
in
the
meantime-
and
you
know,
maybe
even
when
I'm
down
in
San
Francisco
might
be
the
time
that's
the
week
of
April
16th.