►
From YouTube: CNCF Serverless WG 2020-08-06
Description
CNCF Serverless WG 2020-08-06
B
A
D
D
A
G
A
A
E
A
A
H
Oh,
I've
got
a
question
here:
yes,
sir,
the
status
on
doing
cloud
events
in
aws
I've
got
some
questions
on
that
from
some
friends.
I
know
there
were
initially
talks
about
doing
custom
transports
for
sns
sqs,
whatever
that
got
cancelled
and
it
was
going
to
be
implemented
in
the
sdk
and
in
the
sdk.
The
conclusion
was
that
it
was
going
to
be
implemented
somewhere
in
aws
land
and
not
in
the
official
cloud
events
sdk,
because
it
doesn't
really
make
sense
and
it
seems
that
nothing
happened.
H
A
H
A
L
L
A
L
K
F
Not
one
transport
and
for
aws
and
for
aws
or
sorry,
amazon
mq,
since
that
is
standard
space,
and
it's
it's
based
on
active
mq,
there's
a
binding
and
for
all
the
other
things
and
for
sqs.
Arguably,
because
send
is
just
a
post
that
can
also
likely
be
done
with
a
with
the
cloud
events
binary,
http
call,
but
for
everything
else,
the
engineering
work
of
that
mapping
is
something
that
arguably
aws
will
have
to
do
and,
and
there
are
server
side
there
are
servers
at
work.
That
needs
to
be
done
for
everything.
F
F
F
H
J
A
All
right
moving
forward,
then,
so
I
got
a
note
from
the
kubecon
north
america,
folks
or
organizers,
asking
if
we
want
to
do
a
maintainer
session
for
either
cloud
events
or
the
serverless
working
group.
We
don't
necessarily
have
to
decide
on
this
call
right.
We
have
until
september
13th
to
take
it
back
to
them,
but
we
can
do
two
different
sessions
because
we
have
cloud
events
and
service
working
group.
Each
one
is
a
35
minute
session
up
to
four
speakers
each.
A
If
you
are
interested
in
participating
in
that,
please
reach
out
to
me
and
then
we
can
figure
out
exactly
who's
going
to
do
it.
What
the
topics
would
be
and
stuff
like
that.
I
figure
worst
case
scenario.
If
no
one
really
volunteers,
I
could
strong
arm
clemens
to
redo
the
thing
we
already
did
for
china
and
europe.
A
Maybe
I'm
just
getting
the
same
video
since
it's
not
even
tagged
with
what
kukan
it
was
for,
but
I
figure
we
should
at
least
do
something
to
update
people
if
they're
interested,
but
if
people
have
specific
topics
or
if
anybody
else
besides
clement
myself
wants
to
talk.
Please
ping
me
offline
and
we
can
make
it
happen.
I
don't
think
climbing
to
myself
or
care
that
much
whether
we
do
it
or
not,
just
somebody
should
do
something.
Is
that
the
biggest
thing?
I
think?
A
Okay,
any
questions
about
that
all
right.
As
I
said,
we
do
have
an
sdk
call
this
week
after
this
one
we
do
have
an
agenda.
So
please
take
a
look
at
that.
If
you're
interested
teamwork
isn't
able
to
make
the
call
today,
he
updated
me
offline,
nothing,
real,
nothing,
really
major
dimension
other
than
they're
still
working
on
their
new
logo,
but
they
are
getting
lots
of
interest
from
other
folks
who
are
looking
to
spec
and
they're.
A
They
seem
to
be
potentially
lining
up
some
collaborations
with
the
projects
which
is
really
kind
of
cool
all
right.
So
before
we
jump
into
the
prs
anything
I'm
missing
from
the
agenda
before
we
jump
into
it
all
right
now,
the
first
one
we
actually
approved
last
week,
but
just
let
you
guys
know
I
haven't
merged
it
yet,
because
I
have
not
been
able
to
sync
up
with
kristoff
he
may
be
on
vacation
to
find
out.
If
he's
okay,
with
removing
that
little
bit
of
non-normative
text,
that
people
had
a
problem
with.
M
A
J
J
So
we
just
loosened
the
requirements,
because
the
spec,
as
it
was
designed
before
you
will
not
list
even
that
you
don't
have
access
to
in
the
discovery
service,
but
the
discovery
service
can
basically
aggregate
several
services
without
knowing
their
permission
scheme.
So
in
that
case
he's
not
able
to
do
it
dynamically.
So
it's
just
to
fix
that.
A
A
Where
is
it
yeah
so
down
here
in
the
api
section?
I
made
it
so
that
it's
the
exact
name,
it's
not
a
search
term,
so
the
name
has
to
match
it
exactly
case.
Insensitive
though,
and
then
I
opened
up
an
issue
for
us
to
revisit
the
topic
of
of
how
to
do
a
popular
phrase,
a
wild
card
type
search
right,
so
a
partial
name,
matching
kind
of
thing.
A
Given
all
the
talk
we
had
on
this
one,
I
I
don't
want
to
jump
right
to
any
objection
to
approving,
because
I
don't
know
how
people
feel.
I
know
that
there's
there
was
some
reservations,
but
in
my
I
don't
know
it's
biased
or
not,
but
in
my
opinion,
more
people
were
in
favor
of
doing
it,
even
though
there
may
have
been
some
concerns
about
losing
the
the
human
readability
form
of
having
the
name
of
the
url.
A
A
I
took
an
ai
to
go,
see
what
it
would
take
to
add
paging
type
of
functionality
to
our
spec,
and
I
decided
that
we
actually
may
want
this
type
of
functionality
for
other
specs,
like
perhaps
for
the
schema
registry
or
the.
I
guess,
that'd
be
the
only
other
one
on
the
screen
registry.
So
I
decided
to
create
a
separate
specification
that
can
be
reused
in.
A
A
It
wasn't
333,
no,
it's
yeah.
I
think
it
might
be
this
one
rfc
5988.
It
defines
how
to
add
http
header
links
that
look
like
these
to
your
http
responses
to
include
exactly
this
type
of
information.
You
know
things
how
to
how
did
I
get
the
the
next,
the
next
chunk
of
responses
or
to
get
the
previous
ones?
I
don't
mandate
anything
in
particular.
In
terms
of
you
know,
minimum
sizes
and
stuff
like
that
that
I
do
to
find
a
little
bit
of
a
negotiation.
A
I
did
notice
a
typo
here.
I
did
it
in
the
text
I
removed
the
talk
about
expires
as
being
part
of
this.
This
is
actually
a
typo
here.
The
expires
here
should
not
be
here.
Rather
instead
you
know
what
this
is
old.
I'm
sorry,
I
forgot
the
pushes.
I
made
a
change
to
this
section
where
I
included
http
header
for
the
expires
based
upon
clemens's
comment.
A
I
will
fix
that.
I
apologize
so
if
you're
looking
at
this
know
that
the
expires
is
not
a
field
on
the
link.
It's
actually
a
separate
hp
header
that
tells
you
when
this,
this
pagination
stuff
will
expire
and
that's
going
to
be
useful
in
cases
where
someone
actually
wants
to
have
a
sort
of
a
persistent
state
associated
with
their
pagination
query,
because
maybe
the
data
is
changing
on
a
regular
basis
and
they
don't
they.
They
can't
return
a
static
set.
A
You
know
for
page
or
the
static
list
for
say
page
three
is
always
fixed
right.
It
may
be
changing,
you
know
every
minute
kind
of
stuff,
and
so
they
may
need
to
keep
some
sort
of
persistent
state
associated
with
it
and
in
which
case
that
will
include
some
sort
of
unique
id
somewhere
in
here
that
allows
them
to
know
which
query
this
person's
iterating
over
anyway.
I
apologize.
I
thought,
I'd
push
this
up,
but
I
must
not
have
for
the
expires
header,
but
with
that
any
questions.
A
A
A
C
A
N
A
A
Yeah,
actually
one
of
the
changes
I
picked
up
from
last
week
is,
I
don't
know
who
this
person
is
sanjay.
They
suggested
using
limit
and
offset
instead
of
size
and
page,
which
I
actually
did
change
and
again
I
apologize
for
not
pushing
it
up
there.
So
I
don't
know
if
that
that
helps
your
concern
at
all.
A
Yes,
that's
exactly
why
I
wanted
to
talk
about.
That's
exactly
why
I
wanted
to
add
that
expires
thing,
because
if
someone
on
the
server
side,
if
you
want
to
actually
support
not
you
know,
you
want
to
support
someone
not
getting
messed
up
as
they
iterate
over
these
things.
They
want
to
get
us
in
essence,
generate
a
static
list
and
then,
when
they're
done
pagination
when
they're
done
with
the
pagination,
they
want
in
essence
delete
that
temporary
result
set.
O
Yeah
some
apis,
they
use
like
the
next
token
kind
of
thing,
which
is
the
next
cookie
usually
is
like
a
a
primary
key
or
something
of
the
collection
back
to
the
you
know,
the
name
and
id
discussion
like,
for
example,
a
name
could
be
a
a
good
next
token
like
if
I
have
100
all
the
names
right,
I
can
no
matter
how
you
add
a
new
name
to
the
beginning
or
the
end.
I
can
always
use
my
current
next
token,
which
is
the
name
to
paginate
to
the
next
next
page.
A
O
Is
removed,
I've
seen
yeah,
but
but
that's
fine.
You
know
it
says
I
can.
Usually.
We
just
need
to
make
sure
the
then
next
time
when
I
use
this
key
to
query
the
next
page,
you
already
it's
just
larger
than
this
key
another
thing,
yeah
gotcha
I
can.
I
can
comment
on
some
some
more
details
and
examples
later
maybe
yeah.
A
L
L
A
Right,
interesting,
okay,
I'll,
go
back
and
take
a
look
at
the
text
and
see
because
because,
honestly,
when
I
made
that
change,
I
did
basically
just
a
search
and
replace
on
the
on
the
words.
I
guess
I
need
to
go
back
and
make
sure
that
the
wording
is
more
record-based
as
opposed
to
page-based,
because
there,
because
you're
right
there
are
different
semantics
there.
So
I'll
take
a
look
at
that.
So
thanks
for
the
reminder,
scott,
okay,
any
other
comments.
A
A
A
Okay,
in
that
case,
we
have
a
whole
bunch
of
work
in
progress
things,
the
sdk
rules
or
maintainer
rules.
That's
on
the
agenda
for
the
sdk
call,
so
I
want
to
say
how
to
discuss
that
here.
However,
if
you
are
interested
in
that
topic,
please
join
the
sdk
call,
because
we're
going
to
be
talking
about
that
one
jim,
unfortunately
told
me
he
could
not
make
the
call
today,
I
don't
believe
he's
had
any
updates
to
the
protobuf
specifications.
I
don't
think
it's
going
anywhere
slinky.
M
A
Well,
I
I
I
don't
necessarily
have
to
close
them,
it's
more
from
my
perspective,
it's
more
if
we're
going
to
keep
them
open,
then
I'd
like
to
see
at
least
some
forward
progress
being
made
like,
even
if
it's
just
offline
discussions
that
are
happening,
but
I
got
the
sense
that
that
there
really
aren't
even
offline
discussions,
and
I
don't
know
how
to
interpret
that.
Is
it
people
don't
like
the
solutions?
Is
it
people,
don't
think
it's
a
problem?
A
A
M
L
I'm
very
interested,
I
just
don't
have
a
lot
of
time.
We
have
a
concrete
use
case.
Around
data
ingestion
on
big
data
pipelines
and
multi-part
or
json
streaming
would
be
exactly
what
they
want
to
ingest
cloud
events
into
like
a
data
lake
but
yeah.
I
don't
have
time
to
dedicate
to
that
solution.
Right
now,.
A
So
it's
interesting:
do
you
guys
want
to
keep
them
open
and
just
let
them
sit
in
the
backlog
for
a
while
or
close
them
and
reopen
cause?
We
can,
I
don't
mind,
going
either
way.
I
just
wasn't
sure
if
there
was
any
interest
in
it
because,
aside
from
from
slinky
scott,
I
think
you're,
the
first
one
who
actually
spoke
up
and
said
hey.
This
might
be
useful.
M
My
in
my
use
case,
I
I
wanted
to
to
to
play
with
canadian
venting
and
try
to
to
implement
some
kind
of
streaming
between
the
different
components.
So
at
some
point
I
used
to
to
to
experiment
some
kind
of
use
case,
so
a
use
case
for
that,
because
again,
it
always
connects
to
the
fact
that
there
are
some
payloads
that
are
trimming
by
nature.
Okay,
so.
A
Okay,
well,
it
sounds
to
me
that
we
have
a
proposal
rather
than
to
close
it
right
now
to
give
it
at
least
one
more
week.
Have
people
go
off
to
the
respective
companies
or
whatever,
to
see
if
there's
interest
in
the
stuff
and
then
maybe
on
next
week's
call
revisited
and
see
what
kind
of
information
we
get
back
and
make
maybe
make
a
decision
next
week
or
at
least
revisit
the
discussion
next
week?
Does
that
sound,
fair
yeah.
A
A
I
suspect
everybody's
busy
scott
said
the
same
thing:
okay,
I'm
not
hearing
anybody
jump
in
there,
okay,
so
maybe
by
next
week
the
phone
call
next
week
might
be
a
forcing
function
for
us
to
find
some
time.
Maybe
we'll
see.
Okay
with
that
her
technique
at
the
end
of
the
agenda.
Are
there
any
other
topics?
People
would
like
to
bring
up
concrete.
O
O
A
A
We
know
that
there
are
some
out
there,
because
we
just
hear
about
it
like,
for
example,
might
give
kudos
again
to
microsoft
being
the
first
one
to
formally
support
it
in
their
in
their
bridge
stuff,
but
I
don't
think
they
have
a
formal
list
anyplace
unless
someone
else
on
the
call
can
think
of
someone
who's
been
gathering.
This
information.
G
A
A
Yeah
very,
very
useful.
I
guess
what
we
could
do
is
rename
this
from
open
source
to
just
usage
or
something
like
that
right
and
have
an
open
source
section
as
well
as
a
proprietary
section.
As
long
as
we
have
more
than
one
then
I
won't
feel
like
it's
straight
to
advertisement
right
then.
I
won't
feel
as
bad.
A
A
I
agree
so
why
don't
we
do
that?
If
so
I'll
tell
you
what
I'll
send
out
a
note
to
the
mailing
list,
saying
if
you
want
to
get
you
know
your
company
or
offering
whatever
it
is,
add
it
to
this
page,
open
up
a
pr
in
our
web
repo
and
then
alibaba
you
guys
can
can
do
that
as
well.
Does
that
sound,
fair,
yeah,
yeah
yeah?
Thank
you
grant
for
reminding
us.
We
have
a
website
that
is
a
great
place
to
put
it
so
hold
on.
A
A
M
A
A
A
M
Oh
yeah,
so
after
one
or
two
months
I
finally
managed
to
release
the
sdk
rust
version.
2
version
0.2
huge
thanks
to
a
new
guy
in
the
community,
which
is
helping
quite
a
lot
with
device
features.
If
you
open,
can
you
open
them?
So,
among
the
new
features
really
important?
Now
we
have
the
kafka
integration,
so
there
is
an
integration
with
raster
de
kafka,
which
is
the
most
important
library
to
use
capital
rust.
M
So
you
can
do
things
like
sending
or
receiving
cloud
events
with
kafka,
and
then
we
did
a
lot
of
improvements
on
the
apis
to
send
and
receive
hp
requests.
We
have
new
apis
on
the
event.
We
have
already
decided
event
builder
and
then
there
are
improvements
in
duck
and
stuff
like
that.
So
yeah
go
and
check
it
out.
A
F
A
F
I
think
we
should
have
them,
but
I'm
not
I'm
not,
and
I'm
okay
with
these
rules,
but
I
have
no
strong
opinion
of
whether
they
should
be
at
the
sdk
level
or
at
the
at
the
overall
community
level.
I
would
be
okay
with
the
latter,
but
I
can
could
understand
if
individual
sdk
sub
teams
would
want
to
have
their
own
their
own
rules.
A
R
L
A
P
Yeah,
that's
a
good
point.
I
think
personally,
I'm
not
in
favor
of
of
like
enforcing
or
writing
down
rules
with
maintenance.
I
mean.
Ideally,
someone
can
come
and
go
for
some
languages
like
php.
There's,
there's,
probably
not
going
to
be
someone
creating
20
pr's
before
becoming
a
maintainer,
and
I
don't
know
if
everybody's
going
to
read
all
of
this
sdk
governance
before
occurring
prs
and
I'm
not
sure
that
they
need
to,
but.
L
Yeah,
I
think
I
think
this
isn't
really
for
contributors.
It's
for
the
actual,
like
the
maintainer
role
for
the
repos,
so
people
coming
casually
to
update
random,
bugs
and
stuff
seems
fine,
but
if
you
actually
want
to
have
the
keys
to
the
castle,
then
it's
nice
to
have
some
guide
some
guideline
to
understand
how
to
get
there.
If
you're
interested.
L
A
A
S
A
Would
would
you
be
okay
with
language?
That's
something
like
that.
Something,
like
you
know,
they've
made
a
significant
number
of
reviews
and
put
something
in
parenthesis
as
significant
is
obviously
subjective
and
will
vary
based
upon
the
repo.
But
you
know
at
least
then
they
know
it's
not
just
one.
M
M
Well,
in
other
language,
it
may
be
some
it's
shorter,
so
I
think
then
we
can
maybe
make
these
requirements
a
little
bit
more
art
on
each
repo,
but
the
reason
why
I
prefer
having
other
requirements
in
general,
it's
that
you
make
things
more
transparent.
So
if
you
use
software
requirements,
my
I'm
worried
that
this
could
make
it
could
make
decisions
less
transparent.
M
Okay,
that's
that!
That's
that's
really
my
concern
about
having
software
requirements,
but
again
these
we
can
maybe
relax
the
requirements
in
the
in
this
document
and
then
on
each
repo.
We
make
the
requirements
more
strict,
depending
on
the
language
depending
on
the
library,
depending
on
the
project
itself.
A
Okay,
so
I
think
in
the
document
here
there
are
two
different
sets
of
numbers.
There
are
things
like:
where
is
it
like
20
reviews?
There
are
those
types
of
hard
numbers,
and
then
there
are
other
sets
of
numbers
like
at
least
two-thirds
of
the
votes.
Based
on
what
I'm
hearing
here.
Is
it
fair
to
say
that
people
are
okay
with
things
like
two-thirds
of
the
voters
have
to
agree.
Those
numbers
are
okay,
it's
just
whether
we
want
to
loosen
these
numbers
like
the
20
reviews.
Kind
of
thing.
Is
that
fair
to
say.
A
A
A
Okay,
so
what
do
we?
Why
don't
we
do
this?
I
I'm
not
hearing
anybody
say
no
to
doing
the
rules.
So
what?
If
we
do
this?
What
if
we
say
we'll
give
people
one
more
week
to
offer
up
alternative
language,
we'll
put
a
message
out
into
the
sdk
slack
channels
to
warn
people
that
they
need
to
speak
up
by
next
week,
because
if
we
don't
hear
any
major
objections
to
doing
this-
and
you
know
whatever
minor
tweaks
of
the
wording
we
make
between
now
and
then
hopefully,
they'll
be
they'll,
be
done
relatively
quickly.
A
But
we're
going
to
approve
this
thing
next
week
and
be
warned:
this
will
be
at
the
community
level,
which
means
it
will
apply
to
all
sdks,
and
so
they
need
to
review
it
and
and
and
it's
it's
what's
the
term
people
use
lazy
consensus
kind
of
thing,
so
they
better
speak
up.
So
it's
a
it's
a
warning
shot
across
the
bow
to
pay
attention.
A
P
Yeah
sure
so
yeah
I
want
to
first
give
the
preface
of
I
think
some
of
these
issues
have
been
solved
for
our
contacts.
I've
been
wishing
to
use
some
developing
some
packages
and
samples
for
javascript
using
cloud
events
and
I've
been
wishing
to
use
the
cloud
events
sdk
rather
than
just
manually
parsing
the
http
headers
and
embodying
and
creating
typescript
types.
P
Second
issue
is:
there's
just
there's
some
things
that
have
been
improved
over
time
about
just
providing
a
more
idiomatic
common
note,
experience
of
being
able
to
consume
and
sending
cloud
events,
and
I
do
ideally
like
one
line
of
code
where
you
don't
need
to
create
new
objects
for
emitters.
All
of
that's
been
been
fixed
still
still,
I
think,
there's
some
still
some
other
issues
that
we
could
fix
and
I
guess
overall,
like
I,
I
sort
of
wanted
wanted
to
understand.
P
P
P
A
A
So,
okay,
so
grant.
Let
me
ask
a
sort
of
a
naive
or
simplistic
question
here
for
the
things
that
you've
noticed.
Does
the
current
process
of
just
either
opening
up
issues
or
or
even
better
pull
requests?
Is
that
process
broken
in
some
way?
I
I
guess
I
was
kind
of
confused
when
you
put
together
this
list,
because
my
first
reaction
was
to
be
quite
blunt.
It's
like
okay.
There
are
issues.
Let's
get
some
pr's
generated
right.
P
R
R
R
You
know
we
javascript
sdk
and
the
python
sdk.
Those
were
our
starting
points,
you
know,
and
so,
if
and
we're
doing
a
you
know
a
kind
of
a
clean
room,
you'll
start
from
scratch.
Implementation
from
that,
so
yes,
of
course
you
know
we
have
kind
of
a
much
more
clean.
You
know
experience
when
we
don't
have
that
long.
History
of
you
know
churn
in
the
the
spec
and
users
and
bugs
and
all
that
stuff
that
makes
software
development
so
interesting.
R
P
P
The
main
issue
is
that
I
shouldn't
be
like
developing
a
demo
or
testing
in
production
and
then
finding
an
issue
in
an
sdk
are
in
the
in
the
I
guess,
the
experience
of
using
it.
I
know
there's
a
lot
of
tests
for
the
javascript
sdk,
but
somehow
I
don't
know,
I
think
they
were
like
100
something
tests,
but
then
something
for
like
receiving
a
cloud
event
like
like
somehow
the
tests
passed,
but
the
actual
developer
experience
failed.
So.
P
One
thing
that
I'm
looking
for
is
I'd
hope
I
mean,
I
know
that,
like
daniel
said,
a
lot
of
a
lot
of
the
change
has
been
incremental,
and
I
I
guess
what
I'm
I'm
looking
for.
Is
I
I'd
love
to
sort
of
like
finalize.
I
guess
the
javascript
sdk
and
move
on
to
other
languages
and
and
not
sort
of
have
months
where
we're
constantly
improving
the
sdk
and
we
sort
of
just.
A
So,
but,
but
help
me
understand
here
so
so
I
think
what
you're
saying
is
based
upon
your
experience
with
sdk.
There
are
some
things
that
are
lacking
and
that's
you
know
always
going
to
be
true
every
piece
of
software,
but
in
order
to
address
the
things
that
you're
seeing
I,
I
really
only
see
two
paths
forward
right,
because
you
can't
just
snap
your
fingers
and
say:
okay
tomorrow,
everything's
gonna
be
perfect
right
and
we
can
move
on
to
another
sdk
or
another
language
right.
A
P
L
L
You
know,
like
I
mean
this:
isn't
production
stuff
yet
we're
all
trying
to
work
on
this
and
try
to
get
to
a
common
place
and
the
reason
we're
doing
it
in
cloud
events.
Repo
is
so
that
all
of
these
vendors
go
and
participate
and
we're
trying
to
make
this
very
generic
solution.
That
fits
the
needs
of
a
lot
of
use.
L
Cases
like
one
of
the
balancing
acts
of
being
one
of
the
sdk
maintainers
is
that
you
have
to
think
about
features
for
specific
use
cases,
but
don't
exclude
the
myriad
of
other
use
cases
in
in
my
day-to-day
stuff.
I
only
think
about
kubernetes,
but
there's
not
a
single
kubernetes
thing
inside
of
the
golang
sdk.
P
P
R
Yeah,
so
I
think
what
I'm
hearing
here
is
that
there's
some
there's
a
sense
that
you
know
a
particular
sdk
is
really
not
production
ready.
It's
not
it's.
You
know,
they're
they're
they're
their
issues
with
it
and
there
isn't
a
us
there.
There
isn't
a
well-defined
path
and
a
well-defined
metric
for
saying.
Okay.
R
This
thing
is
this:
this
is
ready
now,
for
you
know
all
the
general
use
cases
that
we
cut,
that
that
we
expect
from
like
a
a
ga
level,
a
piece
of
software,
and
so
maybe
you
know
and
for
conformance
tests
have
been
have
been
mentioned
before
and
I
think
maybe
we
we
need
to
kind
of
define
okay.
So
what
what
does
it
mean
for
one
of
these
to
be
kind
of
quote,
unquote:
1.0,
ready
or
quote
unquote.
You
know,
general
general
availability
of
of
that
quality.
R
Where
and
then
kind
of
have
a
have.
A
comprehensive
set
of
tests
have
a
and
then,
and
then
you
have
a
way
to
measure
okay,
so
now
and
and
then
we
can
god,
then
then
we
can
number
one
test
against
that
and
then
have
a
have
a
goal,
and
you
know
to
be
able
to
better
communicate
these.
These
types
of
you
know
these
types
of
concerns.
So
oh,
this
isn't
working
for
my
my
case.
Well
is
your
case
in
the
conformance
test.
R
Is
it
is
it
part
of
the
spec?
Is
you
know,
there's
something
missing
from
the
spec
and
you
kind
of
have
those
those
kinds
of
conversations,
because
that's
that
sounds
like
what
we're
we're
we're
saying
here.
We
have
a
a
particular
experience
that
was
was
not
was
not
great
and
well
how?
What
is
that?
How
does
that
translate
into?
What
do
we
do
about?
What
do
we
do
about
it
in
the
sdk?
Well,
we
can
fix
bugs
here
and
there,
but
does
that
satisfy
the
the
experience.
R
And
so
you
know
bridging
that.
That's
that
gap,
kind
of
the
abstract
experience
for
for
a
developer,
doing
a
demo
and
then
how
meat
and
potatoes,
what
do
we
do
about
it
in
the
sdk
so
yeah,
maybe
maybe
having
a
a
a
conformance
test
or
some
metric
for
this
saying,
okay,
this
is
this
is
how
general
ga
quality
is
defined
for
our
sdks.
P
R
P
P
A
P
A
A
Struggling
with
what
you're
looking
to
get
out
of
this
conversation,
because
you
you
you,
you
express
your
your
concern.
You
think
that
the
sdk
isn't
where
you
need
to
be
okay,
but
I'm
not
hearing
a
path
or
a
suggestion
for
you
to
get
there
beyond
what
I
think
is
already
our
our
normal
process,
which
is
issues
pr's,
but
but
I
feel
like
there's
something
else
running
around
your
head
that
I
just
haven't
been
able
to
grasp
yet
that
you're
looking
for
something
different.
Besides
that.
P
P
M
Yeah
what
I'm
struggling-
and
I
think
dougie
already
said-
that
what
I'm
struggling
to
understand
from
this
conversation
is
what
is
for
you
and
sdk
production?
Really,
because
that
that's
that's
what
I
really
do
not
understand.
I
mean
that's,
not
a
requirement
that
is
written
on
the
stone
for
any
sdk
out
there.
I
mean
somebody
might
come
here
tomorrow
and
say:
golong
sdk
is
not
production
already,
but
it's
that's
not
enough.
I
mean,
if
you
have
some
ideas,
some
of
these
cases.
M
M
A
I
mean
sort
of
along
those
lines
it
sounds
like
grant,
may
be
useful
if
you
could
document
sort
of
your
vision
for
what
a
production
ready.
Sdk
looks
like
what
its
features
are.
What
is
the
user
experience
and
stuff
like
that,
because
if
nothing
else
it
will,
it
would
force
a
discussion
among
the
group
to
see
if
everybody
agrees
with
that
vision
and
hopefully
they
do
and
if
they
do,
then
that's
going
to
lead
to
you
know
either
concrete
issues
or
even
better
concrete
pull
requests
to
take
a
step
in
that
direction.
A
A
But
but
I
guess
the
one
thing
that
I
that
you
said
something
interesting,
though
grant
in
your
last
statement.
He
said
something
about
you
know
it
it's
taking
a
long
time
or
the
hearing
or
the
exact
wording
right.
It's
a
it's
a
very
time
consuming
process,
and
I
don't
think
anybody
would
disagree
with
you.
P
P
A
C
A
Oh,
this
should
be
this
way,
because
the
current
way
you
can
do
it
isn't
as
user
friendly
as
it
should
be
right
if
you
can
at
least
enumerate
the
things
that
you
think
are
missing,
that
keep
it
from
reaching
that
that
happy
state
that
you
want
to
get
to
get
being
able
to
jot
those
down
in
some
fashion
would
be
really
useful.
I
would
think.
A
P
P
S
There
are
there's
sort
of
the
really
simple
use
case
that
I
think
you're
looking
for,
but
there,
but
that
use
case
isn't
the
only
one,
and
it
might
be
that
you
know
in
in
a
certain
system.
We
know
that
all
of
the
events
are
going
to
be
structured,
for
example.
So
why
go
through
in
order
to
optimize
our
code?
Why
go
through
a
more
abstract
sort
of
just
receiver
thing
and
instead
actually
use
this
thing?
That's
a
little
bit
more
specific.
You
know
the
structured
receiver,
so
I
guess
that's.