►
From YouTube: 20210128 SIG Architecture Community Meeting
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
Hello,
everybody:
this
is
the
kubernetes
cig
architecture,
community
meeting
for
january,
28th
2021
and
thank
you
everybody
for
attending.
Please
remember
to
follow
our
code
of
conduct
and
treat
each
other
with
respect,
and
I
guess
that's
it.
So,
let's
get
started.
Hippie
hacker
looks
like
you've
got
the
first
three
agenda
items.
So
why
don't
you
take
the
floor?.
B
Thanks
for
that,
john
just
a
quick
conformance,
some
project
update
without
going
through
the
slides
that
we
can
hence
it
down
since
I've
got
a
couple
of
other
agenda
items
today,
we're
still
sticking
to
our
30
endpoint
goal
for
121
stretch,
goal
of
40.
B
B
B
B
We
usually
do
the
obligatory
go
visit
the
api's
new
site
and
look
into
the
chart
up
to
the
right.
When
you
look
at
that,
it's
a
little
bit
of
a
lie.
This
time
and
I'll
tell
you.
Why
is
that
we
have
metadata
inside
our
conformance
yaml?
That
gives
you
the
date
that
that
or
the
release
that
that
test
was
promoted
and
becomes
part
of
the
conformance
program.
When
we
update
those
tests,
we
add
a
comma
and
then
date
that
it
was
updated.
B
Hopefully,
we
won't
hit
so
many
tests,
we're
updating,
because
most
of
the
other
things
for
the
rest
are
completely
untested
in
points,
and
we
do
have
a
couple
of
endpoints
that
look
like
they
snuck
in
as
far
as
ga,
and
that's
because
of
the
next
topic
in
illinois
and
points
and
eligible
for
conformance,
there's
a
link
to
a
conversation
there
on
google
on
google
groups
that
I
sent
out.
B
That
notes
that
oh
this
is
actually
for
our
conformance.
I
think
we
may
have
got
the
links
backwards
there
that
first
link,
if
we,
if
we
bring
it
up
and
share
it
for
the
conformance
testing,
for
we
want
apps
and
status,
is
about
clearing
out
the
one
nine
data
set
and
that's
us
working
with
the
sig
apps
group
to
try
to
figure
out
how
to
fix.
All
of
that.
Some
of
this
it
was
noted
that
status
endpoints.
B
Are
not
user
facing
usually
status?
Endpoints
are
hit
by
controllers
and
they're
a
bit
tricky
to
test,
because
the
controller
is
constantly
checking
the
status
and
updating
it,
and
it
tends
to
be
our
approach
to
set
the
status,
ensure
that
we
were
able
to
set
it
and
then
ensure
that
the
controller
reset
it
back
to
what
it
needs
to
be.
So
that
is
happening.
B
I
guess
that's.
The
one
of
the
topics
I
wanted
to
bring
up
today
was:
do
we
want
to
include
continue
to
include
status
endpoints
in
conformance
or
do
we
want
to?
Because
people
could
write
their
own
controllers
and
whatnot?
That's
what
was
kind
of
where
I
was
thinking
that
we
need
to
continue
to
test
status
and
sub-resources,
because
they
are
part
of
the
the
operation
ids
and
surface
area
of
the
fibonacci.
A
Yeah,
I
mean
right
conformance,
isn't
just
for
things:
people
consume,
but
also
for
things
machines
consume,
and
we,
you
know
if
you,
if
you
broke
status
status,
didn't
work
appropriately
better
as
expected.
That
could
break
people's
automation.
So
I
I
would
certainly
think
it
needs
to
be
continued
to
be
in
conformance.
B
B
Okay
and
I
go
back
to
our
agenda
so
and
here's
a
deeper,
a
deeper
thing
is:
if
we
click
on
that
list
of
ineligible
endpoints,
it
grows
as
we
find
things
that,
in
this
case,
we're
about
to
add
some
more
because
of
those
three
three
new
endpoints
that
are
actually
part
of
an
alpha
program.
But
there's
75
endpoints
here
and
the
tracking
of
the
operations
of
kubernetes
that
are
not
part
of
conformance
is
a
list
that's
written
in
sql
within
the
api's
new
repository
in
the
cncf
org,
it's
not
exactly
accessible.
B
It
feels
like
it's
in
the
basement.
You
know
during
the
vogon
fleet
coming
in
and
like
hey,
we
warned
you,
but
those
things
are
destined
to
not
be
looked
at
and
it
might
make
more
sense
for
us
to
have
some
metadata
somewhere
and
maybe
it's
in
the
kubernetes
testing
dd
test.
B
Ede
conformance
folder,
where
we
add
some
a
list
at
a
minimum,
just
a
yaml
list
of
something
with
endpoints
that
we
have
deemed
not
okay,
not
part
of
conformance,
and
why
so
that
those
can
be
tracked
as
pr's,
rather
than
my
team,
trying
to
make
sure
they
don't
show
up
in
the
list
of
things.
We're
tracking.
C
E
E
F
F
B
The
reasons
things
are
inside
that
list
vary
and
they're,
not
always
because
we
never
want
them
to
be
part
of
conformance
they're.
If
they're
vendor
specific
features-
and
we
can
come
with
a
framework
and
a
way
to
test
that.
But
I'd
love
to
pull
them
out
of
not
eligible
at
the
moment
for
conformance.
A
So
so,
let's
get
back
to
like
what
clean's
comment
gets
back
to
like
a
sort
of
we're
trying
to
make
this.
The
conformance
suite
serve
two
purposes,
and
one
is
for
vendors
to
verify
that
they're,
that
their
distribution
or
managed
service
is
conformant,
but
we
also
want
customers
users
to
be
able
to
run
that
conformance,
tweet
and
validate
validate
their
cluster,
but
but
really
it's
not
so
much
if
it's
not
designed
around
validating
a
specific
cluster.
Yet
people
are
using
it
for
that.
So
I
don't
know
that
we
have
the
bandwidth
really.
A
We
would
address
those
in
two
different
ways,
and
I
don't
know
that
we
have
the
bandwidth
in
this
group
to
do
that.
Like
I
don't
know,
anybody
stepped
up
to
kind
of
build
a
conformance
suite
for
running
production
clusters,
so
we
we
kind
of
fudge
it
by
just
not
letting
certain
things
we
like.
We
do
mark
certain
things
as
disruptive
and
those
aren't
run
when,
when,
when
users
run
it
in
their
own
clusters,
whereas
they
are
run
by
the
providers.
But
beyond
that,
we
don't
really
try
to
address
that.
It's
like.
B
In
order
to
submit
to
the
cncf
case
conformance
repository,
you
are
required
to
run
some
destructive
tasks.
Just
so
that's
super
clear
people
may
not
want
to
install
those
in
in
their
normal
day-to-day
operations,
but
as
far
as
making
sure
that
they
do
offer
something
that
is,
you
know,
kubernetes
conformant,
that
that's
where
that
should
be
running.
C
Like
tests
that
mess
with
your
cluster
in
more
substantial
ways
but
yeah,
I
think
that's
an
interesting
topic
for
discussion.
Maybe
at
the
next
conference
call.
B
Excellent
we'll
add
that
to
the
agenda.
I
just
wanted
to
make
sure
we
had
a
broader
view
here
and
then
the
last
thing
we've
we've
come
up
a
couple
times
against
this:
whether
we
go
to
sig
api
machinery
or
or
if
you're,
trying
to
track
when
it.
B
What
is
our
list
is
not
it's
our
own
opinion
within
the
api
team
and
our
original
opinion
is
if
the
url,
the
path
as
part
of
an
api
did
not
include
alpha
and
beta
alpha
or
beta,
then
it
became
ga
and
that's
not
not
exactly
true,
there's
lots
of
little
exceptions,
which
are
if
it's
one
of
our
ways
of
getting
around,
that
is
adding
it
to
ineligible
endpoints,
which
is
not
accurate,
because
at
some
point
later,
when
they
do
get
promoted,
we
want
to
catch
them,
and
we
thought
about.
B
We
kind
of
keep
our
own
metadata
around
that,
so
the
most
accurate
and
authoritative
place
for
that
is
going
to
be
to
encode
that
metadata
within
the
swagger
json
and
another
possible
thing
that
might
be
useful.
I
don't
know
if
that's
within
swagger
json,
but
would
be
tying
it
together
with
the
feature,
and
then,
if
this
is
part
of
the
kept
process,
it
kind
of
ties
in
multiple
places,
but
on
the
caps,
the
list
of
the
api
operation
ids,
and
I
think
it
does.
B
We
do
currently
attempt
to
track
the
feature
slides,
but
in
this
case,
for
this
group,
just
tying
it
down.
Do
we
want
to?
Is
this
a
completely
fig
machinery
thing,
but
I
wanted
to
be
like
a
request
from
architecture
to
engage
in
that
in
a
more
formal
way,
rather
than
me,
walking
over
and
saying
hey.
A
Well,
you
walking
over
is
totally
valid,
but
but
the
the
we
did
talk
about
this
like
a
year
or
two
ago,
and
it
was
you
know
it's
essentially
we
kind
of
tabled
it
because
just
api
machinery
has
so
much
going
on
and
didn't
have
the
bandwidth
to.
You
know
it
just
didn't
bubble
up
to
the
priority
in
in
their
environment.
But
of
course,
if,
if
your
team
or
somebody
else
involved
in
conformance,
can
you
know
lend
a
hand
that
maybe
they'll
be
review
bandwidth
for
it?
A
I
don't
know,
but
it's
definitely
something
you
can.
We
can
talk
to
cigar
teacher
about
our
apm
machinery
about
you,
but
you're
totally
have
all
it's
open
source
man
go.
Do
it
like
you,
don't
have
to
discuss
anything.
E
So
hold
on,
I'm
I'm
looking
through
here
trying
to
figure
out
what
are
these
things
that
are
using
api,
v1
prefixes
that
aren't
v1
and
I'm
not
finding
the
list
is.
Is
there
a
list
or
some
examples,
just
go
to
api
snoop,
dot,
cncf.
B
E
E
Well,
one
one
could
argue
that
we
should
not
add
sub
resources
to
a
stable
api
group.
We
should
add
them
to
a
beta
api
group
until
we
ga
the
sub
resource,
just
like
a
regular
old
type
right,
we
wouldn't
add
an
alpha
type
to
core
v1.
We
would
add
it
to
v1
alpha
or
v2
alpha
or
something
we
actually
do
really
poorly.
At
this.
B
Rion
just
dropped
a
link
to
the
pr
for
the
promotion
which
discusses
this
particular
one
and-
and
I
think
they're
also
the
comments
why
how
the
machinery
adds
it
at
that
point
understand
why
and
how
we
can
change
that
in
the
future.
G
A
B
I
think
that's
it,
I'm
not
sure
what
to
do
with
the
beta
api
conversation
as
far
as
in
ensuring
that
we
that
we
create
that
that's
kind
of
an
architecture
conversation,
so
that's
another
email
to
the
list
to
try
to
get
some
consensus.
But
that's
almost
like
a
policy.
You
know,
like
a
kubernetes
community,
my
policy
change.
A
Okay,
well
yeah,
I
think
that's
probably
the
place
to
start
would
be
to
mail
the
list.
Let's
talk
to
machinery.
C
H
H
A
I
see
jim's
just
commented
is,
is
lincoln
on
the
call?
No,
I
don't
see
it
all
right.
Well,
thank
you
and
it
looks
like
we've
got
an
update
from
the
enhancement
sub
project
too.
So
I
don't
know
if
jeremy
laurie
or
kirsten.
I
Wants
to
pick
that
up,
hey,
I
think
we're
gonna
ping
pong
that
and
cover
a
little
bit
of
different
stuff
inside
of
it.
Is
it
okay?
If
I
share
we
made
some
slides
just
to
so,
we
didn't
have
to
talk
to
bullet
points
on
a
word
doc.
Is
it
okay?
If
I.
G
I
Okay,
so
we're
gonna
talk
about
a
couple
of
different
things:
kind
of
a
venn
diagram
of
release
and
enhancements,
because
they
kind
of
you
know
there's
a
lot
of
things
that
go
hand
in
hand
there.
So
we'll
start
off
with
some
changes
in
121.
Some
changes
that
we're
looking
at
for
post
121
like
122
and
beyond,
and
then
just
some
general
updates
around
the
subproject
itself.
So
we'll
start
off
with
the
121
updates
and
kirsten's
gonna.
Take
that.
J
Forgot
to
unmute
myself,
I'm
a
professional
software
engineer.
So
are
the
slides
okay
for
everyone
just
to
make
sure.
G
J
J
J
Now
we
have
for
121
an
opt-in
issue,
an
opt-in
process
where
we're
asking
the
sigs
to
tell
the
enhancements
team
the
enhancements
release
team,
what
enhancements
they're
targeting
for
121.
This
is
pretty
awesome.
Honestly,
the
sig
the
process
is
basically
that
the
saves
will
go
to
a
special
sheet
and
the
enhancement
tracking
sheet,
so
we're
still
using
that
and
by
sig.
Let
the
team
know
what
caps
they're
targeting
for
121..
J
So,
instead
of
me
or
anybody
bothering
200
300
enhancement
issues
in
the
repo,
the
sigs
and
the
sig
leads,
are
going
to
come
to
us
and
say:
hey
like
these
are
the
five
keps
that
you
know
we're
going
to
be
working
on
for
the
enhancement
cycle.
These
are
the
ones
that
we've
already
thought
through,
and
you
know
you
don't
have
to
worry
about
the
rest
of
them
they're
going
to
enter
those
in
the
tracking
sheet
and
then
the
process
is
going
to
basically
proceed
from
there.
J
The
tracking
sheet
is
going
to
be
still
the
source
of
truth.
So
if
you
want
to
know
if
the
sigs
have
any
enhancements,
what
enhancements
they're
targeting
for
the
release
it's
going
to
be
on
that
sheet
and
then
we're
going
to
migrate
those
issues
over
into
the
normal
enhancement
sheet
and
then
track
them
as
at
risk
fully
tracked
et
cetera,
go
through
the
enhancements
and
let
the
authors
know
like
what
they
might
be
missing.
This
is
going
to
be
super
helpful
for
the
enhancements
team.
J
Like
there's
a
lot
of
prior
releases,
there
was
a
lot
of
really
sort
of
trivial
work
that
I
feel
like
nobody
really
liked
like
we
didn't
like
pinging,
you
didn't
like
getting
the
pings.
There
was
also
a
little
bit
of
ambiguity.
Did
the
right
person
get
the
right
ping?
Did
they
see
the
right
thing?
Did
they
know
about
the
issue
and
it
was
very
author-centric,
and
this
is
really
like
putting
the
responsibility
on
the
sticks.
J
The
sigs
are
the
people
who
have
to
maintain
it
they're
the
ones
who
have
clarity
about
whether
or
not
they
have
capacity
to
review
these
prs
to
review
these
kept
and
frankly,
they
don't
have
capacity
to
look
at
every
single
enhancement
issue,
every
single
release
and
say
yes
or
no,
so
this
is
hopefully
like
a
streamlined
process.
J
A
One
of
the
things
that
I
I
shadow
or
I
I
shadowed
on
that
team
for
a
couple
releases
and
I
do
recall
that
it
was
not
unusual
for
me
to
ping
somebody
and
then
be
like
oh
right.
I
forgot
about
that.
I
need
to
get
that.
D
A
And-
and
you
know,
obviously,
that's
not
great
on
their
part,
but
you
know
it's
human,
so
I'm
wondering
what
what
do
we
do?
You
know
we
we
used
to
take
that
list.
I
know
bob
had
written
an
automated
script
in
the
sheet
that
would
populate
it.
I'm
wondering
how
do
we
educate
the
cigs
that
their
responsibility
has?
They
have
to
be
more
proactive
right
because
they've
been
reactive
and
they're
accustomed
to
that.
So
how
do
we
go
to
them
and
say?
Look
you
need
to
do
like
enhancement.
J
A
that's
a
really
good
question
and
I
think,
like
proactive
versus
reactive,
is
kind
of
like
the
the
biggest
pain
point
that
that's
perfectly
summarized.
What
we've
been
doing
is
the
enhancements
lead,
along
with
the
shadows,
have
been
reaching
out
to
all
of
the
things
and
letting
them
know,
and
you
know,
keeping
them
updated,
sending
emails
directly.
J
I
mean
it's
actually
almost
easier
because
there's
a
limited
number
of
people
that
you
have
to
contact
to
contact
sigs
as
opposed
to
this,
like
infinity
group
of
authors,
that
you
may
or
may
not
be
able
to
get
into
contact
with,
like
we
frequently
have
authors
of
keps
who
are
no
longer
active
and
we're
pinging,
basically
the
wrong
person.
So
this
also
picks
up
that
process.
Where
you
know
the
sig
actually
wants
to
work
on
this,
but
they're
not
getting
ping.
J
The
author
is,
you
know,
working
on
something
else
now,
so
we've
been
actually
super
proactive
on
the
enhancements
team
trying
to
let
things
know
about
the
process.
Keeping
in
communication
with
that
anna's
been
really
great
about
updating
the
tracking
sheet
to
sending
out
updates
with
the
tracking
sheet
explicitly
saying
you
know
hey.
These
are
the
things
that
we
have
kept
for.
If
your
swig
is
not
on
this
list,
we
have
no
caps,
which
is
also
a
really
clear
message,
as
opposed
to
previously
where
it's
like.
J
J
I
think
that
we're
having
very
like
clear
communications
as
well,
so
we've
been
proactive,
and
I
think
that
the
way
that
we've
been
proactive
is
more
effective
this
time,
because
the
messaging
is
a
lot
clearer,
so
yeah
like
the
enhancements,
lead
and
the
shadows
are
posting
in
the
slack
channels,
they're
emailing
to
the
to
the
sigs
they're
emailing
to
kdev.
J
A
I
Outreach
we
also
hit
up
the
chairs
and
tech
league
meetings,
both
of
them
for
the
month
to
just
make
sure
that
we
we're
trying
to
get
all
the
communication
avenues
covered
for
this.
D
K
I
still
have
the
question,
so
are
you
going
to
add
another
date
by
which
the
six
have
to
enter
their
information
into
their
tracking
sheet.
J
We
pondered
this.
We
honestly
this
was
something
that
we
were
thinking
about
and
then
we
thought
hey
like
having
this
update
kind
of
sucks
right,
because
you're
also
trying
to
review
caps
at
the
same
time.
So
the
enhancements
freeze
is
still
the
enhancements
freeze
like
if
you
want
to
give
people
a
heads
up
before
then
like
that
is
highly
highly
recommended.
J
But
if
you
put
it
in
the
last
minute
I
mean
that's
kind
of
on
you,
but
it's
still
going
to
be
held
to
the
same
standard,
so
you're
kind
of
missing
out
on
the
opportunity
to
have
other
people
get
other
eyeballs
on
it
and
let
you
know
whether
or
not
it's
met
all
the
criteria
by
the
date,
but
we
thought
that
we
did
have
that
discussion
and
we
thought
that
it
was
just
too
many
deadlines.
You
know
it's
like
yeah,
you
have
to
you
have
to
let
us
know
and
and
at
the
enhancements
freeze
deadline.
J
We
take
those
we
take
that
list
and
we,
you
know,
make
sure
that
they
all
meet
the
criteria
and
then
that's
that
if
you
want
to
put
them
in
the
list
sooner
anna
and
the
shadows
are
going
through
those
caps
and
interacting
with
all
of
the
with
a
lot
of
the
authors
on
that
list.
Now
saying:
hey
like
you
still
need
test
plans,
you
might
still
need
a
graduation
criteria
here.
K
Other
than
the
communications
and
the
proactive
help
that
the
team
provides,
what
do
those
do
those?
Basically,
what
is
this?
What
is
the
stick
right
like?
How
do
we
make
sure
that
people
do
the
right
thing?
So,
what
other
than
the
positive
stuff,
with
the
engagement
and
like
things
like
that,
what
do
they
lose
if
they
don't
put
it
in.
J
K
J
J
It's
the
same
thing
except
we're,
not
pinging
every
author
now
we're
asking
the
figs
to
tell
us
what's
in,
what's
in
the
what's
in
what
what
they're
intending
to
target
okay.
K
So
let
me
poke
at
it
a
little
bit
more,
so
what
we
are
saying
is
they
have
to
mark
the
caps
properly
in
the
cumulative
enhancements.
They
have
to
make
sure
that
the
metadata
is
correct.
They
should
make
sure
that
the
milestones
are
set
correctly
in
the
cap
that
is
checked
in
they
have
to
update
the
kubernetes
enhancements
issue
related
to
the
cap
and
keep
that
up
to
date
right
if
they
do
those
two
things,
but
if
they
don't
put
it
in
the
tracking
sheet,
then
it's
still.
They
can't
merge.
D
K
I
understand
I'm
just
just
so
that
all
of
us
are
on
the
same
page
on
what
will
happen
right
so
that
that's
what
I'm
poking
at
so
that
we
can
support
you
in
this
decision
making
process
like
if
you,
if
the
release
team
says
this
is
what
we're
going
to
do.
If
the
issue
is
up
to
date,
cap
is
up
to
date.
Everything
is
checked
in
everything
is
lgtm
approved
in
enhancement,
repositories
and
merged,
but
they
haven't
entered
into
the
tracking
sheet.
I
It's
there's:
we
don't
have
that
stick
right
now.
People
can
still
merge
things.
Unfortunately,
we've
had
this
over.
You
know
putting
my
release
hat
on
we've
had
this
a
few
times
like
there
were
things
that
don't
end
up
with
enhancement,
tracking
issues
or
caps
that
get
merged
in,
like
in
118,
the
client
go
updates.
There
was
no
cap
and
no
enhancement
issue
for
that.
I
It
was
just
like
a
really
big
change
to
client
go
like
there's
a
new
context,
parameter
that
goes
into
everything,
and
we
have
one
or
two
of
those
every
time
and
we
try
to
we.
We
handle
them
in
a
best
effort.
Kind
of
way
like
there
is
no
enforcement.
You
know
if
to
merge
into
kk.
There
has
to
be
something
in
in
the
enhancements
repo
I'm
trying
to
get
you
that.
K
General
yeah
yeah.
I
want
to
get
get
it
in
an
automated
fashion,
because
the
tracking
sheet
is
disconnected
from
the
github
stuff.
K
J
Period
where
we're
trying
to
like
we
can't
the
old
process
is
unsustainable,
we
run
into
a
lot
of
issues
like
authors,
get
left
out,
they
get
the
wrong
impressions.
Things
are
overwhelmed,
so
this
is
like
a
transitional
release
before
we're
totally
automated,
and
a
lot
of
sigs
have
also
been
taking
advantage
of
it
by
organizing
themselves
a
little
bit
better.
Taking
a
lot
of
responsibility
for
the
kept
saying
these
are
the
only
ones
that
we're
doing
like.
J
K
Got
it
so?
The
last
question
I
have
is
say
some
set
of
features,
since
this
is
you're
rolling
out
just
now
fall
into
this
hole
right.
Do
they
ask
for
a
exception
and
then
update
this
tracking
sheet
for
121.
J
You
would
need
an
exception,
but
then
I
would
also
ask
for
a
bit
of
reflection
of
why
a
sig
was
unaware
that
a
feature
was
merging
and
couldn't
tell
anybody,
because
this
is
a
little
bit
different
than
usual,
where
the
authors
merge
it
without
the
sigs
really
knowing.
So
that
would
also
be
a
point
of
like
reflection
of
like.
Why
are
we
merging
features
like?
Why
are
some
people
merging
features,
but
that's
not
seemingly
in
the
plan
of
the
sig.
K
So
you
will
be
forcing
the
sick
chair
and
the
tears
to
file
the
exception
and
not
the
authors
themselves,
because
it's
just
an
email
right.
Anybody
can
do
it
and
that
typically
folks
will
just
go
ahead
and
you
know
send
an
email
out
for
an
exception
right.
So
how
are
we
forcing
the
author
and
the
sig
leads
to
talk
to
each
other?
So
you
know
so
so
that
seed
leads
can
get
a
sense
of
like
why
they
missed.
K
I
The
way
we
would
enforce
it
before,
I
think,
every
time
we
would
when
we
were
proactively
reaching
out
to
people
and
doing
the
polling,
you
know
we
would
tell
them
hey.
You
need
to
open
a
exception
request
for
this
or.
D
I
On
the
issues
hey,
you
need
to
open
an
exception
request
for
this,
so
I
think
it
just
becomes
a
communication
task
on
the
part
of
the
release
team
and
we'll
definitely
push
for
that
this
time
around
going
forward.
It
will
be
a
pr
in
122
when
we
move
to
the
enhancements
process
or
the
receipts
process,
which
is
what
we're
going
to
talk
about
next
again,
like
that'll,
be
more
automated
it'll,
be
much
easier
for
us
to
put
some
some
gating
and
some
some
enforcement
in
place
for
that.
A
If,
if
I
could
just
say,
I
think,
especially
in
this
transition
period,
it
would
be
really
helpful,
I
think,
for
cigs,
if,
if
there
can
be
a
reconciliation
process,
where
you
look
at
people
who
have
done
it
like
if
they've
already,
if
a
sig
has
approved
a
cap
and
the
metadata
in
the
cap
says
that
it's
targeted
for
this
release,
but
it's
not
in
the
sheet,
it's
likely,
they
just
didn't,
know
or
forgot,
or
weren't
paying
attention
to
the
process
changes.
A
I
also
think
that
you
know
our
kep
process
that
theoretically
sigs
know
what
they're
doing,
but
actually
anybody
can
list
anybody
as
an
approver.
I
guess
I
guess
the
owner's
file
only
lets
sig
leads
approve
caps
in
the
enhancements
repo.
So
there
should
be
some
awareness
by
a
sig
lead
is
approving
that
so
yeah
we
should.
I
think
we
should
do
that
reconciliation,
our
cross-reference,
so
that
we
make
sure
people
don't
just
inadvertently
leave
it
off
the
list.
D
I
mean
if
you're
a
sig,
and
you
have
a
list
of
enhancements
that
you're
preparing
for
a
release
cycle.
You
could
review
those
during
your
meetings.
Have
multiple
people
aware
to
watch
out
for
enhancements
and
track
them,
and
then
you
delegate
the
job
instead
of
having
a
sig
chair,
do
all
of
it
all
the
time
or,
however,
some
manage
this.
This
is
this
could
become
a
group
activity
by
bringing
visibility
into
your
intended
workload
for
the
upcoming
release
cycle
and
then
discuss
this
in
the
group
figure.
D
D
Well,
I
mean
that's
why
I'm
presenting
help
on
slide
11
but,
like
we
are
doing
this
in
sig
release
a
lot
all
the
time
now,
like
we've,
we've
been
able
to
stretch
the
sig
in
such
ways
to
involve
more
people
to
actually
make
this
real.
It's
not
even
a
theory
anymore.
For
us,
it's
real.
It's
happening.
A
So
I
think
it's
wonderful,
I'm
just
saying
that
the
big
cigs
may
be
very
organized
and
have
a
lot
going
on
and
so
have
need
that
organization.
There's
a
lot
of
sigs
with
literally
just
a
couple
of
people
that
participate.
That
may
not
be
aware
of
what's
going
on,
so
it's
not
so
we
just
have
to
be
sure.
A
D
But
you
know
usually
with
a
sig,
even
if
you're
a
very
busy
large
sig,
that
most
you're,
if
we
have
52
and
handsome
it's
going
into
release
you're,
not
you're,
probably
in
charge
of
eight
to
ten.
So
it's
just
really
a
matter
of
choosing
those
eight
to
ten
that
you
want
to
prioritize
and
get
in,
and
that
can
be
where
the
discussions
happen
in
the
meetings
which
are
already
taking
place
anyway,
but
also.
J
Just
as
a
point
there's
quite
a
few
sigs
that
have
already
started
participating
in
the
project
I
mean
in
the
in
the
new
process
like
I
know
that
there
were
at
least
five
or
six
that
are
actively
getting
their
their
cups
together.
So
it's
not
the
case
of
like
one
fig
is
like
doing
it,
and
everyone
else
is
like
I
don't
know.
J
What's
going
on,
like
people
are
being
pretty
responsive
about
this,
so
I'm
quite
optimistic
about
the
process
and
the
process
of
moving
to
a
more
automated
process
like
people,
people
are
doing
it
and
it's
pretty
cool
to
watch.
If
that
makes
anybody
feel
better.
I
Awesome,
thank
you
cool,
so
we'll
move
on
just
in
the
expediency
of
time.
Just
a
quick
one
for
prr
we
have.
The
enhancement
team
has
been
reminding
people
that
they
need
to
complete
the
prr.
It
seems
like
not.
Everybody
is
super
aware
of
that,
so
we've
been
pointing
them
to
the
proud
readiness
channel
if
they
have
questions
so
be
on
the
lookout
for
those
people
coming
to
to
ask
people
started
to
see
like
kept
foul
failures
and
they're
like.
Why
is
this
failing?
I
I
don't
I
didn't
know
I
needed
to
do
this
now,
so
we've
been
kind
of
pushing
them
along
that
route.
So
for
122
and
on
our
goal
is
to
move
to
this
process.
We've
been
calling
the
receipts
process
so,
instead
of
using
the
enhancements
tracking
spreadsheet
and
instead
of
you
know,
doing
the
polling
that
we're
doing
we're
going
to
move
to
an
opt-in
sort
of
process
where
sigs
will
open
up
a
receipt.
I
A
piece
of
metadata-
that's
enamel,
form
that
links
to
which
caps
they're
going
to
launch
in
you
know
in
basically
in
what
release
so
there
will
be
a
you'd
open,
a
pr
to
like
the
122
release
folder
in
the
enhancements
repo
and
say
you
know,
kep,
1089
or
whatever
you
know
the
issue
that
matches
up.
I
That
would
be
your
intention
to
join
the
release
and
we'll
be
able
to
keep
track
of
things
that
have
landed
in
the
release,
things
that
will
be
removed
from
the
release
and
would
require
exceptions.
Exception
requests
will
become
prs
to
move
those
things
back
and
forth
with
the
appropriate
approvals.
This
is
gonna.
I
There's
a
cap
in
process
right
now
that
you
can
go
and
we'd
ask
you
to
go
review.
We
would
like
to
opt
in
and
do
this
work
during
the
121
release.
That
will
be
some
process
changes
and
it
will
be
a
lot
of
kept
ctl
enhancements.
We
want
to
make
a
lot
of
this
not
manual,
so
people
can
just
use
the
tooling
to
generate
the
receipt
so
that
we
can
use
the
tooling
to
generate
a
summary
manifest
that
will
replace
the
the
enhancements
tracking
spreadsheet
additions
to
kept
val.
I
That
will
do
this
validation
for
us,
so
we
would
like
to
get
this
pr,
so
this
kept
approved
by
the
exception,
sorry
by
the
enhancements
freeze
date,
which
is
next
the
9th.
I
So
this
is
a
take
away
action
item
for
people.
Please
go
review
this
cup.
Please
leave
any
feedback,
it's
pretty
detailed
right
now
and
listing
out
what
the
process
will
look
like
and
what
the
tooling
will
do
has
not
been
defined
yet.
But
it's
going
to
really
just
you
know,
give
automation
to
that
that
process
we
wanted
to
get
the
process
defined
in
the
cap
before
we
started.
Writing
the
kept
ctl
updates,
so
we're
going
to
do
it
during
hopefully
during
121
we're
trying
to
dry
run
it
right
now.
I
Now,
varun-
and
I
are
doing
some
some
manual
things
just
as
things
come
into
the
spreadsheet,
we're
doing
things
in
a
fork
or
sorry
in
a
branch
to
just
kind
of
track
things
and
work
through
the
process
a
little
bit
and
a
lot
of
the
work
is
going
to
end
up
being
a
revamp
of
kept
ctl
and
kept
valid
to
just
support
this
process
a
little
bit
more.
I
Why
change?
I
think,
we've
covered
all
of
this
as
we
went
through
some
of
the
problems
in
you
know,
what's
going
to
happen
in
121,
but
really
we
want
to
make
things
a
little
bit
more
transparent,
a
little
bit
more
discoverable
like
right.
Now
it's
not
really
easy
for
people
in
the
community
to
come
and
say
what's
going
to
be
in
this
release,
they
have
to
go
click
through
the
spreadsheet
and
it's
just
it's
not
super
awesome.
I
I
Okay,
some
other
updates
lori
go
ahead.
D
Yeah,
so
we
were
talking
about
this
earlier,
I
was
actually
thinking
as
we
were
talking
like
what
about
a
kind
of
very
simple
toolkit
to
help
sigs
along
who
are
struggling
with
some
of
these
alignments
and
communication
issues.
So
just
basically
have
a
couple
of
simple
things
that
sigs
can
do
to
to
get
to
get
going
with.
D
You
know
just
to
help
themselves
really,
but
some
of
the
things
that
we've
tried
in
sig
release
might
be
useful,
for
example,
how
we've
delegated,
where
can
involve
more
contributors
and
the
actual
running
of
the
group
so
creating
topic
sponsors.
These
are
basically
tech
leads
or
release
managers.
D
Who
will
drive
a
topic
to
get
something
complex,
that
we've
wanted
done
during
a
release
cycle,
and
so
this
model
could
be
adapted
for
sigs
that
are
overwhelmed
with
work,
to
be
able
to
create
a
group
just
looking
out
for
their
package
of
caps
for
the
upcoming
cycle.
But
that
is
basically
what
I've
posted
here.
I've
shared
a
spreadsheet
before
and
shares
and
leads
with
some
of
these
process
improvement
offerings.
D
So
if
you
want
help
with
alignment
or
delegation
or
some
something
else,
happy
to
help,
I've
been
a
little
busy
recently
in
the
last
few
months,
but
I'm
still
around
even
more
than
usual,
just
a
little
more
behind
the
scenes
and
focusing
on
some
of
some
of
the
sig
release
process
improvements,
because
we'd
really
like
to
show
the
community
that
we
can
make
these
things
work.
I
D
I
Sue
elena,
she
dropped
a
link
into
the
enhancements
channel
with
a
curated
list
of
what
they
have
that
they're
tracking
so
far
that
they
can
then
build
their
list
for
121
and
122
off
of
super
cool
signate
in
general.
I
think
just
did
a
really
good
job
in
1
20,
as
well
with
with
coming
together
and
making
sure
they
had
a
good
list
of
things
that
they
wanted
to
to
get
forward.
D
Yeah
exactly
so
like
when
I
was
thinking
of
the
toolkit
idea.
A
lot
of
what
alana's
doing,
I
think,
would
be
extremely
helpful
to
show
exactly
how
you
can
create
a
structure
for
contributors
to,
for
example,
use
a
github
project
board
and
know
exactly
what
to
do
to
understand
what
all
the
labels
mean
and
just
help
out.
You
know
she's
really
reduced
the
friction
around
supporting
a
say
ground
process.
D
So
if
that's
of
interest
reach
out,
but
I
think
I'll
just
make
it
anyway
and
then
show
people
what
it
looks
like
and
then
you
can
all
decide
if
it's
something
you
want
to
adopt,
but
it'll
be
just
a
collection
of
best
practices
that
have
been
used
throughout
the
ecosystem
in
the
last
few
months
to
address
this
very
topic
of
managing
workflow
and
delegating
it
to
others,
so
that
people
don't
burn
out.
I
Cool
thank
you
for
that
update.
Sorry,
next
up,
two
really
quick,
like
kind
of
technical
updates,
so
we
have
this
tool
called
ctl
and
we
haven't
like
super
widely
publicized
it
yet,
but
I
think
john
and
the
prr
team
have
been
using
it
to
do
queries
to
find
things
they
need
to
review.
I
We've
been
using
it
internally
at
vmware
to
do
some
reporting
just
querying
stuff.
There
have
been
a
few
pr's
that
have
gone
in.
They
just
wanted
to
give
a
shout
out.
We
had
a
new
contributor
that
did,
I
think,
all
of
these
he's
added
some
tests
to
it
and
added
some
abilities
to
do
additional
queries.
So
that's
pretty
cool
when
we
start
doing
the
receipts
process,
we
will
add
more
functionality
to
this
and
make
it
more
of
a
ready
to
consume
tool.
I
But
right
now,
if
you're
curious-
and
you
want
to
query
to-
you-
know,
find
like
what
caps
are
available
for
mysig
chemctl
will
do
that
for
you
and
it'll
check,
prs
it'll
also
check
things
that
have
been
merged
in
we
added
the
ability
to
query
for
author
and
nabaroon
has
added
an
extra
output
format.
So
it'll
also
generate
like
a
csv
file.
If
you're
trying
to
get
some
new
output
formats,
this
one's
a
pretty
big
one.
I
As
we've
been
doing
some
of
these
changes,
you
know
adding
the
kep
yaml
moving
away
from
that
single
kind
of
markdown
file
to
a
more
directory
structure
based
thing
we're
ending
up
in
the
state
where
things
are
in
various.
You
know
on
that
continuum.
Some
things
have
not
been
updated,
yet
some
things
have
been
updated.
Yet
we've
generally
been
trying
to
get
people
to
update
them
or
forcing
them
to
update
them
for
a
release.
I
I
So
stephen
is
looking
at
how
we
can
move
to
version
the
caps
so
that
when
the
metadata
is
present,
we
can
do
validation
based
off
of
different.
You
know
different
versions,
make
things
a
little
bit
easier,
a
little
bit
better
to
maintain
going
forward.
I
There's
an
issue
open
here
with
a
description
of
what
is
what
we
have
in
mind
for
this
we'd,
encourage
everybody
to
go
read
that
steven's
also
got
a
small
work
in
progress,
pr
kind
of
moving
things
out
of
the
kep
val
structure
into
an
api
package
that
we
can
version
and
and
work
with
going
forward
all
right.
So
a
lot
of
information
that
we've
given
you
so
far.
If
anybody
is
interested
lori,
do
you
want
to
talk
about
the
meeting.
D
Yeah,
so
we've
really
been
able
to
get
more
and
more
momentum
around
the
enhancement
sub
project.
Overall,
we've
had
more
people
showing
up
to
the
meetings,
but
we
will
change
the
meeting
time
and
day,
maybe
not
the
day,
but
definitely
the
time.
It
doesn't
work
for
kirsten
and
many
other
people.
So
the
link
there
is
so
that
you
can
contribute
your
input
if
you'd
like
to
start
joining
these
meetings-
and
we
have
a
doodle
poll
set
up
and
I'll
extend
that
until
next
tuesday
and
then
we'll
take
the
findings
and
rework
our
meeting.
D
Invite
but
there's
a
lot.
We
can
actually
do
in
enhancements
and
arguably
there's
a
lot.
We
should
do
there.
So,
if
you're
having
struggles
with
the
process,
for
example,
it
would
be
great
if
you
or
some
delegate
from
your
sig
would
join
us,
and
then
we
can
talk
about
that
issue
or
where
we've
been
talking
about
and
actually
getting
a
couple
of
product
managers
from
different
companies
to
join
and
you're.
D
They
may
be
able
to
help
your
sig
with
some
of
the
prioritization
and
just
running
of
your
of
your
meetings
and
refining
your
backlogs
so
that
you,
you
can
manage
your
ket
backlog
better
and
maybe
your
backlog
overall,
you
know
they
can
provide
prioritization
strategies.
They
can
help
you
validate
the
importance
or
the
impact
of
caps.
D
So
if
that's
of
interest
getting
an
actual
product
manager
to
join
your
say,
can
just
offer
some
of
that
guidance.
Then
you
can
reach
out
in
the
channel
and
we
have
a
few
that
are
that
are
part
of
the
sub
project.
Now
we
also
could
be
doing
some
office
hours
type
activities
where
we
help
authors
of
caps
that
are
in
your
sig,
so
you
could
match
them
or
you
could
just
direct
them
our
way.
D
If
they
would
like
to
learn
how
to
write
really
good
caps,
they
could
get
that
kind
of
advice
through
the
enhancement,
subproject
but
I'd
say
start
with
any
of
your
feedback
in
the
enhancements
channel,
and
we
can
see
if
we
can
build
some
momentum
because
it's
historically
been
a
rather
quiet
channel,
which
is
a
little
bit
surprising
to
me.
D
Given
how
important
enhancements
are
to
the
evolution
of
this
project,
so
maybe
2021
can
be
the
year
that
we
really
make
enhancements
the
place
to
be,
and
maybe
we
can
even
meet
in
person
at
some
point
we
can
all
travel
again
or
something,
but
yes,
for
now
we
can
just
socialize
and
coalesce
on
the
channel
and
and
at
the
meetings
and
and
get
it
more
active.
We
also
have
needs
like
the
cap,
tooling.
You
know
when
we
have
a
technical
need.
D
It
often
will
wait
for
months
because
there,
just
historically
haven't
been
enough
people
with
enough
bandwidth
to
do
that
work.
We
have
a
lot
of
extremely
busy
people
in
that
sub
project
that
are
stretched
across
the
project.
So
it's
always
an
outlet
for
someone
in
your
sig
who
may
just
want
to
help
keep
kubernetes
running.
Who
wants
to
help
out
with
a
task?
You
can
send
them
our
way
if
they're
interested
in
and
how
enhancements
work
and
making
the
process
better.
J
That's
a-
and
I
guess
just
just
for
me
as
a
note
like
I've
been
involved
now.
I
guess
in
enhancements
for
a
year-
and
I
just
see
a
lot
more
people
involved
with
the
release
team
sticking
around
and
really
like
hearing
about,
what's
happening
and
absolutely
like
wanting
to
help
authors
and
wanting
to
help
sigs
and
wanting
to
really
try
to
get
a
process.
That's
sustainable.
J
J
We're
all,
I
think,
on
the
same
team
like
trying
to
push
this
to
something
that
really
works
and
there's
like
a
huge
there's,
just
like
a
huge
desire
to
make
it
better,
and
I
haven't
like
seen
that
until
now.
So
I'm
super
optimistic
about
2021.
like
there's
so
much
energy
and
there's
so
much
like
goodwill
and
like
desire
to
put
in
that
little
bit
of
effort
to
make
things
better.
That's
like
at
least
for
me
pretty
exciting.
So.
D
Yeah
seconded
I
mean
a
lot
of
it
was
kirsten's
work
driving
enhancements
to
the
next
level.
We've
had
great
retros,
you
know,
jeremy
nabarro
and
running
taylor,
running
the
release
cycles
and
we've
been
collecting
a
lot
of
the
feedback
and
not
just
collecting
it,
but
organizing
the
release
team
and
then
the
broader
sake
and
some
of
the
sub
projects
actually
act
on
that
feedback.
So
we
don't
let
those
issues
kind
of
linger
around
indefinitely
anymore,
they're
getting
acted
upon
and
and
that
cycle
is
shortened
significantly.
D
When
I,
when
I
showed
up
last
spring,
there
was
a
backlog
of
100
items
that
were
related
to
process
improvements
and
and
they're
gone
like
we
either
bunch
them
with
other
things
or
we
just
did
them
or
we
found
a
simpler
way
to
to
knock
out
20
items
that
were
all
pointing
toward
the
same
basic
desire
to
make
something
better.
So
this
has
been
such
an
amazing
and
inspiring
group
effort.
So
that's
I
echo
christian
saying
we
could
definitely
do
this.
K
So
thanks
a
lot
laurie
kirsten
jeremy
thanks
for
giving
us
an
update
here,
yeah,
I
always
worry
about.
You
know
whether
we
can
do
this
for
the
long
haul,
so
getting
more
people,
especially
newer
people
involved
on
the
tooling
side
website.
Those
kinds
of
things
will
be
really
useful.
There
is
a
flip
side
to
this
too,
which
we
haven't
done
really
well
yet,
which
is
actually
a
set
of
people
going
and
reading
the
caps
and
doing
things
you
know.
K
So
we
don't
end
up
burning
out
people
like
they
match
our
legit.
You
know
they
are
always
completely
blasted
the
week
before
the
feature
freeze,
so
we
have
to
do
some
set
of
things
around
that
for
122,
but
I
think
for
121.
This
is
awesome,
so
let's
continue
the
good
work.
Thank
you.
D
Yeah
tim,
can
you
provide
a
little
more
info
for
that
like
to
set
up
that
like
that's
something
we
we
can
get
ahead
of
for
122.?
If
you
can
provide
some
of
the
concerns
like
what
you
know,
what
what
could
go
wrong
and
then
we
can
try
to
work
backwards.
You
know
get
ahead
of
that,
and
eventually.
E
To
add
on
that,
there's
I've
struggled
with
two
facets
of
the
flow
of
caps,
not
the
process,
but
this
the
the
existence
of
them
one
is
finding
the
ones
that
are
interesting
to
me
or
the
ones
that
I
can
have
meaningful
impact
on,
and
the
second
is
not
being
looped
into
the
ones
that
I
don't
have
meaningful
impact
on
right.
People
assign
all
sorts
of
random
stuff
to
me
because
apparently
I
can
still
approve
just
about
anything
but
a
lot
of
times.
I'm
like
I
just
don't
know.
E
What's
going
on
with
this
cap
like
this
is
news
to
me,
I
didn't
know
we
were
doing
this
and
I
have
yet
to
find
a
good
way
to
to
filter
that.
A
I
yeah
we,
we
did
jim
and
a
few
others,
and
I
did
a
kept
leading
group
a
year
ago,
maybe-
and
that
was
the
biggest
problem-
was
just
just
identifying
the
ones
that
we
really
want
to
put
some
focus
on,
I
don't
know
like
kept
control,
could
do
some
querying
and
filtering
and
slicing
and
dicing,
but
I
just
don't
know
this
is
like
after
you
read
it,
you
know
whether
you
want
to
know
about
it
or
not.
I
don't
even
know.
D
D
D
A
spreadsheet
where
I
I
spent
some
of
the
holiday
break
just
capturing
the
descriptions
just
so
that
I
could
also.
I
could
just
do
that,
like
okay,
what
is
going
on
with
these
cups?
But
you
know
we
don't
want
to
have
that
as
being
the
only
option,
it'd
be
great
to
have
something
that
would
just
give
you
that
quick
view
of
caps,
like
you
could
skim
and
say
yep
nope,
yeah,.
E
I'll
take
a
new
year's
resolution
to
learn
to
use
cap
cuddle
as
my
first
step,
not
the
web
ui.
M
E
A
Okay,
we
are
out
of
time,
so
I
just
wanted
to
say
thank
you,
everyone
and
great
work.
I
mean
for
the
enhancements
team.
Really
it's
it's
awesome
to
see
this
moving
forward
so
much,
and
we
will
see
you
all
in
two
weeks.
Thank
you
very
much.