►
From YouTube: CNCF Serverless Working Group 2020-05-07
Description
CNCF Serverless Working Group 2020-05-07
C
D
F
G
A
D
I
A
A
H
A
C
A
A
J
A
All
right
three,
after
let's
get
this
show
on
the
road
all
right,
computer
design,
anything
from
the
community.
People
like
to
bring
up
all
right,
not
hear
anything.
So
this
is
kind
of
funny.
Teneriffe
was
last
week
or
during
this
week
we
found
out
from
Vinay.
He
wanted
on
mute,
I'm.
Sorry,
that's
okay,
I
got
10
dateless
now
I
was
gonna,
say
oh
yeah,
so
I
got
a
message
from
Liz
who's,
the
TOC
chair
and
apparently
the
TOC
would
actually
prefer
that
we
not
become
a
working
group
under
SigEp
delivery.
A
So
we're
looking
for
a
time
when,
when
we
can
all
chat,
don't
know
where
it's
gonna
go,
but
it's
not
let
you
guys
know
that
that's
the
current
status
of
things
just
kind
of
interesting
I
mean
I'm
the
one
hand
it's
actually
it's
kind
of
nice
that
they
think
that
our
area
is
important
enough
to
warrant
its
own
sig,
which
I
guess
is
good,
but
that
also
then
probably
means
lots
of
extra
bureaucracy
for
for
us.
So
good
and
bad
points
anyway,
just
like
I'd
mention
it
all
right.
A
So
technically
we
not
have
an
SDK
called
Scouts
over
this
week.
However,
given
that
people
have
done
things
like
added
SDK
type
topics
to
our
agenda,
there's
a
lot
of
chatter
going
around
around
some
relatively
significant
topics,
at
least
my
opinion
they're
significant
in
the
SDK.
It's
like
channel
and
issues
I'm
wondering
whether
we
should
switch
back
to
having
it
every
week
for
a
while.
F
D
A
G
We
do
have
a
meeting
just
with
the
Argo
team,
I
think
Monday
the
11th,
so
we're
gonna
start
I,
guess
our
kind
of
hopefully
talks
with
them
about
a
possible
integration
and
and
see
how
there
it
goes
and
yeah
that's
it.
We,
we
did
have
a
our
monthly
meeting
anyway
well
and
we're
just
joking
on
things.
But
yeah
next
step
is
the
talk
with
the
Argo
team,
and
actually
it's
funny.
A
A
All
right,
in
that
case,
Clemens,
couldn't
make
the
call
today,
apparently,
Microsoft
gave
them
today
and
tomorrow
off
lucky
them.
However,
we
did
on
last
week's
call
talk
about
bringing
up
his
proposal
for
a
new
sub
working
group
and
this
to
be
clearer.
This
would
be
under
the
cloud
events
banner,
not
service.
A
K
A
I
A
A
All
right
now
hearing
anything.
Thank
you.
Thank
you.
Everybody
Clemens
will
be
thrilled
all
right
and
so
well.
I
work
with
Clemens
offline
to
talk
about
the
structure
of
how
this
works.
For
example,
will
he
want
to
try
to
squeeze
time
into
this
call?
Do
you
want
us
up
a
separate
call,
a
directory
structure
or
repost
structure,
those
kind
of
things
you
know,
process
type
stuff,
we'll
talk
offline
about
that
that's
necessary
and
we'll
bring
that
back
to
the
group
before
any
decision
is
made
all
right.
K
Doggett
I
want
one
more
comment
on
that
like
we,
it
feels
like
we
started
the
discovery
subgroup
or
that
the
discovery
work
as
well
as
the
subscription
work,
and
it
feels
like
we
haven't
made
like
meaningful
progress
on
like
those
as
a
whole.
So
I
guess
my
other
question
is
like.
Should
we
should
we
make
sure
we
focus
on
one
thing
and
and
not
and
not
make
you
know
slightly
incremental
progress
on,
but
not
getting
anything
done.
Yeah.
A
I
actually
funny
you
mention
that,
because
I
actually
did
talk
to
Clemens
slightly
about
this
before
when
he
first
proposed
this
I
said
you
know,
I,
don't
miss
I
have
a
problem
with
this
concept.
I
just
fear
that
it's
going
to
slow
down
the
other
work
that
we
have
going
on
and
he
didn't
seem
to
think
it
would.
Obviously
it's
just
his
opinion,
though
I
I
hope
you
like.
This
is
not
something
that
we
can
necessarily
fix
up
front
I
think
we
have
to
see
how
it
plays
out
and
I.
A
Think
your
initial
comment
there
about
things
appearing
to
slow
down
on
the
to
new
specs
is
definitely
true
and
I've
definitely
be
concerned
about
this,
which
is
why
I've
been
trying
to
open
up
issues
here
last
you
know
today
you
could
try
to
force
some
discussions
to
happen
and
in
particular,
then
hopefully,
for
some
PR
is
to
happen.
I,
don't
know
whether
it's
because
people
are
losing
interest,
people
are
just
busy
I,
don't
know
what
the
reason
is.
A
C
A
I
I
F
F
F
E
F
A
J
I
mean
I
was
just
you
know,
my
understanding.
Your
original
question
was,
though,
building
an
implementation
to
see
if
the
spec
makes
sense
rather
yeah
I
agree,
there
should
be
a
reference
implementation
in
the
future,
but
I
think
the
first
step
is
to
try
and
implement
what
people
are
designing.
Almost
like
a
code.
I
don't
want
to
say
code
first
rather
than
spec
for
us,
but
it
seemed
to
be
that
sort
of
approach
rather
than
coming
at
it
from
a
reference
implementation
perspective.
I
I
A
At
this
point
in
time,
is
there
anybody
willing
to
raise
their
hand
to
say
that
they
would
be
interested
in
it,
at
least
in
the
short
term,
I
know
long
term
I'm
sure
people
will
probably
come
on
board
later,
but
I'm
just
wondering
it's
that
we
can
get
started
now
on
or
is
it
too
soon?
People
too
busy
interested.
A
A
A
Do
does
anybody
else
have
any
had
other
ideas,
because,
because
I'm
stumped
here,
to
be
honest,
I
mean
unless
you
guys
want
to
just
give
it
a
little
more
time
and
see.
You
know
whether
the
new
issues
help
whether
someone
will
magically
find
time
to
start
doing
implementation
work.
Obviously
we
can't
strongarm
people
too
into
doing
stuff.
This
is
like
open
source
for
me.
J
Well,
I
I
think
this
comes
back
to
the
focus
issue.
Yeah
there
seems
to
be
a
lot
of
you.
You
could
even
argue
could
split
discovery
and
subscription
yeah,
and
maybe
it's
just
the
size
of
those
those
things
that
are
difficult
for
people
to
digest,
if
they're
not
intimately
involved
with
it.
If
that
makes
sense.
J
A
J
A
A
J
K
Me
what's
one
thing:
looking
back,
it
felt
like
we
made
a
lot
of
progress
when
we
had
actual
working
subgroups
dedicated
to
these
issues
and
once
we
pulled
them
back
up,
you
know
we
merged
those
four
requests
and
then
the
activities
sort
of
died
off
so
I
wonder
if
just
you
know
not
strong-arming,
but
assigning
responsibility
would
be
helpful.
Okay,
I.
D
A
F
A
I
do
not
know
if
they
have
a
specification.
Written
up.
We'd
have
to
wait
for
him
to
come
back
to
know
but
I
hate
to
be
honest,
I'm
I'm,
not
as
concerned
of
that
right
now,
I'm
more
concerned
about
the
slowness
of
our
two
specs
in
front
of
us
and
Ryan
your
comment
about
things
making
progress
when
there's
when
we
had
subgroups
I
I
do
agree
with
you
Mike.
My
concern
was
sort
of
punting
it
to
a
subgroup.
A
Is
it
feels
a
little
bit
and
maybe
I'm
I
shouldn't
be
speaking
for
Mike
and
Clemens,
but
it
seems
a
little
bit
unfair
because
I
I
felt
like
we
based
got
two
people
doing
all
the
work
and
I
know:
that's
not
necessary
hundred
percent.
True
cuz,
there
were
other
people
who
were
joining
phone
calls
and
stuff,
but
I
just
got
the
sense
that
it
was
all
put
on
one
person's
shoulders
and-
and
that
doesn't
seem
quite
right-
we're
supposed
to
be
a
group
here
trying
to
push
this
thing,
but
Mike
did.
A
A
K
A
And,
to
be
honest,
that's
part
of
the
reason
why
I
was
opening
up
some
issues,
because
because
if
someone
saw
a
smallish
issue
out
there,
they
may
then
just
jump
up
and
say:
hey
I
will
take
that
small
issue.
My
service
ample
lance
was
saying,
he's
new
he's.
Maybe
do
you
think
a
little
uncomfortable,
try
and
jump
in
there,
but
maybe
one
of
those
issues
is
small
enough.
A
So
I'm
not
hearing
any
any
real,
significant
suggestion
here
in
terms
of
how
to
fix
this
problem,
so
I'm
inclined
to
say,
keep
on
the
path
or
on
right
now
and
ask
people
to
please
open
up
issues
even
for
things
that
you
think
are
silly
just
to
force
some
discussions,
because
it's
like
I
said
it
in
another
call
I,
actually
think
that's
what
happened
with
cloud
events.
We
had
a
whole
bunch
of
issues
out
there.
Some
of
them
were,
in
my
opinion,
really
silly
in
nature
and
just
flat-out
wrong,
but
nothing
else.
A
E
That
that
scene
is
reasonable.
It's
a
from
from
our
perspective
in
terms
of
where
I'm
at
currently,
in
terms
of
my
internal
group
we've
had
some
recent
product
changes.
That's
loaded
a
lot
of
things
down
so
I'm,
trying
to
reevaluate
what
this
project
is
doing
with
some
other
projects
are
going
on
a
separate
but
I'm
trying
to
see
if
there's
actually
connection
and
that's
with
open
telemetry,
so
I'm
gonna
be
taking
more
time.
A
A
If
my
computer
wakes
up,
you
guys
see
the
spinning
thing
there
we
go.
Alright
I
was
hoping.
This
would
be
an
easy
one
to
get
behind
us,
so
Fabio
opened
up
PR
to
change.
The
avro
schema
I
believe
this
is
their
scheme
array
just
to
rename
it
for
cloud
events
to
Avro
cloud
events.
This
seem
like
a
no-brainer
to
me,
but
I
know
nothing
about
Avro,
so
I
don't
know
what
their
schema
talks
are
normally
like.
Does
anybody
on
the
call
have
any
comment
about
whether
this
is
a
bad
thing
to
do
or
a
non-normal.
M
N
H
M
A
H
A
A
K
A
Well,
it
sounds
like
there's
enough
possibility
of
think
that
this
being
a
BAC,
a
a
breaking
change
that
I'll
take
the
action
I,
don't
the
pink
favio
and
ask
him
about
that
since
I'm,
assuming
he's
a
pro
expert
and
if
he
comes
back
and
says
yes,
it's
a
breaking
change,
then
we
need
to
really
think
hard
about
why
they
want
to
do
it
because
that's
not
good
put
it
that
way.
So
there.
F
A
A
A
Okay,
so
apparently
this
this
having
no
here
breaks,
I,
could
think
tooling
is
what
this
is
Thomas
right,
yeah
Thomas
was
saying
this
will
break
some
tooling,
and
so
he
just
wants
to
remove
it
I'm,
assuming
no
one
cares.
This
is
all
part
of
the
new
spec
in
it.
Everything's
gonna
change
anyway
over
time,
but
anybody
have
any
problem
with
this.
K
A
Fix
that
alright
distributed
tracing
Francesco,
do
you
want
to
talk
about
this
one
today,
or
do
you
want
to
actually
or
do
you
or
because
there
is
activity
recently
or
do
you
want
to
continue
having
these
discussions
offline,
or
do
you
want
to
try
to
force
the
discussion
today?
I
McCall
I
feel.
A
F
Ian
is
not
there,
I
think
I,
don't
see
him
now,
but
I
mean
he's
proposing
to
change
the
behavior
of
this
back.
While
my
PR
is
not
changing
the
behaviors
just
trying
to
reward
and
make
clear
what
what's
the
goal
of
the
session
right.
A
A
A
M
A
A
A
F
A
Yes,
fine
guys
I
know
he
has
some
opinions
on
this
one
okay.
So
this
one
I
thought
I
supposed
to
remove
this
one,
because
we
talked
about
this
one
last
week.
A
I
A
Well,
it
seems
to
me
that
at
some
point
we
need
to
come
to
a
decision
and
I
know
that
there
was
okay.
I
know
there
that
there
are
plenty
of
people
who
say
that
graph
QL
is
nice
and
I
like
it.
However,
I
think
the
last
time
we
talked
about
this-
and
this
is
I-
think
I'm,
probably
very
biased.
So
please
someone
jump
in
to
correct
me,
but
my
general
take
of
it.
A
Most
of
the
conversations
we
had
up
till
date
were
yes,
graph
kill
is
nice,
but
we
should
probably
still
support
a
simplified
REST
API.
That
does
not
require
seven
like
graph
QL,
but
that
we
can
do
a
graph
QL
as
an
optional
layer.
On
top
of
it,
that's
my
interpretation
anyway.
What
previous
conversations
were
like
look
like
I,
said,
I'm,
probably
very,
very
biased.
Does
anybody
want
to
chime
in.
I
A
J
I'm,
a
fan
of
graph
QL
I
mean
I,
wonder
I,
understand
a
concern
with
would
drift
of
resource
or
entity
models
or
whatever
you
want
to
call
them,
but
I
wonder
if
you
can
address
that
with
you
know,
having
common
representations
that
you
know
are
managed
together.
So
the
you
know,
that's
certainly
something
we're
starting
to
do.
Have
common
models
that
are
updated
together.
J
M
Visiting
this
topic-
and
it
is
my
only
concern-
is
from
what
readings
I
have
done.
It
seems
a
more
efficient
manner
to
access
data
etc,
but
it's
the
interoperability
and
being
using
rest
for
I,
don't
know,
let's
say
a
decade
or
so,
and
how
the
implications
on
interoperability.
That's
my
only
concern
mm-hmm.
K
I
think
you've
provided
us
feedback
before,
but
to
me
like
the
success,
for
this
whole
thing
is
adoption
and
so
I
just
question
how
widely
supported
and
adopted
is
rep
QL
across
vendors
across
companies
across
systems,
and
that's
really
the
question
for
me.
It's
like
I
like
graph,
you
all
might
myself,
but
is
it?
Is
it
something
that's
going
to
help
or
hinder
adoption?
I.
A
O
Sorry
good
so
just
my
two
cents
I
just
wanted
to
mention
that
draft
Clio
is
pretty
dumb
specification.
Actually,
if
not
talking
about
the
HTTP,
binding
and
so
on
and
so
forth,
and
adding
support
for
it
doesn't
require
a
complex,
SDK
or
anything
so
I
guess
we
are
talking
about
very
lightweight
specification,
that's
very
easy
to
add,
support
off
and
there's
nothing
to
be
afraid
of
kinda.
A
Yeah
I'm
definitely
hearing
that
consistent
theme
that
it
is
relatively
lightweight
and
it's
not
a
huge.
It's
not
a
huge
burden,
and
forgive
me
for
trying
to
put
words
in
people's
mouths.
I
think
what
we're
hearing,
though,
is
it
is
more
of
a
burden
than
say
just
vanilla.
Rest
is
what
I'm
hearing
and
there's
a
concern
that
people
express
that
in.
If
we're
looking
for
me
as
wide-eyed
op
ability,
as
we
can
wrest,
might
be
the
more
appropriate
choice
but
Jim.
J
All
that
happens
is
a
burden
gets
moved
around
yeah,
because
if
you
with
the
sort
of
query
semantics,
that's
where
you
know,
if
you're
trying
to
do
queries
on
on
a
restful
interface
that
can
become
very
messy
and
just
graph
QL
simple
eyes
that
aspect
of
it.
But
then
it
pushes.
You
know
the
complexity
into
the
server
yeah.
M
J
You're
gonna
have
that
complexity
for
trying
to
decode
restful
based
queries
as
well,
so
I
I
see
them
as
complementary,
but
I
agree,
there's
a
danger
of
sort
of
creating
two
solutions
to
the
same
space
and
again
I
think
we
come
back
to
that
until
you
have
clients
that
wanna
integrate
against
these
things
and
and
see
what
the
use
cases
are.
That's
when
it
may
become
more
obvious,
which
is
a
more
viable
option.
H
I
J
So
why
would
it
be
I
mean
it
I
think
it
all
comes
down
to
the
information
model
that
you're
trying
to
query
on
there's
no
I
mean
that
I
think
is
part
of.
Is
that
part
of
the
sticking
point
with
this
is
just
trying
to
agree
the
the
model
that
we're
trying
to
query
on
whether
is
a
graph
QL
model
or
a
restful
implementation
emit.
I
A
I
A
Yeah
anyway,
you
didn't
speak
up,
but
I
agree
with
you.
I
probably
would
have
us
kept
quiet
as
well,
because
I
heard
enough
people
would
say
or
expressed
concern
that
yeah
okay.
So
let
me
make
it
a
little
more
formal,
so
I
guess
the
proposal
is
to
start
out
with
the
the
rest
API
and
then
revisit
this
issue
at
some
point
in
the
future.
We
can
change
our
mind,
but
we
will
definitely
revisit
it
before
the
spec
goes
1.0,
because
before
anything
with
1.0,
we
can
change
anything.
M
A
To
be
clear,
I'm
not
proposing
that
we
closed
this
issue,
I'm
just
proposing
that
we
defer
it
because
I
do
want
to
even
and
before
we
go
one
point,
oh
I'm
just
trying
to
look
for
as
we
start
hopefully
filling
out
these
specifications.
What
is
the
API
right?
We're
gonna,
bright
up,
you
know
tomorrow.
Is
it
rest,
ORS
or
graph,
QL
and
I?
Think
I'm,
hearing
more
people
say,
let's
start
with
with
rest,
so
the
proposal
is
to
do
that
and
then
revisit
this
later
before
we
go
1.0.
E
A
A
L
P
A
P
We
have
our
own,
we
use
typescript
rap,
which
many
Google
open-source
projects
and
the
current
f-ck
of
the
for
JavaScript
does
not
support
tech
script
and
it
also
uses
a
really
weird
object.
Creation
pattern:
that's
served
over
like
it's,
not
very
JavaScript
II
and
in
order
to
support
edge
good,
the
library
would
be
used
to
be
converted
to
you.
It's
good,
and
you
can't
just
add
that
trip
support
on
top
of
JavaScript.
P
P
With
at
least
one
maintainer
of
the
library
and
so
I
I,
don't
really
understand
like
how
to
proceed
from
here.
Yes,
there's
two
options
that
I
listed
right
there,
whether
we
could
say
we
should
add
petrol
support
to
the
dumpster
SDK
mom
just
requires
the
double
script
files
to
type
your
files,
just
adding
a
build
Whatcom,
and
you
don't
really
have
to
change
any
go
actual
source
files.
Another
option
would
be
to
create
a
separate
type
of
repo,
although
in
the
end
of
the
day,
it's
all
just
JavaScript.
P
D
I
hope
that
I
was
pretty
clear
about
that,
like
I'm,
not
opposed
to
that,
but
when
I
think
about
what
it
means
to
like
what
would
be
the
motivation
to
change
over
to
typescript
as
a
whole
like
completely
that's
a
developer
productivity
thing,
the
end
user
doesn't
really
have
any
knowledge
of
this.
For
the
most
part,
I
I
will
not
be
productive
in
typescript,
so
I'm
opposed
to
it.
D
O
Since
we
were
having
similar
issues
in
another
SDK,
Java
SDK
I
wanted
to
ask
a
question:
how
how
does
it
work
in
cloud
defense,
SDK,
community
or
group
when
there
is
one
maintainer
of
a
library?
And
then
there
is
controversial
discussion
and
a
decision
has
to
be
made
so
far,
I've
seen
that
the
maintainer
decides
of
and
it
doesn't
feel
that
the
SDKs
community-driven
it's
rather
one
person
who
makes
the
decisions,
but
then
it
it
doesn't
really
sound
like
a
CN
CF
project
and.
M
N
To
jump
so
like
sort
of
not
just
nothing,
nothing
sort
of
second,
what
sergey
said,
but
rather
point
out
the
fact
that
it
is
my
strong
to
leave.
Look.
I
don't
know
much
about
javascript
right,
but
there
is
somebody
who
does
and
somebody
who
believes
he
may
be
more
productive
or
somebody
believes
that
it
will
really
help
the
community
to
be
better
so
that
in
itself
says
we
need
to
do
it.
It's
not
a
question
of.
N
If
it's
a
question
of
how
do
we
gonna
approach
it
and
right
now,
for
example,
within
the
given
two
options,
it
appears
to
me
that,
for
example,
option
two
is
better
because
it
doesn't
it
doesn't
make.
You
doesn't
put
you
in
a
position
to
make
a
binary
decision
right,
but
again,
Sergey
is
point.
It's
really
more
about
the
fact
that
there's
a
community
and
community
expresses
certain
desires,
certain
concerns
and
the
maintainer
of
the
repository
may
not
be.
N
You
know
aware
of
all
these
concerns
and
that's
why
we
have
this
meeting.
That's
why
we
have
this
feedback
that
you're
asking
us
about,
and
so
on
and
so
forth.
We
need
to
I,
guess:
listen!
Learn
how
to
listen
to
it
in
a
way
where
it's
not
the
question
of
whether
we
need
to
put
that
script,
support
or
not
it's
a
question
of,
is
it
requested
enough?
N
A
N
I
Honey
yeah,
I
I
was
I
just
wanted
to
say,
+1
on
potentially
a
new
repo
for
typescript
because
it
does
seem
like
a
different
language
and
it
is
a
different
productivity.
So,
personally,
I
I
hesitate
to
use
typescript,
but
I
would
use
JavaScript,
but
I
also
don't
really
want
to
block
the
typescript
people
from
adoption.
So
for
me,
it
makes
sense
to
have
to
even
though
it
compiles
down
to
JavaScript.
O
B
Your
hands
up,
let
me
have
a
personal
opinion
about
dollars
to
decide
script
because
I
could
be
both
irritating.
My
question
is
for
the
people
who
are
living
living
this
there's
the
tip
on
our
side
and
the
consumer
side.
So
if
you
take
this,
hey,
it's
a
big
world
like
multiple
implementations
running
and
all
of
that.
What
confusion
is
docking
caused
from
the
user
side
where
they
come
in
and
say:
okay,
there's
two
equally
supported:
SDKs:
okay
for
nominally
the
same
thing
right,
the
JavaScript
browser
ecosystem.
B
A
D
So
so
I
I
want
to
be
clear.
It
is
I,
don't
think
it
is
a
binary
decision,
because
you
you
can,
basically
you
can
create
type
typescript
types
that
can
be
published,
definitely
typed
or
within
our
repository.
That
will
expose
your
JavaScript
code
through
some
typescript
representation,
but
you
don't
have
to
write
all
of
the
code
in
typescript.
You
just
write
these
little
types
that
expose
that
on
other
projects
that
I've
worked
on.
This
has
been
way
that
we've
handled
this
and
I
would
be
totally
happy
with
it.
D
I
just
don't
want
to
have
to
start
writing
and
I
don't
see
like
if
the
end
user
experience
is
still
just
npm
install
and
they're.
Not,
actually
you
know
working
with
the
code
itself,
then
it's
the
the
committers,
the
maintainer
z',
the
developers
on
the
sdk,
who
this
primarily
benefits-
and
you
know
I
get.
H
D
A
I'm
so
I'm
gonna
ask
this
question
not
having
touched
Java
in
years
and
never
touching.
Typescript
is
option
three
viable.
Can
you
add,
can
you
add
this
stuff
to
the
existing
repo?
Without
forcing
someone
to
step
over
to
type
scrub
pinyon,
they
could
still
do
JavaScript.
If
they
want
the
core,
they
can
use
typescript,
or
does
it
actually
require
a
separate
reco
to
make
it
happen?
No.
D
It
does
require
a
separate
repo.
It's
I
mean
I
can
give
you
I'll
link
an
example
here
in
a
second.
P
P
N
P
So
we
really
have
an
internal
version
of
a
crowd
event,
SDK
and
that's
sort
of
a
shame,
because
you
can't
contribute
to
the
existing
one
right
because
doesn't
support.
Thank
you.
Yeah
I
wouldn't
be
opposed
to
creating
a
separate
repo,
which
is
something
that
I
think
all
these
be
the
best
option
here.
I
think
it'll
still
be
a
shame
that
we're
gonna
have
implicated
functionality.
A
That's
what
I
was
going
to
ask
about
because
obviously
option
to
Z,
it
sounds
like
it
may
be
the
best
option,
based
on
what
you
guys
are
saying.
However,
I
do
know
that
we've
had
some
trouble
in
the
past
with
getting
people
to
participate
in
these
SDKs
because
they
get
pulled
off
other
things.
You
know
they're
busy
and
stuff
and
I'm
wondering
now
whether
having
to
repose
that
are
so
similar
in
nature
is
just
gonna
make
that
problem.
You
know
horse.
P
A
N
To
go
back
to
what
you
said
earlier:
it's
not
just
there's!
No,
there
should
be
no
objection.
It's
like
you
said:
let's
try
it
and
then,
before
the
oh
there's
going
to
be
a
chance
to
revisit
it,
you
talk
about
it
again
and
either
drop
it
or
continue
with
it.
So
that's
how
I
would
look
at
it
yeah.
It's
definitely
yes!
For
me.
Okay,.
A
P
A
Know
no
I
totally
agree
I'm
just
trying
to
follow
some
process
here
so
yeah.
Okay,
so
tell
you
what
let
me
do
two
things
here:
one
is
I'm
not
hearing
any
objection
from
it.
I
will
go
ahead
and
create
the
repo
for
you
guys
that
way.
You're
not
blocked.
A
So
what
I'll
do
is
I'll
add
the
next
week
agenda
the
idea
of
making
sure
there
was
no
objection
to
create
in
the
repo
and
if,
for
some
reason,
somebody
raises
a
good
point
and
everybody
says
hey:
this
is
a
bad
idea
and
we
vote
it
down.
Then
we'll
kill
the
repo,
but
at
least
the
in
don't
say
that
oh
that's
gonna
happen,
but
at
least
for
the
next
week
or
so
you
got
blocked
and
you
can
still
make
forward
progress.
I
don't
create
the
repo
today.
Is
that
sound,
fair.