►
From YouTube: CNCF Serverless WG 2020-06-18
Description
CNCF Serverless WG 2020-06-18
A
C
D
C
C
C
H
C
B
I
B
C
C
C
E
C
C
C
All
right
moving
forward
to
SDK,
we
do
have
a
call
scheduled
right
out
to
this.
One
I
do
have
a
agenda
item
on
there.
It's
more
of
a
bureaucratic
process,
kind
of
a
thing,
so,
if
you're
interested
please
join,
will
be
right
after
this
call,
workflow
see
where
you
want
to
update
us
on
anything
going
on
at
work
for
those
stuff,
yeah.
J
J
So
if
anybody
is
interested
in
that
area,
you
know
let
me
or
us
know,
and
and
and-
and
there
definitely
can
help
on
that
and
we're
also
in
the
process
of
adding
a
Java
SDK
or
like
a
SPI
type
of
thing,
so
kind
of
like
good
things
going
on
and
just
trying
to
get
the
community
behind
us
or
increase.
You
know
the
number
of
people
they
expose
ourselves
to
more
and
more
people
to
get
more
help
and
that's
kind
of
like
the
current
stats
things
any.
J
No,
the
the
sick
people
have
a
meeting
the
sorry
the
delivery
stick
has
a
meeting
next
week,
so
I
was
told
kind
of
like
the
day.
There
would
be
the
date
that
meeting
would
be
where
to
make
a
decision
and
I'm
not
really
sure
how
to
communicate
the
decision
with
everybody,
but
I
guess
we'll
find
out
process
I'm.
Sorry,
okay,.
C
K
He
first
saw
that
on
the
HTTP
binding,
so
there
was
seemed
to
be
a
slightly
it's
like
a
contradiction
because
in
the
I
think
1.3,
it's
said
that
the
structured
mode
should
be
supported,
but
then
and
below
I.
Think
in
the
event
formats
was,
then
that
must
Jason
form
it
must
be
supported.
So
if
you
have
a
short
one
hand
and
a
must
later
on,
it
seemed
to
be
a
bit
contradictive.
K
So
AMQP,
Kafka
and
MQTT
I
think
that
was
so
I
added
those
this
change
there
to.
It
is,
of
course,
a
bit
different
for
mqtt,
for
example,
as
it's
only
makes
sense
for
MQTT
5,
but
I
think
the
way
I
edited
it.
It's
still
here
then,
and
also
for
Kafka
I,
think
in
the
older
versions.
It
was
not
possible
to
do
a
binary
mode,
so
then
it's
clear
that
it's
must
be
supported.
Okay,.
C
K
I
C
So
I
should
be
safe.
Okay,
now,
technically,
up
until
yesterday,
there
was
just
the
HTTP
change,
but
then
yesterday,
if
the
glass
cloud
said
he
knows
the
other
ones,
but
he
made
basically
the
exact
same
chain,
textual
change
and
all
the
other
ones.
The
only
thing
I
didn't
follow
that
pattern.
This
was
just
a
typo
was
that
he
said
it
was
mqtt
right
and
Kafka.
K
C
So,
even
though,
from
the
for
the
2-day
limit
thing
technically,
maybe
additional
changes
but
I
think
it's.
The
the
changes
are
consistent.
All
the
way
through,
so
people
do
need
more
time
or
want
more
time.
We
can,
you
know,
feel
free
to
speak
up
and
ask
for
it,
but
it
seemed
like
it
was
a
minor
change,
given
a
minor
change
for
the
time
period
thing
that
we
talked
about.
So
any
questions
on
this.
C
Discovery
revamped,
so
this
one
was
the
one
I
mentioned
last
week
where
I
went
through
him,
get
a
whole
boatload
of
changes
to
the
discovery,
spec
I
think
making
it
easier,
follow
easier
to
implement
I'm
not
going
to
list
all
the
changes.
I
think
probably
try
to
think
what
might
be
some
big
ones
that
I
made
I
think
probably
the
biggest
one
is.
If
you
query
by
types,
the
result
is
actually
very
see
if
I
can
easily
show
that.
C
Yeah
to
do
so,
if
you
query
by
type,
then
you
will
get
a
type
value
as
the
top-level
thing.
It's
just
an
array,
but
then,
underneath
there
you
get
the
service
definition,
because
I
believe
of
the
old
version
of
the
spec
kind
of
implied.
You
were
forced
into
two
different
queries.
First,
to
do
a
type
query:
to
get
the
list
of
types
and
potentially
list
services,
I
think
but
then
actually
get
the
two
guys
to
get
the
metadata
about
each
service.
C
You
then
have
to
do
a
subsequent
query
and
I
thought:
that's
not
very
optimal
for
a
user
and
it's
actually
kind
of
annoying,
so
I
thought
well,
let's
just
make
it
so
that
the
return
value
from
the
service
side
is
the
same
regardless
of
whether
you're
searching
by
type
or
by
services.
It's
just
in
the
type
case
it
has
a
type
on
the
outside.
Then
you
drop
into
the
service.
That
way
you
get
the
full
metadata
every
single
time.
C
If,
in
the
future
we
decide
it's
just
too
much
data,
then
I
think
we
can
look
at
adding
flags
that
says,
or
that
do
things
like
give
me
that
say,
give
me
a
reduced
set
kind
of
thing,
but
I
did
I.
Do
think
it's
important
for
somebody
who
know
that
they're
hitting
a
consumable
chunk
of
data
to
come
back
to
get
it
all
in
one
shot.
If
they
really
want
to
I,
think
that's
going
to
be
important
and
not
force
everybody
into
a
a
to
query
model.
I.
C
C
B
C
C
So
I'm
not
gonna,
ask
for
it
today,
but
maybe
for
next
week,
people
can
be
thinking
about
whether
they
would
volunteer
to
put
together
an
implementation
of
the
spec
to
see
if
it's
actually
implementable
and
then
we
could
start
maybe
doing
some
Interop
testing
or
something
along
those
lines
just
to
prove
out
the
spec
actually
works.
Great
I
figured
that
we'll
probably
expose
lots
more
bugs
and
just
keep
reading
it
over
and
over
so
anyway.
C
A
So
there
have
been
a
108
comments
on
this
and
I
think
I've
addressed
in
one
way
or
the
other
I
think
some
of
the
discussions
kind
of
resolved
themselves
resolved
themselves,
and
then
there
were
some
some
comments
too,
with
minor
wording
things,
or
there
are
two
spaces
too
many,
and
so
did
those
but
I
think
I
caught
everything.
So
I
think
my
proposal
would
be
at
this
point,
because
this
becomes
a
little
unwieldy
and
to
manage
if
there
are
no
grand
objections
to
the
overall
tenor
of
the
documents.
A
C
That's
agreeable:
yes,
that's
much
better
than
the
opposite.
I
guess
all
right!
This
one
was
open
relatively
recently,
but
it
is
just
a
change
to
our
community
/
demos
file
and
it's
just
pointing
to
a
demo.
That's
this
person
has
run
cloud
events,
it's
non-controversial
my
opinion,
so
I
don't
think
greenness
I
had
to
make
too
much
sense.
C
K
Talk
to
this
one,
okay,
so,
first
of
all
this
dependent
on
your
change
to
the
discovery
model,
so
I
really
have
to
change
and
adjust
it
a
bit.
The
source
template
will
then
be
under
type
I
think
so
that
would
be
change.
I
will
have
to
make
we
discussed
I
think
two
weeks
ago,
if
we
should
constrain
it
to
adjust
the
level
one
templates,
they're
suggesting
so
I
could
add
something
some
comment
to
that.
K
It
is
recommended
to
use
the
normative
recommended
to
use
just
the
level
one
templates
or
we
could
do
a
hard
constraint.
I,
don't
know
that
was
one
thing.
The
other
thing
is
that
I
think
you
asked
somewhere
in
this
PR
if
it
would
make
sense
to
further
describe
the
parameters
mentioned
in
the
templates
and
I
thought
about
a
use
case
where
it
might
make
sense.
C
C
The
quest
the
word
levels
right,
so
there
was
at
least
two
different
levels.
Does
anybody
have
an
opinion
on
restricting
it
to
just
level
one
because
I
think
if
I
remember
correctly
level,
two
or
other
levels
allow
you
to
do
really
fancy
substitutions
and
yes
loops,
and
we
really
would
cool
stuff
like
complicated
stuff.
F
F
K
G
C
G
C
C
True,
yes,
okay,
so
there's
the
two,
so
I
assume
you'll
you'll
make
a
change.
Okay
and
then
the
third
one
was
the
more
much
more
advanced
feature
of
actually
describing
the
actual
variables.
Yes,
that's
something
you
suggested
in
one
of
the
comments.
I
think
yeah
and
I
definitely
would
not
want
that.
As
part
of
this
PR,
we
could
consider
that
as
an
add-on,
PR
I
would
want
to
keep
this
one
small
and
simple.
So
we
could
talk
about
that
one
later,
in
my
opinion,
unless
someone
else
wants
to
say
no,
we
need
to
know.
C
C
Okay,
I
won't
force
you,
then
in
that
case,
Jem
was
not
able
to
make
the
call
today.
He
warned
me
about
that
and
I
promised
him.
I
would
just
remind
people
to
take
a
look
at
his
protobuf
PR.
He
is
still
working
through
the
discussions
and
comments
and
stuff
there.
So
if
you
have
anything
to
add
to
that
conversation,
please
go
ahead
and
comment
in
the
PR
I
believe
he's
still
hoping
to
come
up
with
a
final
draft
of
the
PR
for
next
week.
So
don't
wait
the
last
minute.
If
you
have
comments
or
concerns.
C
C
I'm
waiting
for
that
to
happen,
you
know,
I
gotta
find
a
good
topic.
Okay,
let's
see
who
did
I
miss
Rekha,
hey
there,
yes
time!
This.
Is
this
your
first
time
on
the
call?
Yes,
this
is
the
first
time.
Okay,
if
you
can,
if
you
want
to
be
associated
with
a
company,
can
you
just
put
the
company
name
in
the
zoom
chat
and
I'll
put
it
in
there?
Okay,.
C
C
C
So
Wow
Oh
Thank
You
Lance
for
adding
a
topic
so
just
stuff
for
you
guys
to
think
about
when
to
are
waiting
for
the
minitek.
The
item
I
want
to
talk
about
was
right.
Now
we
have
basically
one
gigantic
maintainer
x'
group
inside
the
inside
the
project,
and
that's
was
fine.
When
we
only
had
a
handful
of
people,
they
you
know
they
bounced
around
between
us
CK's.
C
It
wasn't
worth
having
individual
teams
per
SDK,
but
now
that
we're
getting
a
little
bit
bigger,
we
should
probably
start
looking
to
add
a
little
more
formality
and
process
to
things.
So
what
I
was
going
to
do
or
suggest
is
that
we
actually
create
separate
teams
per
project
and
I,
don't
know
for
sure.
If
I
got
this
list
right,
so
please
look
at
the
list
make
sure
the
names
are
correct
in
terms
of
who
goes
where
in
particular,
slinky
I
wasn't
sure
which
groups
you
wanted
to
be
in.
G
C
I
went
through
the
list
of
people
that
are
in
the
maintainer
group
and
then
I
tried
my
best
to
look
at
who
did
commits
on
each
project
and
if
you
had
more
than
like
two
commits
I
thought:
okay
they're
busy,
not
they
should
be
maintainer,
but
to
be
honest,
if
oh
I'll
edit
this,
however,
you
want.
This
was
just
my
initial
guess.
G
L
G
C
G
C
G
In
the
rust,
so
the
roster
is
funny
because
when
we
started,
I
started
with
the
larger
80
and
the
other
guy
is
named
Venus
Venus
bossy
girl
and
we
decided
to
gather
all
the
design
decision.
So
we
did
some
meetings
for
that
by
the
ended
up.
Writing
all
the
code,
so
I
mean
IIIi,
asked
them
to
join,
participate,
write
code,
but
they
never
contributed
with
code.
They
just
did
the
review
so
I
don't
know
how
should
we
end
on
that
I?
Don't
think
comfortable
being
the
only
one
honestly,
but.
C
It's
up
to
you,
I'm
gonna,
listen
to
you
guys!
Well,
actually,
let's
back
up
before
we
continue
editing
lists.
Do
people
agree
with
creating
separate
teams,
first
of
all,
any
objection
to
that:
okay,
okay,
good,
okay!
So
now,
let's
go
back
to
list
honestly,
it's
up
to
you
whether
you
I
keep
them
there
or
not.
I.
We
can
always
riad
people
later
if
they
object.
G
C
G
A
C
C
C
My
first
guess
was
to
say
50,
police,
50%
or
I'm.
Sorry,
50,
more
than
50
percent
of
the
existing
maintainer
x'
should
vote
to
either
add
or
remove
somebody
just
to
have
it
consistent
across
all
the
repos.
But
it's
up
to
you
guys
in
terms
of
what
kind
of
process
you'd
like.
Actually
they
back
up.
Do
you
want
to
define
a
shared
process
across
all
repos
slinky
Europe.
G
Yes,
so
I
think
we
should
have
it
definitely.
Okay
and
but
I
propose
to
add.
Also
a
contribution
bar
go
to
Buscemi
no
bar
okay,
at
least
the
XP
ours.
I.
Don't
know
that
number
now
for
sure,
but
I
think
it's
important
to
say:
let's
I
have
that
I
don't
have
the
number
but
I
think
I
think
we
should
put
a
bar
in
terms
of
how
much
beers,
okay.
L
G
If
it
happens
again,
situations
like
an
maintain
it
as
decay
where
somebody
wanted
to
contribute,
but
there
wasn't
an
opportunity
to
do
that
because
maybe
somebody
because
the
SDK
wasn't
maintained,
then
we
need
to
have
another
rule
for
that
situation.
Yeah
I,
don't
know,
but
my
first
guess
is
that
we
need
at
least
experience
okay.
B
It
may
also
not
be
the
best
net
week
because
it
also
depends
on
the
current
maintainer
and
the
billing
mess
to
contribute,
because
sometimes
there
is
a
huge
wheel,
a
big
wheel,
to
contribute.
But
unless
some
agreement
is
reached
with
the
maintainer,
it
may
not
be
something
that
people
would
want
to
do
and
just
submitting
random
PRS
to
get
the
maintainer
status
would
also
be
weird,
although
it
would
improve
the
project.
B
C
They
did
know
people
playing
games,
you
know
doing
type
o
type
p
RS
just
to
get
that
number
up
would
not
be
good
like
that.
Yeah.
Absolutely
we've
all
seen
that
before
so
you
mentioned
concerns
with
those
two
things.
Do
you
have
any
recommendations
on
what
kind
of
criteria
you
would
like
to
see
at
it.
B
Perhaps
identifying
the
companies-
maybe
because
usually
we
talk
about
the
companies
I
mean
there
are
individual
contributors
as
well,
which
is
great,
but
sometimes
there
is
a
company
that
wants
to
use
some
of
the
SDK
is
the
case,
and
they
may
also
have
a
desire
to
contribute
so
focusing
on
the
end.
Users,
as
big
groups
of
users
and
their
representatives
may
also
be
an
auction.
B
I
mean
obviously
I'm,
considering
some
of
the
cases
we
had
in
the
past,
but
at
least
when
we
are
talking
about
an
SDK
official
as
decay
for
cloud
events,
which
is
a
community
driven
project
from
the
foundation,
I
would
expect
it
to
be
more
foundation,
driven
where
foundation
is
a
group
of
companies
rather
than
individuals
and
maintainer.
So.
A
A
Reasonable
bar
that
what
that
should
be
in
the
governance
rules
that
a
single
company
can't
have
more
than
X
percent
of
the
maintainers
where
by
X
percent
must
be
on.
It,
certainly
must
be
under
50%
and
I.
Think
a
third
would
be
like
if,
if
it's,
if,
if
it's
a,
if
it's
more
than
a
third
I,
would
question
the
health
of
the
project.
F
C
F
I
I
mean
the
I
can
say
right
now
that
you
know
the
JavaScript
SDK
has
two
thirds
of
the
maintainer
is
coming
from
Red
Hat,
but
I
I
would
say
that
that
that
doesn't
necessarily
it's
not
a
detriment
to
the
health
of
the
project.
In
fact,
the
project
is
actually
getting
a
lot
more
attention
than
it
had
yeah.
F
A
I
think
this
is
why
why
I
don't
think
on
the
individual
SD
kala,
it's
like
if
we,
if
we
say
for
the
SDKs,
we're
basically
going
to
make
that
a
pool,
a
pool
thing
that
works
better.
But
it's
so.
My
concern
is
that
when
you
put
governance,
rules
like
this
in
place
and
you
allow
effectively
a
quorum
of
folks
to
decide
who
gets
in
to
the
project
or
not.
A
Then
once
a
company
has
amassed
enough
committers
to
be
having
majority
to
control
who
gets
integrates
not
in
then
the
project
has
a
fairly
easy
way
to
deteriorate
into
a
marketing
effort
of
a
particular
company
when
they
could
still
put
up
the
sign
on
the
outside.
To
say
we
are
open-source
and
we're
running
in
the
in
the
in
the
foundation.
B
Just
want
to
said
one
hand,
I
think
it's
exciting
to
see
companies
commitment
to
the
cloud
events,
the
red,
hard,
google
whirring
as
a
company,
but
a
thing
clemont's
made
a
good
point
about
and
I.
If
I
may
I'd
like
to
coat
a
diversity
of
thinking,
because
when
the
majority
of
SDKs
are
maintained
by
the
same
company,
you
may
have
a
problem
of
being
very
like
biased
towards
this
company's
needs
and
I
think
what
HUD
is
doing
great
job
right
now
and
it's
listening
to
other
companies.
C
A
Think
I
think
so.
This
is
so
we're
I
think
what
I
want
to
avoid
is,
if
we're
having
a,
if
we're,
having
kind
of
a
governance
rule
that
that
that
says
you
are
in
or
you
are
out
and
we're
doing
this
as
a
maintainer
like
who
do
we
give
commit
rights,
and
we
should
have
a
governance
mechanism
that
prevents
a
single
company
for
being
able
to
effectively
control
that.
A
I'm
thinking,
yes,
the
global
level,
because
we
all
I
mean
we
need
to
go
all
pool,
pool
resources
and
there
is
probably
there
will
be
companies
which
are
really
really
interested
in
doing
something
in
whatever
Haskell,
and
that
might
be
a
bit
of
a
niche
opinion.
And
so
that's
certainly
something
where
just
one
person
or
two
people
from
the
same
team
might
be
doing
this.
So
instituting
that
role
that
rule
there
doesn't
really
make
any
sense
but
like
at
the.
A
C
C
C
Speaking
just
for
myself,
I
would
personally
prefer
to
avoid
anything
too
formal,
yet
because
I
haven't
need
to
introduce
anything
yet
I
think
if
I
think
a
formal
structure
within
an
SDK
of
having
well-defined
maintained
errs,
which
you
already
do
have
sort
of
women
now
would
be
a
little
more
formalize
with
this
list
above
I
think
that's
definitely
needed,
because
you
need
to
be
able
to
resolve.
You
know
disputes
at
an
SDK
level,
so
I
think
that's
definitely
needed
it's
just
when
we
start
talking
about
company
representation
within
a
particular
SDK.
C
The
max
per
company
I
mean
that
that
one
scares
the
bejeebers
out
of
me
because
I
don't
necessarily
think,
for
example,
the
c-sharp
one
is.
It
has
anything
wrong
with
it
right
now
right,
even
though
that
you
guys
are
both
Microsoft
right,
the
sergej,
the
thing
you're
talking
about
of
getting
representation
from
companies
who
want
to
participate
and
from
end
users,
I
well
I,
agree.
C
I
want
their
input
I'm,
not
sure
that
anybody
should
necessarily
gets
maintained,
ership
status
without
putting
in
the
work
right
just
because
company
X
says
hey,
we
want
to
join
forces
and
we
got
ten
people
who
want
to
join
that's
great,
but
they
have
to
do
the
PRS
and
and
and
and
do
the
work
before
the
each
individual
person
would
become
maintainer.
At
least
that's
my
thought
process
there
and
I
see
a
cube
piling
up.
So
let
me
pause
on
that
there's
just
my
current
thought.
Processes
on
this
sergej
your
hands
up
first,
so.
B
First
of
all
absolutely
agrees
that
without
commitment
making
someone
a
maintainer
would
be
simply
a
mistake,
even
if
he
is
loud
or
anything
so
I
agree
here,
Auto
may
be,
PRS
is
not
the
best
metric.
Maybe
commitment
can
may
also
be,
can
also
be
counted
by
issues
reported
and
discussed,
and
other
PRS
review
and
other
open-source
activities
that
it's
not
measured
by
PRS.
E
G
Okay,
no
I
just
want
to
say
then
I
completely
agree
with
you
Doug
that
if
you
want
to
put
some
metrics
about
companies,
that's
the
point.
But
if
we
don't
see
commitment,
I
personally,
wouldn't
I
personally
would
never
love
to
accept
somebody
as
a
maintainer.
If
he
hadn't
did
some
some
work
and
review
is
a
thing.
I
agree
with
the
fact
that
we
should
also
count
review,
but
at
some
point
somebody
must
break
code.
I
mean
I,
mean
I.
L
B
Sergej
ends
up
again
yeah,
just
maybe
a
quick
one
so
does
hand
if
you
want
to
count
the
code.
We
should
also
make
sure
that
PR
should
be
proceed
in
order
submitted,
because
we
have
seen
it
in
the
Java
SDK
when
a
PR
was
submitted,
but
then
rejected
by
the
maintainer,
and
we
created
the
way
he
sees
it
and
it
kind
of
stops
external
contributors
from
submitting
code,
because
the
maintainer
disagrees,
so
maybe
more
work
on
the
review
could
help
here.
Okay,
that's
it
that's
a
slightly
different
topic.
G
C
B
Is
there
some
sort
of
a
definite
process
from
the
cloud
native
Candida
foundation
that
we
inherit
I
mean
the
bureaucracy?
B
wouldn't
be
something
good
to
have,
but
at
least
maybe
I
mean
I'm
pretty
sure
there
are
some
other
projects
that
were
thinking
about
the
same
thing.
So
maybe
you
can
get
some
inspiration
from
them
as
we
are
inside
the
foundation,
not
just
yeah.
C
I
have
to
double
check,
I
offhand
I,
don't
think,
there's
anything
at
the
CN
CF
level
itself.
There
may
be
other
projects
within
the
scene,
CF
that
have
good
ideas
that
we
could
steal
from,
but
I'm
not
sure
I've
seen
anything
at
the
scene,
C
F
level,
but
I'll
I'll,
double
check
and
see.
Maybe
I'm,
just
forgetting
okay,
so
I
think
objected.
G
G
D
C
B
C
F
G
C
I
guess
the
question
is
when
it
comes
to
process
like
that,
do
we
want
a
single
because
there's
over
an
ample
Lance
picking
on
your
repo
for
a
sec,
you
guys
define
a
process,
or
at
least
a
set
of
recommendations
for
even
things
like
tagging
of
issues
in
the
name
or
some
like
that
right?
Is
it
a
feature
versus
a
bug,
request
chore
that
kind
of
stuff
I
can't
really
exact
terms
you
guys
use
right.
C
F
Well
I'll
say
in
particular
for
the
JavaScript
repository
that
that
process.
That,
basically
is
you
know,
have
your
commits
prefixed
with
basically
a
subsection
of
the
what
the
repository
is,
like
you
said,
bug
fix
or
feature
or
whatever
that
feeds
into
a
tool
that
does
things
like
generates
change
logs,
creates
the
release,
tag
and
stuff
like
that,
so
that
none
of
that
has
to
be
done
by
hand.
That's
definitely
a
node
specific
kind
of
tool.
There
may
be
other
tools
like
that
with
other
languages,
but
I'm
not
aware
of
them.
C
C
Well,
Lance,
in
terms
of
trying
to
have
a
commonality
are
trying
to
have
coming
out
a
process
across
them.
Would
you
like
to
I
was
going
to
say,
submit
a
pull
request,
but
then
it
so
let
me
back
up.
Do
people
want
a
single
SDK
repo
to
hold
cross
SDK
things,
or
do
you
want
to
just
create
like
a
folder
inside
the
main
spec
repo.
C
B
C
That
yeah,
that
that
government
stock
definitely
is
about
the
the
cloud
of
inspect
work
itself
and
the
other
respects.
It's
not.
It's
not
methane.
It's
like
cover
the
SDKs
okay.
So
it's
a
what
I'm
not
hearing
opens
people
speak
up,
saying
we
need
a
brand
new
repo
just
for
common
governance
or
other
types
of
documentation
for
this
decays.
So
why
don't
we
look
at
these
in
the
spec
repo
now
so
Lance?
Do
you
do
you
want
to
formally
propose
common
process
and
if
so,
I
would
recommend
a
PR
against
the
main
repo?
Then?
C
C
I
still
think
we
should
probably
create
a
say,
an
SDK
directory
there
to
put
all
these
things
into,
because
otherwise,
the
top
level,
the
top
levels
already
too
big.
In
my
opinion,
so
I
think
we
should
have
an
SDK
directory
to
put
all
this
stuff
into
and
I
could
work
on
doing
that,
but
yeah
a
PR,
it's
the
main
repo,
be
good,
okay,
sure,
cool.
C
C
Okay,
anything
else
relative
to
governance,
so
I
will
do
this.
I
will
create
the
separate
teams.
So
it's
able
to
create
a
PR
as
a
proposed
process
for
a
how
to
add,
maintain
errs
answer
that
I'll
do
that:
okay,
anything
else
about
governance
or
anything
from
that
space
once
it
reach
up
over
to
Lance's
topic.
Here,
you,
okay,
moving
on
Lance
no
I
had
that
AI
and
I
have
not
done
squat
with
it
and
I
apologize.
If
someone
else
wants
to
take
a
stab
at
it,.
G
C
We're
looking
for
is
just
a
in
this
particular
case
now
it
would
be
a
PR
to
the
spec
repo
explaining
when
or
what
kind
of
review
process
would
happen
on
an
SDK
to
determine
whether
it's
still
active,
whether
it
should
be
archived
and
that's
about
it.
I
think
right,
I,
don't
know,
I'm,
not
sure
what
we
meant
by
quality
of
service,
an
SLA
except
for
the
except.
G
G
C
Obviously,
I
think
if
we
actually
create
a
separate
governance
doc
that
talks
about
things
like
how
to
add
marine
tears
and
stuff
I
think
that
proposal
fits
very
nicely
in
that
same
governance
stock.
So
we
can
look
at
merging
it
later,
but
for
right
now
you
know
create
a
separate
PR
with
a
separate
doc
and
we
can
worry
about
the
but
right.
L
G
C
C
C
C
C
G
But
the
the
the
discussion
that
Sergey
D,
where
I
think
went
in
this
direction,
somehow
I
mean
and
but
but
also
it
comes
like
another
thing
that
comes
to
my
mind,
is
for
example,
let's
assume
we
have
one
of
these
decays,
which
we
don't
want.
We
don't
want
to
archive,
because
there
is
no
me
because
it
works.
It's
updated,
but
the
maintainer
is
not
alive,
I'm,
not
wrong
to
archive
an
elaborate
that
just
works
only
because
the
maintainer
is
not
alive.
G
G
C
And
I
think
I
think
some
of
the
stuff
that
you're
talking
about
there
would
I
would
hope
would
appear
in
this
in
this
document
that
you're
gonna
write
up
a
proposal
for
right
because
I
agree
with
you
just
because
no
one
is
active
on
an
SDK
doesn't
necessarily
mean
we
should
archive
it,
because
people
are
using
it
right
and
we
don't
want
it
to
go
away
and
at
that
point,
if
something
needs
to
change
in
that
SDK
I.
Think
that's
why
we
have
these.
These
regular
phone
calls
right.
C
Someone
can
identify
the
issue,
something
needs
to
happen
and
we
just
need
to
get
a
volunteer
to
make
it
happen.
Even
that
they're,
not
a
maintainer
of
that
particular
SDK,
I.
Think
I,
don't
think
we
need
the
means.
You
could
talk
about
that
in
your
proposal.
If
you
want
but
I,
don't
think
we
necessarily
have
to
spend
too
much
time
on
it.
I
think
that
we'll
kind
of
fix
itself
I'm,
hoping
anyway.
F
Haven't
really
given
a
lot
of
thought
to
this
yet,
but
the
fact
that
we
keep
saying
SDK
over
and
over
again
and
all
the
the
repos
were
named
SDK
there's
there
was
a
proposal
in
the
JavaScript
repo
to
to
change
the
name
to
not
have
to
not
have
that
acronym
in
their
SDK,
because
SDK
actually
implies
something
bigger
and
broader
and
stuff
like
that.
Are
there
is
there
governance
or
guidance
or
anything
on
if
names
change
and
what
they
should
be
changed?
You
know
whether
or
not
I'm
curious
about
this
I
I.
C
Know
of
no
rules
either
from
the
CN
CF
or
within
this
group
that
we've
discussed
at
that
level.
I
think
if
we
wanted
to
make
that
kind
of
name
change,
it's
just
something
we
as
a
group
we
decide
on
our
own,
but
though
it's
a
good
or
bad
and
what
we
change
it
to
would
be
up
to
us
to
decide.
I
think
it
that'd
be
a
pretty
massive
discussion,
though,
because
people
probably
reference
our
repos
already.
Yes,.