►
From YouTube: CNCF Serverless WG Meeting - 2018-10-18
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
All
right,
it
is
three
after
the
hour.
What
are
we
going
to
get
started?
I
assume
you
guys
can
see
my
screen.
Okay
right,
I'll.
Take
that
as
a
yes
all
right,
move
forward,
so
I
don't
think
that
anything
special
to
mention
on
the
AI
is
when
Austin
gets
on.
If
I
don't
know,
please
somebody
remind
me:
we
need
to
name
to
send
the
next
SDK
call
community
time.
So
for
those
of
you
are
new.
This
is
a
time
when
people
who
don't
normally
join
the
group
can
bring
up
topics
for
discussion.
A
Is
there
anybody
I'm
a
call
who's
new?
They
would
like
to
bring
up
a
topic
and
Josh
already
have
your
topic
added
to
the
agenda.
I
believe
anybody
else
all
right
moving
forward,
then
without
Austin
here
for
the
SDK
I.
Don't
think
anything's
really
happened
there
other
than
the
golang
sdk
repoed.
That
vmware
was
working
on
was
just
officially
moved
over
this
morning
to
our
org
and
github.
A
So
if
there's
anybody
in
the
call
who
would
likely
add
it
as
a
maintainer
to
any
of
the
SDKs,
please
let
me
know
cuz
right
now,
I
think
I've.
Only
added
one
person
as
a
maintainer
on
one
of
the
projects
and
obviously
we
need
more
because
otherwise
nothing's
gonna
get
done
so
please,
let
me
know
if
you
won't
actually
work
on
those
and
now
the
time
to
jump
in
as
a
maintainer.
Well,
there's
nothing
there!
A
Kathy
I,
don't
see
her
on
the
call.
So
I
don't
think.
Anything's
happened
there,
though
relative
to
the
work
flow
subgroup.
She
joined
I'll,
ask
her
again
so
and
I
forget
some,
please
remind
me:
I,
don't
think
anything's
happened
there.
We
did
have
a
meeting
relative
to
the
Shanghai
coop
concessions.
You
can
see
the
links
to
the
document
and
the
slides
they're
working
on
mainly
Kathy
Clemens
myself
will
be
doing
some
presentations
for
the
intro
and
deep
dive.
A
I,
don't
think
it's
a
whole
lot
of
stuff
in
there
right
now,
I
think
Kathy's,
the
only
one
that's
actually
added
some
information
to
the
slides,
but
whether
you're
going
or
not
feel
free
to
review
those.
And
if
you
have
any
questions
or
comments
or
suggestions,
please
speak
up
and
we'll
try
get
them.
It
accommodated.
A
Eric
work
I
haven't
rolled
out
from
anybody
about
the
Interop
demo.
They
were
trying
to
do
for
coop
con
Seattle.
So
what
I
want
to
do
is
try
to
force
discussion,
so
I
will
be
sending
out
a
doodle
poll.
Unfortunately,
due
to
travels
and
stuff
I
need
to
make
it
end
kind
of
early,
so
expect
the
doodle
poll
to
come
out
later
this
afternoon,
but
I
will
shut
it
down
by
end
of
business
tomorrow,
with
the
hopes
that
we
can
maybe
have
a
meeting
early
next
week
to
start
talking
about
the
Interop
demo.
A
Okay,
so
just
the
heads
up
keep
an
eye
out
for
a
doodle
poll.
Note
alright
and
with
that
I
think
we
now
jump
into
PR
stuff
or
discussions.
So
last
time
we
were
talking
about
casing
of
our
properties
and
we
had
I
think
at
least
four
different
options
in
front
of
us
now.
Clemens
you
closed
one.
This
morning,
327
I
believed
you
want
to
talk
a
little
bit
about.
Why
you
closed
that?
One.
B
About
this
yeah,
the
the
microphone
yeah
so
I
had
to
PRS,
which
we
basically
we
went
through
the
last
time,
which
are
effectively
the
same.
The
second
one
and
first
one
here
in
the
list.
They
introduced
an
underscore
character
and
then
no
separating
all
the
terms
with
other
scores,
and
it
ended
up
looking
very
super
clunky,
I
think
and
to
effectively
limit
the
choices.
Unless
someone
really
really
really
really
wants
to
insist
on
the
underscores
and
then
I
can
go
and
revive
it.
B
But
so
this
is
the
one.
Yes,
so
I
caused
that
one,
because
ultimately
I
think
the
one
where
we
have
simply
a
certain
character
said
two
lowercase
characters
served
in
purpose
and
if
we're
doing
a
further
cleanup
of
names
where
we
strike
like
the
event,
prefix,
etc.
Then
legibility
is
not
going
to
be
too
terrible
and
so
I'm,
basically
we're
tracking
the
under
squads
on
this.
A
Okay
and
someone
on
last
week's
call,
it
may
have
been
Tim
a
care.
Member
mentioned
that
some
web
servers
have
problems
with
underscores.
So
I
did
a
quick
search
this
morning
and
I
did
find
this
link
stuck
into
the
agenda
doc.
That
talks
about
some
issues
that
some
servers
like
nginx
has
with
them.
You
can
tell
it
to
support
it,
but
have
to
go
out
of
your
way
to
support
it.
So
I
thought
that
was
kind
of
an
interesting,
a
little
bit
of
information
and
then.
B
So
that's
why
I'm
favoring
having
none
and
then
we
have
to
save
you
some
more
case
folding
and
that's
why
I'm
favoring
you
all.
You
have
lower
case
characters
and
that's
how
we
avoid
most
of
the
problems
and
I
understand
people's
desire
for
legibility,
etc.
But
all
you
needs
about
interoperability
and
with
the
least
common
denominator
approach.
A
C
I
mean
if
we
go
all
lowercase,
then
that
solves
my
issues.
So
nothing
to
add
really
are.
My
issue
was
was
like.
Clemens
was
saying
some
of
our
databases.
Don't
you
know
are
not
case-sensitive,
and
so
then
we
would
have
a
little
bit
of
difficulty
in
terms
of
these
long.
You
know
field
names
that
would
kind
of
get
munched
once
they
all
became
a
single
case.
A
A
E
A
Okay,
so
I'm
not
hearing
anybody
asking
for
327
to
be
reopened
in
that
case
am
I
correct
and
my
assumption
that
were
basically
then
back
to
I.
Guess,
I
want
to
say
two
choices,
but
technically
it's
three
because
we
could
choose
to
do
nothing
and
leave
it
as
is,
but
the
two
alternatives
for
making
changes
are
three
17,
which
is
camelcase
and
321,
which
is
lower
case.
Everything
with
no
underscores
I
believe
those
the
two
choices
in
front
of
us
Kristof.
A
F
Was
there
listening,
but
we've
run
out
of
time:
okay,
yeah
well,
I,
don't!
But
before
we
kind
of
start
arguing
names,
I
want
to
say
that
I
opened
the
first
PR
and
my
main
concern
was
that
spec
currently
doesn't
really
define
what
the
character
said
is
that
it
allows
why
space
control
characters
and
so
on,
and
it
doesn't
define
how
a
chibi
had
wrestled
and
I
think
it's
good
that
we
now
have
two
PRS
to
choose
from
and
they
both
address
these
concerns
so
I'm
also
super
happy
as
Clemens
PR
gets
merged.
F
I
think
it
addresses
the
same
things
and
that's
really
a
big
step
forward.
So
that's
the
big
big
picture
for
me:
I
still
prefer
camelcase,
it
looks
nicer,
and
so
what
I
did
is
basically
I
didn't
touch
any
of
the
attribute
names
I
kept
on
this
camel
case,
but
I
restricted
the
character
set
to
ASCII
I
disavowed.
Basically,
anything
that
is
not
enough
and
I'm
a
character.
F
The
difference
to
Clemens
is
that
I
or
the
difference.
Basically,
that
I
still
have
the
case
until
DBT
yeah
and
that's
basically
it
for
the
main
spec
and
the
question
is:
how
do
you
do
it
in
the
HCP,
which
is
actually
I,
think
the
only
transport
way?
Maybe
someone
can
correct
me
if
I'm
wrong,
but
I
think
all
on
our
transport
layers
that
we
currently
support
also
support
a
sensitivity.
F
So
then
the
DHCP
address
are
the
only
ones
that
don't,
and
so
here
that
kind
of
the
convention
in
HTTP
headers
is.
Is
that
you
separate
words
by
all
right.
Try
table
this
I.
Wasn't
that
says:
if
there
is
a
dash
in
front
of
a
character,
you
have
to
treat
it
as
uppercase
and
a
bit
if
there's
no,
it
should
be
lower
case
and
given
that
we
are
in
the
Escalade
character
that
it
is
actually
fine.
F
A
C
This
is
Josh
I'll,
just
say
that
you
know
the
one
of
the
reason
that
I
brought
up
327
is
because
you
know
in
but
I
think
I
mentioned
in
databases
in
some
of
our
databases
and
there's
no
case
sensitivity
so
that
mapping
kind
of
gets
I
know
it
looks
better
and
I
know.
Camelcase
looks
better
in
face-on
and
elsewhere,
but
in
some
of
the
databases
it
would
look
very
bad
just
pointing
that
out.
G
A
A
What
I'd
like
to
do,
then,
is
start
of
do
a
formal
vote
and
I
think
per
the
latest
governance
rules.
It's
going
to
get
seven
day
vote
so
which
gaenso
and
the
beginning
next
week's
call
what
I'll
do
is
I
will
I'll
put
a
comment
in
yeah.
I
do
have
some
ports.
Why
not
just
one
one
PR
to
take
a
look
at,
but
I
think
I
sort
of
thought.
This
thing
through
I
was
I
was
actually
gonna.
Do
a
CI,
vs
boats,
but
I
thought
we
had
three
choices.
A
So
tell
you
what
I
will
figure
out
which
PR
to
pick
on
and
put
a
note
in
there
asking
people
to
vote
one
way
or
the
other
for
317
or
321,
and
you
guys
will
have
until
beginning
of
the
phone
call
next
week
to
vote?
Is
there
anybody
who
would
like
to
vote
right
now?
Otherwise
I
was
just
gonna
wait
for
people
that
may
put
comments
into
the
PR
itself.
A
Oh
I'm,
sorry
Josh
you're
talking
voting
rights,
I
apologize,
so
oh
those
who
have
voting
rights
can
we
go
back
over
here,
get
the
link
I
apologize.
This
is
yours,
as
you
knew
the
group
Josh.
You
had
no
clue
about
the
wonderful
bureaucracy
we
have
so
anybody
any
company
that
has
a
green
box
associated
with
their
name
has
a
can
vote.
A
D
B
A
A
D
A
And
you
want
a
317
correct:
yes,
okay
got
it
all
right!
Anybody
else
would
like
to
vote
now,
all
right
cool.
In
that
case,
please
wait
for
the
comment
in
in
the
PR
and
then
you
can
vote
over
there
and
you
have
until
the
beginning
of
next
Thursday's
won't
call
to
do
that.
All
right
is
there
any
other
discussion
points
on
the
case
property
casing
issue
people
would
like
to
bring
up
before
we
move
on
okay,
Lou
next
on
the
agenda,
protobuf
I
don't
see
Spencer
on
the
call
I
Rachel
that
Thomas
came.
I
Can
I
can
say
some
things
about
it
if
that's
useful,
I
think
if
you
had
looked
at
this
before
and
you
had
made
comments,
your
comments
have
probably
been
addressed
in
this
version,
so
it's
worth
looking
at
it
again.
This
is
this:
doesn't
try
to
serialize
things
any
differently.
It
doesn't
try
to
match
up
JSON
to
print
a
buff
in
any
way.
So
it's
just
dealing
with
protobufs,
so
take
a
look
see
if
there's
anything
like
my
expectation
of
this.
Is
that
there's
nothing
controversial
in
this
we'll
see.
If
that's
true.
A
E
A
A
C
Sure
yeah,
so
we
started
having
some
discussions.
This
issue
and
I
mean
so
my
my
initial
feeling
was
probably
the
same
as
I.
Think
what
you
guys
initially
decided
was
that
hey,
you
know
what
an
ID
is.
It's
a
good
thing
to
have,
and
then
we
realized
that
you
know
we
didn't.
We
actually
didn't
need
it
at
all.
We
didn't
want
to
have
it
because
it
would
be
come
a
secondary
source
of
truth
or
what
isn't
a
unique
event
for
us
and
we're
one
company,
but
we
have
you
know.
C
One
group
that's
mission
is
to
have
an
accurate
accounting
of
events
that
happen
in
the
company
and
we
don't
necessarily
you
know
want
to.
We
don't
want
to
make
the
effort
for
the
bureaucracy
side
too,
to
make
sure
that
every
group
that's
going
to
be
submitting
events
into
the
platform
is
going
to
create
the
event
IDs
correctly.
C
So
we
said
you
know,
there's
no
need
for
an
event.
Ide,
there's
no
need
for
anyone
to
create
one,
because,
even
if
we're
not
going
to
necessarily
trust
it
so
for
us
we
just
want
you
know
the
data
that's
coming
in
and,
as
I
mentioned
in
the
original
comment,
the
data
being
who
created
the
event
in
which
system
at
what
time
and
what
type
of
event
it
is,
is
enough
to
uniquely
identify
the
event
in
every
case
that
we
have.
C
C
B
And
from
the
top
front
perspective,
so
if
I'm
from
a
it's
a
mediating,
middleware
visit
messaging
perspective,
let's
say
you're
producing
an
event
and
then
you
expect
that
an
event
to
pump
out
somewhere
else,
and
there
are
no
three
or
four
moving
pieces
and
robbers
in
the
middle
that
take
care
of
taking
event
in
holding
it
moving.
It
forwarding
it
and
then
making
making
it
ultimately
available
to
you
just
basically
for
Diagnostics
when
you
say:
hey,
I'm,
missing
this
event
and
I
wonder
where
it
is.
B
The
great
thing
about
the
event
idea
is
that
it
is
a
field
that
we
know
of
because
it
is
in
cloud
vents
and
that
we
will
put
into
logs
and
so
that
we
will
have
in
our
pricing
information.
So
if
you
show
up
at
our
support,
we'll
be
able
to
use
that
ID
together
with
your
tenant
information
to
go
with
that
event
and
and
basic
crazy,
that's
an
evidence
trail
to
help
you
if
you
are
I'm
using
another
combination,
you're
effectively
forcing
us
as
a
cloud
provider
to
do
a
correlation
query
through.
C
Yeah
some
so
I
saw
this
argument
as
well.
I
I
think
I
mean
that
makes
some
sense
for
sure
what
I
think
about
it,
though,
is
that
what
you're
talking
about
is
kind
of
like
a
trace,
ID
use
case
and
again
I
think
that
will
certainly
be
useful
under
certain
circumstances,
like
you
said
where
you
have
complicated
pipeline
of
things
happening,
but
I
think
that
using
the
event
ID
or
the
trace
is
necessarily
I.
Don't
know
I
mean
it's
not
necessarily
the
the
ideal
solution,
because
there
can
be
a
more
dedicated
field
for
for
tracing.
B
But
see
the
point
is
me:
as
an
infrastructure
provider
who
builds
generic
messaging
infrastructure
right
I.
The
point
of
almost
the
point
of
my
work
to
participate
in
here
is
because
we
want
we
want
cut.
We
want
to
have
standardized
minimal
metadata
that
we
can
rely
on
that
everybody
says
so
that
we
can
then
provide
services
like
traceability
and
Diagnostics
Osetra
and
debug
ability
ultimately
based
on
top
of
those
features.
B
So
so
you
turning
on
next
are
extensions
to
turn
on
features
that
we
have
that
it
becomes
very
complicated
and
that's
why
that's
why
message
IDs
are
required
in
messaging
systems
and
that's
why
these
event
IDs
are
made
required
here,
because
the
middleware
can
help
you
with
that
and
even
if
it's
not
complicated,
even
if
it's
just
a
topic
with
with
a
dispatcher
there
are
you
already
and
you're,
not
operating
it
any
or
anyone
to
have
traceability?
And
that's
that's
why
the
the
ID
here
is
hard
yeah.
G
And
just
to
add
on
to
Clemens
these
cases,
event,
ID
is
also
hugely
important
for
idempotency
and
though
it
may
be
possible,
within
your
specific
application
domain,
to
build
idempotency
on
the
specific
events
that
you
produce.
The
whole
point
of
cloud
events
is
interrupts
and
we
want
to
make
sure
that
anyone
who
receives
a
cloud
event
can
use
it
for
adding
potencies.
So
like,
though
it
may
sound
a
little
harsh.
G
H
Sorry,
just
to
push
on
that
on
maybe
Clements
point
a
little
bit
as
these
events
move
between
providers
doesn't
that
tracing
argument
fall
away
there,
because
it's
only
in
a
must
be
as
well
since
I
read
the
spec
is
that
eventid
meds
being
globally
unique
to
everybody
or
unique
to
a
publisher
or
unique
to
a
tenant
cloud
provider?
I
I
always
assumed
it
was
an
idea
signed
by
the
guy
that
generated
it,
and
it
was
just
unique
to
them
unique.
H
J
Yeah
I
think
this
board
has
a
very
good
discussion.
So
what's
the
unique
scope,
if
you
say
this
unique
for
further
event
producer
scope,
then
a
might
not
be
unique.
Further,
I'm,
sorry,
this
platform
scope,
it
won't
be
it.
It
might
not
be
unique
globally.
How
can
you
I'm
here
with
all
these
different
producers?
They
can
cooperate
well
that
they
all
use
different
event.
Ids.
K
Isn't
it
going
to
be
contextualized
within
that
the
source
contacts
like
Clarence
said,
but
then
again
the
domain
through
which
that
cloud
event
can
travel
is
going
to
be
security
restricted
anyway,
and
so
then,
that
context
is
further
further
boundary
within
which
it
needs
to
be
unique.
So
I,
don't
think
saying
it
needs
to
be
globally
unique
between
everyone
on
the
cloud
provider
is
actually
an
issue,
because
the
security
implications
of
that
would
be
massive.
So
as
we
have
these
boundaries,
that's
where
the
the
uniqueness
defines
its
context
and
that's
where
it's
needed
so.
J
Not
really
right
because,
for
example,
if
like
for
I'm
a
service
platform,
I
could
be
always
over
I
mean
maybe
like
over
time
even
sources
different
immense
sources.
How
could
how
could
I
be
sure
those
event
sources?
They
cooperate,
cooperate.
Well,
they
are
going
to
send
out.
You
know
they
are
going
to
assign
the
unique
event
IDs,
because.
J
If
it's
algorri
is
unique
per
that
source,
but
if
I
receive
events
from
many
different
sources
and
from
are
those
sources
belong
to
different
event?
Producers,
different
vendors,
I
I-
don't
think
you
know
as
a
even
consumer
as
a
service
platform.
I
can
be.
You
know,
peace
of
mind,
all
those
event.
Ids
are
I
unique
globally
and
all
you
need
her.
The
platform
scope,
I.
A
J
Yeah
source,
you
are
I,
think
that's
not
is
that
can
be
guaranteed,
but
I'm
thinking
you
know
we
cannot
guarantee,
is
unique
globally
or
unique
per
the
consumer
scope.
If
that
consumers,
you
know,
receive
events
from
different
event,
sources
different
event
when
their
producers
or
vendors,
so
I
I,
think
you
know
so
the
usage
of
this
event
idea.
Although
I
agree,
it's
it
will
ease
implementation
and
just
wondering
actually
I
think
this
PR
race,
race
raced
a
very
good
point.
J
K
I
think
my
point
was
the
company
that
that
we
work
with
we're
never
going
to
reach
all
the
security
considerations
that
are
required
if
our
events
again
are
going
to
be
naked
or
non-encrypted
within
the
context
of
other
events,
which
we
don't
trust,
there's
always
going
to
be
some
kind
of
security
context
which
is
trusted
and
within
that
security
context
you
know
who
you're
talking
to,
and
you
know
the
other
organizations
and
that's
the
boundary
within
which
you
have
the
ability
to
understand
whether
or
not
it's
going
to
be
unique.
So
long.
K
A
L
A
Hearing
I
think
I'm.
One
hearing
is
sort
of
two
different
discussions
going
on
here
at
once.
One
is
Joshua's
proposal
which
is
to
make
it
optional,
but
then
there's
a
there's,
a
secondary
discussion
here,
which
just
talks
about
whether
the
text
around
event
ID
needs
to
be
clarified.
With
respect
to
the
uniqueness
aspect
and
I
think
those
are
almost
separate
discussions,
because
whether
we
adopt
Joshua's
proposal
or
not
I
think
basically
what
I'm
hearing
it
sounds
like
people
do
want
a
little
more
clarity
around
what
the
uniqueness
is
for
the
event
ID.
A
Yes
I,
think
so?
Okay?
So
let's
take
that
as
a
follow-on
discussion,
and
it
will
start
a
separate
thread
about
that
one.
But
let's
try
to
circle
back
around
to
the
to
the
optionality
aspect
of
event:
ID
I'm
hearing
a
few
people
say
that
they
think
it's
important
to
be
there,
which
is
why
I
was
required
in
the
first
place.
A
A
C
Mean
I
think
I
think
that's
fair
enough
like
if
you
know
you,
if
you
want
to
define
the
cloud
platform
to
start
at
the
point
at
which
the
event
ideas
has
been
defined.
That's
fine
and
we'll
just
we'll
just
keep
our
our
stuff
that
doesn't
have
an
event
ID
in
it
separate
from
that,
and
if
we
need
to
use
any
tools
for
an
interoperability
sake,
then
we'll
transform
it
into
a
proper
cloud
event
by
creating
the
idea
at
that
point.
Okay,.
A
You
said
something
in
the
introduction
of
your
clear
issue
and
they
kind
of
stuck
in
my
head.
I
just
want
to
get
some
clarity
when
you're
talking,
you
said
something
along
the
lines
of
there
may
be
some
some
issue
with
people
generating
the
the
event
ID
properly,
and
it
was
the
notion
of
it
being
generated
properly.
That
I
got
a
little
confused
by.
Can
you
elaborate
on
on
why
people
would
have
it
difficulty,
because
it's
just
a
string,
it's
not
even
a
good.
So
what
do
you
mean
by
properly.
C
Well,
what
I
mean
is
that
that
it
has
the
meaning
that
it
intended
that
it's
intended
right.
So,
for
instance,
we
mentioned
somebody
mentioned
idempotency
right.
So
if
someone
is,
let's
say,
generating
a
good
every
time
they
make
the
call-
and
you
know
they
do
that
free
to
retry.
That
obviously
wouldn't
be
what
we
expected.
C
If
some
when
this
is
something
we've
seen
before,
if
people
have
accidentally
set
it
to
a
constant
value
or
not
set
it
at
all,
and
then
it's
a
constant
value
and
then
obviously
that's
not
what
we
want,
and
so
by
setting
it
properly,
that's
that's
kind
of
what
I
mean
or
you
know.
Maybe
they
make
it
a
hash
of
a
certain
set
of
fields,
but
they're,
not
the
right
set
of
fields
got
your
home,
so
yeah,
okay,.
A
Okay,
so
guaranteeing
the
uniqueness
aspect.
Okay,
that
makes
sense.
Thank
you,
yeah,
okay,
so
then
in
case
and
so
I'm
moving
forward
here
since
I'm,
not
hearing
anybody
else,
arguing
in
favor
of
this
proposal
am
I
hearing
the
the
consensus
of
the
group
as
of
right
now
is
that
we
could
be
closed.
This
issue.
A
I'm
not
tearing
the
objections
of
that
so
Joshua
I,
keep
in
mind
that,
just
because
we
may
close
an
issue
doesn't
mean
that
we
can't
reopen
it,
especially
if
new
data
pops
in
like,
for
example,
you
come
across
a
use
case
that
we
just
hadn't
thought
about
that
everybody
does
care
about
and
making
it
required
it
becomes
problematic.
We
can
definitely
reopen
these
things.
Okay,.
J
A
A
Okay,
cool
Thank,
You,
Joshua
I
appreciate
you
joining
the
call
okay,
so
we
have
a
Kafka
transport,
binding
PR
out
there
and
it's
been
out
there
for
quite
a
while.
Oh
let's
see
so
August
and
unless
I
messed
up
I,
don't
believe.
The
author
has
actually
commented
on
any
of
the
questions,
comments
or
anything
in
here
and
I've
asked
them
several
times
to
speak
up
or
they're
gonna
address
these
questions
or
comments.
I
have
heard
back
from
them.
A
I
did
give
them
sort
of
a
little
bit
of
a
warning
shot
saying
you
know
if
it'll
speak,
don't
mention
anything
by
this
Thursday
I'm
going
to
propose
that
we
actually
close
this.
But
what
I
want
to
first
do
is:
ask.
Is
there
anybody
on
the
call
who
would
like
to
champion
this
and
own
it
going
forward?
I.
A
K
A
The
minutes
I'll
add
a
comment
to
the
issue
or,
if
necessary,
to
the
PR
saying
that
you
volunteer
to
do
it
and
they
obviously
can
speak
up
and
object,
but
I
think
probably
the
best
way
to
move
forward
is
probably
open
up
a
follow
on
I'm
sorry
open
up
another
PR
that
just
picks
up
their
commits
and
add
stuff
to
it,
because
I
don't
think
you
have
the
access
rights
to
actually
modify
their
PR
directly.
That's.
A
M
A
Excellent,
thank
you
very
much.
I
felt
a
little
weird
closing
it,
but
without
any
movement
is
a
little
hard.
So
thank
you
guys
for
much.
Let's
see
last
item
on
the
agenda,
this
one
has
actually
been
there
for
a
while
from
a
process.
I'm,
sorry
from
a
release
process
perspective
I,
don't
think
we're
very
clear
about
whether
we're
going
to
version
each
of
our
documents
independently
from
each
other
or
bundle
them
all
together.
A
So
when
I
did
is
put
out
this
astromech
proposal
here
to
suggest
that
basically
we
take
all
of
our
normative
specs
and
the
primer
and
group
them
together.
It
has
a
single
logical
unit,
which
means,
as
we
move
to
point
two
point,
three
or
one
point
or
whatever
everything
will
get
tagged
with
that
particular
version
number,
regardless
of
whether
that
particular
doc
itself
has
changed
that
way.
A
Everything's
sort
of
added,
consistent,
semver
number,
the
only
doc
as
of
right
now
that
would
not
be
included
in
there
is
the
extension
document
since
that's
more
like
a
wiki
page
more
than
anything
else,
but
it
would
include
the
main
spec,
the
primer,
the
transport
bindings.
All
those
things
would
get
lumped
together
and
so
that
that's
my
proposal
for
how
we
handle
versioning
of
our
Doc's.
I
A
I
Like
we
have
a
lot
of
moving
parts,
you
have
a
lot
of.
We
have
a
lot
of
specs
right
now
and
thinking
about
like
what
it
was
like
for
them
to
for
them
to
like
move
along
at
their
own
pace
or
all
move
together
through
semantic
versioning
has
different
implications
like
say,
I'm
thinking
about
the
JSON
spec
JSON
spec
is
fine,
but
this
other,
like
the
proto
spec
needs
to
increment
I,
might
be
miffed
if
I
had
to
like
continually
like
increments.
I
Oh
so,
for
example,
if
every
time
something
increments,
we
increment
every
single
thing
we're
going
to
get
up
to
pretty
high
numbers,
pretty
quickly,
for
example,
and
I,
don't
know
it's
just
why
we're
thinking
about
rather
than
just
saying
like
this
looks
like
I
I,
think
I
think
this
is
probably
the
right
thing
to
do.
I'm
just
saying
we
should
think
about
it
for
a
second
yeah.
A
And
I'm,
not
yes,
unless
everybody
was
saying
yeah,
yeah
yeah:
let's
do
this.
I
was
I,
wasn't
gonna
say
push
to
resolve
this
one
today,
I
just
wanted
to
bring
it
up
to
people's
attention,
because
I
do
think
we
need
to
get
this
resolved
at
some
point.
So
I
agree
with.
You
definitely
take
some
time.
Look
this
over!
G
I
wonder
if
we
can
come
up
with
a
process
that
fixes
that,
where
we
don't
end
up
in
weird
situations,
we're
like
on
one
hand,
I
totally
get
the
primer
for
version.
2
should
be
associate
with
version
2,
but
if
I
add
to
the
primer
in
order
to
help
people
better
use
version
2
it's.
Where
did
that
now
makes
version
2.1.
A
G
A
Okay,
obviously
I
said
don't
want
to
push
this
thing
takes
on
just
take
some
time
to
think
about
it.
Are
there
other
ideas
that
people
have
on
the
call
here
that
they'd
like
to
offer?
Even
if
it's
just
a
something
you
just
thought
about
that
this
exact
moment
it
hasn't
been
five
fully
a
thought
through
just
to
get
some
brainstorming
going.
I.
H
Think
this
sort
of
works
because
we
should
allow
changes
to
document
said
the
minor
or
patch
level
yeah.
So
you
try
to
group
a
family
of
things
together,
yeah
and
that's
really
to
me
the
major
version:
I
guess
it's,
whether
you
you
treat
major
and
minor
as
a
room,
darris
air
releasable
item,
because
all
those
other
things
are
really
saying.
Yeah
I
want
to
add
a
Cathcart
binding
to
version
no
got
one
that
shouldn't
change.
The
major
release
of
that
respectfully.
H
Exactly
well,
I
mean
it's
whether
you
want
to
take
you
to
X
dot,
Y
or
whether
you
just
want
to
take
you
to
X
I
mean
we
follow
our
API
versioning
internally
at
PayPal
follows
that
major
version,
semantics
yeah.
So
you
you
subscribe
to
a
major
version
of
something
and
everything
is
compatible
with
in
that.
So
stuff
can
evolve
minor
or
patch
levels,
and
you
can
add
new
features
yeah
without
all
mappings
without
breaking
stuff.
So
it's
where
you,
where
you
want
to
pin
the
level
of
grouping
that
I
think
is
important.
A
So
that's
interesting,
I'm
a
little
nervous
about
suggesting
this,
but
sometimes
additional
text
for
clarity
sake
isn't
necessarily
a
bad
thing,
even
if
it
is
a
bit
duplicate
of
the
semver
kind
of
defines
all
this
already
right.
Members
basically
says:
all
minor
versions
are
supposed
to
be
compatible
anyway,
but
would
it
be
useful
to
call
out
that
aspect
in
this
definition
that
way,
people
understand
that
you
know
just
because
we
goto
1.1
business
I
mean
you
have
to
jump
up
to
one
point
one,
because
1.0
is
still
fully
compatible.
A
Okay,
not
hearing
anything
I'm,
not
gonna,
add
unless
someone
says
so.
Okay,
so
take
your
time
think
this
over
it
will
still
be
on
the
agenda
for
next
week.
I,
don't
think
we're
necessarily
a
huge
rush,
but
obviously
before
we
get
to
one
point,
though,
we
need
to
make
you
know
this
kind
of
decision
going
forward.
A
A
A
A
A
N
A
A
A
That
was
supposed
to
be
a
cancellation
notice.
All
I
think
yeah
that
I,
because
I
I
apologize
I
misunderstood
what
you're
saying
I
can't
remember
the
person's
name,
I
think
the
person
name
is
Taylor
the
one
of
the
CNCs
sort
of
administrative
people.
They
ping
me
yesterday
asking
whether
they
should
remove
the
work
flow,
subgroup,
calendar,
invite
and
I
said
yes,
because
we
were
not
doing
a
rate
of
a
meeting
anymore.
So
maybe
they
made
a
mistake
and
they
sent
out
a
modification
rather
than
a
cancellation,
but
it
was
supposed
to
be
a
cancellation.
A
J
That's
correct,
I
think
for
the
workgroup
that
draft
I
think
we
still
need
to
go
through
it
and
there
are
some
where
I
saw
some
arrows
there.
So
maybe
in
after
the
coop
come
from
hi
I'm
going
to
go
through
it,
then
you
know
post
a
new
PRS
to
correct
those
things
and
other
people's
are
welcome
to
go
through
it.
And
then
you
know
pour
issues
or
you
know,
pour
PRS
yeah.
J
Now
is
managed
by
this
group
yeah.
Previously
we
had
a
separate
sub
group
meeting
we
have.
Then
we
reached
some
consensus
on
the
first
draft
and
then
we
decided
there
is
no
need
for
you
know
that
intensive
meetings
so
we're
going
to
just
discuss
it
in
as
part
of
this
group,
but
if
needed,
you
know
we
can
always
have
you
know
another
another
meeting,
specifically
on
the
workflow
draft.
J
A
To
answer
your
question
from
our
broader
perspective,
if
the
workflow
specification
that's
been
developed,
becomes
mature
enough
to
warrant
it
being
sort
of
a
standalone
entity,
then
I
could
see
a
new
workgroup
or
whatever
the
proper
word
is
for
it
being
initiated.
Since
the
cloud
events
is
focused
just
on
the
cloud
event,
spec
itself
and
the
workflow
sits
on
top
of
it.
So
I
probably
a
separate
entity
at
some
point
in
the
future.
Once
it
gets
mature
enough
yeah.
H
A
Yeah,
okay,
yeah:
it's
actually
kind
of
funny,
you
think
of
it
right,
because
you
got
the
workflow
subgroup,
which
is
under
cloud
events,
which
is
technically
still
sort
of
under
the
service
workgroup.
Even
though
they're
somewhat
separate
entities,
we
have
those
kind
of
a
weird
relationship
right
now.
So,
okay,
thanks
yeah,
okay,
any
other
topics.
If
you
want
to
bring
up,
we
have
five
minutes
left.