►
From YouTube: 20201110 SIG Arch Enhancements
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
A
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,
so
we
have
been
working
on
chatting
about
and
chatting
about
and
writing
up
some
stuff
and
writing
up
some
more
stuff
and
chatting
about
the
stuff
that
we
wrote
up
and
now
hacking
on
some
of
that
stuff
related
to
the
release
the
receipts
process
right.
So
the
receipts
process
is
for
new
folks.
Actually,
actually,
let's
do
this.
A
First,
we
have
some
new
folks
on
the
call,
if
you'd
like
to
say
a
few
words
about
yourself.
Why
you're,
here,
what
you're
looking
to
get
out
of
it,
where
you
work
all
those
good
things,
feel
free.
B
I
guess
I'll
start.
My
name
is
adam
malloy,
I'm
I
work
for
obviously
workday.
My
apologies
for
the
branded
background,
but
so
you
know
I
have
I've
been
working
with
the
workday
kubernetes
platform
for
about
a
year
now,
so
I'm
the
product
manager,
that's
responsible
for
their
kubernetes
platform.
Inside
the
workday
data
centers
I've
been
working
nearly
four
years.
C
I'll
go.
I've
been
part
of
the
sick,
willis
team
for
a
while
now,
and
I
have
a
shadow
for
enhancement
team
before
and
I
work
at
vmware.
I
was
working
with
kubernetes
for
a
while,
but
I
no
longer
do
but
still
part
of
the
kubernetes
a
string
contribution
team.
So
I
was
just
really
interested
when
I
heard
about
the
receipt
process,
so
I
just
wanted
to
know
a
little
bit
more
about
it
and
see
if
I
can
help
out
here.
A
Awesome
anyone
else
want
to.
D
A
Okay,
so
just
to
give
everyone
a
quick
briefing
on
the
receipts
process.
The
intention
behind
that
you'll
see
in
the
agenda
that
laurie
and
and
gang
have
linked
the
receipts
process
roadmap,
so
that's
kind
of
where
we've
been
dumping.
A
The
idea
here
is
to
track
all
of
the
actions
and
git
no
more
of
the
mixing
of
the
comments
on
issues
and
in
the
kep
itself,
and
the
general
back
and
forth
of
the
release
team
tracking
down
people
looking
for
various
information,
so
that's
the
general
idea
behind
it
and
that
doc
details
some
of
the
specifics
of
the
process.
The
rough
overview
is
that
you
would
submit
a
tiny
piece
of
yaml.
A
We
would
run
with
some
of
the
data
that
we
need
for
you
to
commit
to
a
release
or
commit
to
an
enhancement
for
the
release.
We
run
some
magic
tool
on
top
of
that,
which
then
generates.
Essentially
what
would
be
a
release
roadmap
right
so
the
same
way
that
we
have,
if
you're
familiar
with
the
enhancements
tracking
spreadsheet,
that
the
release
team
uses
the
same
way.
A
We
have
that
we
kind
of
want
to
draw
down
on
some
of
the
human
toil
that
it
takes
to
maintain
that
sheet
across
cycles
and
make
it
a
little
less
error
prone
to
do
so.
So
that
is
kind
of
the
the
motivation
behind
the
receipts
process
and
jeremy
and
not
burn
now
are
gonna.
Take
it
away
with
some
of
the
work
that
they've
done
recently.
E
Cool
yeah,
so
we
both
took
a
look
at
the
problem
and
the
road
map,
and
we
wanted
to
kind
of
like
work
through
the
process
and
just
like
hack
on
it
a
little
bit
now.
Everyone
took
the
point
of
view
of
like
trying
to
write
user
stories
about
how
different
personas
would
use
this
process.
E
I
have
like
a
really
simple
prototype
kept
ctl
enhancement.
If
we
want
to
see
that,
but
I
think
we're
at
the
point
now,
where
we're
mostly
confident
that
we
can
go,
do
updates
to
kept
or
propose
a
new
one.
However,
we
want
to
handle
that
a
couple
of
open
questions.
Like
the
you
know,
the
stated
goal
is
to
reduce
the
toil
get
rid
of
the
enhancements
tracking
spreadsheet.
I
think.
C
E
Thing
we
didn't
really
clearly
address
in
the
roadmap
was
how
we
handled
the
kkprs
and
the
k
website
prs
so
as
part
of
the
enhancements
collection
process
for
the
release
and
like
and
really
the
received
process
to
me
is
really
a
release.
Artifact
and
not
necessarily
purely
an
enhancement
artifact
like
there's
the
enhancements,
workflow
and
then
there's
the
release
management
of
like
what's
going
to
go
into
the
race
and
tracking
sort
of
stuff.
E
One
of
those
aspects
of
that
process
is
that
as
the
enhancements
owner
or
enhancements
lead
or
shadow
or
the
docs
lead
or
shadow
one
of
the
things
we
do
is
constantly
ping
in
the
issue.
Hey
tell
us
what
your
kk
prs
are
so
that
we
can
track
those
things.
Tell
us
what
your
k
website
prs
are,
so
that
we
can
track
the
docs
and
make
sure
they're
reviewed,
and
I
don't
think
we
explicitly
called
that
out
into
the
roadmap
like
where
would
that
fall
inside
of
the
would
that
be
in
the
receipt?
E
Would
that
be
another
thing?
Do
we
still
do
that
in
the
issue
comments?
I
think
we
don't
want
to
do
it
in
issue
comments.
I
think
it
needs
to
be
explicit
and
part
of
the
the
receipts
process.
Does
that
end
up
being
like
multiple
pr's
that
people
have
to
file
to?
I
think
that
gets
a
little
a
little
frustrating
for
people
like.
Oh,
I
have
to
go
open
another
pr
to
like
reference
this
other
pr.
E
So
I
think
that's
one
area
that
we
need
to
think
of,
like
as
the
stated
goal
of
getting
rid
of
the
enhancements
tracking
spreadsheet.
That's
one
of
the
things
we
do
track
in
the
spreadsheet.
Both
of
those
lists
of
pr's.
Just
to
you
know,
help
the
team
track,
those
things
to
make
sure
they're
getting
done,
and
then
another
aspect
was
what
are
the
buckets
we
really
end
up
with?
There
was
an
open
question
I
think
in
the
roadmap.
E
E
So
I
think
we
need
to
answer
those
things
as
we
start
doing
this
cap
update,
so
we
can
present
it
to
everybody.
Get
get
feedback
and
communicate
it
out
to
the
the
sigs,
because
if
we
want
to
do
this
for
121,
we
need
to
start
that
ball
rolling
now
and
have
that
communication
flowing,
and
then
I
guess
just
another
open
question
is:
does
this
go
into
617
we're
trying
to
make
kept
transparent,
or
does
this
fall
under
something
more
interesting
release
where
we're
proposing
a
change
to
the
release
process?
E
Again,
these
are
like
process
related
caps
that
we
also
haven't
like
super
defined
yet
but
like
to
me
as
like,
as
I'm
thinking
through
this
stuff.
It's
super
related
to
the
release
process
and
not
super
related
to
the
general
enhancement
workflow.
I
mean
it's
part
of
the
enhancement
workflow
when
you
get
it
into
the
release,
but
as
a
kep
author,
I'm
going
through
this,
you
know
review
process.
It's
going
from
proposed
to
implementable,
I'm
getting
reviews
all
that
stuff.
That's
that's
really
part
of
like
the
kep
process.
E
A
F
C
E
Cool
okay
is
that
text
big
enough?
E
E
How's
that
yep,
okay,
so
definitely
anna
anybody
else
that
hasn't
looked
at.
It
would
definitely
recommend
going
to
read
the
roadmap,
because
it
lays
out
a
whole
lot
of
things
and
there's
a
lot
of
open
questions
inside
of
it,
people
have
dumped
a
lot
of
a
lot
of
work
into
it,
so
it's,
I
think
it
definitely
sets
the
stage
pretty
well
but
think
about
the
release
process
right
now,
as
a
docs
lead
you're.
E
The
way
we
track
enhancements
is
super
human
intensive
right,
like
it's
very
manual,
very
toily,
and
we
want
to
get
away
from
that.
We
want
to
make
it
so
that
the
the
onus
is
really
on
the
sigs
to
opt
into
the
release
rather
than
us
saying:
hey:
are
you
in
in
the
release?
Hey?
Are
you
in
the
release?
Hey?
Are
you
in
the
release
and
the
way
we
thought
about
that
is
to
create
this
small
piece
of
metadata?
E
That
would
signify
that
you
are
intentionally
coming
into
the
release,
and
that
would
include
things
like
the
the
link
to
your
cap.
It
would
include
things
like
the
link
to
the
issue
track
like
the
track
issue,
which
would
be
awesome
right,
like
we
missed
that
a
couple
times
this
release
where
people
have
been
working
on
stuff,
there
wasn't
necessarily
a
tracking
issue.
E
This
makes
it
much
more
clear
and
then
kind
of
codifies.
The
workflow
codifies
the
stages
like
you're
accepted
or
you're,
not
accepted
helps
us
do
a
little
bit
more
tracking
of
exceptions
rather
than
like
dumping,
all
of
that
to
a
mailing
list
and
that's
the
source
of
truth,
like
going
back
at
the
end
of
the
release
and
verifying
that
we
got
all
the
exceptions
like
it's.
It's
kind
of
coming
through
k,
dev
or
k,
release
or
sig
specific
mailing
lists,
so
it's
kind
of
all
over
the
place.
E
This
is
all
kind
of
putting
it
together
in
the
roadmap,
we
discussed
whether
this
should
live
in
sick
release
or
whether
it
should
live
in
enhancements
repo,
since
their
enhancements,
like
I've
gone
with
the
approach
that
they're
in
the
ansem's
repo.
E
So
if
we
look,
we've
got
this
new
releases
directory
and
we
would
kind
of
track
inside
of
here
each
one
of
the
releases.
So
if
I
tree
releases,
there's
a
120
folder
just
notionally
and
then
right
now
the
buckets
we
proposed
were
accepted
at
risk
proposed
and
removed
inside
of
those
things
you
know
in
the
way
we
have
the
roadmap
written
right
now.
E
As
someone
opting
into
the
release,
you
would
say:
hey
here,
are
the
caps
that
I'm
proposing
for
this
release,
so
cap1441
isn't
accepted
right
now,
but
initially
that
would
go
into
the
proposed
bucket.
According
to
the
mile,
the
roadmap,
as
you
got
closer
to
you,
know,
enhancements
freeze,
and
we
could
apply
validation
to
these
things.
They
would
either
move
to
accept
it
or
at
risk
based
off
of
doing
some.
Automated
automated
validation
is
the
cap
actually
merged.
E
Is
it
implementable,
there's
some
metadata
that
we
can
extract
from
those
things
now
and
do
some
automation
invalidation
around
those
things
that
the
team
is
really
doing
themselves
right
now,
right
like
when
kirsten
or
her
shadows
are
going
through
and
looking
at
the
enhancements
during
the
enhancements
collection?
They
are
going
to
say:
is
this
kept
merged?
Yes
or
no?
Is
this
an
implementable,
yes
or
no?
All
of
those
things
are
real
manual
right
now
we
want
to
get
rid
of
that
rely
on
some
automation.
E
E
However,
many
there
are,
when
you
get
to
enhancements
freeze,
we
would
move
things
to
probably
removed
or
exception
required,
whatever
that's
going
to
be
named
just
so,
that's
very
explicit
and
very
clear
sort
of
things
we
have
in
the
the
spreadsheet
right
now
would
just
be
moved
into
git,
and
we
would
use
git
history
to
be
able
to
kind
of
discern
like
what's
changed
and
what's
happening.
It
would
also
give
us
really
good
ties
to
the
exceptions
like
moving
back
into
accepted
from
removed,
like
would
be
an
exception
request.
E
Maybe
that
simplifies
that
process
down,
but
the
other
thing
this
gives
us
is
the
ability
to
generate
a
single
manifest
for
what
is
going
to
be
in
the
release.
So
maybe
that
looks
like
something
like
this,
like
I'm
gonna
generate
the
release
for
120,
and
that
gives
me
a
new
file
in
here
called
manifest.yml
and
manifest.yaml
will
tell
us
exactly.
What's
in
the
release.
It'll
give
us
a
link
to
the
the
issue.
It'll
tell
us
what
stage
it
is
what
sig
it
is.
E
So
it's
really
easy
for
us
to
have
this
auto-generated
report
kind
of
like
what
the
spreadsheet
has
now,
with
the
things
that
we're
in
the
things
that
we're
out
the
things
that
at
any
given
point
in
time,
will
tell
us.
You
know
what
things
are
at
risk.
What
things
are
not
at
risk
what
things
are
accepted?
E
None
of
this
really
requires
a
tool
at
this
point.
All
of
this
for,
like
121,
can
be
done
super
manually.
I
think
the
important
parts
for
121
are
adding
in
some
of
that
validation
to
help
remove
some
of
the
manual
checking,
but
obviously
all
of
this
can
be
done
in
an
automated
way
and
it
gives
us
the
opportunity
to
to
roll
more
and
more
automation,
more
and
more
refinement
of
that
out.
E
Once
we
nail
the
process
and
get
the
process
defined,
and
I
think
that's
what
we're
doing
right
now
for
the
enhancement
or
for
the
kep
updates,
whatever
we're
going
to
do
for
this
process,
defining
the
process
getting
it
documented,
getting
it
reviewed
and
then
getting
it
communicated
to
the
the
sigs
for
121
so
that
we
can
go
out
and
make
sure
that
they're
on
board
with
this
process
they're
aware
of
this
process,
you
know,
but
people
in
general,
I
think,
understand,
enhancements
collection
now,
but
we
still
end
up
with
those
situations
where
oh,
we
didn't
open
the
tracking
issue.
E
For
this
or
oh,
we
didn't
respond
like
somebody
else
has
picked
this
up
and
we
didn't
respond
on
the
the
issue
thread
because
of
github
notification
overload.
So
it
really
becomes
more
of
an
opt-in
process,
really
becomes
more
of
a
sig-owned
process
and
really
becomes
much
more
of
a
declarative
thing
rather
than
this
multiple
source
of
truth.
There's
one
source
of
truth
for
what's
in
the
release,
and
it's
going
to
be
very
well
defined.
E
So
the
one
gap
that
we
hadn't
identified
really
in
the
the
roadmap
and
as
I
was
working
through
this
and
thinking
like
as
previous
enhancement
owner
like
where
do
we
track
the
kkprs?
Where
do
we
track
the
k
docs
prs,
because
those
things
I
think
are
you
know
those
repos
aren't
connected
to
the
enhancements
repo
and
that's
like
one
of
the
problems
with
this
process
in
general.
E
Right
now,
is
that
there's
a
disconnect
between
and
no
enforcement
between,
work
happening
in
kk
work
happening
in
k
website,
like
those
things
still
aren't
going
to
get
fixed
by
this
process,
but
we
need
a
way
of
explicitly
as
part
of
this
process
having
the
the
kep
authors
or
the
the
person
doing
the
implementation
to
to
give
us
that
information.
So
we
can
better
track.
It.
C
So
it
looks
like
with
this
process,
then
we
would
probably
get
rid
of
the
tracking
sheet,
then
for
the
enhancement.
But
if
that
we
do
that,
then
we
need
definitely
a
solution
for
dogs.
Then
yeah.
E
Right,
I
mean,
I
think
one
of
the
goals
steven
has
always
stated
is
that
we
don't
eventually
need
the
release
team
right
like
we're
gonna
automate
and
do
some
of
that
so
definitely
before
we
could
get
rid
of
the
enhancement
sheet.
We
definitely
need
to
think
about
how
we
track
those
things
and
how
we
we
fold
that
into
the
process.
E
Maybe
we
don't
do
that
for
121
and
we
still
rely
on
the
issues
and
like
the
banging
away
and
pinging
stuff,
but
I
I
think
that
that
that
process
just
doesn't
doesn't
work
super
well,
and
it's
really
frustrating
for
the
enhancements
team,
like
as
kirsten's,
been
going
through
stuff.
Not
getting
a
response
from
people
has
been
tough
and
you
know
requires
us
to
go
ping
people
the
same
thing
for
the
like
the
docs
prs
right
like
we
have
to
go,
say
hey,
please
tell
us
what
this
is.
Please
tell
us
what
this
is.
E
You
know
it's
two
days
before
the
doc's
placeholder
pr
and
we
have
25
of
the
50
that
haven't
given
us
anything.
This
alone
won't
fix
that,
but
I
think
like
making
a
more
explicit
process
working
on
the
communications
will
help
kind
of
flip.
The
responsibility.
E
I
don't
think
it's
a
problem:
it's
just
extra
work
for
people,
so
we
just
have
to
figure
out.
If
like
do
they
pr
those
things
into
the
receipt,
maybe
that's
the
right
way
and
it's
just
then
it
becomes
like
the
release
team's
job
to
to
look
at
these
things
like
the
accepted
ones
and
oops.
Sorry,.
F
E
F
E
And
I
think,
along
those
lines
like
we
often
at
the
end
of
the
release,
have
people
that
forget
to
flip
them
from
implementable
to
implemented
when
they
go.
Ga
and
the
same
thing
could
happen
here
when
you
have
a
ticket
in
a
release
that
is
staged,
ga
or
stable
or
whatever,
there's
some
automation
that
can
go
and
like
flag
those
things
open,
pr's
to
update
them,
whatever
it
just
gives
us
like
building
blocks.
I
think
that
down
the
road
become
much
nicer
for
this
whole
process.
E
So
it
does
tie
back
into
like
the
general
enhancements
workflow
there,
but
again
like
is
it
a
release
process?
Is
it
an
enhancements
process?
I
think
it's
gray
for
me.
A
A
Yes,
so
so
one
of
the
things
that
we
want
to
want
to
get
done
with
the
receipts
process
is
also
like
minimize
the
burden
overall
for
even
generating
the
receipts
right
like
what
we
don't
want
to
have.
Is
the
receipts
essentially
be
a
duplication
of
the
caps
metadata
right,
so
the
idea
would
be
to
push
as
we
kind
of
proceed
down
the
line
right.
A
The
first
phase
of
this
is
going
to
be
like
very
manual
like
we'll
have
to
deal
with
it,
because
we
don't
have
the
tooling
and
all
the
bits
in
the
right
places
just
yet
you
know
the
next
phase
of
this
is
like,
as
kind
of
as
that's
happening.
In
parallel,
we
want
to
attack
making
sure
the
kept
metadata
is
actually
valid
right.
So
we
have
a
lot
of
valid
metadata
right
now,
but
maybe
some
things
that
are
not
quite
in
the
right
places
right.
A
There
are
some
caps
that
are
in
the
old
format,
they're,
not
in
the
directory
structure.
Right
so
sorting
that
out
right,
I
think
getting
the
caps
to
the
place
where
we
can
run.
We
can
run
a
pre-submit
against
them
and
say,
like
your
cap,
can't
merge
because
it
doesn't
have
the
right
things
right
is,
is
probably
a
phase
to
run
in
parallel
right
from
there.
I,
like
the
idea
of
the
implementation
history
updates.
A
What
I
worry
about
with
the
implementation
history
updates
is
ideally,
ideally
I'm
describing
in
vivid
detail
the
stuff
that
happened
right,
and
it's
not
just
a
link
to
a
pr
right.
If
we
give
it
to
the
bots,
if
we
give
it
to
the
bots,
it
will
just
become
a
link
to
a
pr
right,
our
link
to
multiple
prs.
A
We
recently
did
an
update
to
the
enhancement
tracking
issue
template
right,
where
it
kind
of
expounded
a
little
further
on
you
know
what
stage
is
your
thing
in?
What
is
it
you
know?
What
milestone
is
it
supposed
to
be
landing
for,
as
well
as
like
give
me
the
the
kkpr
give
me
the
docs
pr
and
give
me
the
whatever
else,
pr
right
that
could
be
encoded
in
the
kept
metadata
instead
right?
A
So
then
it
becomes
you
know,
then
it
it's
so
so
the
idea
being
as
we
move
things
through
these
buckets
right
from
proposed
to
accepted
you
run
that
generator
again,
and
it
says
okay.
I
I
put
your
things
here,
because
you
were
missing
these
things
right,
whether
it
be
also
being
a
comparison
to
the
the
kept
metadata
once
all
the
kept
metadata
is
in
a
good
state
right.
If
you
submit
a
receipt
and
the
kept
metadata
doesn't
match
what
the
receipt
says,
or
rather
the
receipt
doesn't
match.
A
What
the
what
the
kept
metadata
says,
then
it
should
throw
a
validation
error
right,
and
this
is
assuming
that
again,
the
kept
metadata
is
is
perfect.
At
that
point,
the
generation
process
can
also
start
to
pull
in
the
prs.
If.
C
A
Make
the
prs
part
of
part
of
that
milestone?
Struct
we
can.
We
can
start
to
pull
in
the
prs
there
right
and
if
you
know
every
time
we
run
that
validation
as
we
move
things
into
accepted,
if
at
certain
phases
of
the
release
cycle.
A
If
we
say
you
know,
this
is
kept,
ctl
generate
blah
blah
blah
blah
blah
blah,
whatever,
whatever
the
commands
are
right
code
freeze
right,
if
we
specify
a
stage
for
like
code
phrase
right
the
expectation
being
for
code
free,
is
that
you
have
landed
prs,
you
have
done
certain
things
right.
Maybe
you
have
a
docs
a
placeholder
in
place
right.
I
would
expect
the
link
that
does
in
four
or
four
for
that
case
right
and
if
it
doesn't
have
that,
then
it
automatically
gets
shifted
into
the
the
at
risk
bucket
right.
A
We
repost
that,
and
that
becomes
you
know
we
can.
We
can
generate
reports
off
of
that,
send
it
out
to
the
community
and
go
like
here's.
The
current
status
of
all
of
your
things.
If
you
want
to
click
in
see
more
details,
the
release
team
has
the
expectations
that
everything
that's
in
in
at
risk.
Will
be
brought
forth
into
back
into
accepted
right
by
x
date
and
if
it
isn't,
then
it's
removed
from
the
release
right.
A
So
that's
kind
of
the
sum
of
the
workflow
that
would
be
involved,
but
it
does
involve
better
validation
and
starting
to
get
stricter
as
we
go
through
those
different
phases
of
the
release.
So.
A
There
was
the
question
of
who
owns
this
and,
and
that's
a
tricky
one.
I
I
think
as
shepherds
of
this
process,
it
makes
a
lot
of
sense
for
us
to
to
own
it,
given
what
I
worry
about
the
most
right
now
is
that
we
we're
starting
to
kind
of
fork
off
into
different
things
right
where
the
kep001,
which
is
like
the
initial
foundation
of
what
this
process
is
supposed
to
be
no
longer
necessarily
reflects
what
we're
doing
today
right
right.
A
F
A
A
Back
all
right
yay,
so
I
think
you
know
the
first.
The
one
part
of
this
is
the
reason
we
we
have.
Caps
in
git
is
so
that
we
can
reference
git
history
right
as
as
we
go
backwards
right,
so
I
think
it's
entirely
fine
to
evolve
to
evolve
the
original
kep.
The
reason
we
kind
of
had
the
617
one
is
to
kind
of
say,
like
the
original
one's
done,
we're
doing
more
stuff.
A
Here's
what
the
new
stuff
looks
like
it's
over
here,
but
there
does
need
to
be
a
a
bit
of
a
unification
right,
and
maybe
that
is
maybe
it's
not
even
the
kep.
Maybe
it's
just
bringing
it
out
into
documentation
right,
and
I
think
that
becomes
a
little
clearer
that,
like
we,
we
stopped
work
on
this
cap
because
it
was
implemented
and
that's
what
we
said
for
for
zero
zero
one
617
is
kind
of
in
flight
with
various
things,
especially
this
receipts
process.
Maybe
we
come
back
to
you
know.
A
Maybe
we
come
back
to
documentation.
This
becomes
part
of
the
documentation
effort,
especially
with
the
cap,
the
kept
template
rate,
zero,
zero,
zero
template,
kept
template
and
making
sure
these
things
are
up
to
date
right.
So
I
think
you
know
in
in
terms
of
ownership
of
the
process.
We
we
do
still
steward
the
process,
and
we
do
need
to
make
sure
that
what
is
required
of
people,
regardless
of
what
release
cycle
it
is
is,
is
still
in
the
repo
in
some
way,
shape
or
form.
A
I
think
that
sig
release
will
be
close
partners
in
terms
of
just
you
know,
one,
the
people
who
are
on
the
call
right
now
and
two
executing
on
on
the
various
bits.
But
you
know
if
this
was
to
be
another
cap,
it
would
probably
be
a
kept
that
is
owned
by
sig
architecture
and
with
sig
release
as
a
supporting
group
there.
I
think
that's
probably
how
we
want
to
play
it.
A
A
Asking
the
hard
questions.
Well,
I
I
think
I'd
mention
this
to
you
lori,
but
I
want
to
see
the
code
right.
I
think
I
think
one
of
the
next
steps
is
to
put
it
up
in
the
enhancements
repo,
so
we
can
start
to
reason
about
it
a
little
bit
and
you
know
just
for
the
sake
of
visibility.
People
know
that
we're
starting
to
do
this
thing.
We
can
reference
the
the
road
map
there
question
there
is:
do
we
want
need
to
tighten
up
the
road
map?
A
I
think
you
know
a
lot
of
it
is
a
lot
of
it
is
it's
it's
pretty
clean,
but
it's
also
brain
dumpy
and
commenty.
So
maybe
we
want
a
finalized
version
of
that,
but
do
we
feel
we're
at
the
place
to
put
forth
a
finalized
version
of
it,
and
I.
D
Would
keep
it
simple?
I
would
post
the
code
post
the
high
level
steps
in
some
sort
of
like
in
a
description
of
the
the
pull
request
for
the
issue,
depending
I
would
think
you
know,
would
make
sense
for
the
long
term.
But
then
what
are
the
to
do's
like
the
next
few
to
do's?
E
E
E
Yeah
so
tomorrow,
navaroon
and
I
were
planning
on
pairing
to
review
the
roadmap
and
kind
of
like
start
identifying.
What
changes
we
would
need
to
make
for
the
cap
just
to
document
those
things,
and
then
we
can
also
take
a
look
at
the
user
stories
he
built
and
like
the
poc
that
I've
made
so
far
and
kind
of
rationalize
those
and
open
a
pr
with
that
stuff.
Sound
good,
there's.
A
A
Yeah,
so
one
note
for
the
code
versus
the
the
rationalization
is
that
it's
going
to
be
easier
to
land
if
it
is
two
separate
two
separate
pr's,
even
if,
even
if
we
want
to
say
that
the
what
we
have
today
as
a
roadmap
process
as
a
receipts
process,
is
a
draft
right
draft
proposed
whatever
the
status
is
at
least
just
so
it's
out
there
right,
yeah.
A
So
so,
first
is
a
feature
request
right
feature:
request
issue
that
just
kind
of
lays
out
some
of
these
bits
it.
I
would
make
it
an
enhancement,
tracking
issue
right
and
just
keep
it
keep
it
within
the
process.
A
Enhancement
tracking
issue
tracked
out
of
tree
milestone,
121
alpha
stage,
yada
yada,
the
the
cap
is
going
to
contain
what
is
in
the
road
map
link
it
backlink
it
to
617
as
well
as
the
original
kep
and
then
and
then
another
pr
for
the
for
the
yeah
for
the
actual
code.
A
So
so,
within
the
within
the
enhancement
tracking
issue,
you
can
you
can
take
an
opportunity
to
to
lay
out
some
of
your
actions
for
for
the
alpha
phase
right,
at
least
so
it's
it's
visible
and
it's
and
it's
immediately
visible,
as
opposed
to
the
as
opposed
to
the
in
flight
kept,
which
would
be
not
merged
for
some
time
right,
yeah.
A
G
Just
to
confirm
so
we
are
doing
the
usual
kubernetes
code.
Implementation
flow
right,
create
kubernetes,
enhancements
issue
start
with
a
provisional
cap,
start
like
putting
your
thoughts
there
into
the
pr
and
then
like
put
some
associated
implementation
right
and
then
maybe
some
day
down
the
line.
We
will
graduate
it
to
alpha
and
implement
real
state.
A
Well,
it's
going
to
start
as
alpha,
so
yeah
start.
It
started
right
there
and
yeah
and
if
you
I
think
you
know
the
make
sure
that
it
is
in
a
provisional
state.
So
provisional
is
easier
to
merge
right
yeah.
We
started
in
provisional
state
and
we
we
say
that
this
is.
A
This
is
something
that
we've
talked
at
length
about
at
this
point
right
and
really
from
you
know
if,
if
it's
the
owning
group,
sig
architecture
as
well
as
the
as
well
as
a
participating
group
of
sig
release
approved
from
the
sig
release
side-
and
you
know
and
we'll
work
on
the
sig
architecture
approval.
But
I
think
it
should
be
a
stretch
to
get
this
merged
as
provisional
and
then
work
into
get.
You
know,
get
the
quick
merge
rate
and
then
work
into
the
implementable
state
source.
D
D
E
Cool,
I
can
start
on
that
today
and
sync
up
with
navajo
tomorrow.
A
A
Cool
all
right,
I
think
we
have
expounded
on
that
enough.
Let's
jump
back
to
the
docs
task.
D
Actually
here
I
I
took
it
from
the
chat,
so
I
can
get
around
this
weird
issue,
so
adding
explicit
guidance
for
subprojects
in
kubernetes
enhancements.
This
is
a
follow-up
from
the
thread
by
shubeksha.
D
A
Yeah,
so
so,
basically,
this
emerged
from
there
is
a
new
sub
project
forming
for
sig
sid
cluster
lifecycle
around
the
cluster
api
area
and
what
they
were
trying
to
get
clarity
on
is
who
they
have
to
go
to
to
propose
this
new
project.
So
the
short
answer
was,
it
depends,
and
more
specifically,
for
I
mean
it
honestly
depends
on
the.
C
A
Sub
project
right
and
more
specifically
for
for
cluster
api
cluster
api
has
kind
of
forked
off
and
they
have
a.
A
They
have
like
a
sub
process
that
is
called
the
cat
cat
cap,
which
is
the
the
c-a-c-a-e-p
which
is
the
the
cluster
api
enhancement
proposal
right,
which
is
roughly
a
mirror
of
the
kep
process.
But
it
was
done
initially,
I
believe,
to
kind
of
speed
through
things
that
could
be
handled
on
the
sub-project
level,
with
a
reasonable
amount
of
rigor
for
the
sub
project,
without
having
to
expand
and
and
do
it
on,
the
community
level.
D
C
A
D
D
Okay,
so
probably
hasn't
had
time,
so
we
jump
and
we
can
ask
in
the
channel
covered
receipts
then
down
to
kept's
website.
Now
everyone
again.
G
G
G
On
the
listing
down
of
capsid,
we
already
had
something
like
epsilon
query,
which
basically
prints
all
the
caps
into
a
table
format.
I
just
added
two
more
printers,
just
like
cube
ctrl,
which
outputs
as
yaml
or
json,
so
that
that's
additional
feature.
I
also
linked
the
prototype
implementation
there
I'll
shortly
be
going
to
just
pr
in
those
changes
into
enhancement
so
that
it
gets
like
broader
review
scope
from
all
owners
of
enhancements.
D
One
comment,
so
I
wonder
if
putting
a
deadline
for
feedback
would
be
a
good
idea
to
give
folks
an
incentive
to
look
at
these
items
so
that
you
can
get
get
on
with
them.
Sooner
than
later,.
G
Yeah,
that
would
be
like
really
great.
However,
I
feel
that,
like
I
think
next
week
is
cubecon
right,
so
yeah
next
week
is
kind
of
no.
H
A
There
yeah,
assuming
it's
it's
kubecon
and
then
and
then
thanksgiving
for
us,
so
so,
like
I
was
saying
like
the
the
year,
is
dead.
Basically,
I
I
think
that
this
is
we've
gone
back
and
forth
on
on
this
for
a
little
bit,
and
I
would
sooner
I
would
say,
put
this
pr
up-
it's
probably
fine
to
merge,
as
is
sooner
yes,
jeremy
there's
also
a
release
coming
right
immediately
afterwards,
so
anyone
involved
in
that
it
will
be
busy.
A
A
This
is
important,
but
it's
it's
kind
of
priority
important
long
term
and
I'm
happy
to
punt
on
that
in
favor
of
making
sure
that
people
are
focused
on
delivering
the
receipts
process
for
121..
I'd
much
prefer
to
see
focused
work.
There.
G
It
actually
touches
code
and
need
some
ice
from
four
six
one
is
the
announcements
are
project
not
sake,
but
for
the
first
point,
which
I
think
we
already
have
a
sign
off
based
on
the
comments
on
this
call
that
we
can
just
we
are
in
the
changes
to
print
things.
The
next
thing
is
like
creating
the
gcs
bucket,
so
there
we
need
work.
Group
cadence,
infras
inputs,
like
is
this
even
feasible,
giving
right.
A
G
A
It's
completely
feasible.
We
just
need,
and
I'm
happy
to
prove
that
the
the
difficulty
here
is
not
glory
disappeared.
Oh
I'm
gonna,
I'm
gonna
like
drag
my
words
out
for
a
little
bit.
A
It
is
the
structure
of
the
website.
We've
been
talking
about
various
websites
for
a
while
and
different
different
areas
have
gone
off
and
made
websites
right
for
for
reasons
right.
There's
one
for
release,
notes,
there's
the
contributors
thing,
there's
k
website,
there's
talk
of
this
enhancements
website.
There's
also
talk
of
a
release
website
right.
We
from
I
think
from
the
release
perspective
and
from
the
enhancements
perspective.
A
We
need
to
get
a
better
pulse
on
what
we
want
to
do
as
groups
like
there's.
You
know.
One
presentation
aspect
is
like
I
don't
know.
What's
going
on
in
sig
release
at
all,
and
I
want
to
get
a
better
idea
right.
I
want
to
view
their
docs.
I
want
to
see
all
that
stuff
a
little
tightly
a
more
tightly
scoped
one
is,
I
am
specifically
interested
in
when
releases
happen
right
so,
depending
on
what
type
of
release
you're
thinking
of
right.
A
If
it's,
if
it's
a
minor
release
and
the
pre-releases
that
kind
of
lead
up
to
that,
that's
one
scope,
then
then
you
also
have
the
scope
of
like
patch
releases
right,
which
is
across
the
year
and
somewhat
a
different
team
altogether
right
do.
Do
we
couple
that
stuff
right
when
you're
thinking
of
releases,
I
want
to
know
what's
inside
of
a
release,
not
just
when
it's
going
to
be
released
right.
A
That's
the
kind
of
information
that
you
would
get
from
this
metadata.yaml
that's
happening
in
the
the
kep
kep
receipts
bit
right,
which
doesn't
exist
yet
so
some
of
it
yeah.
We
need
to
figure
out
what
we
want
to
do
and
and
where
it
should
be
right,
because
I
think
you
know
once
we
have
a
set
of
pages
with
the
appropriate
metadata,
there's
nothing
stopping
other
consumers
from
picking
up
those
pages
via
netlify,
right
yeah.
A
So
I
think,
first
and
foremost,
less
concern
about
making
everyone
happy
and
and
more
concern
around
figuring
out
what
we
want
to
do
and
getting
something
live,
because
I
think
the
concern
around
making
everyone
happy
is
the
reason
that
we
have
never
published
websites
for
either
of
these
things.
For
for
years
now,
so
yep.
D
There's
this
thing
called
electricity
that
you
need
to
power
computers,
and
I
let
mine
go
too
long.
So
basically,
I
just
where
I
was
left
leaving
off.
My
question
was
just
essentially
about
you
know
when,
when
we're
ready
to
pick
this
back
up
like
making
the
ask
narrow
means
that
you
just
have
an
easier
time,
you
know
knowing
whose
feedback
you
want,
because
it's
a
little
broad
for
me
right
now.
It's
just.
A
Yeah,
so
I
think
the
the
broadness
is
what
has
prevented
us
from
landing
this
website
for
as
long
as
we've
been
talking
about
it,
so
getting.
C
A
Idea
of
what
we
want
to
land
and
then
doing
it
and
iterating
over
that
that
can
be
improved
over
time.
So
I
can
help
with
that.
But
I.
D
G
Yeah,
so
I'm
already
like
filing
the
pr
for
point,
one
in
my
plan,
two
three
four
can
be
taking
it.
Taken
up,
two
three
four
five
can
be
taken
up
by
anyone.
It's
not
necessarily
me
who
has
to
do
it.
Five
specifically,
is
more
related
to
the
I
think.
It's
the
dogs,
slash.
G
Experience
basically,
whoever
owns
the
contributor
site
and
talks.
D
A
Cool
yeah,
so
just
one
big
thing
to
note
here
again
is
that
this
doesn't
need
to
be
someone
else's
website.
If
we
want
to
publish
a
website,
we
can
do
that.
It
does
not
need
to
be
in
the
contributor
site.
We
can
link
out
to
our
website
from
the
contributor
site
right,
so,
let's
not
block
on
the
thousands
of
different
potential
interested
parties,
because
again,
this
is
what
this
was.
The
reason
that
this
website
has
never
been
launched.
D
Yeah
yep
so
yeah.
Let's,
we
can
do
an
exercise
where
we
just
kind
of
think
about
the
risks.
Here
you
know,
let's
just
get
something
out
the
door
if
possible,
but
not
if
that
is
at
the
expense
of
receipts.
So
my
suggestion
here
would
be
trying
to
trying
to
get
those
volunteers
to
carry
some
of
the
work
forward.
D
D
It
wasn't
super
clear
to
me
what
the
plan
was
there,
so
hippie
hacker
and
some
others
can
fill
me
in
and
then
for
the
other
items.
These
were
what
we
thought
would
be
good
for
a
product
manager
to
take
over.
This
is
about
the
whole
kept
process
and
different
artifacts
related
to
it.
So
aidan
is
here
and
was
on
the
list
of
potential.
D
B
D
B
D
B
Like
about
explicit
guidance
for
subprojects,
okay,.
D
Sure,
yes
yeah,
that
would
be
good.
I
I
don't
know
in
the
hierarchy
of
what
is
most
urgent
and
valuable
here.
If
that
would
come
before
these
different
asks,
I
think
it's
more
of
a
short-term
task
and
these
other
things
are
going
to
require
a
little
bit
of
outreach
and
discussion.
C
A
Yeah,
I
think
you
know
the
check
out.
I
would
I
would
check
out,
what's
in
the
front
page
of
the
repo
first,
it's
under
a
heading.
That's,
like
is
my
thing,
an
enhancement
and
we
we
lay
out
some
guidelines
for
potential
enhancementy
type
stuff.
But
again
that
will
depend
on
what
sub-project
you're
in
and
if
your
thing
qualifies
or
if
you
live
outside
of
the
enhancements
process.
So
it's
a
little
harder
to
peg
down.
E
D
A
H
D
But
is
that
that's
three
items
then
right?
So
maybe
we
just.
D
A
D
H
A
So
there
was
a
recent
update
to
the
issue
template.
I
think
what
we
could
do
is
we
want
to
probably
start
thinking
about
things
that
fall
not
explicitly
within
the
enhancements
template
because,
like
I
think
an
example
would
be
if
we
wanted.
If
we
had
a
feature
request
for
the
enhancements
subproject
right,
it's
not
necessarily
an
enhancement
tracking
issue
right,
there's
not
necessarily
going
to
be
a
kept
bound
to
it.
D
What
was
the
ask
again,
we
need
bug
template.
D
A
A
A
C
A
About
right,
as
opposed
to
an
enhancement
tracking
issue,
anyhow,
we
are
at
time
so
with
that
I
will
say
bijal
adieu
and
you
know
if
you're
heading
to
cubecon.
I
will
see
you
there,
if
not,
I
hope,
you're
taking
some
time
off
and
we'll
catch
you
at
the
next
one
right
later.