►
From YouTube: CNCF Serverless WG 2021-03-11
Description
CNCF Serverless WG 2021-03-11
B
A
B
Well,
one
option:
it's
not
pretty
is
to
kill
the
pr
and
create
a
new
one,
or
I
mean
if
you
want.
I
could
take
a
stab
at
it.
If
you
want
to
save
your
work
first
and
if
you
want,
I
can
go
in
there
because
I
think,
as
an
admin
I
can
do
some
funky
stuff.
I
can
try
to
squash
it
and
rebase
for
you
or
whatever.
B
A
B
A
B
B
B
B
B
B
A
E
B
B
B
B
B
Let's
see
if
I
can
spill
this
right,
perfect,
thank
you,
yep
all
right
and
someone
else
went
flying
by.
Was
it
lou?
Are
you
there?
Yes
hi
good
morning?
How
are
you
good?
How
are
you
I'm
pretty
good?
Thank
you
excellent
all
right.
So
I
think
we
we're
three.
After
the
hour,
let's
go
and
get
started,
22.
okay,
cool
I
saw
I
did
remove
one
ai.
I
can't
which
one
it
was.
B
All
right
sdk
calls
this
week
just
to
quickly
double
check.
I
doubt
we
have
anything
on
the
agenda.
I
didn't
notice,
let
me
see
yeah,
so
we
have
until
the
end
of
this
call
to
add
something:
oh
wait,
a
minute,
yeah
yeah.
Sorry,
we
have
something
if
you
wanted
to
add
a
link
or
an
add
it
for
the
end
of
this
call.
Otherwise
we
may
not
have
a
call
moving
forward
discovery
interrupt.
I
don't
think
we
really
talked
about
anything
last
week.
B
Just
a
reminder:
we
are
planning
on
doing
the
interops
starting
at
the
end
of
march.
So
that's
about
what
two
three
weeks
away
or
something
like
that
workflow
two,
more
cities
can
make
it
but
they're
still
preparing
for
these
0.6
release
and
they're
hoping
to
have
that
done
next
week.
So,
if
you
have
any
questions
on
that,
you
may
want
to
reach
out
to
him,
and
I
did
sign
up
for
the
kubecon
for
the
office
hours,
which
will
give
us
two
45-minute
sessions.
B
B
C
E
B
B
All
right,
in
that
case
I
know.
Last
week
we
talked
about
possibly
merging
slinky's
sql
express
language
pr,
but
he
pinged
me
offline,
saying
he's
been
working
on
it.
He
thinks
it's
pretty
much
ready
to
go,
and
even
though
I
mentioned
that
we
were
probably
going
to
merge
it
this
week,
he
said,
let's
hold
off
another
week,
because
it's
kind
of
large
and
he's
in
no
rush
for
it
to
get
in.
B
B
All
right,
cool,
yep,
okay,
yeah,
I
didn't
think
anybody
was
in
a
big
rush
other
than
it
would
be
nice
to
have
a
rough
draft,
an
official
rough
draft.
Okay
in
that
case
next
one.
So
this
was
mine
in
response
to
lance's
request
for
a
little
bit
more
formalness
around
our
decision
to
change
how
we're
going
to
merge
trivial,
typo
type
prs.
B
B
B
Okay,
so
the
point
here
is
to
make
it
so
that
we
can
merge
typo
type
changes
without
having
to
worry
about
new
branches,
new
releases
and
stuff,
like
that,
there's
obvious
things
that
obviously
they're
just
typos,
but
anything
pretty
much
bigger
than
a
typo
would
probably
well
then
have
to
go
through
the
normal
release
process,
and
we
just
want
to
make
our
life
a
little
bit
easier.
So
hopefully
lance
that
satisfies
your
your
concern
and
your
ask
yeah
that.
B
I've
had
major
issues
here:
okay,
cool
now
that
was
it
in
terms
of
pr's
that
are
ready
to
go.
I
did
notice
a
couple
of
commits
go
flying
by
this
morning,
so
obviously,
that's
too
soon
to
talk
about
those
or
to
approve
those.
But
did
anybody
do
any
of
those
commits
want
to
talk
about
their
pr?
I
think
I
may
have
seen
something
from
lance
and
clements
either.
One
of
you
guys
want
to
talk
about
yours.
B
A
A
H
A
Yeah,
so
there
should
only
be,
I
think,
that's
what
I
pulled
in
that's
what
the
dco
issue
is
right,
so
we're
only
looking
at
this,
so
the
ignore
the
rest
I'll
go
and
fix
that.
So
I
have
two
events
that
are
defined,
so
I'm
defining
cloud
events
and
cloud
events
and
those
are
for
updated
and
deleted,
updated,
also
covers
created,
and
so
whenever
there's
there
are
three
modes.
If
you
scroll
up
a
little
bit,
I
can
go
to
the
to
the
the
actual
definitions
of
how
things.
B
A
A
Let
me
let
me
talk
about
the
motivation
for
this
for
for
a
moment,
and
I
believe
that
most
of
these
infrastructures
will
compose
so
most
of
the
event.
Brokers
will
compose
in
some
way
and
we
will
have
scenarios
where
we
will
have
to
go
and
route
from
one
to
the
other
and
we're
having
one
concrete
example
between
klaus,
what
klaus
does
and
what
we
do
where
there
is
in
cloud
system
over
in
sap.
A
They
have
a
event
broker
inside
of
their
own
application,
where
they
do
a
lot
of
event-driven
stuff,
and
now
they
want
to
involve
involve
applications
that
are
hosted
inside
of
azure.
So
we
kind
of
need
to
go
and
and
connect
all
the
connect.
Those
things
up
in
a
way
and
so
applications
will
first
post
to
the
sap
event
broker.
A
They
will
probably
have
to
go
to
one
or
two
hops
inside
the
sap
world,
and
then
the
events
will
hop
over
to
the
microsoft
broker
and
will
be
distributed
from
there.
So
that's
these
multi-hop
scenarios
is
something
that
I
envisioned
will
be
more
and
more
common.
So
now
the
question
is,
if
you're,
using
a
model
like
what
you
would
use,
what
you
today
use
with
kafka,
where
you
are
effectively
writing
an
app,
and
you
have
some
code
that
defines
the
events
and
then
you
start
publishing
the
events
in
a
in
kafka.
A
So
that's
the
thought
behind
this
and
there's
as
I'm
explaining
some
potential
topologies
in
this
section,
and
then
I'm
I'm
landing
on.
There's
a
pull
model
and
there's
a
push
model
and
then
there's
an
event
driven
model.
The
push
model
is
that
a
you
have
a
schema
registry
and
it
knows
about
a
target
schema
registry.
It
gets
it
is
configured
and
whenever
a
change
is
being
made
in
the
source
registry,
it
goes
and
just
pushes
to
the
target
registry.
A
A
So
I'm
just
also
mentioning
that
and
then
the
last
one
is
the
the
event-driven
model
for
which
I
have
the
events
at
the
bottom,
where
every
time
an
event
every
time
a
schema
or
a
schema
group
or
schema
or
schema
version
changes
or
when
it's
deleted
we're
raising
an
event.
And
then
the
party
which
is
receiving
the
event
notification
through
cloud
events
can
then
go
and
turn
around
and
fetch
the
change.
A
So
that
would
kind
of
be
the
the
the
middle
ground
between
the
between
the
two
and
kind
of
the
event-driven
reactive
way
of
doing
those
changes.
So
I'm
defining
all
of
those
all
of
those
three
cases,
and
then
there
is
a
yeah
and
I'm
effectively.
I'm
also
referring
there
to
our
to
the
authority
model
which
we
already
have
in
the
in
the
schema
registry.
A
B
Okay,
so
I
think
it
sounds
like
people
just
need
to
take
the
time
to
go
off
and
read
the
changes.
Thank
you
comments
for
doing
all
that.
Once
we
get
past
any
wording,
changes
or
issues
that
people
might
find
from
here
on
out.
Is
there
more
work
on
your
side
that
you're
planning
on
doing
on
this,
or
do
you
think
it's
pretty
much
ready
to
go
and
get
reviewed
and
merged.
A
B
B
F
B
B
B
That's
fine
just
wanted
to
give
you
a
chance
to
speak
to
it
if
you
wanted
to
okay,
in
that
case,
let's
move
forward
with
some
of
the
open
issues
in
particular
this
one,
I
thought,
might
be
interesting
and
problematic,
so
therefore
it
must
be
clemens.
So
therefore
clemens
you
want
to
talk
to
this
one.
A
Yeah,
this
is
something
that
phil
hack
brought
up
on
twitter
to
me,
and
this
is
something
that
we
had
already
kind
of
flagged
internally
a
while
ago,
but
for
some
reason
I
so
I
at
microsoft
it
was
something
that
we
stumbled
upon
and
I
then
failed
to
to
to
file
the
issue
and
then
someone
externally
came
and
said:
hey
there's
this
thing
and
I
said:
whoa
wait.
Sorry
there
was
something
so
now
I
felt
the
issue
so
the
the
the
web
hook.
A
Spec
is,
I
made
a
mistake.
I
wrote
I
wrote
most
of
it.
So
therefore
it's
my
mistake
and
that's
the
following:
the
origin
header
that
we
are
using
in
the
in
this
webhook
spec
has
a
very,
very
deceivingly,
similar
function
to
the
origin,
header,
of
course,
so
the
cross-origin
resource
sharing
and
I
have
I
had.
I
had
used
effectively
the
the
the
the
I
only
have
looked
at
the
core
spec
and
I
had
not
looked
at
6454,
which
score,
which
course
is
referencing,
and
I
had
not
looked
closely
enough.
A
A
The
origin
that
we're
using
here
is
the
the
push
engine
from
which
that
request
comes
from,
which
is
also
origin.
So
I,
as
I
wrote
this
spec,
I
kind
of
conflated
those
two
concepts
in
my
head
and
that
would
not
be
terrible
if
the
cor,
if
our
origin
header,
which
I
defined,
is
a
simple
dns
expression
and
the
origin
header
as
defined
in
rfc
6454,
is
a
uri
and
it
is
a
uri
that
must
be
the
root
of
the
site.
A
A
That
is
entirely
my
my
fault,
where
we
have
we're
using
in
the
spec,
the
origin,
header
or
a
header
named
origin
that
is
defined
as
carrying
a
dns
name,
which
has
a
different
semantic
function
than
the
origin
header
that
is
defined
in
rfc
in
that
rfc,
and
also
they
differ
in
the
rules
for
how
the
header
value
is
formed.
One
is
the
dnx
dns
expression
and
one
is
the
euro.
One
is
a
uri.
A
Now
we
have
two
choices
that
I'm
and
that's
something
that
I'm
I'm
pointing
out
in
the
in
the
in
this
issue.
That
is,
we
can
basically
ignore
the
fact
that
6454
exists,
and
it
can
say
you
know
this
is
not
using
course.
It's
actually
not
relevant.
We
can
also
ignore
the
existence
of
of
that
spec
and,
and
then
just
say,
yep.
Okay,
we
have
a
name
clash
and
our
origin
header
is
this,
and
the
semantics
are
that
and
be
okay?
A
The
problem
is
that
core's,
the
cross-origin
resource
sharing
mechanism
isn't
by
now
so
commonplace
that
it's
kind
of
baked
into
the
hdp
stack,
so
they
are
kind
of
all
by
themselves.
Without
you
being
able
to
go,
and
sometimes
probably
without
you
being
able
to
override
it,
so
so
we
can,
we
could
we
could.
We
should
go
away,
but
then
it
might
not
go
away.
A
Now
that
said,
it's
impossible
at
this
point
to
implement
the
to
implement
that
spec
to
spec,
as
we
have
it
really
correctly,
and
that's
why
my
dev
team
actually
didn't
so
what
they
did
is
they
literally
did
what
I
did
what
I
did
in
b,
what
I'm
proposing
in
b,
that's
what
they
did
looked
at
the
spec
and
said.
Well,
sorry,
we
can't
use
origin
because
origin
is
is,
isn't
h,
a
uri.
A
A
B
B
B
G
B
If
we
looked
at
our
spec
and
said
clearly,
whoever
wrote
this
was
smoking
something
and
they
got
it
wrong
and
it's
just
a
flat
out
bug
in
our
spec
granted.
It
is
a
breaking
normative
change,
but
still
it
is
busted.
You
cannot
implement
this
as
it
currently
is
written
in
the
spec.
Therefore,
we
are
going
to
make
a
change
without
bumping
the
major
version
number,
I'm
pretty
sure
that
has
been
done
in
the
past
and
other
specs,
but
I
was
wondering
what
people
thought
about
that
notion.
A
Do
any
implementations
rely
on
that?
That's
that's
the
other!
That's
the
other
question
right!
Yes,
because
because
it
is
one
where
you
are
allowing
a
another
party
and
then,
as
you
have
allowed
that
other
party
to
do
this,
you
need
to
go
and
do
some
constru.
You
would
have
to
implement
some
constraint
based
on
this.
It's
basically
just
just
valid
it's
just
allowing
you
to
kind
of
validate
that
this
is
coming
from
the
place
that
you
have
allowed.
A
A
B
That,
well
that's
what
I
was
going
to
that
that's
actually
the
path
I
was
heading
down,
it's
like
if
you
would
actually
mention
the
other
spec.
I
think
it
actually
would
have
been
easier
to
justify
and
convince
people
that
we
just
goofed
right
yeah,
because
we
knew
about
the
other
spec
and
we
didn't
mean
to
do
a
conflict.
We
just
made
a
mistake,
but
someone
could
look
at
this
and
say
where's
the
mistake.
You
define
a
new
header,
okay,
it
overlaps
with
somebody
else
or
some
other
spec,
but
who
cares.
A
Yeah,
so
so
so
I
have,
I
have
had
a.
I
have
had
a
had
a
had
a
some,
not
in
my
head
at
that
point
where
which
made
me
write
the
the
origin,
header
kind
of
the
in
these
three
places,
where
I'm
referring
to
just
origin,
so
there
and
then,
and
then
next
and
then
the
next,
the
next
one.
So
I
have
three
mentions
of
origin,
but
I'm
not
even
referring
to
the
other
spec.
So
that's.
That
is
what
I
find
my
even
even
me.
C
I
B
H
B
D
B
Okay,
just
I
think
people
need
probably
a
little
more
time
to
think
about
it.
Clemens.
Would
you
be
one
to
take
an
ai
to
write
an
email
to
the
mailing
list
asking
for
for
the
community
at
large
to
look
at
this
and
ponder
it
and
give
feedback
either
through
email
or
through
the
issue?
Yes,
sir
cool.
Thank
you
very
much.
B
B
B
You
were
basically
asking
whether
we
need
to
have
some
sort
of
life
cycle
relative
to
state
in
the
discovery
spec
for
the
services,
and
the
second
one
was,
I
think,
that's
kind
of
related
to
what
should
a
client
do
when
a
service
disappears
and
as
a
result
of
a
get
or
in
response
to
a
get
a
service
appears
to
have
disappeared
appears
disappeared,
it.
It
seems
it
to
have
vanished
how's
that
and
how
should
the
receiver
of
that
interpret
it?
Should
they
say
it's
gone
now?
B
They
need
to
wait
a
period
of
time
to
realize
it's
really
gone
or
whatever.
Okay
and
unfortunately,
I
don't
think
I
can
remember
the
person's
name.
I
think
I
think
it
was
jennifer.
I
think
that
was
her
name
said
she
wasn't
necessarily
against
the
idea
of
a
service
life
cycle
type
stuff
to
it,
at
least
from
a
deprecation
perspective.
B
B
B
You
may
not
know
what
for
sure
whether
there
was
a
bug,
someplace
or
or
really
is
deleted,
but
I
think
in
most
cases
there
will
probably
be
more
than
one
so
having
one
missing
at
an
entire
list
of
things,
but
you
still
got
a
completely
valid
hp
response.
Just
feels
like
a
weird
thing
for
a
bug
to
manifest
itself.
That
way,
unless
someone
actually
deleted
by
mistake
by
that
fingering
something.
But
in
that
case
well,
tough,
that's
the
state
of
the
system
and
we
want.
We
don't
want
to
lie
to
people.
B
So
I
think
you
have
no
choice
to
say:
missing:
equals
deleted
from
a
client
perspective,
but
then
a
phase,
two
kind
of
a
thing
and
say:
okay,
that's
fine,
but
should
we
look
at
adding
some
sort
of
additional
optional
property
that
allows
a
discovery?
Endpoint
to
say
this
thing
is:
will
be
deleted
at
this
particular
time.
I
don't
think
I,
like
the
phrase
plan
deletion
time,
but
you
get
my
point
right
where
the
presence
of
that
time
stamp
says
the
service
has
been
deprecated.
B
It
will
go
away
at
this
particular
time,
so
we're
just
giving
you
a
warning,
but
it
is
optional
for
them
to
use,
but
we
would
recommend
it
as
a
heads
up
to
people
if
they
want
to
take
some
action
anyway.
I
think
that
we
at
least
probably
need
to
do
one
if
we
want
if
we
want
to
agree
that
missing,
equals
deleted
and
then
think
about
possible
phase
two
or
a
second
step,
but
I
wanted
to
open
that
up
for
discussion,
see
what
people
thought
and
jim.
H
Well,
when
sally,
when
we
look
at
what
we
do
internally,
deprecation
and
retired
means
something
different
so
to
us
deprecation
means
you
shouldn't,
you
know
we're
still
doing
it,
but
you
shouldn't
add
any
more
dependencies
on
it.
So
whether
you
know
whether
a
deprecated
state
means
that
you
don't
accept
any
new
subscriptions,
I
guess
that's
an
interesting
scenario
and
I
it's
interesting
as
we
see
the
word
retired,
I'm
not
sure.
Obviously
that
makes
sense
from
an
internal
or
a
documentation
perspective.
H
If
you
expect
this
portal
to
be
used
as
a
sort
of
data
source
for
documentation
as
well,
I
think
retired
is
useful,
because
you
can
you
know
it's
blindingly
obvious,
then
that
you
shouldn't
you
can't
subscribe
to
this
anymore,
and-
and
you
know
it
did
go
away-
it's
not
that
you're,
it's
not
that
you're
going
mad.
It
didn't
vanish
to
to
use
your
terminology.
B
H
I
mean
potentially
and
we're
not
we're
not
supporting
temporal
queries.
Are
we
we're
not
saying
what
was
the
state
of
this
last
thursday,
for
instance
yeah?
Okay?
I
I
I'd
buy
I'd,
buy
into
that
I
maybe
just
active
and
deprecated
then
or
whatever,
and
presumably
we're
deprecating.
We
should.
We
should
give
some
indication
as
to
when
it's
going
to
retire.
Yeah.
B
Yeah
and
that's
what
I
was
kind
of
thinking
is
that
we
have
this
sort
of
time
stamp
here.
That
gives
you,
I
think
at
least
those
two
states
is
no
timestamp
means
active
timestamp
being
there
says
it's
been
deprecated
and
when
it's
going
to
actually
vanish
and
then
when
it
actually
does,
when
that
time
passes,
then
you
can
actually
remove
the
whole
service
and
lack
of
being.
There
means
it's
retired
or
gone.
H
H
B
H
Well,
I
mean
you,
you
have
well,
maybe
maybe
I've
gone
completely
off
track,
then
your
events
are
versioned
yeah
and,
as
you
make
breaking
changes
those
events
and
you
move
from
version
one
to
version
two.
You
might
be
running
both
in
parallel
for
a
while,
while
people
get
off
your
old
one
and
get
onto
the
new
one,
that's
what
I
was
alluding
to.
Maybe
I've
misunderstood
the
discovery
side
of
this
thing.
H
H
B
Yeah,
it's
just,
I
don't
think
we
have
the
notion
of
so
okay.
So,
first
of
all,
I
think
we're
talking
about
deprecating
the
entire
service,
not
one
particular
event,
and
I
don't
think
we
have
the
notion
of
versions
between
services
right
if
you
want
to
have
a
completely
new
version
of
a
service,
I
think
from
a
discovery,
endpoint
perspective
I
think,
get
to
create
a
whole
new
service
and
the
fact
that
it
may
have
some
correlation
or
similarity
to
an
existing
service
is
interesting.
B
H
B
No,
I
know
I
think
I
think
what's
happening
is
if
you
wanna
have
a
version
two
of
your
rape
of
your
subscription
stuff,
then
you
can
create
another
service
in
your
discovery,
endpoint,
and
it
happens
to
look
very
similar
to
the
previous
one,
but
it's
a
completely
different
name,
completely
different
id
and
from
discovery.
Endpoints
point:
it
is
a
completely
different
service.
B
Well
I'll
go
back
and
double
check,
but
I'm
pretty
sure
we
don't
have
any
kind
of
correlation
attributes
in
our
in
our
spec
today,
okay
and
but
then
I
want
to
go
back
to
something
else.
You
said
about
having
an
explicit
field
that
kind
of
represents
state.
I
think
that's
that's
interesting
and
definitely
an
option.
My
only
concern
with
that
is
then
we
basically
have
two
fields
in
a
service
definition,
that
kind
of
say
the
same
thing
right.
B
H
H
B
That's
a
good
point,
I
think
I
know
at
some
point.
Somebody
talked
about
doing
events
from
discovery
endpoints,
I
think
maybe
it
might
have
been
scott.
I
would
imagine
that
yeah,
if
any
metadata
on
a
service
does
change,
I
would
think
an
event
should
be
emitted.
If
someone
subscribes
to
the
discovery,
endpoint
itself
right
to
get
events.
Yes,
I
would
think.
H
B
Yeah,
that's
a
good
point.
I
I
don't
know
yeah.
I
have
to
think
about
that.
My
initial
reaction
is:
why
treat
this
one
as
special
just
say:
hey
this
thing's
changed
and
you
can
go.
Do
a
diff
yourself,
but
I
could
also
understand
that
this
thing
going
away
is
a
pretty
darn
important
event
and
maybe
that
should
have
its
own
special
event.
Yeah.
I
H
B
B
Deleted,
okay,
what
I'll
probably
do,
then,
is
I'll
write
up
a
pr
for
that
one
piece,
and
then
I
think
I
I
personally
would
like
to
do
a
little
more
thinking
about
this.
Given
everything
that
jem
said,
because
I'd
like
to
I'd
like
to
think
more
about
all
the
all
the
things
you
mentioned
jim,
I
think
there
are
some
interesting
aspects
to
it
that
I
hadn't
considered.
B
B
B
B
J
J
K
K
So
it
may
well
be
that
we
want
to
enlighten
those
two
issues,
but
yes,
plus
one
for
the
idea
of
some
kind
of
change
log.
That's
ideally
semantic
between
versions.
Rather
than
having
to
read
all
the
different.
I
don't
want
to
have
to
read.
30
different
commits
to
tell
the
difference
between
1.0,
0
and
1.01,
so
yeah.
B
Get
thanksgiving
for
bringing
this
back
up
you're
right,
I
stepped
off
my
radar.
So
basically
I
want
to
make
sure
I
understand
what
you
guys
are
asking
for
you're,
basically
saying
interesting
list,
but
oh
my
gosh,
what
a
pain
in
the
butt
to
deal
with
you
want
something
that
someone
basically
calls
through
the
list
and
says
these
are
really
the
things
you
guys
gotta
you
you,
as
a
reader
need
to
pay
attention
to
right,
because
these
are
the
big
ones.
Is
that
what
you're?
Looking
for.
J
K
B
J
B
K
You
be
willing
to
turn
this
into
a
pr.
To
be
honest,
no,
given
that
I
have
two
existing
action
items
that
I
haven't
managed
to
get
to
in
the
last
week
beyond
I
was
going
to
say
on
the
http
header
action
item
I
have
from
last
week.
I
have
made
some
progress
on
an
internal
dock
enumerating
some
options.
K
J
B
B
We
may
want
to
consider
changing
our
process
such
that,
as
we
approve
prs
to
ask
ourselves.
Is
this
change
worthy
of
adding
something
to
release
notes
kind
of
thing,
because
that's
typically,
what
people
do
for
open
source
right?
It's
yeah!
You
know
for
this
pr,
so
we
have
to
should
we
change
the
release,
notes,
I
think
that's
kind
of
what
you're
looking
for
here,
grant
yeah.
J
J
Yeah
one
comment
around
that
like.
I
think
it
would
be
useful
if
so
just
like
looking
at
the
commits
for
the
spec
like.
Maybe
it
would
be
useful
to
have
like
the
semantic
conventional
commits
where,
like
you
say,
if
something's
a
feature
or
docs
looks
like
yeah
like
lance
has
some
conventional
commits
and
but
like
we
don't
sort
of
enforce
it.
So
maybe,
when
we're
merging
pr's
in
the
future.
B
Yeah,
yes,
I
think
I
yeah.
Basically,
I
think
we're
in
agreement.
I
think
there
are
some
process
changes.
We
can
look
at
doing
going
forward
to
make
it
easier.
So
it's
not
oh,
my
gosh
we're
doing
a
release,
and
now
someone
has
to
do
the
leg
work
of
just
going
back
and
scanning
every
single
pr
that
we
merged
we'll
do
it
as
we
go
along.
So
it's
less
painful
yeah.
I
think
that's
a
process,
change
that
I
can
look
at
doing.
B
B
B
K
I
would
say
this
list
of
differences
was
done
by
taking
the
0.3
spec
and
the
1.0
spec
and
just
diffing
them
so
that
it
may
well
not
map
cleanly
to
pr's
or
commits
because
the
same
section
may
have
changed
multiple
times.
For
example,
that's
more
to
grant
if
you
were
expecting
to
find
corresponding
commits
than
anyone
else,
and
it
may
well
be
that.
K
B
K
F
Good
discussion,
okay,
good!
I
just
wanted
to
say
that
we
do
have
some
automation
around
stuff
like
this
in
the
javascript
sdk,
that
you
know
we
might
want
to
look
at
for
some
sort
of
ideas
about
how
to
format
commits
and
automate
some
of
the
things
like
the
actual
release,
processes
and
versioning
and
stuff
like
that
and
generating
the
change
logs
automatically.