►
From YouTube: 20191024 SIG Arch 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
B
A
B
It's
not
the
actual
time
isn't
specified.
Yet
it
has
just
been
a
couple
of
email
exchanges
right
now,
so
the
Bulls,
the
goals
here,
are
really
to
read
through
identify
or
scan
through
the
titles
of
new
tabs,
identify
ones
that
may
have
architectural
significance
or
whether
our
are
potentially
controversial,
read
them
through
review
them,
potentially
bring
them
here
to
the
larger
group
or
the
mailing
list.
They
need
that
sort
of
discussion,
I,
think.
C
The
biggest
part
of
this
is
that
it
will
shame
the
small
number
of
people
who
signed
up
who
have
not
even
meeting
as
many
as
they
thought
they
should.
It
will
shame
us
into
reading
them.
So
so,
if
you're,
if
you're
not
in
the
invite
list,
it
just
means
you
you're
doing
a
good
job.
So
we
excluded
you
intentionally
Jordan
I,.
E
Hey
everyone
so
I'm
Alejandro
Jorge.
So
today,
so
in
the
technical
dead
area
we
James
Antonio,
my
young
and
myself
have
been
meeting
the
DOS
far
we
have
a.
We
had
two
meetings
to
started,
start
organizing,
in
which
we
started
organizing
this
project.
If
you
want
to
catch
up,
I
added
a
link
to
the
meeting
notes
down
today
to
the
meeting
notes
for
all
the
way
where
we
document
everything
that
we
have
been
doing
discussing
and
the
like
do
in
the
middle
notes.
E
You
will
also
find
a
link
to
the
technical
tech,
research
project
or
a
project
board
which
is
on
the
kubernetes
organization,
page
those
right.
Now
we
are
planning
to
meet
every
week
on
Wednesdays
at
1:30
US
Pacific.
If
anyone
wants
to
join,
please
say
so
in
the
city
architecture
it's
like
channel
and
somebody
will
notice
and
write
right
now
in
the
one
managing
the
invites
so
I'll
send
the
invite
to
whatever
you
may,
whatever
you
want,
you
decide
right
now.
We
are
starting
to
a
were
starting
to
look
into
all
the
issues
in
kubernetes.
E
We
are
looking
for
any
feature
requests
or
any
complaints.
I
have
received
a
lot
of
comments,
a
lot
of
vacuum
for
my
by
users
or
by
the
community.
We
are
looking
into
anything.
That's
that's
really
all
and
the
we
are.
We
are
focusing
one
on
trying
to
discover
why
certain
a
why
why
we
accrued
so
much
a
technical
depth
in
certain
areas
and
number
two,
once
we
actually
have
a
once,
we
actually,
this
have
a
better
understanding
of
all
the
things.
I
need
work
on.
E
We
want
to
shed
some
light
in
them
and
work
with
Sagarika,
texture
and
cichlids
to
moving
forward
right
now.
We
are
essentially
an
experimental
trial,
so
for
the
Wii
for
the
next
couple
weeks,
two
weeks
we're
going
to
see
what
data
we
we
gather
and
then
based
on
that,
we'll
see
how
to
move
this
whole
effort
forward.
F
Yeah
I
think
the
the
idea
is
to
look
at
issues
bugs
or
things
that
the
wider
community
has
been
asking
for,
or
kind
of
figure
out.
The
pain
points
or
repeated
repeated
wants
from
the
community,
which
we
have
kind
of
either
failed
to
notice
or
failed
to
address,
because
either
that
was
not
part
of
our
six
priority
list
or
or
the
community
itself
didn't
pony
up
and
write,
wrote
a
gap
to
fully
clarify
what
they
wanted.
So
basically
kind
of
gather
issues
around
those
topics
and
figure
out.
F
D
A
A
D
A
B
All
right,
John,
yeah
I,
just
wanted
a
quick,
quick
reminder
here.
We
we
are
starting.
This
PR
put
up
production
readiness,
review,
islet
team
to
kind
of
exactly
how
we
do
this
and
put
together
the
questionnaire
and
start
the
sort
of
implementation
of
the
first
version
of
the
chat
we
we
have
take
off
a
couple
weeks
ago
now,
I
sent
out
a
sign-up
form.
I
we
have
half
a
dozen
of
people,
so
it's
got
some
momentum
behind
it,
but
anybody
who's
interested
sign
up.
Obviously
anybody
can
come
later
to.
G
B
A
A
H
A
We'll
see
up
to
four
the
next
time
unless
I
want
to
once
to
give
up:
okay,
Oh
Bucky,
that
guy
review
stuff.
So
looking
at
the
board,
these
are
the
requested
reviews.
There
are
a
few
that
have
not
been
picked
up,
I
reached
out
to
the
reviewers,
for
those
one
is
not
prioritized
for
that
project
right
now.
This
one,
the
pod
affinity,
I,
think,
is
the
only
one
that
is
actually
blocked
on
a
peer
review
and
as
a
priority,
so
I
reached
out
of
the
API
reviewer
will
try
to
get
movement
on
that.
A
I
B
Think
we
decided
not
to
deprecated
I,
think
you
know
she
is
still
open,
but
what
we
got
when
we
put
an
issue
on
saying
we
wanted
to
duplicate
it.
We
did
get
some
feedback
that
it
isn't
used
by
some
folks,
and
you
know,
while
it
doesn't
have
anything
backing
it
typically
I'm,
not
sure
that
we
have
really
the
justification.
We're
deprecating
that
yeah.
A
The
so
the
v1
and
extensions
versions
predated
any
concept
of
like
subdividing
resources
among
groups
and
our
actual
policy
on
deprecation.
So
there
is
some
kind
of
wiggle
room.
Is
the
right
word,
but
like
we
kind
of
have
to
figure
out
what
to
do
with
things
in
those
groups
specifically,
but
for
things
like
storage,
where
we
had
written
the
deprecation
policy
and
in
started
this
version,
we
need
to
follow
the
policy
more
closely.
J
A
J
My
feeling
is
the
way
the
rules
are
written
are
very
clear
if
we
want
to
rewrite
the
rules.
That
is
something
we
can
consider,
but
I'm
not
doing
it
again.
I
wrote
the
last
one.
It
was
incredibly
painful
to
get
to
language
that
I
thought
was
clear
enough
that
we
could
point
to
it
and
say
not
allowed
to
do
that
in
this
case,
I
think,
as
I
said
in
the
thread
and
I
commended
Michelle
for
stirring
up
the
hornet's
nest,
I
think
that
the
way
we're
versioning
api's
at
this
point
is
a
is
a
mess.
J
A
K
E
K
L
Any
just
didn't
just
in
practices
like
I've
started
to
get
is
like
you
can
shift
side
and
some
of
the
projects
I've
seen
like,
as
you
start,
to
get
into
the
v2
territory
the
amount
of
churn
you
caused
by
bumping.
Everything
is
extremely
high
and
does
it
feel
worth
it,
whereas
going
and
selectively
coming
up
with
you
know,
new
versions
of
a
resource,
we're
justified
is
a
little
bit
more
tactical,
like
this
kind
of
gets
into
that
v1
beta
1
is
significantly
different
from
v1
in
terms
of
perception.
V1
and
v2
are
also
substantially
different.
L
C
L
L
Promoting
them
causes
a
cost
on
every
downstream
consumer
across
the
board
like
starting,
you
know
timelines
of
changing
the
objects
you
have
to
change
all
of
your
objects.
People
who
have
clients,
and
so
I
think
the
sparseness
starts
is
like
the
first
phase
of
when
you're
trying
to
come
up
with
a
reason
you
have
to
make
a
change,
but
you
can't
do
it
within
the
group
version.
If
you
force
everybody
to
change
everything
to
consume
that
one
thing,
I
think
you're
getting
into
a
lot
of
additional
work
for
very
little
benefit.
Now.
I
agree.
L
There
is
a
confusing
thing,
which
is,
if
you
do
v2
of
1
you're
not
going
to
ask
I
haven't
seen
that
be
as
much
of
a
problem
as
the
continual
revs
of
bumping
versions
like
v1
beta
1,
2
v1
for
a
large
number
of
our
groups
was
incredibly
invasive
to
the
entire
ecosystem.
Like
I,
see
PRS
on
other
repos
like
cockroach
DB
was
one
I
saw
the
other
day
where
they're
bumping
to
v1
apps,
and
it's
a
disruptive
change
that
they
have
to
spend
time.
J
On
the
one
hand,
if
it's,
if
we're
changing
one
resource
and
all
the
others
are
just
being
carried
forward,
then
the
only
change
you
need
to
make
is
in
your
client,
like
which
version
you're
going
to
consume,
escape
if
they're,
schematically
and
semantically
identical
right.
If
they're
actually
different
in
a
meaningful
way,
then
they
probably
should
be
a
new
version
anyway.
But
it's
that
aside,
I,
don't
have
the
whole
conversation
here.
If
we're
going
to
say
that
deprecation
applies
to
individually
versioned
resources.
J
J
We
can
rewrite
or
retool
parts
of
the
deprecation
policy
to
be
very
clear
that
in
doing
that,
versioning
covers
individual
resources,
and
then
we
can
say
that
deprecating
and
removing
something
from
an
old
room
from
an
api
group
is
appropriate.
At
that
point,
though,
I
question,
but
I
have
lots
of
questions,
but
we
can.
We
can
find
the
right
words
in
there
to
make
it
clearer
that
that's
the
case.
I
don't
have
a
problem
with
that.
It's
just
not
what
it
says
today,
yeah.
A
And
I
think
I
would
try
to
figure
out
like
what
the
implications
of
every
like
there
are
a
few
directions
we
can
take.
We
could
take
what
you're
saying
is
the
current
stance
where
you
wait
until
everything
is
ready
to
be.
Everything
has
lived
out
the
deprecation
period
in
a
group
given
group
version
and
then
turn
off
that
poll
group
version
and
the
cost
there
I
guess
is
we
serve
things
like
individual
resources
that
we
could
have
turned
off
earlier.
J
Clearly,
some
fellow
who
jumped
on
our
mailing
list
very
very
early
on
and
said
you
guys
are
doing
it
all
wrong.
This
guy
is
doing
it
all
wrong.
You
should
version
every
resource
individually
and
that's
just
what
they
are
I
said:
you're
crazy,
get
out
of
here
and
now
here
we
are
four
years
later:
I
hope
that
guy's
not
on
this
meeting,
because
I
remember
his
name,
but
if
you
migrate,
what
we
are
talking
about
is
every
kind
is
version
independently
and
that's
I
mean
like
am
I
misinterpreting
the
sometimes.
A
J
Sorry
it
used
to
be
you.
Could
the
historical
argument
was
well,
then
it
should
have
been
in
a
different
group,
because
a
group
was
supposed
to
be
meaningful,
like
that's
what
I
called
it
a
group,
but
if
what
we
really
believe
with
our
20/20
hindsight
that
groups
actually
aren't
that
meaningful
that
individual
resource
persons
are
I'm
totally
cool
with
that
we
should
adjust
our
language
and
we
should
adjust
the
rules.
The
rules
talk
about
removing
API
versions.
They
do
not
talk
about
removing
API
resource
versions.
I
Although
I
agree
with
the
sentiment,
I
would
hope
that,
just
because
we
have
so
much,
you
know
code
written
both
internal
and
external.
Now
that,
if
we're
gonna
make
any
of
these
types
of
changes
would
be
like
an
API
v2
schema
idea,
because
we
already
have
people
who
have
mountains
of
code
written
against
this.
J
D
D
A
Very
little
I
mean
they're,
the
ripples
were
big,
but
it
was.
The
deprecation
period
was
generous
for
those,
as
there
was
I
did
not
see
any
pushback
related
to
all
of
the
apps
and
workloads
resources,
getting
deprecated
and
no
longer
being
served,
but
ingress
still
being
served.
So
they
I
saw
no
issues
with
one
resource
remaining
in
that
version
and
the
others.
Not
all
the
issues
were
just
around
right,
which
workloads
API
I'm
using
now
and.
A
Know
the
FEMA
changed
for
some
resources
and
the
requirements
for
like
specifying
labels
and
selectors
changed
for
others.
So
they
were
converging
steps
required,
but
that's
not
related
to
doing
a
whole
version
at
once
or
individual
resources.
So
I'll
take
a
stab
at
seeing
what
it
would
take
to
express
that
and.
J
J
A
In
addition,
like
the
examples
for
a
developer,
it's
like
what.
What
should
you
do
if
you
want
to
remove
a
feel
like
how?
How
can
you
do
that?
How
many
versions
you
have
to
do
it
over
and
round-tripping
and,
like
we
kind
of
hand
away
at
some
of
those
things,
and
we
say
things
that
you
may
not
do,
but
we
don't
actually
give
great
guidance
about
how
someone
could
and
should
yeah.
J
We
tried
to
keep
the
deprecation
stuff
like
relatively
to
the
point
and
not
turn
it
into
a
book
so
that
somebody
could
reasonably
look
at
it
and
internalize
the
rules.
But
if
we
need
to
do
more
examples,
that's
fine
too,
okay
and
you,
you
seem
to
be
the
vault
of
how
to
do
X,
Y,
&
Z
within
the
API
machinery,
so
I'm
always
consulting
you
when
I
can't
remember
what
the
process
is
anyway,.
A
J
A
H
H
So
far,
we've
been
measuring
operations
and
that's
the
list
of
all
endpoints
there's
another
word:
we've
been
calling
it,
but
it's
not
a
great
picture
for
everything.
As
we
add
more
and
more
tests,
sometimes
we'll
remove
things
that
add
things
that
have
an
impact.
For
example,
we
had
a
really
good
PR
that
sped
up
our
tests
runs
speed
wise
by
getting
rid
of
the
the
cleaning
up
of
namespaces,
but
those
that
that
that
have
during
the
namespace
cleanup
was
called
by
every
test.
H
So
when
we
stopped
using
that
code
in
that
way,
we
actually
dropped
coverage
quite
a
bit
and
trying
to
make
sure
that
what
we
are
measuring
on
is
meaningful,
so
I
wanted
to
make
sure
we
had
a
agreement
on
what
the
numerators
and
denominators
were
for
increasing
our
percentages
of
coverage.
So
the
only
thing
we
currently
have
fully
agreed
on
I
think
is
operations.
H
I
just
wanted
to
make
a
quick
check
that
the
the
definition
of
of
that
as
we
go
through
down
the
numerators
and
denominators
of
conformance
coverage,
but
with
results
to
the
to
the
PR
bot
that
will
be
blocking
for
the
suggestions
that
be
blocking
for
all
PRS
that
are
in
KK
is
defining
a
back
to
the
PR,
the
list
of
specific
numerators
and
denominators
that
are
added
or
removed.
So
if
we're
increasing
the
numerators
I
think
that
increase
in
the
denominators
at
the
target,
then
I
think
that's.
D
A
H
I
In
TLDR
was
that
we
have
api's
that
should
have
been
in
conform,
should
have
had
conformance
test
written
for
them,
and
the
overall
API
coverage
dropped
it
over
time.
We've
been
noticing
this
across
releases
like
hippies,
been
reporting
out
to
the
group.
They
have
API
stamp
reading,
they're,
seeing
a
drop
in
coverage
and
we
try
to
inspection.
We
figure
out
what
the
API
is
arm
and
we
determined
what
the
API
should
be
doing.
I
They
are
clearing
the
API
is
that
we
should
have
conformance
test
for,
and
this
is
kind
of
against,
the
policy
that's
listed
down
in
the
caps,
so
we
wanted
to
enable
a
PR
blocking
jump,
and
so
we
hit
the
road
up
baby
proposal
to
have
these
very
conservative
means
by
which
we
can
start
to
approach.
This
and
feedback
is
solicited,
but
I
think
we
have
policy,
we
don't
have
enforcement,
so
this
is
a
method
of
getting
us
towards
that
enforcement.
I
I
H
A
Yeah
I'll
throw
a
link
into
the
section
as
well
thanks.
That
was
really
good
yeah.
It's
a
this
is
already
something
that's
part
of
performance
like
the
conformance
policy
like
you're
not
allowed
to
use
beta
api's,
and
there
are
multiple
issues
that
have
been
looking
through.
Logs
of
conformance
test
runs
and
saying:
hey!
Look
at
all
these
beta
things
that
are
getting
called,
and
so
this
is
just
a
proposal
to
like
the
clearest
way
to
demonstrate
that
that
stuff
is
not
required
is
to
turn
it
off
and
then
pass
compromise.
A
Every
night
I
think
it
can.
It
doesn't
have
to
hit
a
release
boundary
exactly
if
you
look
at
the
cap,
I
got
the
Lincoln
later.
The
first
step
is
just
identifying
what
beta
things
currently
are
required,
either
by
the
set
of
tools
or
by
the
conformance
tests,
and
then
putting
things
in
place.
Pre
submit
to
keep
us
from
adding
new
dependencies
on
beta
stuff.
So
the
sooner
we
get
that
in
place,
the
better
it
doesn't
have
to
sync
up
with
our
release
boundaries
and
then
having
issues
for
all
of
the
individual
beta
dependencies.
Some.
A
A
H
Goodlove
help
with
that
Jordan
are
less
our
last
part.
There
is
actually
making
sure
everybody's
clear
on
what
the
current
suggested.
Numerators
and
denominators
are
operations
being.
If
a
path
has
doesn't
have
beta
or
alpha
in
it,
then
it's
considered
GA
and
that's
for
operations
which
are
separate
from
fields
and
then
for
fields.
It's
it's
whether
or
not
the
object
itself
is
alpha
or
beta,
so
that
it's
GA,
that's
we
concerts
VGA
and
weight
and
whether
we
should
go
all
the
way
down
to
the
stringer
integer.
H
H
H
A
H
D
G
Yeah
yeah
right,
my
question
was
basically
just
trying
to
get
ignorance
of
where
there
are
features
that
go
to
GA,
that
don't
compact
again,
these
are
facing
API,
and
so
my
plugins
or
no
apology
or
a
lot
of
them
are
along,
say,
exotics,
but
the
more
how
individual
components
interact
that
are
back
like
50
dates
that
don't
actually
impact
the
image
in
his
jaw
and
how
he
wanted
to
pose.
And.
G
My
takeaway
from
the
discussion
was
now
we're
not
truly
changing
our
policy
in
any
way
or
even
a
conformance
is
still
up
API
level
and
we
work
necessarily
requiring
performance
tests.
For
these
other
points
that
we're
building
and
that's
not
to
say,
we
don't
have
to
see
your
informants
fear
on
some
of
this.
You
can
get
difficult
in
our
available
infrastructure.
I
A
concrete
example
here
that
we
use
is
typically
storage.
We
want
to
basically
have
some
level
tests
that
verify
that
your
storage
provider
integration
meets
a
certain
criteria
against
the
API
yeah,
but
we
still
have
yet
to
do
that
work.
So
we
have
not
taken
it
on
so
we
don't
address
it
yet
inside
of
performance,
but
we
do
plan
to
eventually
end
all
these
things.
We've
been
the
planet
record
for
a
long
time,
but
it's
just
everything
we
do,
because
we're
such
a
small
group
rolls
at
a
glacial
pace.