►
From YouTube: 20200910 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
All
right
welcome
everybody.
This
is
the
kubernetes
sega
architecture
meeting
for
september,
10th,
2020
and
today
just
want
to
remind
everybody
to
follow
a
code
of
conduct
and
be
respectful
one
another
and
let's
get
started
lori,
you
wanna.
So
the
first
item
on
our
agenda
is
to
talk
about
the
sort
of
backlog.
B
A
That
we
have
in
the
sig,
then
actually
I
prefer
to
put
some
project
readouts
last
because
they're
sort
of
like,
if
we
don't
need
them,
we
can
issue
they
want
to
cover.
I
prefer
that
okay,
so
let's
get
started
laura.
Do
you
want
to
present.
C
So
basically,
oh
I
get
the
note
yeah.
I
will
stop
your.
B
C
Sharing
and
then
I
will
try
to
find
it
doesn't
okay.
Here
we
go
okay,
so
basically
just
a
few
things
about
the
stock
that
you're
looking
at
and
its
contents
to
create
the
content.
I
just
ran
through
the
issues
and
pull
requests
that
were
labeled
sig
architecture
that
either
seemed
like
they
fall
directly
within
the
context
of
the
sig,
and
you
can
tell
me
if
I'm
wrong
and
we
just
move
on
from
that
item.
If
it's
not
relevant,
another
thing
was
if
it
was
a
small
fix
that
was
dox
related.
C
That
seemed
to
be
either
something
you
could
close
or
you
know
it
was
just
hanging
around
for
a
long
time
and
maybe
too
long,
given
the
small
size
of
the
of
the
item
itself,
like
the
amount
of
work
was
required
to
merge
it
and
then
the
second
thing
or
the
third
thing,
rather
that
I
was
noticing
here
that
any
issues
that
seem
to
have
been
around
for
a
while,
like
that
are
20
19.
C
A
A
Sure
I
don't
know,
there's
there's
quite
a
long
list
here
whether
we
have.
How
did
you
want
to
do
this?
Did
you
want
to
go
through
this
here?
Should
we
go
through
this.
C
You
could
go
through
this
offline.
I
think
it
depends
on
if
you
we
can
so
I
tend
to
do
these
things
somewhat
rapid
fire.
We
can
sidebar.
If
any
item
requires
discussion
and
then
here
the
recommendation
will
be
who's
going
to
talk
about
this
later.
C
When
will
they
have
something
to
share
with
the
group
again,
and
maybe
what
is
the
key
question
related
to
the
to
the
item
that
you
want
to
solve?
Does
that
seem
reasonable.
A
Sure
yeah
sure
I
don't
know
who
do
we
have
here
today.
Do
we
have
a
relatively
small
group,
but
let's,
let's
see
what
we
can
get
through
and
maybe
we
should
time
box
it
and
then
come
back
to
it.
If
there's
time,
something
like
that.
A
All
right,
so
why
don't
we
plan
to
spend
15
minutes
or
so
on
this
and
then
we'll
go
to
the
other
agenda
items?
If
we
have
time
at
the
end
of
the
meeting,
we
can
make
you
go
back
to
this
okay,
so
this
one
is
definitely
the
enhancement
sub
project
and
it
seems
appropriately
done.
I
don't
know
the
status
of
it.
It's
we're
reworking
the
process
for
or
we're
discussing,
updated
process
and
stephen
augustus
is
working
on
that
with
ticketing
and
things
like
that.
So
I
don't.
A
I
don't
know
if
there's
not
one
there
with
that
other
than
it's
it's
in
the
in
the
realm.
C
A
A
Third
item
is
kind
of
related
to
that
right.
We
have
these
caps
and
the
caps
tend
to
the
process
was
originally
conceived
around
features,
and
but
we
use
it
as
just
like
the
mechanism
for
getting
feedback
from
people
and.
C
C
So
then,
the
action
to
take
on
this
first
item
is
just
leave
it
to
the
enhancement
sub
project
to
decide
what
status
it
is
and
everything
else
and
then
come
back
to
this
group
at
some
point
right.
A
E
Yeah,
this
is
the
background
here.
John,
is
people
file
caps
and
then
they
go
to
social
media
and
they
end
up
talking
about
it
and
they
try
to
advocate
for
it,
and
if
the
question
here
is,
should
our
we
have
some
accounts
that
tweet
out
as
well?
E
Should
we
retweet
things
that
way
right
to
shine
light
on
that
to
get
more
contributors,
but
it's
also
been
used
negatively
a
lot
of
times
to
you
know
broad
beat
us
is
a
simple
way
to
put
it,
so
we
want
somebody
to
set
some
policies
saying:
okay,
if
all
the
authors
and
the
sig
leads
sign
off,
then
we
can
talk
about
it
using
the
official
handles
or
not
right.
So
right.
That
is
the
background.
There.
A
E
Yeah
the
steering
committee
can
sign
off
on
it,
but
we
want
the
people
responsible
for
the
enhancements
or
the
architecture.
E
A
We
can
work
on
that
and
the
enhancements
is
the
the
policy
around
that
I
think,
there's
some
valid
uses,
like
one
of
the
reasons
is
when
a
cap
goes
to
functionality
as
a
beta
like
or
even
an
alpha
like,
we
may
want
to
get
and
solicit
feedback,
that's
one
of
the
points
of
alpha,
and
so,
if
it's,
if
the
message
is
sent
out
properly
of
hey,
try
out
this
crazy
new
thing
see
how
bad
it
is
and
give
us
some
advice
as
opposed
to
hey
here's,
a
new
feature
to
run
the
production,
then
I
think
we're
okay.
C
Okay,
so
I
think
that
you
have
their
general
gist
set
up.
It's
basically,
you
know
steering
committees
involved,
but
not
until
cigar
architecture
and
enhancement.
Subprojects
set
the
policy,
so
I
think
it
starts
with
enhancements
goes
to
sig
architecture.
Then
the
steering
committee
does
that
sound
right.
C
A
C
Right
not
any
substantial,
it.
C
So
all
right,
so
we
can
talk
about
this
next
tuesday
because
we'll
cover
enhancements
policy
and
process
by
the
way,
if
you're
interested
in
enhancing
this
policy
and
process
there's
a
meeting
next
tuesday,
if
you're
a
first
timer,
so
you
can
join.
A
What
is
that?
I
don't
know,
that's
not
familiar
to
me.
A
A
C
No,
no
leave
it
there
like
leave.
It
confirm
it
there
all
right.
So
that's
easy,
and
I
can
pinged
him
as
well
and
the
channel
to
see
like
if
he'd
like,
to
make
the
change
himself,
because.
A
C
Okay
yeah:
this
is
nabaren's
question.
Is
this
something
we
can
close
so
to
decide
whether
it's
so
decide
if
it's
valid
and
enhancements
subproject
right.
A
C
Yeah,
but
I'm
just
asking,
if
that's
the
actual
flow
so
like
it,
should
go
to
the
enhancement
sub
project
and
then
they
should
that
should
just
that
group
should
decide
if
it's
valid.
If
so,
then
it
should
be
resolved
there
and
shouldn't
bounce
back
up.
C
C
C
Oh,
I
think
because
it
was
merged,
so
is
there
anything
else
to
do.
C
Cool,
so
I
think
it's
fine
leave,
as
is
yep.
C
Okay,
making
kept
transparent.
This
is
an
enhancements
topic.
We
don't
have
to
cover
it
for
now,
but
then
I
guess
you
would
want
to
bump
it
up
to
the
broader
sig
architecture
at
some
point,
just
for
like
some
final
review
or
would
it
be,
would
it
also
be
settled
there.
C
D
Sorry,
I'm
having
really
terrible
zoom
experience
today,
the
this
one
is
merged
and
I
have
a
pr
that
I'm
working
on
it's
mostly
docs.
C
A
D
C
So
that's
the
last
piece
and
then
yep
is
that
right,
yep
cool,
but
you
still
keep
the
the
issue
open
until
that
last
piece
is
done.
Yeah.
A
Yeah
now
this
is
for
the
apis,
but
I
think
there's
a
discussion
later
in
the
agenda
about
how
we
manage
feature
dates
in
a
similar
way.
Is
that
so?
But
I
guess
that's
irrelevant
right
now,.
C
There's
also
a
reason
why
I
put
this
here.
I
think.
B
A
David,
since
that's
your
issue,
I
think
yeah,
you
want
to
wrap
that
up.
E
One
sec,
jordan,
didn't
we
have
like
a
long
email
conversation
with
some
vmware
folks
on
this,
I
I
know
it.
There
was
a
churn
on
a
pr,
but
I
don't
know
if
it
it
had
merged.
Yet.
E
D
D
F
D
B
C
All
right,
awesome
and
can
close,
I
think,
we're
over
time
we're
also
making
quite
a
lot
of
progress
so.
A
Yeah,
let's
this
last
one's
just
still
in
progress
and
under
discussion.
So
it's
just
continued
performance.
A
A
C
On
the
project,
yeah
should
go
into
the
related
project
board
and
I
also
marked
a
few
items
here
just
strictly
for
enhancements,
and
then
I
think
this
is
the
remainder
for
the
issues
and
then
for
the
pull
requests.
A
Okay,
let's
think
we
said
and
jump
into
the
other
into
the
other
agenda
items,
and
if
we
have
time
we
can
come
back
to
those
so.
B
A
Okay,
all
right
next
item
here
I
assume
this
is
voice
check
or,
if
he's
on
or
or
group,
a
lot
reliability.
G
Sorry
I
was
trying
to
find
the
right
window
and
mute
myself.
Yes,
it
was
me
so
yes,
so
for
the
record,
like
we've
been
talking
a
little
bit
about
that.
Like
a
couple
meetings
ago,
the
proposal
has
go,
went
out
like
yesterday
the
official
proposal
for
the
working
group
with
a
specific
proposal
for
the
charter.
Like
all
the
things
all
the
all
the
questions
from
the
working
group.
G
Create
prerequisites
for
creation,
one
of
the
things
that
we
need
now
is
like
six
sponsorship
official
six
sponsorship
and
like
we
would
like
also
to
ask
for
sponsorship
from
like
cigar,
so
so
yeah
obviously
like.
If
you
have
any
feedback
on
on
the
chart
or
anything,
we
are
still
open,
like
the
initial
set
of.
I
should
probably
mention
that
the
initial
set
of
chairs
that
we
propose
is
david,
eats
steve
kuznetsov,
both
from
red
hat
and
myself,
so
right
yeah.
E
G
G
I
didn't
yet
open
a
pr.
I
just
opened
like
like.
The
initial
thing
I
had
to
do
was
like
start
the
email
and
only
then
like
link
the
email
from
the
from
the
actual
pr.
I
didn't
yet
get
to
it
since
yesterday,
but
I
will
I
will
link
it
once
I
open
it
hopefully
today
or
on
monday.
A
A
Okay,
excellent,
so
next
deprecation
windows
for
beta
api,
tim.
D
Great
so
this
came
up
in
a
conversation
with
a
customer
recently,
and
I
thought
it
was
an
interesting
point
that
the
we
now
say
we're
supporting
a
year
right
and
our
deprecation
policy
for
removing
a
beta
api
is
nine
months.
D
This
makes
it
difficult
for
somebody
who's,
building
a
controller
to
support
all
versions,
all
supported
versions
of
kubernetes
without
having
to
support
both
explicitly
a
beta
api
and
a
ga
api,
and
the
question
was:
should
we
consider
extending
the
deprecation
of
a
beta
api
to
four
or
maybe
even
five
quarters
so
that
it's
possible
to
have
a
controller
that
only
implements
one
of
those
apis
so
that
they
can
support
the
oldest
version
and
the
newest
version?
At
the
same
time,
the
practical
implication,
obviously
is
getting
rid
of
a
beta
api
would
take
six
months
longer.
D
D
So
right
now
the
we
introduced
a
beta
api.
We
don't
immediately
deprecate
it.
So
if
you're
just
talking
about
availability,
it's
typically
available
for
some
number
of
releases,
then
is
deprecated
and
the
deprecation
period
kicks
off,
and
so,
with
the
policies
we
have
today,
a
beta
version
will
actually
be
available
for
all
supported
releases,
it's
possible
according
to
the
rules
today,
to
to
suppose
I
have
beta
version
in
in
version
20
and
in
21
I
introduced
the
ga
version
and
deprecate
the
beta
version
in
23.
D
D
Yet,
once
you
announce
deprecation,
it's
three
relations:
nine
months,
it's
three
releases
nine
months
according
to
what
I
just
looked
at.
So
if
they
want
to
support
all
four
supported
versions,
they
have
to
support
both
beta
and
ga
and
read
or
figure
out,
which
ones
are
supported
in
the
api
server
that
they're
talking
to
now.
I
imagine
a
lot
of
controllers
are
going
to
want
to
do
that
anyway,
so
they
can
support
even
larger
windows,
and
maybe
that's
our
answer
like
just.
Do
it
sorry,
but
I
thought
it
was
worth
throwing
out
like.
D
If
we
supported
five
releases
for
beta,
we
made
it
five
quarters,
then
they
would
be
able
to
say
the
ga
version
was
introduced
as
soon
as
the
ga
version
that
ga
introduction
hits
the
oldest
release,
they
can
switch
to
the
ga
and
know
that
it'll
be
supported
on.
D
Everything
yeah,
I
I
think
practically
I've
never
seen
an
api
show
up
in
beta
in
one
release
and
then
bga
the
next
release,
and
so
I'd
be
hesitant.
It
doesn't
matter
how
long
it's
been
beta,
it
might
be,
it
might
have
been
beta
for
a
long
time.
The
point
is
when
they
introduce
the
ga
they
can
get
to
the
leading
edge
of
that
window
and
have
the
beta
be
removed,
but
the
trailing
edge
of
the
window
doesn't
have
the
ga
yet.
E
Is
what
I'm
hearing
through
some
of
the
discussions
that
that
I
saw
because
of
the
119
extended
release
stuff,
so
we
might
have
to
revisit
the
correlation
between
the
releases
and
the
quarter
thing
as
well.
D
A
So
if
I,
if
I
recall
correctly,
the
supported
window
is
stated
in
terms
of
time
one
year
and
the
the
deprecation
policy
isn't
stated
in
terms
of
releases.
Is
that
correct?
Because
that
could
cause
some
confusion
as
well.
D
D
Anyway,
we
don't
need
to.
We
don't
need
to
wrestle
with
it
here,
but
I
thought
it
was
a
challenging
topic
which
has
real
implications
for
our
ability
to
clean
up
our
own
messes
and
in
light
of
a
really
interesting
blog
post,
which
I'm
sure
you
all
read
it
made
me
wonder
if
we
should
be
more
generous
with
our
deprecations.
E
Yeah,
so
we
should
at
least
log
in
issue
and
track
this
tim,
so
we'll
revisit
when
we
figure
out
the
release
cadence.
I
guess.
A
D
Yeah,
so
just
a
few
things
to
call
out
as
sigs
are
doing
their
health
checks
of
stuff
that
they
have
in
progress
and
are
working
on
taking
features
that
actually
were
well
soaked
and
have
good
feedback
to
ga.
There's
some
discussion
around
how
feature
gates
progress
to
ga
and
sort
of
the
interactions
around
the
deprecation
policy
for
those.
So
I
linked
to
one
of
those
where
we
realized
that
we
have
some
guidance,
that's
more
user-facing
and
we
need
to
flesh
that
out
and
make
it
more
concrete
and
specific
for
developers
progressing.
D
A
feature
to
say
like
do
this
on
this
release,
then
do
this
on
this
release
and
maybe
make
some
of
that
automatic,
so
that
will
feed
into
some
dock
updates,
and
maybe
some
implementation
changes
to
simplify
that
by
far
the
most
interesting
api
exchange.
That
is
in
progress.
Is
the
dual
stack
service
api
pr.
So
I
linked
to
that.
D
That
is
exercising
a
lot
of
the
topics
that
we
have
wrestled
with
over
the
past
years,
around
pluralization
and
dual
representation
of
the
same
data
and
all
the
clients
and
new
clients
and
patches
and
updates,
and
it's
all
there.
So
if
you're
looking
for
greatest
hits
of
thorny
api
issues,
that's
that's
where
you
want
to
go.
Look.
A
I
I
saw
that
on
slack
I
suggested
coming
to
the
enhancements
meeting.
Do
you
think
that's
are
we
talking
about
tooling
around
how
we
manage
that
similar,
how
we
did
with
api
datas,
or
is
this
more
just
around
guidance
in
the
process
of
how
people
manage
their
feature?
Gate
like
I
guess
that
seems
like.
D
Really
concrete
guidance
of
what
should
you
do
when
your
feature
goes
to
ga
and
what
should
you
flip
and
how
long
should
you
leave
them
there,
and
when
should
you
remove
them
and
right
now,
that's
not
super
easy
to
understand,
and
so
we
just
want
to.
We
want
to
be
consistent
so
that
people
using
these
components,
don't
accidentally
think
they're.
D
Turning
on
or
off
a
feature
when
the
lever
they're
using
is
actually
inert,
and
we
also
want
to
give
people
warning
for
at
least
a
release,
ideally
two
releases,
that
a
feature
is
now
like
graduated
and
if
they
were
explicitly
enabling
it
before
give
them
a
heads
up
that
you
don't
need
to
explicitly
enable
it
it's
on
all
the
time,
and
you
should
stop
setting
this
option
so.
D
Yeah
this
this
came
up
as
I
was
we're
see.
Net
was
scanning
through
all
the
gates
that
we
own
and
we're
wondering
like.
Why
are
these
still
here?
Can
we
just
get
rid
of
them
and
realize
they're
the
mechanics
around?
It
are
unclear
and
I
started
on
a
pr
and
then
I
realized
it
was
even
less
clear,
and
so
here
we
are.
D
There
are
a
few
normal
single
field,
edition
proposals
or
approved
designs
that
are
in
implementation
phase.
You
can
see
those
in
the
api
review
project
if
you
are
interested
and
then
I
wanted
to
call
out
two
beta
apis
that
are
on
the.
D
Ticking
time
bomb
list
of
beta
apis
that
have
not
made
progress
to
gaa
right
now.
These
are
scheduled
to
be
deprecated
in
122
and
removed
in
125,
and
so
both
of
them
have
associated
projects
and
kepts
and
issues.
D
But
now
is
the
time
to
make
progress
on
these,
so
I
have
pinged
the
owners
of
those
and
will
ping
them
again,
but
just
for
visibility.
These
are
the
two
long
language
apis
that
I
am
most
eager
to
see
make
progress
now,
so
we
don't
cut
it
close
in
the
122
to
125
timeframe.
A
You're
doing
the
same
health
check
with
node,
you
did
already
so
that's
the
pdb
and
with
apps.
A
Okay,
well,
the
crown
job's
one.
You
want
us
to
gap,
so
that
would
be
a
valuable
thing
to
do
there
if
you're
not
already
in
working
on
that.
A
All
right:
well,
is
there
anything
else
anybody
wants
to
discuss
or
we'll
go
back
to
going
through
our
health
check.
E
Well,
the
only
other
thing
that
came
up
was
dockashim
deprecation.
Does
anybody
have
ideas
or
thoughts
around
how
we
are
able
to
get
rid
of
docker
in
a
fashion?
E
We've
talked
about
this
many
times
in
many
different
things.
I've
started
an
email
thread.
I
have
a
pr
for
just
starting
the
clock
and
if
you
have
any
thoughts,
we
can
follow
up
there
just
wanted
to
make
sure
that
you
all
heard
from
me
here.
C
All
right
so
yeah,
let's
go
back
to
our
sheet
I'll
share
again.
C
I
think
the
next
item
here
this
is
another
enhancement,
sub
project.
C
Okay,
we're
having
a
big
conversation
about
this
at
the
moment,
winding
down
the
working
group
and
that
will
be
discussed
at
the
next
sig
release
meeting
with
the
presentation
from
the
working
group
folks.
So
I
guess
that
one's.
A
I
To
phase
three
was
identifying
optional:
ga
api,
okay,
yeah,
okay,.
I
Programmatically,
that's
just
we
don't
so
that.
A
Why
don't
we
frantically
create
a
separate?
Well,
it's
fine!
I
almost
wonder
if
that
will
separatist
you
right,
like
you
have
this
done
like
because
that's
gonna
require
us
agreeing
on
what's
optional
beyond
just
that.
What
we
do
in
I.
D
Would
be
well
to
tackle
that
as
a
separate
issue,
it
was
requested
to
make
it
part
of
this
issue.
Okay,.
B
D
Not
honestly
right
right,
I
think
the
issue
is
that
some
things
can
accidentally
be
made
part
of
conformance.
So
our
back
is
the
quintessential
example
where,
in
all
of
the
ci
clusters,
we
run,
they
have
our
back
enabled,
and
that
is
a
reasonable
way
to
manage
permissions.
And
so
some
tests
need
to
grant
permissions,
and
so
they
started
granting
our
back
permissions,
which
so
it's
it's
in
conformance
as
a
side
effect.
So
preventing
accidents
like
that
is
what
we're
wanting
to
do.
A
A
B
A
Well,
this
is
a
production
readiness,
sub
project
which,
like
the
I
think
this
is
all
basically
merged,
so
do
we,
I
just
assign
it
to
me
and
I'll
go,
make
sure
that
we've
actually
tied
up
all
the
loose
ends
to
make
it
the
policy,
but
it
should.
H
C
C
K
C
K
The
changing
the
default
to
off
for
the
previous
alpha,
well,
the
previous
behavior.
That
was
never
intended
to
go
in,
but
still
exposed,
and
so
we
might
extend
that
period
as
necessary.
B
C
B
A
What
we
do
is
we
include
the
yaml
of
all
conformance
tests.
What
are
they
asking
for
here,
like
a
pretty
version
of
that
there's
like.
A
A
H
I
know
it's
not
actively
being
worked
on
it.
It
probably
needs
to
be
discussed
with
the
cnc
a
little
bit
more.
They
have
contractors
who
have
been
trying
to
keep
it.
H
They
sort
of
try
to
keep
like
a
separate
document
up
to
date
over
in
the
kate's
conformance
repo
in
cncf,
and
this
was
a
desire
to
maybe
not
have
them
have
to
do
that
because
they
continually
fall
out
of
date.
It's
like
the
most
recent
docs.
H
H
C
Cncf,
okay,
who
wants
to
check
on
that
john
did,
but
also
I
can't
see
who
else
is
from
my.
C
A
Now
dns
auto
path
would
be
a
sig
network
thing.
I
don't
think
architecture
involved.
C
C
April
but
I
guess
oh
it's
in
the
new
to
do
so
I'll
just
strike
this
one
from.
C
It
seems
to
go
through
a
lot
of
comments
and
the
last
comment
was
from
the
creator
itself
themselves
and
it's
not
clear
if
we
agree
with
that.
C
A
B
K
C
Okay,
oh
this
was-
I
was
just
noting
here
that
this
is
good,
like
we
have
a
very
recent
activity
on
some
of
these
items
like
old
items,
so
you
can
just
see
them
all
in
one
place
to
know
that
there's
been
something
happening
on
these
specific
items.
E
Yeah,
it
is
stalled
pending
work
and
signal.
B
C
So
that's
the
short
of
it
stalled
pending
signaled
efforts.
Okay,.
C
Then
there's
a
couple
really
small
dock
fixes,
so
there's
a
couple
from
this
person:
they
they
didn't
actually
sign
the
cla.
So
I'm
just
wondering
can
somebody
like?
Would
it
be
a
norm
to
have
somebody
else?
Just
like
open
up
make
the
change
and
then
close
this
existing
item
because
they
haven't
responded.
A
Yeah
somebody
else
could
fix
it
if
they've
disappeared,
if
it's
especially
if
it's
simple,
but
it
looks
like
it's
a
performance,
documentation
thing
so
just
make
sure
it's
assigned
to
the
conformance
sub
project
and
on
our
board
and
we'll
get
to
it
eventually.
I
think.
C
C
F
C
C
C
C
Yeah
exactly,
and
it
probably
never
will
be
right,
you
know
it'll
be
like
so
this
is,
I
think,
the
reality
to
consider
like
there's,
and
this
is
a
conversation
I
started,
I
have
in
an
api
machinery
and
on
some
contribution
contrabex
today.
It's
like
do
you
want
to
have
like
reviewers,
who
are
really
doing
a
lot
of
high
intense
high
intensity.
Work
also
have
to
take
ownership
of
reviewing
these
typos.
B
D
Same
files
that
do
have
important
things
in
them
and
so,
like
the
the
approvals
like
you
can't
easily
just
sort
of
batch
them
and
say:
oh
yeah,
this
all
looks
fine
like
you
actually
need
to
check
and
make
sure
okay,
this
isn't
changing.
D
Way,
it's
just
fixing
a
typo,
so
I
think
that's
where
these
things
normally
get
stuck
and
it's
hard
to
match
sort
of
in
a
sweeping
way
across
components
or
like
I'm,
going
to
fix
this
typo
in
every
design.
But
in
the
process
I
touched
like
things
owned
by
five
different
cigs,
with
different
approval,
records
and
stuff.
C
E
I
I
think
it
is
fine,
as
it
is
laurie
we,
we
expect
the
bot
to
pick
it
up
and
close
things
out.
Okay,
if
they
are
not
responding,
direct
responded
and
didn't
respond
back
to
that.
After
that,
you
know
it's:
okay,
okay,
you
know
at
some
point
here
to
say:
hey,
I'm
not
going
to
clean
everything
up
right.
C
D
F
A
C
C
C
E
A
Okay,
thank
you,
everybody
and
have
a
great
weekend
and
week
with
you
in
a
couple
weeks.
Bye.