►
From YouTube: 20201222 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).
B
Cool
all
right,
we're
gonna,
get
rolling
hello,
hello.
Everyone
today
is
december
22nd.
This
is
a
bi-weekly
meeting
of
the
sig
architecture,
enhancement
sub
project.
This
is
a
meeting
that
will
be
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people.
So
this
first
off
hello,
welcome
hi
good
to
see
your
your
faces.
This
is
our
last
meeting
for
the
year,
so
I
figured
what
we
would
do.
B
We
have
a
light
agenda
and
a
lot
of
the
things
we
have
discussed
already.
I
figure
what
we
do
is
just
make
sure
that
we're
all
in
line
for
moving
into
the
new
year
talking
about
priorities
really
quickly
and
checking
me
if
I
forgot
anything
on
the
list.
So,
first
off,
let's
do
a
round
of
introductions
or
do
we
have
anyone
new
on
the
call
that
wants
to
say
hi.
C
Yeah
hi,
I
am
new
to
the
call
I
joined
this
as
part
of
the
release
shadow
as
well,
so
I'm
just
trying
to
figure
out.
What's
going
on
my
on.
C
Vmware
and
I
am
part
of
yeah-
I
think
stefan
also
works
in
vmware,
correct
yeah.
B
Figure
cool
welcome
anything
that
you're
interested
in
particular
as
we
go
through
this.
C
I
I
mean
I
know
I
and
nothing
in
particular,
I'm
just
looking
forward
to
what
the
team
does
and
how
we
you
actually
get
new
caps
and
how
it
goes
through
the
whole
process
and
also
understand.
B
All
right
so
bob,
I
know
you
have
to
drop
early.
Are
there
specific
things
that
you
want
to
cover.
B
B
All
right
well
away,
we
go.
I
think
that
a
lot
of
us
are
kind
of
in
line
with
much
of
what's
already
written
down,
so
we
can
probably
also
make
this
a
short
meeting
if
that's
cool
with
everyone.
Like
short
meetings,
sure
meetings
are
awesome.
B
Okay,
so
first
up
on
the
list
is,
is
receipts
so
the
receipts
process.
We've
talked
about
this
a
little
bit
essentially
receipts
for
new
folks
on
the
call.
The
idea
is
that
receipt
is
a
essentially
we're
trying
to
invert
the
flow
of
information
right,
where
usually,
usually,
an
enhancement,
sub
team
member
will
will
gather
feedback
from
the
variety
of
sigs
to
understand
what
is
going
into
the
release
right
by
kind
of
using
the
receipts
process.
B
The
the
plan
is
to
essentially
have
sigs
instead
soft
commit
to
what
they
plan
to
land
for
the
release
right.
This
would
go
into.
B
This
would
go
into
some
metadata
and
then
we
would
use
that
as
a
means
to
essentially
generate
a
roadmap
for
the
release,
so
getting
an
idea
of
what
is
proposed.
What
is
accepted?
What
is
what
is
at
risk
for
any
reason,
as
well
as
being
able
to
apply
pre-submits
and
some
automation
on
top
of
this,
so
I
think
from
our
last
meeting
what
we
had
talked
about
was
planning
to
do
some
of
this
work
for
121..
B
Initially,
we
wanted
to
enforce
this
for
121,
but
I
think
now
we're
we're
saying
that
we
want
to
do
some
of
this
work.
Shore
up
the
met
the
cap,
metadata
and
then
land
this
in
earnest
for
122..
Is
that
still
accurate
everyone,
yep
okay
nods
from
bob
nods
from
navarone
and
laurie
yeah?
I
think
so,
okay
party
away
all
right,
so
we
will,
as
we
go
into
the
holidays,
the
folks
who
are
thinking
about
we're
working
on
receipts,
so
jeremy
and
I'm.
B
I
know
that
jeremy
is
out
today
but
nabor
and
I
believe
you
have
a
provisional
kep
for
receipts
or
in
addition
to
a
current
cap.
E
Maybe
yes,
so
we
do
have
a
provisional
cap.
I
think
it's
two
one,
seven
zero!
I'm
not
accurate
on
that
number,
but
there's
a
pr
open,
there's
just
one
teeny
bit
missing
on
that
cap.
The
provisional
cap
is
the
implementation
detail.
B
Generally,
yes,
so
I
think
I
think
what
we
should
do
is
this
will
be
a
little
later,
but
metadata
versioning
plus
kept
types.
Maybe
we
want
to
talk
about
as
well
so
yeah?
The
idea
is
that
you
would
land
a
provisional
cup.
Provisional
cup
says
essentially
says
from
the
sig.
That's
are
the
the
owning
area
that,
yes,
this
idea
is
sound.
We
should
totally
do
it.
If
people
are
willing
to
commit
to
the
work,
then
it
should
get
done
it.
B
It
essentially
just
solidifies
the
idea
right
as
they
kept
moves
into
implementable.
There
is
a
higher
expectation
of
the
details
that
would
be
involved,
actual
implementation
details,
the
chats
that
you've
had
hopefully
backfilling
some
of
the
implementation
history
so
on
and
so
forth
before
actual
implementation.
But
we
are
we're
pretty
deep
into
this
already.
I
think
from
a
thought
standpoint
at
least
so
I
think
we
should
be
good
to
roll.
B
Okay,
all
right,
so
next
up
is
refining
the
documentation
on
process
as
well
as
publicizing
some
of
what
we
do
are
re-publicizing
some
of
what
we
do.
This
is
kind
of
take
away
from
the
chat
that
we
had
last
week
last
week.
Monday
was
it
last
week
monday.
It.
B
B
No,
no,
no,
sorry,
not
the
not
the,
not
the
120
retro,
but
the
chat
that
we
had
in
the
smaller
group.
I
thought
it
was
thursday.
B
Yeah,
I
I
don't
know
anymore,
all
right
so
so
thursday,
so
yeah
so
thursday.
A
few
of
us
got
together
a
laurie
sushmita
aiden,
myself,
jeremy.
Am
I
missing
anyone
kirsten?
How
can
I
forget
kirsten,
so
we
kind
of
we
kind
of
did
like
a
brief.
I
guess
a
retro
kind
of
of
the
of
the
120
release
a
little
bit.
Some
of
the
some
of
the
interpersonal
things
that
were
ran
it
run
into
as
people
were
collecting
caps.
Some
of
the
feedback
from
the
team.
B
B
The
what's
noticed
is
that
there
is
a
bit
of
leeway
given
for
the
more
senior
contributors
or
misunderstandings
in
the
process,
so
this
this
note
here
is
kind
of
let's,
let's
say
what
we
need
people
to
do
and
hope
that
and
hope
that
we
can
make
that
clear,
moving
into
121
and
122..
B
So
one
of
the
ideas
that
was
tossed
out
in
that
meeting
was
that
we
do
a
blog
post.
We
do
a
blog
post
that
gathers
some
testimonials
from
sigs
subproject
owners
component
leads,
who
have
had
a
good
time
doing
caps
and
want
to
provide
some
feedback
there,
but
we
also
want
to
make
sure
that,
while
we're
doing
that,
we
gather
the
bad
feedback
too
right
or
the
the
feedback
that
is
actionable
for
improvements.
B
So
we
want
to
do
a
little
bit
of
of
both
of
those
and
kirsten
volunteered
to
run
with
that
I'll,
be
helping
her
out
in
terms
of
like
just
figuring
out,
who
needs
to
be
in
the
room
to
provide
feedback
and
whatnot,
and
if
there
needs
to
be
any
sig
leady
cat
herdyness
happening
I'll
help
out
with
that
any
questions.
Anyone
interested
in
also
working
on
that.
A
I
was
going
to
get
into
the
parts
of
the
different
personas,
just
basically
the
long
time,
awareness
of
responsiveness,
differences,
some
sigs
are
quite
responsive.
Some
sigs
are
not
in
any
case.
Enhancements
team
often
runs
into
the
issue
of
trying
to
get
answers
from
cigs
that
they
are
trying
to
help
trying
to
push
enhancements
across
the
finish
line,
and
sometimes
this
requires
more
effort
than
maybe
it
should.
A
Getting
you
know,
getting
responses
in
a
reasonable
amount
of
time
and
then
working
with
some
sigs
who
may
be
on
the
fence
around
that,
and
then
some
sigs
who
seem
to
have
struggles
to
provide
responses
to
the
enhancements
team
in
a
timely
manner,
and
so
just
try
to
figure
out
what
is
what
is
happening
with
the
latter
two
groups
and
then
keep
working
with
the
former
group,
the
ones
that
aren't
fully
on
board,
to
really
try
to
understand
why
you
know
how
to
what
are
they
doing?
A
That
enables
them
to
to
provide
quick
turnaround
for
responses
and
also
is
it
an
attitude
or
is
it
a
workload
issue
these
kinds
of
questions,
so
I
am
to
create
kind
of
a
one-page
plan
around
this.
I
guess
I'll
do
that
tomorrow
and
then
I'll
show
that
in
the
channel
and
then
we'll
go
from
there.
A
So
a
lot
of
the
data
I've
been
collecting
over
the
months
is
in
a
spreadsheet,
and
I
think
I
shared
a
mero
board
because
you
know
me
and
miro
boards,
but
I
shared
a
mirror
board
in
the
chat
just
now,
which
gives
you
some
ideas
about
notes
that
we
took
in
this
chat
and
then
there's
a
spreadsheet
with
some
data
about
how
sigs
are
running
their
processes
at
the
moment.
A
So
you
know
with
an
eye
toward
what
would
what
are
they
doing?
That's
from
a
process
perspective
likely
to
help
them
turn
work
around
faster
turn
responses
around
faster.
You
know
what
are
they
actually
doing
about
their
workload
and
processing
that
so.
B
Awesome
awesome,
I'm
excited,
we've
got
lots
of
cool
things
coming
and
I
think
that
part
of
it
is
making
sure
that
everyone
is
on
the
same
train
as
we
do
it.
B
I
think
you
know
aiden
had
mentioned
something
around
kind
of
the
network
effect
during
the
meeting,
which
essentially
is
for
the
folks
who
weren't
there,
those
those
groups
that
laurier
laurie
was
talking
about
the
folks
who
are
incredibly
responsive,
follow
the
process
to
the
letter,
the
folks
who
are
maybe
having
a
time
and
then
the
and
then
the
folks
that
are
less
responsive,
the
ones
that
we
kind
of
have
to
chase.
B
If
we
are
able
to
get
the
folks
who
are
following
the
process
to
the
letter
and
kind
of
get
an
idea
of
what
their
process
is,
while
following
the
process
that
one
you
know,
we've
got,
you
know
that's
kind
of
building
champions
across
the
across
the
community
right
and
the
the
more
champions
you
have,
the
more
likely
something
is
to
succeed
so
excited
to
see
that
crop
up
for
the
new
year.
Any
questions
comments
concerns
there.
A
Yeah
and
bob's
saying
I
think,
for
many
you'll
find
they're
doing
anything.
They're
yeah
a
lot
of
them
are,
but
maybe
not
enough
or
maybe
not
consistently.
So
maybe.
D
D
A
C
B
So
so
we're
gonna
try
to
attack
that
a
little
bit
the
I
think
ray.
If
you
don't
mind,
noting
that
we
want
to
make
sure
that
we're
in
terms
of
you
know
and
while
publicizing
the
stuff
making
clear
that
people
know
about
all
of
the
different
kep
statuses.
I
feel
like
people
don't
currently-
and
there
are
two
statuses
that
fit
pretty
well
for
deferring
work
or
rejecting
work,
and
they
are
the
deferred
and
rejected
statuses
that
I
don't
think
I've
ever
seen.
B
Anyone
use
for
a
cap
and
those
you
know
the
the
idea.
The
idea
there
is
that
the
caps
are
meant
to
be.
You
know
the
github
is
essentially
our
our
living
body
of
work
for
the
community
right
and
kepts
are
are
meant
to
capture
the
the
essence
of
all
the
big
changes
that
we
we
do
right,
whether
it
be
kk
whether
it
be
elsewhere,
and
when
you
capture
changes,
you
need
to
capture
the
ones
that
you
are.
B
When
you
capture
thoughts
right,
you
should
be
capturing
the
ones
that
we
think
are
good
ideas
and
the
ones
that
we
maybe
don't
want
to
do
yet,
or
maybe
don't
want
to
do
it
all
right,
because
history
repeats
itself,
and
you
will
see
these
ideas
crop
up
again
and
someone
will
dig
up
a
discussion
about
when
why
how
this
happened
or
why
it
didn't
happen,
and
the
kept
should
be
that
discussion
really
right.
The
cap
should
solidify.
You
know
this
is
this
is
an
idea.
Maybe
you
know.
B
Maybe
we
also
want
to
consider
adding
sections
in
caps
for
the
rejection
reason
right
or
the
deferral
reason
right.
If
it's,
if
it's
too
much
work,
I
think
it's
fine
to
say
that
up
front
right,
our
you
know
the
the
sig
doesn't
have
bandwidth.
The
the
component
or
sub
project
area
doesn't
have
bandwidth
right
being
able
to
say
that
stuff
up
front
gives
us
something
to
look
back
on.
B
Right
all
right
any
comments
before
we
move
to
the
next
one.
B
All
right
cool,
so,
as
we
kind
of
I
think
quickly,
is
a
word.
Maybe
quickly
is
a
word
I
think,
compared
to
compared
to
the
history
of
of
the
features
and
enhancements
process.
We've
been
quickly
iterating
over
the
kep
metadata
right.
Lots
of
people
are
starting
to
have
ideas
about
what
is
what
is
and
isn't
useful
what
would
be
helpful
for
them
to
track
over
time,
and
we've
recently
made
a
few
changes
to
the
structs
right
in
in
the
metadata.
B
So
we've
added
things
like
expanded
on
the
milestone
truck
right,
which
includes
the
target
stages
and
and
the
releases
that
that
a
enhancement
would
hit
a
certain
stage
as
we
continue
to
do
that
stuff.
B
It
probably
makes
sense
that
we
start
versioning
keps
versioning
the
kep
metadata,
specifically
right
so
in
in
this
process.
We're
not
too
concerned
about
the
content
of
the
cap
itself,
but
more
so
the
the
validity
of
the
metadata
right.
As
we
start
to
build
more
and
more
tools
around
the
metadata.
We
need
to
make
sure
that
the
metadata
is
sound,
and
if
someone
wants
to
propose
a
change,
we
need.
B
We
need
some
guidance
on
that
process
or
we
need
to
provide
guidance
for
that
process
right
the
same
way.
We
would
the
same
way.
There
would
be
an
api
review
process
if
it
was
a
large
enhancement
for
kubernetes
for
kubernetes
kubernetes.
I
I
think
is
is
some
of
the
structure
that
we
need
to
bring
into
maintaining
the
maintaining
the
metadata.
So
bob
in
the
chat
is
mentioning
the
open
api
v3
schema
for
versioning.
Essentially,
we
do
it
for
crds.
D
B
Oh
yeah,
I'm
I'm
with
a
consistent,
consistent,
well-known
easy
to
consume
for
everyone
involved,
so
I'm
happy
to
I'm
happy
to
go
with
open
api.
If
that
makes
sense
for
people
not
something,
we
have
to
sort
out
now,
just
something
that
we
do
need
to
focus
on,
especially
as
we're
going
through
this
like
next
iteration
of
or
this.
B
This
first
change
from,
like:
let's
clean
up
the
old
kept
metadata
and
and
get
the
and
the
file
formats
right
and
everything
in
the
right
place
to
we
actually
have
a
schema
now
right
and
how
do
we?
How
do
we
follow
it?
B
How
do
we
validate
against
it
so
part
of
those
changes
right,
so
one
kind
of
process
around
doing
the
metadata
versioning,
but
also,
I
think
something
that's
come
up
a
few
times
is,
is
my
thing:
we
have
something
on
the
front
of
the
repo
that
says,
like
is
my
thing,
an
enhancement
right,
and
it
kind
of
gives
you
these,
like
rough
heuristics
of
of
what
it
means
to
be
an
enhancement
right.
B
I
think
that
that
that
section
has
kind
of
existed
for
probably
as
long
as
I
have
been
doing
this,
and
we
could
probably
refine
it
at
this
point,
and
I
think
that
we've
seen
caps
used
for
a
variety
of
things.
B
We've
seen
cups
used
strictly
for
for
enhancements
landing
in
kubernetes
kubernetes,
but
we
also
have
a
class
of
cap
that
are
caps
that
are
landing
for
out
of
tree
enhancements,
and
then
we
also
have
caps
that
are
kind
of
like
process
related
caps
right
and
they're
and
they're
kind
of
a.
I
guess
you
would,
I
guess
they
would
be
a
subset
of
maybe
the
out
of
tree
style
of
cap
rate,
but
essentially
it's
it's
a
big
change.
It's
going
to
affect
a
lot
of
things
right.
B
So
something
like
issue
triage
is
a
good
example
right
or
the
any
or
the
the
receipts
process.
Right.
That's
going
to
be
another
big
change
that
isn't
landing
code
in
kubernetes
kubernetes,
but
will
affect
how
code
is
landed
for
kubernetes,
kubernetes
right
and
then
you've
got
like
617
right.
617
is
the
metacap,
the
kep
for
enhancing
the
kep
process
right
and
that's
another.
B
You
know
policy
based
cap
or
process
base
cap
that
doesn't
later
bob
that
doesn't
quite
fit
nicely
into
into
the
box
of
like
things
landing
in
kubernetes
kubernetes.
I
think
by
delineating
delineating
some
types
for
caps.
B
It'll
allow
allow
one,
maybe
some
different
styles
of
writing
a
cup
some
slightly
different
styles
of
writing
a
cup,
but
two
it'll
also
allow
the
release
team
to
have
very
clear
boundaries
about
when
something
is
out
of
tree
or
how
something
should
be
handled
if
it
is
out
of
tree
right-
and
that
has
been
that
has
been
something.
That's
come
up
for
multiple
cycles
now
and
we
and
we
tweak-
and
we
tweak-
and
I
think-
and
I
think
we
have
enough
data
now-
to
kind
of
write
something
concrete.
B
So
so
the
proposal
there
is
to
add
a
type,
and
this
would
go
into
the
next
version
of
whatever
that
next
version
is
whether
we
we're
calling
them
v,
something
beta
one,
yada
yada,.
A
B
Yeah,
I
would
yeah
so
features
yeah,
so
I
was
so
I
was
just
thinking,
there's
actually
maybe
another
one
right.
So
if
you
look
at
like
the
kate's
dot,
gcr
dot,
io
vanity
domain
flip.
If
you
look
at
something
like
changes
to
policies
around
artifact
management,
those
would
all
fall
into.
I
think
those
kind
of
fall
into
like
an
infrastructure
change
right,
which
is
which
is
kind
of
separate
from
a
code,
change
and
kind
of
needs
to
be
tracked
differently
from
a
code
change
right
so
baseline.
B
I
would
see
entry
entry
out
of
tree
process
and
infra
just
as
a
vague
like
vague
types.
B
So
this
this
kind
of
folds
into
the
versioning
system,
so
when
we
want
to
figure
out
a
versioning
system
and
make
some
rules
around
it
and
then
we
would
want
to,
we
could
do
it.
We
could
do
it
two
ways.
We
could
add
these
types
first
and
then
backfill
a
versioning
system
or
we
could
do
the
versioning
system
first.
I
think
I
think
us
thinking
about
it
can
run
in
parallel
right.
I.
B
A
Try
to
understand
how
they're
dealt
with
if
they
are
dealt
with.
Some
of
them
may
just
be
lingering,
like
the
one
I
posted
in
the
agenda,
which
I
mean
come
on.
It's
fine
but,
like
I
think,
aaron
posted
that
a
while
ago,
if
it
was
this
year,
oh.
B
A
B
A
So
it's
yeah,
it's
just
been
around,
but
we
have
we
have
nobody's
talking
about
it.
You
know
I
mean
we
kind
of
are
now.
B
Exactly
we,
we
don't
say
it
out
loud
too
often,
but
it's
I
mean
honestly,
it's
there
are
so
many
issues
like
this
there's
one.
That's
there's
one
that
maria
opened
in
sig
release.
There
is
this
one
from
jeremy.
There
I
believe
was
one
from
aaron
in
either.
B
K,
this
is
something
that
I
believe
josh
burkus
has
also
left
feedback
on
either
in
the
feedback
gathering
issue
or
on
errands.
It's
something
that
we
know
exists
and
I
think
that
up
until
now,
we
didn't
have
enough
people.
Are.
It
wasn't
high
enough
on
the
priority
list
to
solve.
But
ideally
you
know
in
an
ideal
world,
everyone
uses
caps.
Caps
are
frictionless
and
we
have
some
work
to
get
to
that
point,
but
I
think
that
this
is
part
of
it.
So.
A
I
mean
I
wonder
if
there's
anything
that
maybe
not
a
brand
new
contributor,
but
I've
fairly
been
around
for
a
few
months
contributor
could
do
to
just
pick
up
some
of
the
workload
whether
it's
maybe
what
we
need
to
do
is
put
all
of
these
kind
of
policy
and
process
related
questions
into
a
single
doc.
A
Like
say:
here's
how
these
things
relate
to
each
other
yeah
together,
they
form
a
plan
or
a
collection
of
thoughts
and
then
match
that
to
this
idea
of
versioning
and
then
figure
out
what
are
the
decisions
that
have
to
be
made?
Who
makes
those
and
then
what
a?
How
do
we
make
it
come
to
be?
You
know
this.
F
A
B
A
float
it's
a
flow
chart
right.
I
think
I
think
probably
what
we
want
is
the
is
all
the
leads
we
get
together
and
throw
our
best
guess
at
the
flow
out
and
the
leads
yeah.
A
B
B
A
Cool
yeah
all
right,
so
I'm
putting
this
in
as
I'm
just
that's
something
else
to
kind
of
spin
up.
I
put
it
in
the
existing
mirror
board.
A
B
Now
now
a
word
from
our
sponsors.
B
I
love
it.
Yes,
sorry,
what's
up.
B
Like
here's,
the
pitch
here's
pitch
exactly
so
yeah,
I
think
I
think
that's
great.
I
think
it's
definitely
again.
We
I,
I
think
we
finally
have
the
the
people
to
do
some
of
these
things.
A
B
F
G
Can
hear
you
yes,
okay
by
the
way
my
name
is
mohammed
shiel
and
currently
I'm
living
here
in
germany.
So
I
just
want
to
go
through
all
this
cigs
and
see.
Where
can
I
maybe
start
contributing
and
do
I
have
a
background
in
java
for
more
than
almost
like
10
years
and
now
I
have
start
working
in
some
gold
in
our
company
currently.
Here,
though,
I
don't
want
to
mention
the
name
of
the
company,
but
it's
just
a
side
project.
Yes,
I
just
want
to
start
contributing
we're
in
germany.
G
Currently
in
wolf,
it's
close
to
bayern
tobiara
yeah
byron.
You
know
numb
back.
G
B
B
Yeah,
okay,
all
right
next
one
up
and-
and
this
is
yet
another
thing-
that
kind
of
dovetails
together
right.
So
so
this
one
is
the
metadata
cleanup
right.
So,
as
we
have
kind
of
evolved,
what
is
now
the
enhancements
process?
What
was
previously
the
the
features
collection
process?
B
We
have
moved
documents
a
few
places
so
initially
initially
feature
proposals
were
in
kubernetes
community
repo.
They
have
since
been
moved
to
k
features
which
became
k
enhancements.
So
the
repo
that
you
know
today
has
gone
through
a
few
different
iterations.
As
we
were
migrating
those
proposals,
we've
got.
We've
we've
essentially
got
a
few
different.
We've
essentially
got
a
few
different
kepts
right,
a
few
different
types
of
caps.
We
have
ones
that
are
were
formerly
feature
proposals
and
were
converted
into
caps.
B
We've
got
ones
that
were
created
around
the
time
that
we
were
just
starting
the
kep
process
and
the
naming
situation
was
was
different.
Essentially
we
had
the
the
idea.
Is
that
you
would?
You
would
reserve
a
cap
number
raid
and
the
cap
number
would.
The
cap
number
would
be
in
the
top
level
of
the
caps,
the
kep
subdirectory
and
as
we
kind
of
iterated
through
kept
numbers.
B
If
you
were
writing
a
cap,
you
would
have
to
go
and
make
sure
that
you
were
choosing
a
unique
kept
number
and
then
update
that
kept
number
to
the
next
monotonic
increasing
number
right.
So,
as
you
can
imagine
that
led
to
that
led
to
lots
of
pr
collisions,
we
already
know
that
landing.
These
proposals
are
kind
of
a
hassle.
B
I
I
think,
as
a
is
a
way
to
put
it
definitely
in
the
earlier
days,
so
adding
adding
that
cap
number
into
the
mix
caused
a
lot
of
merge
conflicts
and
made
not
a
lot
of
people
happy.
So
we
decided
to
get
rid
of
the
cap
number
and
moved
to
a
date.
B
Yeah
we
moved
to
a
date
next
right,
so
so
you'll
see
some.
Some
caps
will
have
a
we'll,
have
a
number
zero,
zero,
zero
number
right,
and
then
we
moved
to
dates.
The
date
would
be
the
date
that
the
cap
was
initially
pr'ed
or
that
that
you
started
drafting
it
and
then
that
kind
of
works
out.
B
Okay,
but
it
doesn't
really
tie
you
back
to
the
github
issue
unless
you
go
digging
right,
so
the
next
iteration
and
it's
the
current
iteration
was
create
a
github
issue
in
kubernetes
enhancements.
Once
you
create
the
issue,
the
issue
will
have
a
number,
and
then
you
use
the
issues
number
as
the
cap
number
right.
So
your
cap
would
be
you
know,
cap1337.
B
You
know
supercoolcap.md
right,
so
we
were
doing
that
for
a
while,
and
then
we
did
one
more
iteration
and
that
was
to
move
from
the
from
having
caps
and
their
metadata
in
one
file,
so
kep,
so
kept
number
dash,
kept
name
dot,
md
the
top
of
that
file.
The
front
matter
of
that
file
would
be
yaml,
describing
the
kept
status
type
stage,
name,
approvers,
reviewers,
so
on
and
so
forth.
B
So
since
then,
we've
converted
from
a
single
markdown
file
into
a
directory.
So
now
the
directory
is
named,
kept
number
or
issue
number
dash,
kept
name
right
within
that
directory
is
the
readme
readme.md,
which
is
the
actual
kept
content
and
then
a
kep.yaml
which
is
the
metadata
for
the
cap.
B
By
doing
this,
by
doing
this,
we
have
a
pretty
clear
indication
of
one
where
all
the
caps
are
are
supposed
to
be
located.
We
can
do
some.
We
can
do
some
things
like
finding
finding
cups
based
on
how
folders
are
named.
We
can.
It
becomes
a
lot
easier
to
strip
out
the
metadata
of
an
individual
kep,
because
it
is
essentially
just
reading
the
bytes
in
from
one
file
right
instead
of
you
know,
reading
through
markdown,
and
you
know
searching
for
the
ammo
and
then
kind
of
keying
in
on
that
stuff.
B
So
what
this
means
across
these
kind
of,
like
four
or
five
different
iterations,
is
that
a
bunch
of
different
cups
are
in
different
states
right,
so
you've
got
you've
got
some
of
the
older
ones.
You've
got
some
of
the
newer
ones
that
are
in
the
correct
state
and
some
sigs
working
towards
converting
caps
from
one
one
type
to
another
raid.
B
So
what
we
want
to
do
is
is
make
sure
that
every
cap
looks
the
same
right.
So
it's
going
to
take
some
of
some
metadata
cleanup
and
you'll
see
in
the
next
item.
We
talk
about
the
pre-submit
validation,
so
the
pre-submit
validation
will
get
stricter
as
we
start
to
do.
Things
like
have
versioning
right,
we
can
start
to.
There
is
a
pr
that
jeremy
morris
opened.
B
That
kind
of
raises
a
question,
and
the
question
is
around
well
what
happens
when
a
field
changes?
What
happens
when
anything
changes
in
the
metadata
right?
We
don't
have
a
good
answer
today
and
you
know
the
the
approach
that
was
taken
in
this
instance
was
to
kind
of
search
and
replace
right,
search
and
replace
the
participating
sigs
field.
I've
replaced
that
with
participating
groups
right
because
caps
can
be
kept,
can
be
issued
by
multiple
groups.
B
I'm
popping
that
issue
that
pull
request
in
the
zoom
chat
ray,
if
you
don't
mind,
grabbing
that
so
yeah
I'll
show
I'll
show
this
really
quickly
and.
B
Right
so
with
this
issue,
or
with
this
pr,
you
can
see
that
in
the.
B
Template
in
the
template
kept.yaml,
we
basically
added
open
questions.
This
was
okay.
This
has
changed
since
the
last
time.
I
saw
it,
but
okay,
all
right
so
we'll
get
back
to
this,
but
what
was
happening
is
kind
of
a
search
and
replace
and
the
changes
were
across
all
of
the
caps.
So
this
was
like
files
changed
like
270
or
something.
So
what
I'd
like
to
see
is
kind
of
a
conversion
tool
right
as
we
as
we
kind
of
actually
defined
versions
for
kept
metadata,
we
should
be
able
to
convert.
B
We
should
be
able
to
convert
old
caps
to
new
file
formats
and
new
metadata,
and
for
that
to
happen,
we
need
to
write
some
conversion
tools.
Basically,
is
the
the
long
and
the
short
of
it.
So
as
we
talk
about
versioning
as
we
talk
about
stricter
validation,
we
should
also
think
about
how
do
we
again
kind
of
defray
some
of
that
burden
from
the
cap
authors
on
reviewers?
In
so
when
you
submit
a
cup
and
it
actually
gets
merged,
you
shouldn't
have
to
do
anything
else.
B
If
we
change
versions
right,
we
should
be
able
to
handle
that
with
a
tool.
So
that's
kind
of
what
this
this
is
about.
B
B
B
Next
up
is
process
enforcement
and
in
parentheses
I
have
carrot
versus
stick
right
so
today
in
kubernetes,
there's
there's
really
nothing
stopping
anyone
from
landing
code
right
if
the
code
is
approved,
if
the
code
is
approved
by
a
code
owner
a
you
know,
sig
component
subproject
owner
reviewer
approvers.
If
that
code
merges,
we
have
that's
it,
that's
it
it's
done
right.
So
the
you
know,
the
the
enhancement
has
essentially
landed
and
it
may
be
in
a
partial
state
it
may
not
be.
B
It
may
be
something
that
the
release
team
did
not
officially
approve
or
that
the
sig
did
not
officially
approve.
It
may
be
something
that
we
wanted
to
defer,
maybe
something
that
has
not
completely
landed
and
will
not
land
in
time
for
the
release
rate.
So
this
is
kind
of
this
item
is
kind
of
talking
about
how
we
should
go
about
thinking,
thinking
through
enforcement.
B
B
Contributors
who
are
newer
changes
that
are
smaller
than
the
enhancement
size
changes
that
can
happen
over
the
course
of
one
release
cycle,
which
we
call
features
that
that
is
a
bit
of
a
gray
area
right.
What
happens
when
a
feature
lands
and
someone
builds
on
top
of
that
feature?
How
do
we?
What
happens
when
we
need
to
revert
that?
Do
we
revert
multiple
features
to
get
this
done?
Do
we
revert
an
entire
enhancement?
Do
we
downgrade
an
api?
Can
we
do
that
like?
What
are
the
rules?
B
So
I
think
you
know,
part
of
this
is,
is
getting
a
little
clearer
about
what
can
and
can't
be
done
and
thinking
about
what
the
the
kind
of
stick
or
the
enforcement
piece
of
this
is
right,
because
the
the
offer
for
keps
is
essentially
like
to
get
on
the
the
release.
Train
right
to
you
know
to
be
to
be
in
the
release.
Notes
to
you
know,
have
potentially
a
section
of
the
release
blog
written
about
your
enhancement
so
on
and
so
forth.
Right.
B
The
expectation
is
that
you
do
all
of
these
things
on
time
within
the
scope
of
a
release
cycle,
so
that
the
release
team
doesn't
have
to
go
chasing
people
and
the
release
team
currently
does
quite
a
bit
of
chasing
people,
so
the
this
conversation
is
kind
of
happening
in
multiple
groups.
It's
happening
here.
It's
happening
in
sig
release
across
the
release
team
across
release
engineering,
and
it's
also
happening
in
working
group
reliability.
B
So
one
of
the
ideas
currently
is
merge.
Improving
the
merge
blocking
plug-in
the
merge
blocking
plug-in
allows
you
to
block
merges,
but
it
is
kind
of
an
all-or-nothing
feature
right
now
right.
So
if
you
open
up
a
merge
blocking
issue,
the
merge
blocking
issue
will
block
merges
across
all
branches
for
kubernetes
right
where
in
this
case,
we
kind
of
only
want
it
to
block
for
the
current
release
cycle
right,
so
the
merge
blocking
plug-in
needs
some
granularity
and
what
it
can
do.
B
The
way
that
merge
blocks
happen
today.
Is
you
open
an
issue
and
you
tag
it
with
the
merge
block
or
label
anyone
can
close,
merge,
blocker
issues,
anyone
anyone
should
be
able
to
close
issues
in
general.
I
think
anyone
can
issue
the
slash,
close
command
or
maybe
org
owners.
I'd
have
to
look
into
that.
B
Suffice
it
to
say
there
are
plenty
of
people
who
can
close,
merge,
block
issue
and
kind
of
undo
that
enforcement
mechanism,
so
the
merge
blocker
plug-in
also
needs
to
support
specific
groups
of
of
people
being
able
to
block
merges
for
specific
release
branches
right
so
more
to
discuss
there.
I
think
more
of
that
conversation
will
happen
in
sig
release
as
well
as
working
group.
Reliability.
B
Working
group
reliability
has
a
a
proposal
out
for
increasing
the
reliability
bar
of
releases,
and
I
think
that
the
merge
blocking
plug-in
will
be
a
key
component
of
some
of
that,
as
they
move
from
investigation
into
enforcement.
It's
early
days
for
them
right
now,
so
no
action
required
as
we
move
into
the
new
year,
but
definitely
in
121.
We
need
to
be
thinking
about
it.
B
So
so
this
kind
of
goes
back
to
the
the
conversation
about
kept
types
right.
So
some
some
features
so
the
the
way
we
define
enhancements
versus
features
is
like
a
feature
is
a
unit
of
work
that
can
land
within
the
scope
of
one
cycle
right.
A
an
enhancement
is
a
set
of
features
that
need
to
be
executed
on
across
multiple
cycles.
B
Right,
so,
I
think
say
like
epic
versus
story
right
so,
depending
on
what
it
is
and
again
there's
some
gray
area
there
too,
depending
on
what
it
is,
may
determine
how
it
lands
right.
So
so,
yes,
we
haven't.
Quite
we
haven't
quite
figured
it
all
out
and
and
depending
on
the
scope
of
the
feature
like
there
may
be
different
requirements.
If
it's,
if
it's
a
feature
land,
it
have
tests
right,
get
a
good
release.
B
Note
if
it's
an
enhancement,
it's
a
set
of
features
which
may
require
feature
gate
and
rollout
across
multiple
release
cycles.
If
it's
something
that
doesn't
necessarily
touch
the
api,
it
still
may
require
rollout
across
multiple
release
cycles,
but
doesn't
necessarily
require
a
feature
gate
because
it's
not
because
it's
not
an
api
change
right.
B
So
so
the
answer
is,
it
depends,
but
having
some
clarity
around
and
being
a
little
bit
more
granular
about
the
requirements
as
we
move
through
those
different
types
would
be
something
that
we'd
want
to
get
out
of
this
team.
C
B
So
we
have,
as
far
as
I
know,
there
is
no
code
coverage
enforcement
on
kubernetes
kubernetes.
I
think
it's
something
that
we
would
want
eventually,
but
I
don't
know
where
that
discussion.
Okay
is
currently.
I
would
say
that
this
lands
that's
kind
of
the
cross
section
of
sig
architecture
and
sig
testing,
who
kind
of
have
the
pen
on
making
that
decision
thanks.
B
The
feature
gate
mention
is
a
good
something
I
did
not
mention
in
the
previous
topic
around
metadata
versioning,
but
kept
metadata
versioning.
One
of
the
things
that
was
suggested
by
hippie
hacker
was
a
field
for
the
name
of
the
feature
gate
right.
So
we
can
see,
we
can
see
it
kept.
We
can
see
an
enhancement
as
it's
kind
of
evolving
over
time.
B
Right
now,
the
conformance
group
has
no
way
of
telling
what
is
landing
when
until
kind
of
later
in
the
process,
when
they're
coming
back
to
kind
of
check
on
how
far
along
we
are
with
conformance
tests
for
specific
gates,
so
getting
them
in
earlier
in
the
process.
I
think
I
think
one
way
to
do
that
is
adding
that
field
right
and
that
allows
us
to
kind
of
track
an
api
change
over
time
too
right.
So
that's
something
that
we're
going
to
discuss
in
121
as
well.
B
Okay
and
the
last
two
are
one
shopping
around
the
idea
of
office
hours
and
product
program,
project
management
help
for
various
sigs.
This
kind
of
rolls
back
into
the
discussion
earlier
about
the
the
the
good,
the
not
so
good,
and
the
we
gotta
fix
this
categories
for
enhancement
owners.
B
So
as
we
kind
of
get
a
better
idea
of
who
fits
into
what
bucket
laurie
has
a
ton
of
research
on
this
already,
as
well
as
the
the
folks
who
have
been
on
the
release
team
in
the
past.
The
the
idea
is
that
some
of
the
newer
contributors
who
have
who
who
have
product
product
management
experience
can
work
with
cigs
to
to
start
thinking
through
what
that
sig's
roadmap
looks
like
what
they're
trying
to
execute
on
for
for
a
cycle
for
a
year
right.
B
A
Yeah,
like
I'm
just
actually
sorry
for
the
noise,
that's
a
plumber,
but
basically
I'm
just
getting
pinged
right
now
from
someone
on
this
topic,
I'm
like
please
join
the
enhancements
meetings
because
hey
then
the
scales
and
it's
becoming
a
group
effort
instead
of
focusing
isolation.
A
I
think
yeah.
Perhaps
we
need
some
I'll
drop
this
plan
and
we'll
meet
and
discuss
it,
and
but
I
think
that
maybe
there's
a
visibility
issue
like
people
not
really
recognizing
that
if
they're
sitting
there
wondering
why
certain
cigs
are
not
moving
cups
along,
you
know,
there's
a
group
where
we
can
discuss
it.
Try
to
take
actions.
B
Right
of
of
people
who
really
you
know
kind
of,
I
would
say
probably
in
the
center
of
this-
is
as
the
enhancement
sub
project
owners,
people
who
deeply
understand
this
process
and
had
hands
in
creating
it
then
kind
of
moving
outward
you've
got
the
you've
got
the
enhancement,
sub
team
of
the
release
team
and
then
the
wider
release
team
with
their
understanding
of
the
enhancements
process
and
then
a
little
further
out
you've
got
the
you've,
got
the
enhancement
owners
right,
so
the
people
who
are
actually
improv
enhancement,
owners,
reviewers
and
approvers
right,
so
you've
got
the
people
who
are
actually
executing
on
delivering
enhancements.
B
Who
should
who
should
know
how
the
process
functions
right
and
then
further
out,
you've
got
you
start
to
move
kind
of
outside
of
the
community
right,
and
I
think
that,
as
we
hit
that
circle,
it's
it's
a
little
hard
to
understand,
what's
happening
internally
right.
So
I
think
that
thinking
through
how
we
can
better
again
publicize
the
work
that
we
do
and
how
to
get
involved
with
the
process.
B
I
think
one
is
good
for
the
overall
health
of
the
process
and
the
community,
but
also
gives
a
huge
opportunity
for
people
with
the
the
product
management
experience
and
the
program
management
experience
to
get
more
deeply
involved
across
sigs.
A
I
mean
they're
asking
me
just
now:
this
is
a
project
of
sig
release
and
I'm
like
no,
so
I
mean
this
is
someone
who's
quite
knowledgeable,
so
this
just
is
a
little
indicator
as
we
head
off
into
the
holidays
ponder
what
would
21
2021
enhancements.
Look
like
we
might.
You
know
we
could
have
greater
visibility
and
engagement.
B
Yeah,
I
think
you
know
when
it
when
it
works
really.
Well,
you
know
the
sufficient.
I
I
forgot
what
the
phrase
is
but,
like
you
know,
sufficiently
complex
something
yadda
yadda
indistinguishable
from
magic,
wow,
something
it
was
a
good.
It
was
a
good
quote
and
I
ruined
it,
but
essentially
like
when
we're
doing
our
job
really
well.
This
shouldn't
exist
that
we
we
you
know
it's
yeah.
A
A
We
need
your
ideas.
We
need
more
contributors
here,
just
use
the
channel.
It
might
be
a
little
awkward
as
we
as
we
try
to
onboard
you
and
find
something
for
you
to
do,
but
there's
a
commitment
here.
So
just
hang
hang
in
there
with
us
and
for
sure
like
we're,
starting
to
provide
that
to
the
new
new
folks
that
join
so
you
can
be
the
next
because
we
definitely.
A
We
definitely
need
more
people
here
with
new
ideas,
more
more
ideas,
helping
it's
just
too
much
too
much
effort
for
overstretch
people,
the
overstretched
sub
owner
sub
project
owners,
which
includes
me,
I'm
not
that
overstretched,
but
this
will
be
a
high
priority
for
me
in
121,
but
everyone
else
is
struggling
a
lot
of
responsibility.
So
we
need.
We
need
more
folks
for
sure.
So.
B
Yeah-
and
I
I
echoing
that
I
would,
I
would
say
that,
like
be
be
vocal,
be
very
vocal,
don't
something
I
tell
the
release
team,
don't
assume
that
anything!
That's
written
down
is
correct.
B
It's
everything
is
an
opportunity
for
improvement.
Carrying
this
for
a
few
years.
I
I
do
not
have.
I
do
not
have
product
or
program
management
experience.
I
have
ever
had
that
title
as
a
job
title,
I'm
just
reasonably
organized
in
at
certain
moments.
So
you
know
what
I
would
love
to
see
is
more
people
who
do
have
that
expertise
coming
in
to
this
project
to
to
guide
it
so
yeah
to
wrap.
There
are
two
more
items
that
I
just
stuck
on
the
back
of
the
agenda:
three.
B
Actually,
the
website
the
website
will
come
together
when
all
the
metadata
comes
together.
I
know
that
people
are
starting
to
pick
the
website
idea
back
up,
so
we
should
hope
to
see
something
bare
bones
pop
up
towards
the
end
of
121
or
beginning
of
122..
B
I'm
not
sure
who
all
has
the
access
to
do
so
lori,
it's
possible
that
you
don't
have
access
to
do
some
of
these
things,
so
we'll
work
that
out
in
the
new
year.
I
think
we
also
have
to
make
sure
this
meeting
has
a
password
on
it
and
and
make
sure
everyone
has
access
to
like
the
youtube
playlist
to
do
that
and
host
keys
and
all
that
good
stuff.
B
And
then
the
other
housekeeping
item
is
that
the
we've
got
a
few
comments
from
folks
that
were
not
able
to
attend
these
meetings
across
the
year
that
the
meetings
are
at.
The
meeting
may
be
at
a
inconvenient
time
so
going
into
the
new
year.
We'll
also
be
issuing
a
doodle
to
get
some
ideas
on
new
meeting
times
make
sure
it
is
more
inclusive
for
people
who
want
to
get
involved
and
with
that,
are
there
any
parting
thoughts
as
we
go
into
the
end
of
the.
B
B
Happy
holidays
happy
holidays.
Thank
you
all.
Thank
you
to
all
our
of
our
new
attendees.
Thank
you
to
all
of
the
folks
who
are
on
the
release
team,
who
have
been
making
this
better
and
better
across
every
quarter.
Yeah.
Thank
you.
Let's,
let's
crush
it
in
2021
have
a
good
rest
of
the
year.
Everyone
take
it
easy.