►
From YouTube: CNCF SMI Community Meeting 2020-04-01
Description
CNCF SMI Community Meeting 2020-04-01
A
B
A
I'm
Stephan
Pradhan
I
work
for
weworks
and
SM
I
expect
maintainer.
On
general.
Today
we
have
talked
about
celebrate
the
cnc
of
membership,
talk
about
the
versioning
of
the
api,
how
you
want
to
do
that
and
yeah.
We
have
a
couple
of
more
issues,
a
lot
of
issues,
actually
yeah
governance
and
the
project
board.
I.
Think
it's
also
a
good
topic
to
have
anyone
go
first
membership
and
what
that
implies.
Welcome.
C
Of
that
actually
means
that
you
have
a
neutral
space
to
be
able
to
grow
in
towards
being
whatever
it
is
that
you
want
to
hear
we're
here
to
help
we're
here
to
be
able
to
make
sure
that
you
get
what
you
need
to
be
able
to
be
successful
in
this
and
I
know.
There's
a
lot
of
other
questions
around
like
logistics
and
pieces
further
down,
but
we
can
get
to
those
in
the
agenda,
but
welcome.
A
Yeah
I
think
that
we
have
two
approaches
to
this
I
think
we
should
at
least
now
in
the
alpha
stage.
We
should
list
all
the
API
versions
that
we
currently
have
and
I
think
it's
also
important
to
specify
what
implementation
works
with
what
version,
for
example,
I
think
our
DS
on
alpha
one,
maybe
others
are
on
on
other
versions
and
I-
think
it's
for
someone
that
wants
to
integrate,
let's
say
through
SMI,
with
with
service
mesh
or
other
operators.
A
List
all
the
all
the
versions
consolidate
them
under
alpha
4,
or
something
like
that,
and
every
time
we
make
a
change.
We
bump
abortion
all
of
them.
In
that
way,
people
don't
have
to
worry,
have
a
know,
HTTP
routes
alpha-2.
Does
it
work
with
a
traffic
split,
alpha
2
or
alpha
3?
The
answer
is
alpha,
3
and
so
on.
A
B
Long-Lived
branches
that
would
diverge
from
each
other
I
have
many
concerns
because
long
live
branches.
Is
there
a
way
we
could
have
like?
You
know,
a
compatibility
matrix
that
we
maintain
either
on
the
web
page
or
in
a
markdown
file
and
github
that
people
could
look
at
at
a
glance
and
see
this
is
the
current
compatibility
I
just
worried
that
if
we
have
a
whole
bunch
of
branches,
people
will
still
need
a
chart.
I'm.
D
Telling
a
guy
I
only
have
one
ask,
and
that
is
kind
of
weird
sounding
asking
Buddhists
and
the
negative
example
I
don't
want
to
say
that
this
is
like
in
bad
practice.
But
if
I
look
at
client
go
I,
always
although
I
wrote
a
book
about
it,
I
always
get
confused,
trying
to
figure
out
what
tack
abusing
I'm
sorry.
But
so,
if
we
can
keep
it
as
simple
as
possible,
do
it
once
properly
and
keep
the
matrix
as
far
as
possible
to
not
confuse
people.
That
would
be
awesome.
D
A
C
A
A
E
I,
don't
think
you
have
to
do
a
release,
but
but
I
think
there's
definitely
I
mean
if
we
can't
backtrack
where's,
there's
definitely
being
there
are
definitely
changes
which
are
happening.
All
I'm
kind
of
really
suggesting
is
that
we
we
bundle
changes
into
a
you
know
we
don't
release
before
or
something.
D
D
So
you
know
if
you
want
to
use
it
feel
free
to,
but
we
do
not
make
any
guarantees
that
you
will
see
face
up
to
a
bet
or
whatever,
and
once
it's
j
we
kind
of
commit
and
say
we
do
not
change
the
API
anymore,
and
if
we
then
do
something
changing,
it
would
definitely
get
a
new
API
like
major,
two
or
whatever
I
think
there's.
At
least
that
was
how
I
interpreted
Nick.
B
So
I'm
going
to
say,
quick
time
check
since
we're
gonna,
try
a
condensed
version
of
this
meeting.
We're
trying
that
today
and
we'll
see
how
that
goes.
But
since
we've
allocated
1/3
of
our
time
so
far
and
we've
talked
about
this
item-
I'm
gonna
point
people
to
the
issue
because
I
think
that
there's
a
lot
of
detail,
we
could
dive
into
here.
So
people
who
have
opinions
about
this,
that's
the
issue
to
go,
and
hopefully,
by
the
next
meeting.
Everyone
will
have
put
their
comments
on
the
issue
so
that
sound
reasonable.
A
Should
we
talk
about
the
governance
documentation,
so
we
have
a
government
governance
doc
right
now
that
states
that
maintainer
will
be
removed
after
three
months.
If
he's
not
active
I,
don't
know
what
active
means
I'm
guessing
it's
not
only
about
writing
some
new
spec.
It's
also
about
responding
on
issues.
D
A
F
Yeah
I
think
the
only
thing
in
this
to
fajn
is
maybe
what
active
means
and
specific
with
the
cleanup
I
did.
I
did
actually
reach
out
to
everybody
and
they
specifically
said
I
guess
I
could
have
had
them
comment
on
an
issue
I
reached
them
by
a
slack,
but
I
did
ask
Suraj,
you
know,
are
you
willing,
and
he
said
no,
please
put
me
in
emeritus
so
but
yeah
I
mean
we
could
say
what
what
defines
active.
Have
you
been
to
a
meeting?
Have
you
contributed?
Have
you
opened
an
issue
we
could?
F
G
Want
to
make
things
too
complicated,
but
I
think
we
should
take
it
a
step
further
and
say
hey.
This
is
what
documents
specifically,
what
a
maintainer
responsibilities
are
and
then
the
definition
of
active
will
be
more
clear
in
that
you
know
they
have
not
been
doing
their
duties
for
X
amount
of
time
and
number
of
responsibilities
might
be
helping
with
issue
triage
attending
meetings,
resolving
issues.
So
many
people
realize.
D
D
If,
if
something
goes
right
and
then
it's
like,
you
know
what,
if,
like
you
know,
I've
been
on
the
road,
our
family
business,
whatever
I
still
want
to,
but
they're
just
after
three
well
immediately
get
kicked
out
or
do
I
have
a
way
to
appeal
and,
like
you
know
we,
if
we
do
it
properly,
you
know
listing
all
the
responsibilities.
Then
you
know
what
does
it
mean
after
two
months?
You
get
a
warning.
You
have
a
chance
to.
You
know
pick
it
up
again
or
like
how
does
it
actually
play
out
all
the
ways?
C
A
B
G
A
F
E
B
B
Didn't
sign
off
on
the
issue
you
were
like
took
care
of
it
and
I.
Look
at
the
issue
and
I'm
like
github,
doesn't
agree,
so
I'll
drop
the
link
in
the
chat
but
yeah
so
like
we
don't
want
to
use
anyways
logo
if
they
haven't
said
we
can
use
it.
So
it
co,
because
members
of
this
community
wrote
the
adapter
by
the
way.
If
you
are
interested
in
working
on
the
sto
adapter.
G
A
A
A
G
A
G
A
G
A
B
B
I'm,
not
it's
not
clear
to
me
if
anyone
has
anything
in
the
old
slack
that
they
really
really
want,
but
I
feel
like.
We
should
pick
a
time
that
we're
going
to
either
archive
or
delete,
and
then
let
people
you
know
decide
to
do
what
they
want
to
do.
Does
anyone
have
any
strong
feelings
about
that
was
why
I
brought
it
up.
F
H
B
Well,
okay,
so
we'll
probably
do
that
in
like
the
next
month
we
already
set
them
general
channel
to
read-only.
So
but
I've
just
noticed,
there's
like
395
people
in
that
slack
I
guess
some
of
them
are
already
in
the
stands
you
have
to
suck,
but
they
aren't
in
our
channel,
so
maybe
go
out
and
reach
out
to
the
people
you
think
want
to
be
in
our
channel.
B
Yes,
so,
basically
anything
that's
on
the
q1
project
board.
Still,
if
you
want
to
go
click
on
and
write
things
on
it,
if
you
care
about
those,
otherwise
I'm
gonna
try
to
get
those
ones
resolved
or
moved,
and
if
you
think
things
should
be
on
the
bored
for
q2,
we
haven't
put
a
ton
of
formality
into
what
goes
on
a
project
board
versus
just
the
main
thing
that
I
did
was
I
moved
all
the
stuff
from
the
SM
icepack
project
board.
B
Now
that
we
have
an
organization,
we
can
have
an
organization-wide
project
board
and
you
can
add
cards
from
any
of
the
repos,
so
that
is
like
open
to
people's
ideas
of
how
they
want
to
organize
it.
I
don't
really
want
to
be
heavy-handed
with
it.
I
just
want
to
make
sure
that
anything
that
we
care
about.
We
are
moving
forward
on.
So
maybe
that's
a
discussion
topic.
You
know
what
we
want
to
move
forward
on,
specifically
like
in
q2,
could
be
a
discussion
topic
for
the
next
meeting.
B
We
did
skip
by
the
way
there
were
a
bunch
of
open
pull
requests
and
we
did
skip
the
discussion
of
it
and
I.
Don't
think
that
person
showed
up
to
this
meeting,
but
if
they
did
and
they
are
just
under
a
different
name,
the
pull
request
to
add
support
for
routes
is
actually
something
that
I
was
not
positive.
I
saw
that
I'm
Stephan.
Maybe
you
can
address
that
because
you
did
the
most
review
of
that
code,
but
is
that
something
that
changes
the
spec
significantly
to
the
point
where?
B
B
H
Yeah,
to
give
a
background,
we're
trying
to
get
everything
in
link.
Rd
multi-tenant,
as
my
metrics
would
give
us
all
of
the
read
multi-tenancy.
So
you
just
have
coup.
Grantees
are
back,
but
a
lot
of
that
was
missing
and
so
alex
has
been
working
at
updating
the
spec
to
support
all
the
existing
liquor
d
functionality
routes
as
the
biggest
change
their
there's,
not
anything
necessarily
changing
to
the
spec.
It's
mostly
just
additive,
but
it's
definitely
something
that
we
should
be
comfortable
about.
Moving
forward
on
this.
H
H
An
outstanding
piece
is
updating
the
documentation
inside
the
spec
repo
to
go
and
give
a
feel
for
what
use
cases
this
is
and
what
the
responses
are
and
how
what
we
actually
intend
from
a
support
perspective
I,
don't
think
it
should
block
anything,
but
it's
definitely
provides
a
discussion
point
which
is
I,
think
we
should
have
a
document
written
up.
That
explains
the
checklist
for
how
to
propose
a
change
to
the
SMI
spec
itself
and
what
we
expect
to
get
out
of
it.
A
Yes,
so
the
matrix
changes
got
proposed
in
the
SDK
as
a
client
go
implementation
or
go
line,
implementation
for
SMI
and
afterwards
we
try
to
push
Alex
and
say
hey.
This
should
be
documenting
in
aspect.
First,
then,
implementing
the
SDK
and
she's
trying
to
do
that
right
now,
I
reviewed
the
changes
in
SDK
and
also
the
changes
to
the
spec
in
the
current
state.
The
coracoid
looks
good
to
me.
I
would
prove
it,
but
we
need
another
look
at
it
for
someone
else
and
that's
it.
We
should
move
forward.
A
There
were
a
couple
of
things
like
the
version
wasn't
bombed
everywhere.
It
was
only
in
the
header,
the
examples
or
were
on
the
old
version
and
yeah
I
miss
some
of
those
I
realized
later
I
asked
Alex,
hey,
please
make
hold
changes
like
it
should
and
then
Alex
realized
okay,
but
we
also
need
the
old
version,
and
this
is
how
we
got
the
versioning
discussion
like
I,
managed
to
add
all
the
old
versions
in
the
SDK.
So
now,
whoever
uses
the
SDK
can
use
all
the
versions
as
well.
A
So
it's
easier
to
upgrade
inside
your
own
implementation
from
one
version
to
another,
but
we
also
need
the
same
approaching
in
the
stack
because
you
look
at
the
SDK
okay,
this
is
v1
out
of
our.
What
does
this
mean?
You
look
at
the
spec
and
you
don't
see
it
anymore,
so
you
have
to
look
in
the
get
history.
So
that's
why
I
proposed
either
a
branch
or
let's
make
directories
in
there,
but
we
should
have
everything
until
I.
Don't
know
beta
one
or
something
like
that
when
you
can
archive
the
alpha
version.
B
B
We
did
have
I
did
have
an
item
in
there
about
the
meeting
length.
Alright,
we've
now
tried
a
condensed
meeting.
Do
people
prefer
the
hour-long
meeting
or
do
they
feel
like
we
hit
enough
of
the
high
points
for
discussion
interactively
in
this
one?
Anyone
have
strong
feelings
one
way
or
the
other
I
likes.