►
From YouTube: 20210304 SIG Arch Enhancements
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Hi
welcome
to
the
march
4
2021
enhancement,
sub
project
meeting.
My
name
is
laurie
apple
I'll,
be
your
facilitator
today,
and
I'd
just
like
to
remind
you
of
our
code
of
conduct,
which
is
to
treat
everyone
with
respect,
be
kind.
Remember
what
you
say
here
is
recorded
and
we'll
go
on
the
internet
so
be
mindful
of
that.
B
I
will
share
my
screen
and
then
we
will
look
at
the
agenda.
We
have
a
couple
of
topics
for
today,
so
we
have
the
enhancements
process
diagram
which
I've
been
working
on,
got
some
input
but
need
much
more.
The
second
topic
is
from
dims
really
tools
that
can
be
developed
by
google
summer
of
code
students.
You
know
so
what
project
idea
can
we
file-
and
we
have
some
suggestions
here
and
from
anna
the
enhancements,
repo
access
from
steven
enhancement's
owners
and
refactors
and
then
action
items
that
the
receipts
kept
needs
review?
B
Now,
which
of
these
topics
is
urgent
or
is
one
that
you've
posted,
but
you
have
to
leave
early.
We
should
start
with
that.
C
I
would
say
psa
was
the
enhancements
owners.
First,
okay,
go
ahead,
so
we
have
been
chatting
amongst
the
enhancements
owners
and
laurie,
and
I
have
proposed
some
additional
enhancement,
toners
some
project
owners.
So
first
kristin,
you
have
been
doing
amazing
work
across
multiple
cycles
and
really
championing
kind
of
just
making
sure
that
we
are
honest
about
what
we
do
and
we're
appreciative
of
course,
and
would
like
to
elevate
you
to
a
sub-project
owner.
C
So
the
pr
is
up-
and
I
will
toss
that
in
the
notes
in
a
second
additional
updates,
so
we
have
kind
of
the
the
owner's
file
folded
out
in
a
few
different
ways:
people
that
handle
so
from
the
sub
project
owners.
Those
are
people
that
are
in
the
enhancements,
approvers
slot
in
the
owner's
alias
and
then
for
the
enhancements
reviewers.
C
Now
we
also
have
the
kept
tools,
approvers
and
reviewers,
and
those
are
essentially
people
who
are
have
been
spending
more
time
in
the
code
day
to
day
happy
to
have
more
folks
in
that,
if
that
is
something
you're
interested
in,
so
for
the
rest
of
those
those
aliases
we're
proposing
anna
and
nabarrone
as
enhancements
reviewers
and
nabarine
additionally
as
kep
tool
reviewer.
C
So
thank
you
again
for
all
of
your
contributions.
Y'all
have
been
doing
really
really
really
awesome
work
and
the
pr
is
now
in
the
notes.
So,
if
y'all
want
to
check
it
out,
I'm
wondering
do
we
need
a
I've.
We've
got
approval
from
we've
got
approval
from
a
sig
architecture,
chair,
dims
and
approval
from
multiple
enhancement,
sub-project
owners,
as
well
as
some
plus
ones,
from
members
of
sig
release.
A
I
think
we
can
just
go
right
ahead.
I
just
put
my
approval
on
as
well,
so
I
think
with
enough
owners,
a
bunch
of
donors
and
me
and
tim's.
B
All
right,
yeah,
congratulations
and
thank
you
for
all
of
your
contributions.
I
think,
if
there's
no
more
on
this
topic,
we
move
to
the
next
one.
Do
we
have
anything
else,
that's
urgent
time,
sensitive
or
you're,
leaving
early.
B
Okay,
if
not,
then
I
will
start.
I
don't,
I
think,
with
23
minutes
remaining
in
all
these
topics.
We
could
look
at
the
diagram
in
detail
in
this
meeting.
What
I
think
we
can
do
is
assign
who
would
like
to
get
involved
in
filling
out
that
diagram
and
reviewing
it
based
on
like
sections
or
specific
asks.
So
if
we
go
to
the
board
just
real
briefly,
you
know
I've
broken
this
down
into
the
different
stages,
but
this
is
a
draft
right.
Sorry,
I'm
trying
to
make
this
somewhat
visible.
B
You
have
a
couple
of
items
here
that
don't
have
any
text,
and
these
are
marked
this
way,
because
these
are
things
that
we
probably
need
so,
for
example,
types
of
entry
enhancements,
don't
necessarily
have
templates
for
everything
or
I
wasn't
able
to
find
them
using
existing
documentation,
so
that
might
be
a
set
of
to
do's
to
to
create
those
templates.
B
I
think
we
actually
have
covered
those
in
620,
but
I'm
not
sure
if
we've
gotten
all
of
them
and
then
there
is
the
actual
flow
itself
and
you
can
see,
there's
quite
a
number
of
steps
so
looking
for
ways
to
simplify
this
process.
C
Because
yeah,
it
just
goes
and
goes
and
goes
so
so
I
think
I
think
opportunity
for
simplification
is
solving
for
the
scopes
types
like
getting
routing
them
out
of
the
process.
If
you
know
they're,
they
don't
need
the
more
intensive
review
that
would
be
required
for
admission
into
the
release.
D
All
of
that,
can
you
repeat
again.
C
Yeah,
so
I
think
the
the
the
opportunity
for
simplification
in
the
diagram
is
figuring
out.
If
you
even
need
the
type
of
review
that
we
would
be
giving
for
someone
being
included
in
the
release
right,
if
it's,
if
it's
out
of
tree,
if
it's,
if
it's
process,
we
don't
as
the
release
team
enhancement,
sub
team
or
prr,
doesn't
need
to
look
at
it
really
right
or
does
it
necessarily
okay.
B
Yeah,
so
that
is
already
identified.
We
have
the
out
of
tree
here,
so
I
think
we
probably
just
need
to
tighten
this
up
right.
We
need
to
streamline
it.
Maybe
it's
not
clear.
What's
in
what's
out
why
what's
in
is
in
all
of
those
parts,
so
that
could
be
a
good
to
do
then
making
sure
that
this
is
very
clear
and
doesn't
block
anybody.
C
C
B
Can
folks
somebody
also
take
notes,
because
it's
a
little
hard
to
do
both,
so
I
want
to
make
sure
we
get
that
down
is
to
ask
yeah.
Thank
you.
Steven
I've
stringling
created
a
new
word
for
you.
E
F
That's
the
diagram:
where
would
any
comments
that
we
have
go?
I
assume
that
we
can't
like
comment
on
the
diagram.
A
Are
there
things
that
are
in
jk?
That
really
don't
need,
I
guess,
there's
a
separate
thing
that
doesn't
need
a
cat,
but
like
like
some
of
the
tooling
things,
are
in
jk
and
maybe
don't
need
say,
production
writing
interviews,
so
the
categorization
of
things.
This
is
where
I
get
a
little
bit.
We
talked
about
intrigue
versus
out
of
tree
and
the
categorization
and
I'm
not
sure
the
definition
of
entry.
A
If
it
means
just
in
kkk,
then
that's
not
necessarily
the
same
criteria
for
all
rules
applied
to
it
right.
So,
like
a
process
thing
or
tooling
thing,
more
typically
might
yeah,
tooling
changes
might
be
a
process
type
cap.
A
I
don't
know
if
they
seem
orthogonal,
whether
it's
in
kj
and
whether
the
capitalist
process
versus
functionality
and
things,
I'm
thinking
in
particular
with
my
prr
hat
on
here-
is:
I
don't
necessarily
need
to
pr
the
tuning
changes
because
there's
no
production
code,
whereas
you
know
so
I
want
to
make
sure
we
don't
have
a
gap
here
in
what
policies
apply
to
things.
B
Okay,
so
I
think
what
we
can
get
out
of
this
meeting
right
now
is
what
what
are
the
who
can
work
on
this
offline,
who
is
willing
to
spend
before
the
next
meeting,
contributing
to
this
like
making
this
your
top
one
or
two
priority
for
the
next
two
weeks
of
what
you're
doing
enhancements.
F
B
B
A
B
E
B
C
So
yeah,
so
looking
looking
at
this
diagram
really
quickly,
the
it
would
be
refining
the
the
categorization,
I
think
is,
is
the
biggest
point
right
because,
like
my
two
axes
are
are
do
we
need
to
review
this
or
not
right
and
then
within
that
there,
like
john,
was
mentioning
there's
the
the
tooling
the
process
policies.
A
tooling
change
may
not
require
a
cap.
C
Rather
a
tooling
change
may
not
require
a
prr
review,
but
if
it
is
a
change
that
can't
land
across
release
boundaries,
then
it
is
bound
to
the
gap
the
it
is
bound
to
the
deadlines
that
we
have
for
release
right,
so
that
might
require
more
scrutiny.
So
I
think
the
types
of
we
want
the
scope
in
terms
of
like
is
it
entry
auditory
and
we
also
care
about.
We
also
care
about
like
what
type
of
change
is
it
right
feature
versus,
I
guess,
yeah,
well
enhancement
versus
our
code
enhancement.
C
I
think
it's.
I
think
it's
a
a
glossary
thing
right
like
we
need,
like
we've
classically
talked
about
entry
and
out
of
tree
as
code
that
is
in
kubernetes.
Kubernetes
are
code
that
is
not
in
kubernetes
kubernetes.
We
need
to
explode
that
a
little
bit
and
say
like.
Is
it
not
just
it's
not
just
necessarily
the
code,
that's
in
kubernetes
kubernetes,
it's
is
it
specifically,
something
that
would
turn
into
the
the
product
or
the
project
that
is
like
what
we
ship
right
and
and
whatever
the
name
for
that
is.
There's
a
label.
G
B
Yeah,
okay,
I
think
we
can
take
that
offline.
I
think
we
need
to
end
because
we
have
other
topics
to
get
to,
but
we
have
a
little
bit
of
a
start.
Please
watch
the
enhancements
channel.
I
really
like
to
not
lose
momentum
on
this,
because
I
think
it
is
incredibly
important
for
everybody
here
to
be
able
to
save
time
down
the
road.
B
B
All
right,
moving
on
to
the
next
topic
tools
that
could
be
developed
by
the
summer
of
code.
Students
nabruin,
was
also
kicking
around
some
ideas
here,
so
maybe
nabroom.
If
you
want
to
start
us
off,
is
here.
G
Yeah
sure,
so
the
premise
is
that
right
now,
gsoc
and
outreachy
project
idea
submissions
are
going
on,
and
if
we
have
something
that
we
can
plan
for
two
months
of
work
and
we
have
like
scope
of
what
we
want
to
achieve
at
the
end
of
two
months,
we
can
propose
a
project
in
either
of
the
programs
or
both
if
we
have
like
adequate
number
of
ideas.
G
So
two
of
the
things
that
cropped
up
in
the
community
from
that
slack
thread
and
several
other
threads
were
number
one
was,
can
we
extend
like
do?
We
have
any
work
on
extending
cap
ctl
through,
like
whatever
we
plan,
and
the
second
thing
was
the
website
that
we
have
been
planning
for
some
time.
So
that
was
that
is
a
gist
of
the
conversations
going
on,
and
we
wanted
to
put
this
out
for
discussion
in
this
forum.
C
I
personally
always
have
a
problem.
I
love
the
idea
of
the
program.
I
think
that
you
know
for
like
sig
release
and
and
enhancements
we're
constantly
in
this
weird
spot
where,
like
the
thing
isn't
figured
out
yet
or
the
people
who
are
best
are
have
the
best
opportunity
to
action
on.
It
are
ones
that
already
have
context
with
enhancements.
C
We
are
starting
to
figure
out,
kept
ctl
right
and
and
getting
it
and
getting
it
in
a
place
where
more
people
can
contribute
to
it.
I
don't
think
it's
a
two-month
project
for
someone.
The
website
looks
like
a
potential
good
option
for
someone
to
to
learn
more
about
the
process
as
well
as
execute
on
the
website,
but
because
I
think
I
think
we've
been
talking
about
this
website
for
for
years
now
and
it
doesn't
exist
so
seeing
it
actually
happen
would
be
great,
but
yeah.
C
I'm
not
sure
that
yeah
kept
ctl
is
definitely
not
the
the
thing
so
bob
yeah,
sorry.
H
Oh
sorry
about
cord
yeah,
the
the
one
thing
with
the
website
is
like
once
now
that
we
actually
have
the
the
metadata
the
actual
work,
if
you
just
want
to
do
like
the
original
goal
of
essentially
having
a
big
sort
of
list
view
of
the
caps,
is
not
going
to
be
a
two-month
project
if
it
is
expanded
to
also
displaying
like
you
know,
transforming
displaying
the
caps
themselves.
H
That
might
be
a
little
bit
more
in
scope.
That
would
also
sort
of
fall
in
line
with
a
goal
that
we
have
for
the
contributor
site
itself.
If
we
want
to
display
the
caps
and
have
all
that
there
on
that
site,
but
that
could
be
a
whole
other
discussion.
F
Was
that
one
of
the
pain
points
and
the
enhancement
process
is
the
docs
stuff
like,
and
I'm
wondering,
if
there's
any
like
automation,
that
could
happen
for,
like
the
like,
there's
just
a
lot
of
docs
related
stuff
and
the
docs
team
seems
to
be
getting
really
bogged
down
with
it,
and
I'm
just
wondering
if
there's
like
any
automation
that
somebody
could
work
on
with
maybe
the
docs
team
to
try
to
make
that
process
a
little
bit
smoother
whether
it's
like
some
kind
of
tooling
to
like
open
and
because
we
have
that
sorry,
we
have
that
thing
where
you
have
to
open
a
placeholder
pr,
which
doesn't
necessarily
make
a
lot
of
sense,
but
like
it
just
feels
like
there's
some
kind
of
automation.
F
Potentially
that
could
happen
there
either.
You
know
getting
rid
of
some
of
the
process,
refining
a
process
and
then
automating
something
to
help
the
docs
con
docs
people
with
their
stuff,
because
they're
kind
of
the
one
part
that's
not
really
changing
in
this
enhancement
overhaul
as
of
right
now.
So
I.
C
Yeah,
so
for
for
that,
I
would,
I
would
say,
jim
angel
is
your
your
person.
We
had
talked
about
this
in
the
past.
Around
improvements
for
docs,
maybe
leveraging
some
of
the
work
that
is
done
in
in
krell
to
do
branch
fast
forwards
and
stuff
like
that
so
like
that
is
like
handling
the
branch
situation
for
them
would
be
great.
I
think
that
one
of
the
big
problems
that
you
run
into
is
that
people
in
around
sig
docs
will
have
different
workflows
in
terms
of
git
right.
C
So
there
is
a.
There
is
a
matter
of
like
figuring
out
your
workflow.
What
works
best?
Is
there
a
tool
that
solves
it
all,
not
necessarily
some
people
prefer
to
work
with
github
via
ui
instead
of
the
command
line
tools.
So
that's
one
conversation
and
I
think
it's
maybe
outside
of
the
the
scope
of
this
call
specifically,
but
for
for
the
docs
placeholders.
That
is
that's
a
responsibility
for
the
sigs
that
should
not
be
on
on
the
doc
in
sub-team
members
of
the
release
team.
C
The
the
point
of
you
know
part
of
the
point
of
doing
that
is
so
that
the
people
who
have
to
handle
doc
review
have
an
idea
of
what
their
backlog
is
going
to
look
like
right.
It's
a
it's
kind
of
a
planning
exercise,
almost
right
and
maybe
maybe
the
improvement
there
could
be
like
refining.
What
that
planning
exercise
actually
looks
like.
B
C
B
Okay,
so
the
route
is
talk
to
contrebex
about
the
docs
topic
and
the.
G
D
B
E
Yeah,
so
I
know
some
of
you
were
already
tagged
on
the
slack
for
this,
but
so
since
the
milestone,
maintainer
access
was
reduced,
while
back
so
a
lot
of
sick
leads
have
been
reaching
out
or
commenting
to
the
enhancement
team
asking
how
they
can
edit
the
description
of
the
enhancement
issue
because
they
lost
that
access,
and
I
don't
have
an
answer
for
them.
E
C
So
we
don't
want
a
new
issue.
The
new
issue
is
going
to
break
the
fidelity
of
what
the
kept
number
encodes
right.
The
cap
number
links
you
to
the
the
enhancement
issue,
so
we
don't
want
new
issues.
The
I'm
surprised
that
the
I
guess
the
github
access
does
not
do
the
thing
that
it
says
it's
going
to
do.
The
triage
role
is
supposed
to
allow
you
to
to
edit
edit
exactly
this
edit
pr
descriptions.
So
I'm
wondering
if
the
people
who
are
reaching
out
actually
have
are
actually
in
milestone.
C
Maintainers,
I
I
think
you
know
one
route
is
to
you
know
if
you've
had
reports
who
those
people
are
and
if
they
are
actually
in
milestone,
maintainers
so.
F
C
Well
right,
can
you
see
if
you
can
open
a
pr?
Can
you
see
if
you
can
edit
a
pr
issue,
description
right
now?
Well,.
E
So
I
did
read
that
github
document
of
all
the
access
that
triop
has-
and
I
believe
it
did
say
you
don't
have
edit
access
to
the
description.
C
G
Yeah
it
it
explicitly
says
that
for
any
issue
or
pr
that
you
did
not
create
you
can't
edit
them
so
github
actions,
the
github
documentation
on
the
roles
say
that
right,
it
is
given.
E
C
We
have
these
two
left.
I
can.
I
can
speed
around
so
yeah
for
for
receipts
cap
like
let's
review
it,
let's
get
it
in
period
for
the
refactors.
This
is
around
going
through
going
through
the
repo
I've.
I've
noticed
that,
like
it
looks
like
the
repo
was
written
by
five
different
people,
like
everyone,
had
a
different
approach
for
doing
the
same
things
that
has
led
to
those
pr's
that
I
linked
or
two
massive
refactors
of
the
repo
to
try
to
get
everything
kind
of
on
a
stable
foundation.
C
If
you
are
working
on
new
features
for
kept
ctl,
please
let
people
know
specifically
not
call
them
out
necessarily
but
pr,
reviewers,
john
and
and
your
crew
when
you're
adding
features.
Please
let
us
know
because,
like
often
there
is
other
work
that
solves
the
problem
that
is
in
flight
already
so
like
yeah.
So
there
were
a
few
things
that
I
had
to
dance
around
with
voitex
prs
and
stuff
to
get
it
into
the
refactor.
C
So
let's
make
sure
that
the
process
is
not
messy,
and
especially
now
that
we
have
more
contributors
that
are
interested
in
getting
involved
in
kept
ctl.
It's
going
to
be
hard
for
them
to
do
that.
If
the
way
that
we're
trying
to
build
things
does
not
look
good
yeah.
C
Marching,
thank
you,
so
jeremy
has
jeremy,
has
a
design
doc
that
we
were
poking
at
briefly.
I
have
some
scribbles
that
are
in
that
design
dock.
So
it's
not
public
yet,
but
we
will
make
it
public
to
get
a
get
everyone
on
the
same
page
about
what
kept
ctl
should
and
shouldn't
do,
and
we
can
ship
that,
hopefully,
in
the
next
week.
C
B
Now
bruin
fixes
the
gist,
I
think
that's
f,
but
I
think
that's
all
right.
B
C
Perfect
one
thing
to
mention:
it
feels
like
now
that
we
have
switched
to
30
minutes
that
we're
rushing.
Do
we
need
to
make
this
a
45
minute.
B
Guess
we
could
set
up
a.