►
From YouTube: 20210318 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
march
18th.
This
is
a
meeting
of
the
enhancement
sub
project
of
sig
architecture.
This
is
a
meeting
that
will
be
recorded
and
available
later
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
the
first
topic
that
we
have
on
the
list,
so
one
for
folks
that
are
maybe
new
to
the
call
for
people
who
have
been
here
before.
Please
take
a
moment
and
add
your
name
to
the
attendees
section.
A
Additionally,
if
we
have
anyone
who
is
interested
in
being
a
note
taker,
that
would
be
greatly
appreciated,
go
ahead
and
just
add
your
name
to
the
notetaker
spot.
So
we
want
to
cover
a
few
things
that
are
related
to
kind
of
our
our
workflow
and
and
specifically
for
the
workflow.
How
do
we,
how
do
we
kind
of
defer
our
or
decrease
the
burden
for
people
who
are
submitting
enhancements
to
the
release
process?
So
we've
been?
A
You
know
we've
been
playing
around
with
these
ideas
for
some
time
and
I
think
that
we
have
a
you
know.
Two
things
that
we
want
to
solve.
One
is
understanding
what
needs
to
be
reviewed
and
tracked
by
the
enhancements
sub
team
of
the
release
team,
as
well
as
what
needs
to
be
reviewed
within
the
scope
of
the
production,
readiness
review,
subproject
of
of
of
sig
architecture.
A
So
those
are
two
review
requirements
and-
and
of
course,
as
you
may
know,
if,
if
an
enhancement
is
targeted
as
implementable
for
and
targeted
to
a
release,
then
it
now
requires
a
prr
review
or
a
production
readiness
review.
Rather
so
what
we
would
like
to
do
is
better
understand
the
the
workflow
for
for
getting
that
to
happen
and
then
also
being
able
to
decide
if
you
don't
actually
need
to
to
buy
into
that
process
right.
Is
there
a?
A
Is
there
a
lighter
weight,
iteration
of
that
process
that
still
allows
you
to
deliver
enhancements
without
necessarily
having
the
same
level
of
review?
A
So
we
we've
been
playing
around
with
terms,
and
I
think
you
know
part
of
where
we're
landing
is
we.
We
one
need
to
define
what
the
workflow
is
and
and
in
defining
the
workflow.
There
is
a
requirement
to
speak
the
same
language,
so
to
speak,
so
defining
what
a
glossary
of
terms
would
look
like,
so
that
everyone
can
come
into
this
process
with
a
clear
understanding
of
of
expectations
and
how
to
be
successful.
A
A
Continue:
okay,
cool,
so
we
have
I'm
digging
up
the
mirror
board,
it's
somewhere
in
the
back
scroll.
If
someone
finds
it
before
me,
please
drop
it
into
the
okay
got
it.
A
A
Okay,
that
was
not
great
okay.
So
can
you
see
this
screen
on
my?
Can
you
see
my
screen?
Okay
cool,
so
I
think
that
I
mentioned
in
the
chat
that
we
are
not
quite
done
with
this
diagram.
I
would
say:
let
me
close
some
of
these
things
so,
where
we
landed
was
we
played
around
with
a
few
ideas,
and
I
don't
know
if
they're
still
on
this
board?
Yes,
okay
right,
so
we
had
some
ideas
here,
and
these
are.
A
These
are
fanciful,
miro,
x's
things
we
don't
want
to
do
so.
We
had
some
ideas
based
on
our
past
experiences
process.
Workflow
the
first
one
that
we
want
to
cover,
I
guess
is-
is
core
versus
non-core.
A
I
think
that
core
language-wise
core
has
been
confusing
in
the
past,
and
I
think
that
it
will
mean
different
things
to
different
people,
depending
on
their
their
kind
of
frame
of
reference.
So
we
I
think
we
came
to
the
conclusion
that
core
is,
is
maybe
not
the
right
terminology
to
use
when
referring
to
so
my
my
frame
of
reference
for
core
is
pertaining
to
things
that
would
be
landing
in
the
repo
kubernetes
kubernetes.
A
Are
things
that
are
under
the
purview
of
sig
architecture
when
related
to
repository
management
right
and
someone
else
may
have
a
different
context
for
that
right?
So
a
non-core
being
you
know,
the
the
other
common
term
would
be
entry
and
out
of
tree
right.
So
we
are
so
we
threw
a
few
ideas
together
and
the
one
that
we
landed
with
is
kind
of
the
smooshing.
A
Together
of
my
idea,
john's
idea,
tim
hawkins
idea,
which
led
us
to
this
using
the
term
release
impacting
right
release
impacting,
is,
is
very
clear
about
about
what's
happening
there
right
release
impacting
determines
whether
or
not
an
enhancement
should
be
tracked
right
so
tracked
yes
or
no
release
impacting
yes
or
no
leads
to
tracked
yes
or
no,
so
initially,
this
said
non-code
untracked
code
and
untracked
non-code
and-
and
this
one
only
said
code
so
want
to
call
out
here
that
I
actually
want
to
do
some
live
edits
of
this.
A
If
that's
okay,
one
code
in
non-code
and
then
two,
whether
or
not
a
prr
is
required.
So
I
think
that
I
think
that
actually
we
have
two
concerns
here.
Right,
one
is
non-code.
A
A
B
B
A
Basically
released
impacting
is
anything
that
could
potentially
impact
the
release.
So
a
good
example
of
that
would
be
like
the
release.
Cadence
kept
it's
non-code,
but
it
affects
the
release
boundaries
and
how
we
deliver
right.
So
would
that
need
to
go
through
a
pr
review?
I
removed
all
the
pr
sections
from
that
cap.
No.
A
B
C
A
Sure
so
kate.jcr.io
cut
over
right
changes
to
artifacts.kates.io.
If
we
start
using
that
as
part
of
the
bits
for
the
release
process,
that
is
something
that
would
affect
release
engineering,
that's
something
that
would
impact
release
timelines,
but
it's
not
something
that
necessarily
needs
a
pr
review.
Right.
Infrastructure
changes
right
process
changes
that
would
not
necessarily
be
under
the
the
purview
of
production
readiness,
because
it
is
not
so
for
production
readiness.
The
way
I
see
it
is
like
this
is.
A
This
is
something
that
will
land
on
a
cluster
and
and
we
need
to.
We
need
to
understand
fit
right,
yes
and
then
so
I
was
unsure
of
how
much
I
wanted
to
explode.
This
discussion
regards
with
regards
to
review,
but
I
actually
see
three
three
lenses
of
review.
At
least
three
lenses
of
review
right
production
readiness
within
the
scope
of
a
cluster
release
readiness.
I
don't
know
what
to
call
it
yet
right
but
like
maybe
this
is
something
that
that
someone
in
sig
release
should
take
a
look
at
right.
A
The
cube
adm
going
out
of
tree
an
example
right,
that's
something
that
we
would
have
to
coordinate
with
sync
cluster
lifecycle
and
if
they
were
to
move
forward
with
it
would
without
our
knowledge
right
would
would
it
would
be
a
little
harder
to
to
execute
on
right.
Docker,
shim
hypercube
are
examples
that,
like
we'd,
want
like
their
release
impacting,
and
I
would
want
someone
in
sig
release
at
them
before
before
executing
on
right,
and
then
we
have.
A
S
has
been
talking
about
the
the
security
reviews
as
well
right.
So
where
does
that
go?
So
I
think
that
I
think
that
there
are
multiple,
multiple
review
opportunities
and
I
think
that
not
all
of
them
are
necessarily
relevant
to
code.
Specifically,
if
that
clarifies.
B
It
it
does.
I
totally
understand
your
your
point.
Is
that,
basically,
that
this
this
flag
translates
directly
the
tractor
not
tract
right
and,
and
so
when
it's
tracked,
there's
definitely
things
that
are
not
code
that
need
to
be
tracked.
That's
fine!
I'm
not
gonna
die
on
this
hill.
I
I
just
it
was
different
than
my
understanding
of
the
conclusion
of
the
conversation
we
had
on
slack,
but
it
was
a
long
and
winding
conversation.
B
A
What's
that
moving
around,
can
you
see
my
cursor
moving
around
okay?
So
I
think
that,
like
this
path
is
the
one
that
we
care
about,
first
and
foremost,
because
this
is
the
path
that
exists
right.
This
is
the
this
is
like
if
you
were,
if
you're,
if
you're
submitting
an
enhancement
today
and
you
and
you
hit
certain
buttons
and
you
like,
set
certain
metadata.
This
is
the
expected
path.
B
A
Right,
so
I
think
we
need
to
hit
this
this
path
and
make
sure
the
code
represents
that
path
as
well
as
this
path
right.
The
the
point
of
of
of
hitting
this
first
is
it
release
impacting
or
do
people
think
it's
release
impacting
right
will
immediately
tell
us
okay.
Well,
we
can
route
you
out,
we
can
route
you
out
and
we
just
need
to
figure
out
what
this
process
means
to
us.
A
D
B
B
So,
let's
I'm
okay
with
it,
but
we
do
need
to
make
sure
that
others
that
we're
involved
in
the
discussion
are
also
okay
with
it.
But
I'm
fine.
C
So
question
so
stephen:
what
are
you
trying
to
do
here
in
the
sense
that,
like
are
you
trying
to
figure
out
what
class
of
caps
do
not
need?
Pr
reviews?
Is
that
what.
A
Is
the
objective
of
this
absolutely
right?
So
it's
it's!
A
It's
it's
two
things
right
and
the
first
is
what
class
of
kept
need
to
be
tracked
right
from
the
perspective
of
the
the
the
enhancement
sub
team
of
the
release
team,
first
and
foremost,
when
they
start
tracking
things
that
will
determine
whether
or
not
it
needs
a
pr
review
right
so,
but
before
we
even
get
to
the
pr
step,
we
want
to
know
if
the
thing
should
be
tracked
and
I
think
that
we
were
trying
to
decide
on
like
the
label
the
the
language
to
to
put
that
under
and
and
and
we
landed
on,
release
impacted
yes
or
no
are
true
or
false.
B
Yeah
and
dims
the
the
thing
is
right
once
something's
tracked,
there's
a
bunch
of
rules
that
come
into
play,
there's
also
a
bunch
of
benefits.
Well,
I
don't
know,
there's
some
benefits
they
get
like
like.
It
ends
up
in
release,
notes,
and
you
know
so
so,
there's
tracking
of
how
it
gets
documented,
and
so
people
may
want
to
elect
to
be
part
of
that
process.
B
I
know
kirsten
I'm
just
the
the
the
people
may
want
to
be
part
of
that
process
to
get
those
benefits,
but
but
again
they
may
not
fall
under
the
criteria
of
what
what
they're
required
to
use
the
process.
So
we're
sort
of
like
trying
to
do
we're,
trying
to
help
try
to
streamline
the
process.
B
Now,
it's
not
that
hard
to
put
n
a
in
all
the
pr
questions
but,
as
we
add
more
types
of
review,
if
we
have
to-
or
as
you
know,
we
we
just
may
want
different
process
flows
for
different
types
of
changes,
and
the
sooner
we
can
tell
people
that
the
lighter
weight
it
can
be
for
them.
D
It's
also
memorializing
it.
I
think
that
there's
a
lot
of
just
general
confusion
and
there's
no
like
source
of
truth
of
like
this
is
what
it
is
like.
I
hear
that
a
lot
or
I
see
a
lot
of
confusion
and
instead
of
you
know
having
to
ask
individuals,
is
this
this?
I
think
also
what
laurie
is
trying
to
do
through
the
flow
chart
and
through
sort
of
memorializing.
D
All
of
this
is
to
have
the
source
of
truth,
so
everybody
can
go
to
this
thing
and
clearly
like
take
in
mind
whatever
their
enhancement
is
or
whatever
their
idea
is
and
know
what
they
need
to
do
as
best
as
possible.
It
doesn't
mean
there
won't
be
questions
but
to
sort
of
take
out
the
squishiness
of
it
and
then
the
constant
sort
of
debate
and
just
nail
down
in
this
relief.
D
A
And
and
then
for
you
know
from
from
my
perspective
as
we
start
to
like
clean
up
and
improve
the
tools
and
and
put
more
enforcement
mechanisms
in
place,
it
becomes
a
question
of
like
well.
What
does
the
code
look
like
to
support
that
right
so
currently,
like
the
release?
Cadence
cap
is
an
example
of
like
something
that
I
want
to
flip
to
implementable,
and
I
can't
now
because
the
the
pre-submits
block
it,
because
it
requires
a
pr
review
that
isn't
required.
C
Yeah,
I'm
I'm
just
so
since
we're
talking
about
lightweight
stuff,
like
can
john,
go
and
add
a
label
that
says
pr
review,
not
required
and
then
immediately
the
verification
will
pass.
Would
that
be
a
mechanism
that
you
would
consider,
or
are
you
talking
about
like
text
inside
the
yaml
itself?
That
says
the
pr
require
is
not.
A
Required
for
this,
it
should
be.
It
should
be
text
within
the
the
prr
itself,
because
the
within
the
within
the
cap
metadata
itself,
because
you
know,
as
we
clean
up
the
kept
metadata
and
we're
we're
pretty
clean
now.
Actually,
I
think
you
know
we've
had
a
bunch
of
cleanups
in
the
past
and
it's
and
I
think
we're
the
repo
is
just
about
where
it
needs
to
be
outside
of
adding
backfilling
some
some
fuel.
A
Yeah,
let
me
make
the
the
point,
so
you
know
the
reason.
The
the
reason
behind
this
is
like
as
we
are,
as
we
were,
concerning
ourselves
more
and
more,
with
the
metadata
and
structuring
receipts
generating
manifests
for
all
of
this
stuff
like
it
needs
to
be
in
a
it
needs
to
be
not
a
github
query.
It
needs
to
be
in
in
the
content
itself.
I.
C
I
got
it
stephen,
I
know
a
little
bit
so
I
got
that
part.
So
then
the
question
is
like:
it
is
self-reported
in
the
sense
that
the
pr
author
will
add
that
thing
in
the
metadata
right
or
somebody
will
make
him,
do
it
make
that
person
do
it
yeah,
and
so
that
will
still
john
can
still
go
and
say
no,
that's
not
allowed
like
for
the
kept
that
you're
writing.
You
know
it
falls
under
this
other
category
or
it
qualifies
this
thing,
so
you
need
to
flip
it
back
on.
A
Right
so
right
now
as
it
stands,
our
validations
will
will
will
cause
your
pre-submits
to
fail.
I
know
that.
C
So
I'm
saying
that
if
somebody
says
I,
if
we
have
like
10
things
in
there
and
they
switch
off
all
nine
and
say,
and
only
one
of
them
you
know,
I
want
like
jordan
to
take
an
api
review.
I
don't
want
anything
else
in
this
set
of
things
that
right
and.
C
A
On
because
we're
cause
we're
all
like
we're
running
out
of
time
in
the
meeting
and
we
haven't
covered
everything,
the
the
second
part
of
that
we're
concerned
with
right
now
is
getting
people
to
route
out
of
the
process
right.
We
need
another
piece
of
information
to
help
them
get
routed
out
of
the
process,
so
that
john
doesn't
have
to
come
to
the
thing
and
go.
Oh,
a
prr
review
is
not
required
for
this
right.
C
And
then
I'll
shut
up
you,
you
are
looking
all
of
this
from
the
release
lens
right,
like
what
does
release
team
want
to
do?
What
does
what
does
release
team
need
if
you
step
outside
and
think
of
like
end
users
who
are
going
to
download
this
stuff
and
who
have
to
have
some
faith
in
like
the
production
readiness
of
those
bits
right
like
step
out
outside
from
that
point
of
view,
if
you
you
look
in
like
I'm
getting
a
set
of
bits
from
kubernetes
folks,
is
it
production
ready
right?
A
Absolutely
I
want
to
clarify
that
we're
not
we're
not
only
looking
at
this
from
the
the
lens
of
the
the
release
team
or
other
people
who
are
working
on
this
directly.
This
is
coming.
This
feedback
is
coming
from
like
things
that
have
been
shipped
across
time,
issues
and
pr's
that
have
been
opened
asking
about
like
yeah.
What
do
we
do
with
entry
versus
out
of
tree?
How
does
how's
this
data
presented
so.
A
Not
tracking
it's
it's
well,
it's
yes,
no
and
out
of
tree
and
we're
saying
that
yes,
no
out
of
tree
is
the
wrong
way
to
slice
it
because
they're
they're
combining
multiple
concerns
like
do.
I
want
to
track
it
as
a
as
a
part
of
the
release,
team
or
enhancement.
Sub
team
are
prr
reviewers,
or
is
it
important
to
track
in
general,
and
it
just
happens
to
be
out
of
tree
right.
Those
like
those
labels.
A
Don't
actually
answer
that
question
today,
so
so
finding
the
answer
to
like
figuring
out
the
right
way
to
essentially
saying
out
of
tree
out
of
tree
like
combines
too
many
concerns
right
and
for
someone
who
is
not
in
the
project.
They
don't
know
what
outfit
or
care
what
out
of
tree
means
right,
so
so
one
finding
the
right,
the
the
right,
not
the
the
right
language
that
allows
us
to
to
indicate
to
people
like
this
is
important.
This
is
why
it's
important
right
and
this
these
are
the
kind
of
review
steps.
D
There's
one
thing
that
just
to
to
kind
of
get
to
what
I
think
dim
just
talked
about
was
a
concern
of
mine
of.
Are
we
creating
a
process
where
the
author
is
kind
of
deciding
all
of
this
and
somehow
slips
things
through
without
other
people
deciding
and
one
thing
that
navru
and
anna-
and
I
were
talking
about,
was
and-
and
we
brought
this
up
also-
and
I
think
stephen
agrees
is
that
we
still
want
the
sigs
to
own
these
enhancements
and
these
cats.
D
So
we
don't
want
authors
to
unilaterally
be
deciding
things
and
we're
going
to
have
to
figure
out,
and
I
think
that
this
is
something
that
was
in
progress
in
the
conversation
was
figure
out
a
way
to
still
have
sigs,
be
the
gatekeeper
because
enhancement
team
can't
know
like
I,
I
can
guess,
based
on
my
experience,
but
I
can't
know,
and
the
figs
need
to
be
that
arbiter,
that
that
blocker
to
say
no,
this
actually
needs
a
prr.
This
doesn't
need.
A
D
D
A
D
The
owners
and
gatekeepers
of
these
caps-
and
I
hope
that
that
I
see
some
nodding
so
I'm
hoping
that
that
like
makes
some
sense
there,
and
maybe
we
need
to
reflect
that
better
in
the
chart,
so
that
that's
but
that's
clear.
But
that
was.
A
I
think
hold
on
hold
on.
I
think
we
have
that
right
now
right,
so
we
have
two
two
things:
one:
the
fact
that
all
of
the
directories
that
proposals
are
are
added
to
are
under
the
purview
of
the
sig
right
so
like
you
cannot
approve
something
unless
it
that
has
been
approved
by
mistake.
So
that's
the
first
piece,
the
the
second
concern
that
I
I
believe
kirsten
you
added
a
review
to
the
receipts
kept
was
because
john's
concern
is
well
around
too
many
directories
and
like
this
should
just
be
flat.
A
Keep
it
simple.
An
approval
of
a
receipt
is
saying
that
everyone
has
has
approved
it.
So
the
I
responded
to
your
review
and
suggested
that
when
we
add
receipts,
we
instead
add
the
receipts
to
the
sigs
directory.
So
they
are
the
ones
opting
in
right.
They
are
the
ones
opting
to
the
idea
that
the
proposal
should
land,
then
within
the
receipts
directory
or
the
the
releases
release
whatever
and
and
manifest
that
actually.
A
C
B
A
Yeah
so
so
john,
you
hung
and
I
believe,
like
the
critical
part
of
your
explanation,
we
kind
of
have
a
bit
of
a
cliffhanger,
because
we
are
at
time
so
I
would
say,
like
let's
everyone,
let's
jump
on
enhancements
on
slack
and
keep
keep
the
conversation
going
and
we
will
catch
you
at
the
next
one.