►
From YouTube: 20210202 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
Hello,
hello:
everyone
today
is
february
2nd.
This
is
an
enhancement,
subproject
meeting
of
sig
architecture.
This
is
a
meeting
that
is
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.
A
So
we've
got
a
few
things
on
the
agenda
to
discuss.
Anna
has
dropped
some
enhancement
team
updates.
She
will
not
be
here
to
deliver
those,
but
let's
go
over
those,
and
then
I
have
a
few
things
to
mention
that
I've
not
put
on
yet
secret
technology.
A
That's
no
longer
secret
anyhow,
we'll
do
a
quick
readout
of
anna's
topics,
so
the
so
first
off
there
is
a
another
participating
sig
field
added
to
the
tracking
sheet
to
make
sure
that
sponsoring
and
participating
sigs
have
agreed
to
opt
in
this
is
discussed
with
the
previous
enhancements,
leads
jeremy,
navaroon
and
kirsten,
and
something
to
be
considered
in
the
future
process
if
it
doesn't
exist
already.
So
who
was
part
of
that
meeting
and
wants
to
give
more
details.
B
Yeah,
just
at
a
really
high
level,
there
was
a
kept
that
was
opted
in,
but
that
kept
would
require
review
from
another
sig
and
that
sig
did
not
agree
that
it
should
be
part
of
the
release
due
to
bandwidth
constraints
like
review
bandwidth
and
whatnot.
So
this
was
an
attempt
at
getting
buy-in
from
all
those
involved
just
to
make
sure
that
they're
really
opting
in
and
not
opting
in,
but
not
really
for
other
people,
basically
yeah
just
getting
an
agreement
from
the
principles
involved.
A
So
so
I
think
that
I
think
that
yes,
I
agree.
I
think
we
would
need
to
figure
out
how
to
handle,
because
I
I
would
say
that
the
review
burden
is
going
to
be
a
little
different
than
implementation
burden,
so
figuring
out
kind
of
where,
like
where
that
handoff
is
like.
Do
you
have
bandwidth
to
review
this
buy
enhancements?
Freeze
are
like
in
time
for
us
to
get
an
exception
out,
or
is
it
will
you
be
on
board
to
help
with
implementation
right
and
those
are
two
different
conversations?
A
So,
yes,
I
agree,
but
I
think
that
we
need
to
kind
of
explode
it
and
dig
in
a
little.
C
A
Awesome
awesome
yeah,
so
I
would
say,
keep
keep
poking
at
that
and
if
we
can
get
an
idea
of
general
involvement
and
then
figure
out
what
deeper
involvement
means
later,
I
think
that
we
should
further
define
it
before.
We
put
any
expectation
on
people
to
deliver
that
information.
A
Okay
and
this
readout
is
kind
of
for
the
sake
of
people
who
are
going
to
listen
to
the
recording
later,
although
you
can
also
read
the
meeting
notes
so
question
okay,
so
receipt
kept
not
being
tracked
in
this
and
the
tracking
sheet
and
enhancements
freeze
is
coming
soon
february
9th
that
is
next
tuesday,
get
your
memes
ready.
So
we
need
to.
We
need
to
very
deeply
consider
something
that
I
popped
up
on
the
board
recently,
which
is
the
idea
of
a
type
type
field
for
caps.
A
I
think
that
we
strongly
need
to
consider
doing
that,
so
that
there's
less
of
a
question
around
these
items
when
they
pop
up
right.
So
the
receipts
process
is
a
process
that
is
its
policy
and
implementation
out
of
tree
implementation
right,
but
it
affects
entry
delivery
right.
So
what
would
we
call
that?
So
we
need
to.
We
need
to
have
that
conversation,
I
think,
and
although
I,
although
the
comments
on
the
issue,
looked
like
support,
I'm
not
sure
I
saw
any
objections
to
doing.
A
A
Cool
cool
all
right,
so
something
to
do
for
121.,
but
yes
for
the
receipt
cap.
We
should
we're
going
to
talk
about
it
a
little
later
in
the
notes,
but
we
should
definitely
plan
to
to
deliver
that
for
for
one
121.,
this
yeah,
nabarun
and
and
jeremy,
we'll
we'll
give
an
update
all
right.
So
the
next
one
is
well
any
questions.
C
A
C
A
Okay,
sweet:
let's
take
a
quick
break
because
I
said
I
did
do
it
before
we
started
recording
and
I
did
not
for
anyone
who
is
new
to
the
meeting
and
would
like
to
say
hi
what
they're
here
for
all
that
good
stuff,
all
right.
D
A
Welcome
welcome
excited
to
have,
especially
you
know,
especially
getting
to
get
some
feedback
from
people
across
different
communities
that
consume
kubernetes
about
how
this
process
is
working
for
them,
as
well
as
like
welcome
as
a
new
colleague.
C
I'm
hopefully
a
familiar
face
to
most
of
you
by
this
point,
but
I'm
it's
even
looking
very
suspicious
there.
No
I'm
an
enhancement
shadow
in
121,
so
I'm
largely
here
to
fill
in
for
anna
who
can't
make
it.
But
I've
been
generally
loitering
around
the
release
team
since
118
or
so
so
yeah.
My
first
time
attending
this
meeting
so
nice
to
see
you.
A
And
I
see
we
have
one
more
new
kubernetes
org
member.
If
you
want
to
say
hi
as
well
and
talk
about
what
you've
been
working
on.
F
Yeah
yeah
hi,
my
name
is
shaker,
I'm
active
in
enhancement
project
for
I
think
last
two,
two
to
three
weeks.
I
worked.
I
worked
in
migrating
to
new
template,
so
so
I'm
still
continuing
that.
I
created
few
test
cases
in
for
query
command
and
yeah
yeah.
That's
pretty
much
what
me.
A
Welcome
and
thank
you
so
much
for
the
work
that
you've
been
doing.
It's
really
exciting
to
see
people
like
doing
some
of
the
glue
work.
Some
of
the
stuff
that
like
easily
gets
forgotten
so
like
shaker
mentioned,
he's
been
working
on
converting,
basically
the
the
kept
from
the
old
style
into
the
new
style,
which
is
which
can
be
tedious
at
times.
But
what
it
does
lead
us
towards
is
is
like
bob
bob
is
saying
in
the
chat
it's
very
much
needed
for
us
to
proceed.
A
It
leads
us
towards
being
able
to
validate
these
kepts
in
a
new
style
as
well
as
starting
to
build
some
of
these.
This
tooling,
that
can
help
you
know,
build
websites
and
illicit
roadmaps
and
get
plugged
into
into
kept
ctl.
So
so
thank
you
again
for
for
running
through
the
repo
and
and
doing
some
of
the
the
maybe
what
could
be
considered
lesser
appreciated
work.
I
truly
appreciate
it.
F
I
I
surely
want
to
be
part
of
designing
the
new
website
and
using
that
cap.yaml
metadata
into
for
like
practical
use
like
in
website
or
maybe
fetching
those
data
in
other
another
application
or
main
website.
So
yeah.
A
Awesome
awesome,
yeah
and
more
coming
more
coming
soon
on
that,
so
next
up
so
anyone
else
did
we
miss
anyone.
A
Alrighty,
okay,
so
question
about
the
concern
raised
in
the
sig
architecture
meeting
that
happened
last
week
about
an
exception
being
filed
by
an
individual
versus
a
sig
with
enhancements
freeze
coming
up.
I
assume
we'll
get
a
few
exceptions.
Should
we
plan
to
send
out
a
communication
if
a
process
changes
for
121?
A
Yes,
how
will
the
exception
process
happen
for
the
receipt
process?
What
can
we
do
in
121
to
make
the
process
similar
to
the
future
receipt
process?
Okay,
interesting!
So,
first
off
yes,
when
a
an
exception
is
filed,
an
exception
needs
to
be
approved
by
the
owning
sig
right,
so
we'll
have
that
validation
from
the
owning
sig
that
this
is
something
that
they
agree
to
work
on
for
that
cycle.
So
I
think
I
think
in
that
sense
we
should
be
fine,
any
differing
opinions.
There.
B
G
Perfect
yeah,
so
traditionally
it's
been
happening
over
email,
so
I
don't
know
like
how
we
will
do
it
in
the
receipts
process.
So
that
is
something
that
we
need
to
think
of
have
an
additional
field
or
something
so
or
in
the
github
pr.
A
Yeah,
maybe
maybe
fields
well,
we'll
think
about
it.
Ultimately,
we
will
want
a
tool
to
run
over
some
set
of
content
and
spit
out
what's
wrong
right.
So
if
we
have
I'm
wondering
if
we
need
a
an
approval
field,
let
me
know
we'll
we'll
do
the
next
thing
first,
because
now
I'm
getting
ideas.
A
So
how
will
the
exception
process
happen
for
receipts
process?
What
can
we
do
in
121
to
make
the
process
similar
to
the
future
receipt
process?
Just
reiterating
that
that
question
or
the
set
of
questions
so
part
of
the
receipts
process,
will
be
a
set
of
pre-submit
validations
right.
So
the
the
way
those
validations
will
run
still
be
still
to
be
determined,
but
part
of
it
will
be
as
we
move
things
from
proposed
into
the
accepted
bucket
or
whatever
we
call
these
buckets
like.
That's
it
right.
A
The
things
that
end
up
in
that
bucket
that
are
accepted.
Those
are
the
things
that
are
accepted.
If
you're,
not
in
that
bucket,
you
need
to
file
an
exception
right
and
then
your
process
and
then
part
of
submitting
that
receipt
will
be
getting
approval
from
enhancements
that
it
is
okay
to
submit
that
exception,
as
well
as
from
the
sig
that
they
have
approval
to
include
that
exception
in
the
release.
So
I
think
that
our
process
will
change
slightly
and
we
will
need
to
dig
into
it
a
little
bit
more.
A
G
So
1.21
stays
the
same.
The
announcements
lead
will
send
out
an
email
that
hey
freeze
is
coming
up
and
here
is
the
exception
process,
and
you
need
to
do
so
and
so
right.
So
the.
A
Only
change
yeah,
the
only
change
for
121
is
that
we
we
are
moving
from
or
we
have
moved
from.
Everybody
go
crazy
into
opt-in
for
the
release,
so
the
opt-in
is
supposed
to
set
the
stage
for
saying
that
okay,
well,
the
new
version
of
opting
in
is
the
receipt
right.
A
And
speaking
of
receipts,
the
next
thing
up
on
the
agenda
is
receipts
update
from
navarone.
G
Yeah,
so
there
are
a
few
updates
on
that
front.
I
have
added
it
to
the
1.21
tracking
sheet,
but
then
again
it's
kind
of
blocked
on
that
policy
versus
entry
thing.
So
traditionally
what
we
have
done
is
we
are
tracking
those
enhancements
which
are
policy,
changes
and
possibly
not
entry
changes,
but
then
explicitly
they
are.
They
have
a
loose
validation
on
most
of
the
criteria
and
they
are
mentioned
in
the
cap
itself.
Okay,
this
don't
have
any
kk
test
plans,
but
they
will
have
some
test
plans
inside
whatever.
G
Applicable
and
the
next
update
is
so-
we
have
had
a
mega
dock
on
the
receipts
roadmap
or
kept
ctl.
Thank
you,
lori
for
actually
aggregating
everything
to
a
single
dock,
so
we
kind
of
will
split
out
the
contents
of
that
dock.
The
roadmap
into
two
specific
parts,
one
part,
will
go
into
the
design
details
of
the
cap
itself
and
the
second
part
will
mostly
be
a
capsule,
readme
or
user
guide,
and
I
know
like
there
is
a
hack
empty
as
well
on
bring
brainstorming
on
that.
G
So
that
will
also
have
contents
from
that
and
one
generic
update
is
like
jeremy
and
I
are
periodically
syncing
on
this,
and
this
week
we
have
a
few
sync
ups
scheduled
so
that
we
can
get
the
details,
finalized
and
ironed
out,
so
that
for
the
enhancements.
H
G
We
are
not
at
risk,
we
can
release
through
it.
A
So
if
you
can,
if
you
don't
mind
adding
me
as
optional
to
any
of
those
meetings,
I
can
see
if
I
can
pop
in,
but
I
have
ideas
and
some
of
them
will
be
disruptive
to
the
changes
that
you
will
be
planning
to
make
for
folks
who,
let
me
pause,
are
there
any
questions
on
navaroon's
update
before
I
get
a
conspiracy
theory
e.
A
A
Okay,
here
we
go
so
I
I
was
taking
some
time
to
stare
at
the
kubernetes
enhancements
repo
and
some
of
the
code
that
is
in
there
and
my
feeling,
the
what
I
kind
of
walked
away
with
was
it
felt
like
it
was
written
by
five
different
people
and
that's
roughly
accurate,
based
on
the
different
things
that
have
happened
across
time.
One.
A
We
have
the
kep
val
tools
that
were
brought
in
basically
chaka
wrote
a
bunch
of
tools
to
start
doing,
query
and
validations
on
on
keps
and
he
agreed
to
to
to
donate
those.
So
that
is
the
that
is
kind
of
like
the
the
the
base
for
our
validation
mechanisms.
And
then
there
were
a
lot
of
commands
that
were
built
around
that
right.
But
these
things
were
built
by
separate
people,
there's
also
capify.
A
So
we're
talking
about
the
keps
website
and
the
so
you're
talking
about
the
caps
website
and
capify,
I
believe,
will
dump
json
that
could
be
usable
for
building
a
netlife
site.
A
But
I
will
give
you
kind
of
the
broad
strokes
of
something
that
I
was
hacking
on
over
the
weekend
and
has
just
merged
to
the
repo
it's
somewhat
of
a
functional
rewrite
of
a
lot
of
this
stuff,
and
I
kind
of
wanted
to
like
I
did
it
all
the
weekend,
because
I
kind
of
wanted
to
get
it
out
of
the
way
before
people
started,
jumping
into
the
kept
the
the
receipts
process
build
out.
A
So
a
few
things
here,
one
there
is
an
api
package
and
the
api
package
maybe
doesn't
exactly
respect
what
an
api
package
normally
is.
I'm
calling
it
api
for
the
sake
of
being
able
to
flag
these
have
some
common
types
that
we're
going
to
be
using,
but
primarily
to
be
able
to
flag
this
as
no
parent,
no
parent
owners
true
and
to
force
approvals
through
the
following
labels
and
reviewers
approvers.
The
kep
tool,
approvers
and
reviewers
are
basically
basically
everyone
who's
in
the
enhancements
owners.
A
Group
minus
lori
lori
does
not
want
to
do
code
reviews
right.
So
there
is
so
these
these
approvers
reviewers
have
been
applied
across
some
of
our
common
code
areas
so
get
git
hooks
api,
cmd
docs,
I
believe
hack,
internal
pkg
and
test.
Now
there
are
also
so
owners
updates.
I
started
updating
some
of
the
the
verify
scripts
so
basically
copy
and
paste
from
kubernetes
release
and
search
and
replace
some
of
that
content.
So
we
have
verify
scripts
now.
A
The
next
piece
will
be
kind
of
breaking
those
verify
scripts
into
like
or
breaking
the
scripts
in
general
into
what
proves
that
we
can
build.
What
proves
that
our
all
of
our
go
tests
are
running
properly?
What
is
a
verification
for
kind
of
like
code
overall,
so
think
shell
checks
go
lane,
go,
go
ci,
lint
and
other
stuff
that
I'm
forgetting
at
the
moment
and
then
verify
for
contents
right,
so
think,
pull
enhancements,
verify
kept
right
now.
A
This
will
specifically
go
and
do
verification
for
the
table
of
contents
in
those
caps,
as
well
as
the
the
metadata
so
stay
tuned
for
those
additional
pre-submits.
What
I'm
going
to
do
is
I'm
going
to
wait
until
after
enhancements
freeze
to
try
to
land
any
of
those,
because
I
don't
want
to
be
disruptive
across
all
of
the
prs
that
are
in
flight,
but
going
back
to
this
api
package
really
quickly.
A
So
the
first
thing
I
laid
out
was
something
called
a
document,
and
once
we
once
we
it's
kind
of
like
in
you
know
we're
working
we're
working
on
hacking
up
this.
This
design
dock
jeremy
put
a
a
great
start
on
it
for
the
kept
ctl
command
specifically,
but
there
are
a
lot
of
people
starting
to
work
in
this
repo,
so
we're
going
to
wait
until
it's
a
little
crisper
to
to
drop
it
publicly,
but
that
should
be
coming
very
soon.
Tldr
very
simple.
A
Within
this,
this
document
file
there's
a
document
interface,
there's
a
parser,
a
parser
will
hold
a
slice
of
errors
so
that
we
can
basically
feed
the
the
parsing
errors
into
that
struct.
Instead
of
into
the
actual
set
of
data
that
we
want
to
manipulate
right
now,
the
errors
are
stored.
The
errors
for
a
proposal,
the
errors
for
a
prr,
are
stored
as
a
field
within
within
the
actual
struct,
and
we
don't
want
to
do
that
so
document
file,
document
file
and
parser.
A
The
parser
will
take
any
I
o
reader.
So
if
you
give
it
os
file
or
something
like
that
should
work,
we
want
it
to
spit
out
a
document
and
an
error
right
now
within.
Let's
take
a
quick
look
at
proposal,
so
kubernetes
enhancement
proposal.
A
So
all
the
the
the
content
are
all
the
kind
of
types
for
kubernetes
enhancement
proposals
are
here:
one
you
know
hold,
you
know,
hold
a
set
of
hold
a
set
of
proposals,
be
able
to
add
to
that
set
the
actual
content
that
is
expected
in
in
a
cap
and
then
and
then
that
validate
function,
that
we
were
the
validate
method
that
we
were
talking
about
right.
So
so
this
so
this
proposal
document
implements,
you
know,
satisfies
satisfies
that
document
interface
right
by
implementing
validate
right.
A
This,
the
kep
handler,
is
a
parser
right.
The
parser
again
is
that
struct
that
holds
a
slice
of
errors,
and
then
we
have
a
kept
specific
parsing
parsing
method
that
will
spit
out
a
pointer
to
that,
as
well
as
an
error.
A
If
there
are
any
right
and
then
the
same
milestone,
feature
gate
and
hash
that
we
had
from
the
kepval
package
right
same
was
done
essentially
for
the
prr
stuff,
but
because
because
we
don't
want
them
to
conflict,
and
we
also
know
that
there
will
be
document
types
that
may
need
approval
in
future,
their
approval,
their
approval
type,
was
renamed
to
prr
approval
and
it
still
has
roughly
the
same
content
the
number
of
the
kepp,
the
alpha
beta.
A
You
know
alpha
beta,
stable
and
then
within
those
within
those
an
approver
right
again
the
validate
implementation
for
that
and
a
parsing
for
the
handler,
a
parse,
a
pr
specific
parser
right.
So
as
we
move
into
introducing
receipts
to
this,
I
would
consider
a
receipt
to
be
a
document
right.
So
the
expectation
would
be
that
we
would
write
a
validation,
a
validation
method
for
that
document,
as
well
as
a
a
parser
to
handle
that
right,
and
maybe
we
eventually
get
to
the
place
where
we
are.
A
We
have
a
generic
parser
that
can
do
this
for
everything
based
on.
I
had
initially
written
it
as
like
document
types
right,
so
a
document
type
or
you
know
a
document
type
would
be
some
string
right
and
then
switch
out
to
the
individual
parsers
right,
but
that
is
unnecessary
for
now.
So
I
kind
of
stripped
that
out
of
this
pr,
so
all
of
that
to
say
that
a
lot
of
this
repo
is
being
rewritten
right
now,
so
give
us
a
shout
before
you
try
to
land
any
changes.
A
The
the
other
big
change
here
is
because
I
kept
on
bumping
into
trying
to
make
what
currently
existed
work
when
I
kind
of
felt
like
it
wasn't
so
now
there
is
a
legacy
package.
Basically,
everything
that
was
in
kept
val
has
been
moved
to
a
legacy
package,
so
the
goal
will
be
anything
that
is
importing.
The
legacy
package
should
be
rewritten
to
not
do
that
validation,
wise
moving
forward,
we'll
be
using
the
go,
playgrounds,
go
playground,
validator,
v10
right.
We
should
not
have
to
write
our
own
validation
functions.
A
There
is
plenty
of
content
for
this
out
there
already.
So
very
simply.
Our
our
validate
function
actually
just
emits
a
new
instance
of
this
validator
and
validates
destruct
right.
So
we're
gonna
go
back
into
this
and
drop
in
the
expectations
for
validation,
so
expectations
would
be
like
certain
fields
are
required
right
and
essentially
it's
it's
adding
it's
adding
content
here.
A
That's
like
validate
required
right,
so
this
should
be
a
very
simple
sweep
when
we're
ready
to
do
it,
and
I
will
I'm
likely
going
to
do
that
in
the
next
round
of
sweeps
this
this
week
now
that
now
that
this
one
has
merged,
so
I
knew
I
I
I
would
so
in
this
meeting.
I
also
realized
that
an
exception
is
also
a
document
type,
and
then
we
can,
what
we
can
do
is
we
can
start
playing
around
with
that
idea
too
right.
A
G
So
I
don't
have
any
questions,
but
I
have
a
comment,
since
you
mentioned
in
the
pr
of
yours,
that
we
probably
need
to
rewrite
kp5
through
the
cobra
way
of
doing
things.
So
what
I
realized
was
what
kp5
is
doing
is
basically
capacity.
Query,
so
capsule
query:
if
you
give
it
output
is
equal
to
json.
It
turns
out
the
same
thing.
So
do
we
even
need
kp5
anymore,
because
it
predates
capacitor
query.
A
Yeah
so
I
was
yeah,
I
was
going
to
rewrite
capify
to
be
a
cobra
command
and
I
was
like.
Let
me
talk
to
the
team
during
the
week
instead,
because
I
had
a
feeling
that
there
might
be
some
overlap.
So
if
we
can
prove
that
there's
parity
between
those
two
tools,
we
can
drop
capify
for
sure.
G
I
I
look
at
it,
so
if
there
is
overlap,
can
I
can
I
just
like
create
a
pr
removing
kp5-
or
maybe
I
don't
know
like
if
anyone
is
using
kp5?
Should
we
practically
proxy
capture
inquiry
queries
main
command
here,
because.
A
It's
a
package
roughly,
as
is
what
I
had
in
mind,
basically
pushing
all
the
logic
of
capify
into,
because
all
the
logic
is
in
the
command
right
now
pushing
all
the
logic
of
capify
down
into
a
package
and
reusing
that
as
necessary.
A
What
I
had
in
my
head
was
essentially,
like
I
don't
know,
kept
ctl
dump
or
like
maybe
we
can
find
a
nicer
name
for
that
that
we
can
decide
if
it's
like
yaml
or
json,
and
what
it'll
do
is
a
scrape,
scraper
repo
and
spit
out
something
that's
consumable
somewhere
else
right
and
then
you
know
future.
Looking
export
export
is
much
better.
A
A
What
is
going
to
be
happening
right,
because
we
we
we
kind
of
need
that
for
for
users
right,
we
need
that
if
we're
going
to
raise
adoption
for
these
tools
as
we
build
them
out
and
and
get
more
contributors
working
on
these,
so
like
future,
looking,
what
I
would
see
happening
is
essentially
like
kept.
You
know,
kept
ctl
is
running
in
a
periodic
job
and
it's
dumping
to
some
bucket
there's
another
job.
To
pick
that
up
and
generate
a
website
like
this
is
like
it's
very.
It
becomes
very
hands-off
yeah.
A
A
Cool
cool
so
one
one
more
note
about
kind
of
merging
all
these
various
streams.
One
idea
that
I
had
was
types
for
people
and
groups
right.
So
so,
right
now
again,
this
written
by
multiple
people
situation
is
happening
where
we
have
multiple
fields
that
are,
we
have
multiple
types
that
are
named
the
same
thing
that
do
something
fundamentally
different
right.
A
So
if
you
look
at
the
milestone,
the
the
milestone
struct
for
prrs,
milestone
truck,
holds
a
an
approver
field
right,
whereas
the
milestone
struct
for
for
kep
holds
something
entirely
different
right
holds
the
you
know,
kind
of
a
listing
of
of
the
the
various
milestones
or
the
various
milestone
targets
for
alpha,
beta
and
stable
so
trying
to.
If
we
can
unify
some
of
that
stuff
figure
out
what
the
common
concepts
are.
I
think
we
already
know
them.
A
But
if
you
look
at
groups,
we
have
there's
a
discussion
about
like
participating,
sigs
versus
participating
groups
right
all
groups.
Are
you
know
all
all
things
are
of
type
group?
If
we
do
that
and
say
that
you
know
a
sig
is
a
group,
a
working
group
is
a
group
a
you
know.
Sub-Project
may
be
a
group,
a
committee
could
be
a
group
right
and
then
run
the
validation
based
on
that.
What
we
would
expect
out
of
a
group
so
right
now
we
would
query.
A
I
think
we
query,
you
know
something
external,
whether
it
be
an
owner's
file
or
something
to
see
what
the
list
of
groups
are
and
then
do
a
comparison
based
on
that,
so
that
that
that's
one
aspect
and
then
two
validation
on
user
fields,
so
a
user
is,
could
be
an
approver,
a
reviewer,
editor,
yada,
yada,
yada
right
making
sure
all
of
those
fields
are
prepended
with
prepended
with
an
at
sign
so
that
we
can
look
up
their
github
username.
A
Things
like
that
right,
so
doing
validations
on
the
field
level
as
well
should
be
coming
soon
and
yeah
yeah
that
I
think
that
ends
my
rant.
A
A
A
All
right
moving
right
along,
so
the
next
item
is
released,
his
page,
so
next
steps
to
release
the
caps
website.
Any
progress
here.
Do
we
know
who
put
this
up
me
yay.
H
A
So
just
know
specifically
or
because
jim
is
staring
at
the
the
releases
page
with
me.
Not
the
captain.
H
A
H
A
H
I
know
I've
talked
to
you
and
abron,
and
maybe
jeremy
is
part
of
this
conversation
just
because
you
crafted
the
cap
on
receipts
and
then
in
this
mixture
of
things
came
forth,
and
I
I
had
I
got.
I
went
around
on
this
like
two
or
three
times
to
try
to
understand
what
exactly
was
needed.
I
think
you
even
asked
the
question
and
when
I
brought
the
feedback
to
you
like
what
do
we
mean
by?
Where
does
this
live?
And
I
was
like
that's
a
great
question
and
then
the
answer
became.
H
A
A
So
I
think,
a
general
problem
that
we
have
and
like
this
is
wearing
like
multiple
hats.
At
this
point
right,
I
think
a
general
problem
that
we
have
is
like
front
end
things
like
someone
to
do
a
front
end.
So
if
you
know
folks
that
want
to
do
a
front
end
with
us
or
have
experience
with
netlify
and
getting
some
of
these
things
shipped
feel
free
to
send
them
our
way.
A
There
are
two
separate
efforts
and
really
more
than
two
multiple
efforts
happening
in
tandem
with
different
groups
as
the
approving
areas
here.
So
there's
the
releases
page
right.
The
releases
page
is
intended
to
land
on
k
website.
What
the
release
the
the
intent
for
the
releases
page
is
that
it
will
be
kind
of
like
the
first
step
is
like
the
the
straw.
Man
is
like
faq
right
answering
the
frequently
asked
questions
that
we
get
around
releases.
When
is
the
release
happening?
When
is
the
cherry
pick
deadline
when
like
when
is
enhancements?
Freeze?
A
Can
I
see
a
timeline?
Can
you
show
me
the
cabs?
Where
is
the
enhancement
tracking
sheet
blah
blah
blah
blah
blah
blah
blah?
All
of
those
questions
we
want
to
answer
on
that
page
are
there
cvs?
Are
there
deprecations
happening?
Where
are
the
release
notes,
release
this
page
separate
thing
from
this
meeting?
We
don't
need
to
care
about
it
right
eventually,
when
this
kept
website
goes
live,
we
can
maybe
push
it
into
into
that
area
right
the
now
the
caps
website.
A
If
we
are
trialing
it,
you
know
we
want
to
just
get
some
data
up
in
and
somewhere
visible
if
this
is
staging
dashcaps.case.io
or
something
like
that,
I
I
really
couldn't
be
concerned
where
it
lives
just
that
it
lives
at
this
point,
but
before
we
get
it,
we
basically
this
goes
back
to
the
data
that
we
scrape
right
the
data
that
we
dump
how
it
gets
composed.
So
we
need
to
make
sure
that
that
is
on
point
before
before
we
care
about
a
website
right.
A
I
would
say
that
because
it
affects
sub-project
owners
and
enhancement
sub-team
members,
my
first
concern
is
kept
ctl
the
presentation
mechanism,
we're
going
to
be
using
the
same
functions
to
handle
the
presentation
mechanism
roughly
right
for
for
the
website.
So
we
need
to
care
about
how
the
the
content
is
generated.
First
right
because
that's
going
to
be
pushed
around
in
these
various
tools,
so
we
handle
we
handle
the
data
first,
then
we
move
on
to
the
presentation.
A
The
website
is
important
in
a
general
like
community
happy
feels
way,
but
I
I
would
not
call
it
like
a
target
for
us
right
this.
Second,
unless
there's
going
to
be
someone
dedicated
to
working
on
it,
yeah.
A
So
this
this
maybe
goes
back
to
the
the
owners
of
of
everything,
so
jeremy,
just
linked
the
the
current
release
markdown
gets
generated
into
a
page.
Yes,
there
you
go.
A
On
kubernetes.
right,
we
do
not
own
kubernetes.dev.
I
was
barely
involved
in
release
wise
making
the
decisions
for
what
goes
there
as
like
who
owns
this
content
for
sig
release.
Our
primary
content,
like
the
canonical
references
for
the
things
that
we
do
live
in
k,
sig,
release
right.
A
That
we're
having
with
sig
docs
is
to
pull
out
the
public-facing
content
user-facing.
How
do
I
get
releases?
All
that
all
the
stuff
I
said
previously
bring
that
into
k
website
right,
okay
website,
not
being
kubernetes.dev
totally
different
place
right.
I
think
that
I
think
what's
happening
is
that
other
owners
are
are
thinking
about
decisions
that
should
be
happening
here.
A
H
A
Yeah
outside
of
getting
the
data
right
they
should
they
should
let
us
handle
cleaning
up
the
way
the
data
is
generated
and
whatever
they
want
to
write
on
top
of
it,
I'm
happy
for
them
to.
H
Okay,
so
they
can
okay,
we
clean
up
the
data.
They
can
do
everything
else.
G
Yeah
so
some
background
on
that,
like,
since
you
mentioned,
like
cleaning
up
the
data
and
like
have
format
of
exporting
the
data,
so
this
very
requirement
was
the
motivation
of
adding
ca,
json
and
dml
exports
to
capsidal
query
so
that
they
are
unblocked
in
having
the
data
and
then
they
can
play
with
it
in
any
way
they
deem
necessary.
G
G
A
Okay,
so
my
first
thought
is
that
we,
this
doesn't
go
in
nk
website
yet
right.
I
think
that
we
should
stand
up
a
staging
ground
and
get
c
names
in
place
and
all
that
stuff
and
then
the
correct
infrastructure
like
this
can
be
a
like.
Let
it
be
its
own
site
first
and
prove
the
concept
before
we
start
integrating
with
k
website,
because
that's
where
the
question
about
the
releases
page
is
going
to
come
up,
that's
where
it
probably
has
come
up
and
as
you
can
see,
I'm
not
on
this
issue.
A
A
Yeah
again,
I
would
yeah.
I
would
strongly
encourage,
like
we
push
these
conversations
into
this
meeting
into
our
channels.
Yada
yada,
there's
also
one
note
for
the
code.
Content
specifically,
is
that
they
are
all
now
tagged
with
area
enhancements.
A
All
of
those
code,
subdirectories
and
kind
of
the
reason
for
that
is
I've
been
getting
tagged
on
a
bunch
of
pr's
for
review
and
had
no
idea.
They
existed
because
it's
not
really
easy
to
bubble
up.
It's
not
really
easy
to
bubble
up.
What's
supposed
to
be
like,
what's
in
review
for
for
this
repo
right,
you
yeah,
if
you're,
if
you're
a
reviewer
approver
on
this
repo,
essentially
so
for
me,
I've,
you
know
maybe
been
on
this
repo
for
like
two
years
or
something
like
that
I
have.
A
A
We
can
get
this
on
a
project
board
if
those
items
aren't
already
on
a
project
board
and
I
believe
a
a
good
chunk
of
them
are
from
the
issue
side,
but
not
necessarily
from
the
the
pr
side
right
so
fix
that
raise
the
visibility
of
some
of
these
things,
and
then
we
can
start
walking
walking
these
boards
in
these
meetings.
Right.
A
So,
output
from
that
lorry,
because
I
went
on
a
winding
path-
tldr
like
let's
get
the
data
in
place
like
give
us
a
little
time
to
get
the
data
in
place
firm
up
this
proposal
make
sure
we
feel
content
with
that.
Have
them
review
it
and
handle
and
we'll
start
handling
execution.
I
think
a
lot
of
the
pieces
are
already
in
place
to
do
it
before
we
turn
them
loose
on
on
doing
this
website.
A
I
think
we
want
to
make
sure
that
we're
happy
with
the
validations
or
the
rewritten
validations
before
we
do
that.
H
A
A
H
H
H
And
just
in
some
of
the
work
we've
been
doing
and
enhancements
process
improvements,
it
seems
like
there
are
some
things
that
might
be
a
little
more
flexible
in
adapting
to
process
changes
than
others.
So
we
may
not
be
able
to
get
every
group
on
board.
But
what,
if
we
created
a
subset
group
of
cigs?
Who
we
would
ask,
if
hey
we
can?
Can
we
actually
see
about
putting
together
a
roadmap
even
if
it's
small,
even
if
it's
it's
not
going
to
be
perfect,
but
just
to
get
the
concept
started?
H
And
the
trick
here
is
to
get
six
that
are
maybe
working
on
different
things
to
actually
find
the
common
ground
and
look
at
kubernetes
as
a
holistic
project
where
their
work
influences
each
other.
I
mean,
I
think
there
are
these
kinds
of
alignments
that
are
already
in
our
midst,
and
some
of
them
are
quite
strong,
but
given
the
sample
size
of
the
sigs
that
we
would
talk
to,
they
may
not
have
worked
before.
H
A
So,
yes,
absolutely
sorry,
I
like
ended
up
staring
at
another
conversation
simultaneously,
yeah
upside.
It
was
a
conversation
from
you,
so
the
yeah,
so
I
I
totally
agree.
I
totally
agree.
I
think
that
it's
going
to
be
very
important,
that
we
have
champions
as
we
continue
to
evolve
our
processes
and
that
we're
kind
of
establishing
a
better
feedback
loop
with
them.
A
I
think
that
it
is,
I
think
that
it's
easy
for
us
to
fall
into,
maybe
maybe
I
wouldn't
call
it
a
trap,
necessarily
right,
but
there's
kind
of
already
deep
collaboration
between
sig
release
and
architecture
on
you
know
this
idea
of
enhancements.
I
think
part
of
this
feedback
loop.
We
want
to
be
more
vocal
about
what
we're
changing
when
we're
changing
it,
how
we're
changing
it,
how
to
deliver
feedback
back
into
that
process,
and
I
think
that
you
know
a
way
of
doing
that
again.
A
People
process
tools
right,
so
we
we
have.
I
think,
we've
put
a
lot
of
great
people
into
this
room
already.
I
think
that
we
are
starting
to
generate
some
processes
that
are
sustainable
for
the
community
long
term.
You
know
receipts
just
being
a
start
of
what
we
can
do
and
and
then
tools
right
tools
are
going
to
wrap
those
those
processes
and
help
make
them
successful.
A
I
think
that,
from
a
roadmap
perspective,
my
crazy,
crazy
hack
in
the
basement
weekend,
ideas
was-
and
this
may
be-
I
may
be-
you
know-
standing
on
the
shoulders
somewhat
of
of
something
that
caleb
was
thinking
about
a
while
back
and
we
might
actually
have
the
stuff
that
we
need
to
do
it
now
is
a
kept
ctl
plan
command
right
now
the
kep
ctl
plan
command,
and
this
is
in
the
design
dock
that
will
open
up
once
it's
cleaned
up
later.
A
The
kep
ctl
plan
idea
is
essentially
that
it
would
run
through
again
same
validations.
It's
using
all
of
these
components
that
we're
writing
right
now,
but
it
would
scrape
caps
and
give
you
a
different
view
right.
If
you
said
kept
ctl
plan
with
no
arguments,
I
think
it
would
just
spit
out
what's
coming.
H
E
H
Is
a
three-tiered
program
like
I,
I
wanted
to
pitch
this
idea
just
to
get
a
feel
and
then
I
actually
wanted
to
leave
because
I
have
to
leave,
but
I
wanted
to
see
if
we
could
just
get
the
group's
feedback
on
whether
this
idea
is
good
or
not,
and
and
just
hear
from
from
everyone
in
this
group.
H
H
D
Sure
I'm
looking
at
I'm
getting
to
know
the
whereabouts
like
what's
going
on
exactly
so
it's
new
for
me.
So
let
me
digest
this
I'll.
H
I
mean
it's
basically
just
a
old
concept
applied
to
a
new
domain
and
you
know
maybe
road
maps.
I've
even
read
that
road
maps
are
passe
now
and
we
shouldn't
think
about
road
maps
at
all,
but
something
that
definitely
gives
us
a
sense
of.
What's
coming
in
kubernetes,
like
a
longer
term
view
than
what
we
might
already
might
be
offering
today.
H
A
H
H
Is
that
another
set
another
enhancements
related
tool,
then
that
we
could
actually
try
to
get
some
help
with
bringing
to
to
market?
Is
that
something
yeah?
I
know
nice
speech
right.
What
I'm
saying
is
a
nice
choice
of
words
yeah,
let's
monetize
this.
No,
but
what
I'm
saying
is
like.
Can
we
actually,
we
have
kept
ctl
pretty
well
underway,
but
is
this
something
that.
G
I
want
to,
but
they
have
been
like
at
3.
3
a.m:
3
a.m;
yeah!
So
I'm
trying
to
so
first
trying
to
grab
some
hold
on
issues
there
and
then
probably
asking
them
like.
Can
we
start
a
meeting
in
an
alternate
time
like
a
tree,
so
kind
of
tricky
yeah
for
sure
but
yeah?
I
sync
with
the
meeting
notes
and
the
recordings.
H
A
So
I
I
like,
I
like
the
like
the
end
goal.
What
I
worry
about
there,
a
little
bit
is
shifting
the
expectation
back
to
like
enhancements
querying
versus
people
opting
in
right.
I
don't
like.
H
H
H
A
So
so
the
idea,
the
idea
many
many
moons
ago,
was
to
have
a
sig
pm
liaison
for
each
of
the
stuff,
yeah
right
yeah,
and
they
were
supposed
to
kind
of
create
that
feedback
loop
between
the
two.
There
are
a
bunch
of
like
great
ideas
that
were
generated
in
sig
pm.
That
never
happened
because
we
did
not
have
the
people
for
it,
so
it
might
be
worthwhile
to
like
start
digging
up,
notes
and
see
what
we
got.
A
But
I
like
the
idea
of,
like
a
p,
a
a
liaison
right,
a
pm
whatever
we
want
to
call
it
to
to
create
that
feedback
loop.
But
I
I
really
worry
about
us
doing
it.
H
Yeah
yeah
agreed-
maybe
that
is
the
first
step
in
trying
to
roadmap
like
getting
someone
in
the
sig
who
is
interested
in
building
towards
this
roadmap
plan
and
they
become
the
liaison
from
within
their
thing.
So
it's
not
outward
going
in,
but
in
coming
out
exactly
and
then
they
can
start
talking
and
we
can
facilitate
the
discussion
between
those
folks
from
the
different
sigs.
A
And
yeah
and
then
also
so
the
reason
part
of
the
reason
for
plan
again
not
flashed
out
yet.
But
a
lot
of
people
ask
for
data,
we
don't
have
data,
we
have
data
in
spreadsheets
and
the
data
is
hand-cobbled
right
being
able
to
have
plan.
We
can
start
doing
diffs
across
time
of
different
ways
that
we
generated
this
content
and
see
what
happened.
What
did
didn't
happen
start
comparing
slips
based
on
different.
A
You
know
different
views
of
of
you
know
point
in
time,
so
it
gives
us
the
ability
to
start
generating
the
data,
but
it's
not
necessarily
the
first
step.
I
think
I
think
we're
going
to
end
up
like
having
ideas
about
it
and
then
kind
of
like
slowly
meeting
in
the
middle
after
discussions
with
other
people.
A
We
do,
we
do
send.
A
Them
an
email,
hey,
what's
up,
I
would
say
I
would
say:
maybe
we
want
to
hit
this
for
post
enhancements.
Freeze,
okay,
give
people
like
one,
let
one
less
thing
in
their
their
inbox,
that
they're
likely
to
miss
in
the
lead
up
and
and
two
maybe
some
some
extra
time
to
to
for
us
to
chew.
On
this,
the
group
and
and
the
enhancement
sub
team
for
121.
A
Yeah,
let's
jam
on
the
channel,
I
will
say
that
we
are
one
minute
over
now.
Final
parting
note,
please
do
continue
to
hang
out
in
the
channel
attend
these
meetings.
The
big
final
note
is
that
we
have
issued
a
doodle
for
a
new
meeting
time
to
hopefully
grab
some
more
folks
in
this
lori.
Are
we
good
on
the
doodle?
Do
we
have
a
time?
Do
we
have
a
new
time.
A
Okay,
okay,
we're
so
so
this
thursday
february
4th
doodle
will
be
closing.
If
you
want
to
vote
on
a
new
enhancement
subproject
time,
please
do
so
before
then.
The
following
meeting
will
start
this
new
time:
cool
yep
all
right!
Thank
you.
Everyone
great
conversation.
Lots
of
great
ideas
today
have
a
great
day
bye.
Thank
you.