►
From YouTube: CDEvents Community Summit - cdCon 2022
Description
CDEvents Community Summit
Hybrid event at cdCon
June 10th 2022, Austin / Online
https://cdcon2022.sched.com/event/10fUW/cdevents-community-summit
C
Yeah,
that's
a
good
idea
actually,
so
we
could
do
a
round
in
should
we
do
around
in
the
room
first,
I
can
grab
my
room
computer
here
and
walk
around
a
bit.
So
pirate.
Would
you
like
to
start.
D
So
my
name
is
piratsar
and
I
work
in
dual
and
with
the
while
works
with
a
continuous
integration
for
enterprise
scale
systems,
and
I
work
as
a
system
architect
at
the
well.
I
have
been
in
contact
with
quite
a
lot
with
center
enterprise
scale,
ci
architecture,
also
events
pipelines
all
kinds
of
things.
So
this
is
very
interesting
topic
for
me.
Yes,
you
can
send
it
back
to
minnesota.
E
Hi
I'm
melissa
mckay,
I'm
a
developer
advocate
with
jfrog
and
I'm
a
chair
of
the
interoperability
sig
and
so
very
interested
in
cd
events,
a
child
that
came
out
that
has
been
pretty
successful
here
I
want
to
take
you
know,
information
away,
hopefully
to
share
with
our
own
engineering
teams
to
see.
If
maybe
we
can
get
some
interest
in.
You
know
implementing
this,
or
at
least
helping
to
contribute.
F
That's
me:
that's
mauricio,
yesterday,
working
also
with
vmware
and
k
native,
but
very
interested
in
cd
events,
and
you
know
I've
been
working
with
it
for
some
time
now
and
I'm
hoping
to
be
able
to
keep
working
on
it
for
for
more
more
time,.
G
If
you
haven't
heard
an
earful
about
that
already,
please,
I
would
love
to
talk
to
you
about
it,
but
we
are,
you
know
in
the
business
of
receiving
information
about
software
delivery
processes
and
that's
hard
and
it
sounds
like
this
group
wants
to
help
solve
that
problem.
So
I'm
all
for
it.
H
Awesome,
hey,
my
name
is
sascha,
I'm
from
ibm,
devops,
engineer,
doing
code,
engineer
and
I'm
community
lead
of
shipwright
and
shipwright
is
actually
a
very
good
fit
to
eventually
send
cd
events.
I
My
name
is
david
lai.
I've
come
from
futureway,
I'm
the
cdf
board
member.
I'm
happy
to
hear,
because
I
try
to
see
whether
this
new
initiatives
project,
I
think
that's
so
one
of
the
very
interesting
thing
will
be
benefit
to
the
community.
Thank
you.
C
A
Yeah
sure
my
name
is
andrea
fritoli,
I'm
a
developer
advocate
at
ibm
and
yeah,
I'm
one
of
the
co-creator
of
the
city
events
project,
I'm
co-chair
of
the
sikh
events
and
I'm
part
of
the
cdf
drc,
as
well.
So
the
technical
oversight
committee
and
where
one
of
our
mission
is
about
interoperability
between
the
projects
in
the
cdf
and
beyond.
So.
C
Yes-
and
I
am
here
external-
I
work
with
peret-
do
while
so
continuous
integration,
mainly
for
like
industry
projects
like
autonomous
drive
and
such
solutions,
so
more
towards
embedded
and
safety,
certification
and
those
kind
of
things
less
towards
cloud.
So
I
think
I
think
it's
good
that
we
have
a
wide
base
of
different
interests
in
ci
cd
here
sorry,
and
I
would
like
to
tell
you
a
story-
and
let
me
start
this
week
sharing,
I
guess,
okay.
C
Yes,
so
back
in
november
2019,
I
was
working
at
volvo
cars
and
I
got
the
mission
together
with
pirate
to
try
to
explain
module
by
module
step
by
step
how
our
continuous
integration
setup
worked.
C
So
we
spent
like
a
week
in
front
of
this
massive
whiteboard,
just
drawing
boxes
for
everything
so
that
we
present
it
in
a
rational
and
logical
way,
and
when
looking
at
that
whiteboard,
we
had
like
72
different
components,
not
super
surprising
perhaps.
But
there
was
a
lot
of
like
jenkins
and
artifactory
and
those
kind
of
things
just
to
bring
everything
together.
C
There
was
a
lot
of
configuration
stuff,
but
around
25
of
those
components
were
just
glue
code,
so
just
trying
to
to
bring
things
together
and
yeah
having
your
your
jenkins
pipeline
to
invoke
something
some
python
script
that
in
turn
integrates
with
artifactory
or
integrates
with
our
own
message,
bus,
which
we
had
at
a
time-
and
I
remember
thinking
this-
has
to
be
something
that
everyone
else
is
doing
as
well,
because
back
then
there
wasn't
really
a
good
way
to
to,
or
there
wasn't
a
good
way
to
make
things
work
together,
rather
than
writing,
or
instead
of
writing
just
your
own
blue
code-
and
I
also
remember
thinking
there
has
to
be
a
better
way
and
I
firmly
believe
that
cd
events
has
the
opportunity
to
become
that
better
way.
C
K
C
K
A
K
A
Maybe
folks
in
the
virtual
attendance
would
like
to
introduce
themselves
so
emil.
B
Yeah,
I
can
go
first,
so
my
name
is
emil
beckmark,
I'm
located
in
sweden
currently
at
home.
I'm
unfortunately
cannot
be
with
you
in
in
austin,
so
I'm
together
with
andrea,
the
co-chair
of
the
siege
events
and
also
one
of
the
founders
then
of
the
city
events
project,
I'm
also
a
member
of
the
eiffel
er
event
project
hyper
community,
where
we
develop
a
an
event
protocol
or
have
developed
for
long,
I'm
employed
by
ericsson
and
yeah
very
much
looking
forward
to
the
to
the
work
we
do
together
here.
L
I
guess
I'll
be
I'll
I'll,
be
the
first
adam
to
go.
My
name
is
adam
kaplan,
I'm
a
software
engineer
at
red
hat.
I
am
also
a
co-community
lead
with
sasha
on
the
shipwright
project
and
as
sasha
mentioned,
we
are
definitely
interested
in
becoming
a
participant
in
the
cd
events.
C
M
Oh
sorry,
it
was
up
to
my
head,
I'm
adam
a
software
engineer
at
ericsson,
ericsson,
software
technology,
the
open
source
division.
K
Yes,
yeah,
I'm
dylander
so
working
in
ericsson,
I'm
a
senior
software
engineer.
So
recently
we
started
contributing
to
cdf
events
for
java
sdk
and
we
have.
We
also
started
with
spinnaker
integration
with
the
cd
events,
so
that
we
are
working
on
the
poc
to
try
to
integrate
spinnaker
into
the
sig.
K
C
Happy
to
hear
gauri
do
you
want
to
go
next?
O
Yes,
hello,
I'm
nicholas,
I
I
work
at
apple
only
on
a
spinnaker
team,
so
we're
also
interested
in
seeing
how
cd
events
can
be
integrated
with
spinnaker
and
and
how
they
can
open
further
integrations
with
you
know,
other
tools
that
could
understand
these
events
very.
C
Very
nice,
so
we
have
cara
in
the
meeting,
but
she
doesn't
seem
to
be
on
audio,
so
I
guess
she
will
not
be
able
to
introduce
herself.
So
I
guess
that's
everyone,
I
think
so.
Should
we
now
that
we've
taken
care
of
all
the
introductions?
Should
we
talk
a
little
bit
about
sirius?
Oh,
we
can
read
what
kara
said
hi
all
I
am
an
ecosystem
advocate
at
the
cdf
and
have
been
involved
in
city
events.
C
C
A
C
Yeah,
I
guess
I
think
we
have
something
on
city
events
later
in
the
presentation.
C
A
Right
just
to
give
some
some
background
on
where
we
come
from
so
in
the
cdf,
the
special
interest
group
about
interoperability
started
discussing
about
how
to
have
all
the
projects
in
the
city
space
being
able
to
interpret
with
each
other,
and
one
of
the
things
that
they
started.
A
One
of
the
work
streams
within
the
interoperability
working
group
was
focusing
on
the
van
and
so
later
we
that
work
stream
evolved
into
its
own
special
interest
group,
and
so
they
seek
events
especially
the
event
special
interest
group
and
that
created
the
cd
events
project
then
later
on,
and
so
what
is
city
events.
So
there
are
a
few
things.
So
it's
a
vocabulary
again.
We
want
to
create,
like
a
shared
language,
a
common
language,
for
tools
in
the
cicd
space
to
describe
what
they
are
doing
and
it's
also
a
specification.
A
So
we
are
building
kind
of
json
schema
so
that
describe
how,
if
you're
building
sending
events,
how
you
should
compile
them,
how
you
should
structure
them.
So
it's
easy,
then,
for
the
receiving
site
to
parse
those
messages
as
well.
A
It's
a
project
and
it's
incubating
project
in
the
cdf
and
we
are
working
towards
the
first
release
of
our
specification.
So
it's
in
progress-
and
this
is
a
good
time
to
kind
of
yeah,
bring
your
use
cases
and
we
are
really
listening
to
the
community
to
understand
what
is
it
that
we
can
help
with
a
specific
problem
that
we
can
solve
with
cd
events,
to
make
sure
that
we
we
get
the
specification
in
the
right
direction.
A
We
have
several
events
in
the
in
cd
events
and
we
try
to
group
them
in
different
phases
or
groups
of
events
that
are
specific
to
kind
of
the
the
area
in
your
ci
cd
workflow,
where
these
events
are
going
to
be
generated
and
we
have
the
core
events
which
are
like
the
lower
abstraction.
If
you
will
type
of
event,
so
they
are
describing
like
pipeline
orchestration
type
of
events
like
pipeline
started,
pipeline,
finished
task,
run,
start
and
finish,
and
so
forth.
A
We
have
the
source
code
version
control,
so
the
sem
type
of
events,
which
are
all
about
changes
happening
in
your
source
code
right.
So
this
is
the
type
of
event
that
you
will
get
from
your
github
or
gitlab
or
bitbucket
about
a
change
has
been
merged,
and
this
is
the
sha
of
this
change.
And
what
are
we
going
to
do
with
this
change?
A
Then
we
have
the
the
continuous
integration
pipelines
type
or
the
continuous
integration
type
of
events,
the
packet,
where
we
have
events
that
describe
the
typical
things
that
happen
during
that
ci
phase.
So
like
builds
and
testing,
that
is
happening
and
also
we
have
events
about
artifacts,
and
this
is
a
very
key
area,
because
there
is
a
plethora
of
tools
out
there
that
are
able
to
build
different
kind
of
artifacts
from
container
images
or
else,
but
there
is
again
no
common
language
to
describe
these
artifacts.
A
So
it's
really
important
for
us
to
get
this
right
and
we're
really
happy
also
to
have
like
the
shipwreck
community
joining
today
about
this.
So
we
have
the
continuous
deployment
bucket
or
yeah
phase
where
we
describe.
We
talk
about
environments,
so
we
have
like
environments
that
can
be
created,
provisioned
or
turned
down.
A
A
If
I
do
a
change,
I
do
the
deployment,
but
that
doesn't
go
well
or
if
I
have
maybe
even
some
sli
or
slos
defined
for
my
service
and
they
degrade,
and
I
want
to
be
able
to
notify
that
this
is
happening
and
maybe
have
like
an
automated
remediation
happening
and
then
again,
if
the
remediation
happens,
whether
it's
manual
or
automated.
We
want
to
know
that,
so
we
have
event
for
that
that
we
are
working
on.
So
those
are
more
in
the
phase
of
specification,
but
we've
been
working
with
the
captain
project.
A
A
Yeah,
I
guess
we
talked
about
cd
event
specification.
One
thing
that
maybe
is
worth
mentioning
is
the
binding.
So
how?
What
is
the
relationship
between
city
events
and
cloud
events?
Basically
so
cloud
events
is
a
cncf
project
that
allows
you
to
abstract
away
the
specific
messaging
protocol
that
you
use
to
transport
events
right.
So,
if
you're
developing
an
application-
and
you
don't
want
to-
you-
know-
be
committed
from
the
beginning-
I'm
going
to
use
nqtt
and
that's
that's
it
that's
going
to
be
the
protocol.
A
I'm
using
you
want
to
have
the
flexibility
of
changing
protocol.
Then
cloud
events
gives
you
this
flexibility,
because
it
defines
like
a
standard
way
of
building
your
event
envelope.
So,
where
you
put
your
data
in
and
then
you
can
decide
even
later
on
a
configuration
time
say:
okay,
I'm
going
to
transport
this
over
http,
I'm
going
to
transport
it
over
nqtd,
nuts
or
yeah,
whatever
binding,
specific
binding
that
you
want
to
use.
A
So
our
working
assumption
now
is
that
we're
going
to
transport
cd
events
over
cd
events
over
cloud
events,
because
it
makes
sense
it's
very
convenient.
It
gives
this
extra
power
and
abstraction.
So
we're
defined
we're
defining
the
binding
and
setting
some
extra
rules
on
how
the
cloud
events
envelope
should
be
sent
when
we're
sending
cd
events.
C
C
It
quickly,
but
the
two
main
use
cases
or
the
first
of
the
two
main
use
cases,
is
interoperability,
so
making
things
work
together.
So
I
think
there
is
a
lot
of
stuff
here,
but
I'm
going
to
go
through
it
very
quickly.
So
this
is
again
from
my
work
at
volvo
cars,
so
different
teams
build
their
stuff
with
different
solutions.
C
So
the
packages
have
to
end
up
in
the
same
destination,
and
we
then
would
ask
ourselves
okay,
but
a
package
built
by
zuul.
What
is
that
called?
Well,
it's
called
an
artifact,
in
fact,
they're
all
called
artifacts,
but
this
seems
more
by
happenstance
than
by
planning
because
they
are
all
different
artifacts.
They
all
have
different
metadata.
They
all
have
different
yeah
deliveries
and
how
they
are
how
they
are
used.
M
C
Can't
easily
get
to
it-
and
this
of
course
is
true
for
a
lot
of
things
other
than
just
artifacts,
so
blue
code
again
and
the
solution
could
be
cd
events
if
we
could
say
or
make
these
tools
or
find
some
translation
somewhere,
so
that
all
these
are
presented
as
cd
events
artifacts,
then
we
have
the
metadata
in
a
known
format
and
we
could
even
switch
out
or
introduce
new
type
of
build
systems
to
build
the
stuff
that
we
want,
which
would
make
our
life
a
lot
easier.
A
Thanks
eric
yeah
and
the
second
area,
where
we
think
cd
events
has
a
great
potential,
it
can
help
a
lot
is
observability
and
metrics
and
again,
if
you
have
a
system
or
a
cicd
workflow
that
starts
from
where
you're
writing
your
software,
through
testing,
releasing
deploying
and
maybe
rollback
or
incident
management,
and
you
may
have
different
platforms
involved
in
that
system,
so
you
may
using
github
or
a
combination
of
jenkins
and
tactum
for
your
test,
and
maybe
you
use
argo
cd
or
you
use
captain
for
your
remediation
workflows,
and
so
you
want
to
know
what's
going
on
in
your
workflow
at
any
point
in
time
or
you
want
to
decrypt
keep
track
of
how
long
it
takes
for
your
workflows
to
to
be
executed.
A
That
is
the
vision
that
we
have
is
that
if
all
this
platform
would
send
event
in
a
common
language,
then
an
event
collector
could
have
all
these
events
in
one
place,
and
then
you
could
use
this
data
to
do
things
like
visualizing,
the
workflow
on
one
side,
calculating
metrics
like
the
devops
yeah
that
they
was
mentioning
earlier
that
are
about
like
yeah.
How
often
are
we
deploying
our
software,
how
long
it
takes
or
like
from
source
to
get
into
production
and
yeah
and
etc?
A
So
that's
one
of
the
the
other
core
use
case
that
we
hope
to
to
address
with
this
and
let's
see.
C
Yeah,
I
think
we
yeah
so
basically,
our
plan
for
today
is
not
to
have
too
much
of
a
plan.
It's
it's.
We
would
like
to
hear
what
people
want
to
talk
about
if
everyone
goes
into
awkward
panic
mode,
we
do
have
some
topics
prepared
that
we
could
talk
about,
but
we
would
much
rather
talk
about
what
you
want
to
talk
about,
so
basically
anyone
who
has
anything
they
would
like
to
discuss.
C
C
O
Sure
so
yeah
I
looked
at
the
at
the
spec,
and
one
thing
that
I
was
kind
of
expecting
to
see
and
didn't
see,
is
some
sort
of
of
structure
that
that
links
the
events.
It
seems
to
me
I
could
see
things
like
you
know.
O
Id
timestamps
solars
object
things
like
that,
but
but
not
not
any
sort
of
of
graph
of
you
know
the
relationship
between
these
events
and
if
you
look
at
you
know
any
sort
of
visualization
of
pipelines,
often
you'll
see
them
as
a
graph
without
investigation
in
spinnaker
or
pikton,
or
things
like
that
and
in
here
it
looks
like
the
event
stream
would
be
flat
right
and
there's
no
there's
no
connection
between
between
each
one.
So
have
you
is
that
something
that's
being
considered
or
is
it?
O
B
No,
I
guess
I
could
take
it
happy
nicholas
for
the
opportunity
to
to
talk
about
this.
Actually,
so
I
don't
know
how
we
should
do
it,
but
maybe
first
yes,
yes,
we
have
talked
about
it
a
bit.
It
has
been
based
in
various
forms
in
in
different
for
us
how
we
should
relate
events
to
each
other.
B
There
is
that
there
are
two
two
main
ways
to
do
it.
I
would
say
one
is
to
create
a
graph,
as
you
said,
of
linked
events
that
are
linked
upstream
and
downstream.
In
your
whole
end
turn
pipelines
would
say,
and
the
other
way
would
be
to
to
relate
events
through
some
context
id
which
is
is
often
used
in
many
systems
today
as
well.
B
That
sends
events
that
way
it
it's
a
bit
limited
to
only
those
contexts
I
would
say,
then
you
could
of
course
relate
all
events
within
a
pipeline
to
a
certain
pipeline
context
or
all
events
related
to
a
certain
component
to
some
component
context
or
whatever
you
decide,
but
having
links
gives
you
a
bit
more
freedom,
I
would
say
I
would
call
them
links,
because
that's
what
we
call
them
in
this
eiffel
event
protocol
that
I
mentioned
in
my
presentation,
or
maybe
when
I
presented
myself
so
I
I
often
use
the
term
links
there,
as
you
also
did
niklas
so,
but
but
references
that
can
go
upstream
downstream
to
form
a
graph.
B
M
B
Okay
yeah,
so
you
see
this
now,
so
I
had
a
presentation
last
year
on
silicon,
which
was
the
title
was
linking
if
I
can
just
go
back
to
the
linking
event,
so
the
linking
events
to
achieve
traceability
and
data
aggregation.
B
So
on
top
of
the
use
cases
that
were
mentioned
about
the
interoperability
and
observability
in
metrics,
if
you
would
also
link
the
events
in
a
way
similar
to
how
I
described
it
here,
you
could
also
achieve
traceability
through
your
end-to-end
pipeline
and
you
could
make
it
possible
to
aggregate
data
from
these
events
in
in
a
very
generic
and
yeah
a
general
generic
manner
for
all
of
your
events.
B
So
I
think
this
was,
I
think
you
mentioned
this
andrea,
what
an
event
is,
but
if,
if
you
didn't,
maybe
we
should
just
revisit
that.
So
what
is
really
an
event?
Maybe
not!
Everyone
is
aware
what
we
talk
about
when
we
say
events
there.
You
talked
about
an
envelope
of
cloud
events
and
let
me
put
something
in
there
and
the
thing
we
put
in
there
is
really
a
data
record
that
expresses
an
occurrence
in
the
in
the
ci
series
system.
B
So
if
we
are
two
different
events
here
symbolized
with
these
different
bullets
here
in
this
picture,
I
use
arrows
that
symbolizes
the
actual
links,
so
the
red
event
here
has
a
link
to
something
to
the
blue
event
in
some
way.
So
the
way
it's
done
in
this
eiffel
protocol
that
I
refer
to
is
that
the
event
a
has
an
id
field,
a
uuid
and
then
the
event
b.
B
B
So
that's
how
a
general
link
is
set
up
in
iphone
and
then
the
next
event
coming
could
then
relate
to
the
previous
event
the
event
b
in
this
picture.
But
then
we
also
use
semantic
links.
We
make
these
links
semantics.
B
We
put
them
attribute
on
top
of
the
actual
link,
so
an
event
could
link
to
two
different
events,
for
example,
in
this
case
with
two
different
types
of
links,
so
there
could
be
a
type
x
and
a
type
y,
and
I
will
come
back
to
some
example
on
exactly
what
what
these
types
could
be.
I
just
want
to
show
that
one
event
could
link
to
multiple
upstream
events
and,
in
the
same
way,
multiple
different
events
could
link
to
the
same
upstream
events.
B
So
this
is
there's
a
flexibility
in
this
area
as
well,
and
this
way
we
could
form
such
an
event
graph
that
you
talked
about
there.
So
this
below
the
picture
below
there
is
is
just
a
very
huge
or
somehow
huge
graph
of
a
lot
of
events
with
a
lot
of
inter
links
between
them
in
a
direct
recycling
graph
format.
B
So
what
could
you
use
these
for
them?
Well,
you
could
trace
events
and
trend,
so
you
can
see
what
happens
in
a
complex
production
flow
from
the
earliest
source
code,
commit
to
other
low
level
binary
or
something
in
your
system
or
in
some
other
library
that
you're
dependent
on
all
the
way
to
the
customer
deployment
for
to
the
right
and
beyond.
B
So
if
the
right
most
events,
symbolizes
three
different
deployments
and
the
blue
in
the
middle,
there
is
your
artifact
that
is
built
and
then
tested.
Somehow,
you
can
then
see
where
was
this
deployed,
and
this,
of
course
doesn't
need
to
be
the
same.
The
ci
cd
system
that
does
all
this
as
long
as
they
share
the
same
vocabulary
and
send
links
in
the
same
format.
B
Maybe
I
should
stop
there
for
now,
so
we
don't
go
too
far
into
this
without
having
further
questions.
Maybe.
C
O
So
my
question
was:
was
you
know?
This
is
exactly
what
I
was
asking
about,
but
this
doesn't
seem
to
be
in
the
spec
like
the
the
links
field.
That
you
described
is
not
is
not
a
required
field
or
it's
not
even
listed
as
option
exactly.
B
So
we
have
it's.
I
think
we
have
written
an
issue
for
it,
but
we
should
talk
about
it
or
at
least
it's
a
discussion
point,
but
so
far
we
haven't
put
it
in,
but
I
would
look
forward
to
see
it
part
of
the
specification,
maybe
optional,
but
a
way
part
of
it.
So
it's
possible
to
do
these
links
but
yeah
so
far
we
haven't
included
it,
but
yeah.
We
should,
of
course
I
think
we
should
at
least
okay
great
thanks.
G
Yeah
just
a
sort
of
question,
slash
request
or
something
you
know.
I
think
that
there's
potentially
we
could
do
a
lot
of
the
stuff
without
having
the
data
actually
linking
to
each
other.
As
long
as
a
system,
that's
interpreting
it
can
match
the
entities
between
the
the
events
right.
G
One
thing
I'm
like
about
is
you
know
every
event
has
a
uuid.
Is
that
intended
to
be
generated
uniquely
for
the
cd
event,
or
would
that
potentially
be
the
same
uuid
as
like
a
system
event?
So,
for
example,
cloud
build
our
hosted.
You
know
build
system
on
google
cloud
has
a
uuid
for
every
build
that
happens.
A
Yeah,
that's
that's
a
great
question
yeah,
so
you
you
want
to
say
something
mauricio
or
no,
I
think
yeah.
The
idea
would
be
a
separate
uuid.
So
the
requirement.
A
A
uu
event:
uuid
must
be
unique
within
the
source
of
the
event,
so
that
you
can
control
its
unicity
because
as
an
event
producer,
and
then
we
have
the
what
we
call
the
uid
of
the
subject.
So,
if
you're
doing
like
talking
about
builds,
then
the
build
id
could
be.
The
cloud
build,
build
id
that
you
use
there
and
that's
unique
again
within
the
source.
I'm.
G
G
G
C
We
have
a
source
and
subject
as
part
of
their
cloud
events
attributes,
if
I
don't
remember
so,
a
source
would
then
be,
for
instance,
your
cloud
build
setup
or
something
that
uniquely
identifies.
Where
did
this
event
come
from
and
the
subject
doesn't
have
to
be
just
the
uid.
It
could,
for
instance,
be
the
name
of
whatever
artifact
you're
building
and
then
a
slash,
and
then
the
uuid
yeah,
I
think
idea,
has
has
done
some
some
proposals
regarding
the
subject
and
I'm
not
sure.
C
C
We
haven't
introduced
it
into
the
actual
document,
yeah.
A
I
think
the
first
iteration
should
be,
but
we
are
still
this
have
more
discussion
and
that's
where
we
want
to
get
like
yeah
input
about
what
it
makes
sense.
So
I
think
another
another
thing
that
we
discussed,
that
is
still
not
yet
in
the
spec,
but
it's
about
extensions.
A
So
if
you
have
like
vendor
specific
or
source
specific
data,
we
could
have
specific
headers
or
extensions
where
you
you
introduce
these
and
they
are
well
defined
as
part
of
extensions
of
the
city
event
spec,
so
that
if
someone
receives
a
bills,
a
generic
build
and
want
to
do
something
with
that,
and
there
is
a
share
metadata.
You
can
do
it.
But
if
you
all
know
that
it's
it's
a
google
cloud
build
and
there
is
extra
data
that
you
want
to
take
advantage
of.
A
You
can
do
if
you
want,
and
if
you
need
and
back
to
to
the
point
that
you
you
mentioned
about
being
able
to
correlate
events
with
or
without
links.
So
what
we
tried
like
in
the
in
the
talk
we
made
about.
A
This
week
was
to
see
how
much
we
can
correlate
different
events
just
using
the
subject
you
know
like.
If
I
have
a
change,
I
have
a
change
id
and
then
I
have
a
build.
So
what
is
the
id
of
the
latest
change
included
in
the
build,
and
that
allows
me
to
correlate
things,
and
so
that's
one
way
of
correlating
events.
A
The
advantage
for
me
for
that
approach
is
that
it's
like
it's
easier,
at
least
for
initial
implementation
with
different
platforms,
because
you
don't
need
to
build
in
the
source
of
the
events,
the
logic
that
correlates,
like
whatever
events
you're
receiving,
that
triggered
you
with
the
event
that
you're
generating
right.
A
So
if
you
want
to
have
these
links,
then
you
need
to
have
this
logic
into
the
platform,
so
you
need
to
make
more
more
changes
in
the
platform
and
because
we
try
to
build
pocs
to
make
to
show
what
we
can
do
with
city
events.
A
So
for
this
poc
there's
adapter
layers
around
the
different
tools,
so
we
don't
really
go
into
the
tools
to
and
we
are
not
able
to
create
this
connection.
But
I
think
I
I
do
agree
with
what
emil
presented.
If
you
were
able
actually
to
produce
these
links,
then
you
would
have
really
powerful
tools
to
you
know
create
like
this
kind
of
traces,
more
like
systematically.
P
B
G
If,
if
it's
easy
enough,
if
the
data
is
there,
embedding
it
a
link
is
awesome,
but
I
wouldn't
want
to
lean
too
much
on
it,
because
I
can
imagine
like
a
producer
having
to
query
an
event
store
to
get
the
right
link
before
it
can
emit
an
event
that
seems
problematic
to
me.
I
wanted
to
it'll
just
fire
everything
off
and
you
know
with
whatever
context
it
happens,
to
have.
G
B
Might
be
problematic
so
but
and
of
course
we
would
need
some
events
stored
to
do
that
and
there's
different
solutions
for
for
that
as
well,
and
we
use
it
very
extensively,
I
would
say
in
this
a-field
protocol,
it
works
fine,
I
would
say
there
so
it's
proven
to
work
in
a
way,
but
we
should
discuss
the
details
on
how
this
should
be
done.
Of
course,.
Q
F
M
F
I
mean,
I
think,
that
it's
pretty
easy.
You
have
enough
information
to
not
go
and
vary
some
of
things
but
yeah.
I
can
see
also
the
scenarios
where
you
don't
have
like
that,
like
you
are
just
creating
the
event
for
the
first
time,
based
on
something
that
is
happening,
that
it's
not
creating
another
event
and
then
you
will
just
need
to
yeah
just
figure
that
out,
but
I
think
that
yeah,
but
I
I'm
I'm
leaning
more
on
on
having
that
on
the
spec.
F
So
it
would
be
a
really
nice
thing
to
have
there
as
like
an
optional
field
that
we
can
use.
If
we
have,
you
know
that
thing
in
there
and
I'm
wondering
how
kind
of
like
that's
going
to
materialize
on
the
sdks.
How
is
that
going
to
be?
How
are
we
going
to
make
the
life
easier
for
developers
just
to
create
these
links?
Kind
of
like
in
a
more
like
an
automated
way,
but
yeah
yeah?
I'm
looking
forward
to
to
see
more
of
that
in
the
future.
G
So
let
me
just
clarify
a
second,
because
what
you
just
said
helped
me
clarify
my
thought,
which
is
that's
like,
for
example,
a
a
build,
that's
triggered
by
a
source
change.
You
know
we
have
a
link
already
right.
You
know
the
source
change
has
a
git
hash.
C
Yeah
and
I
think
on
that
level,
it's
usually
we
have
a
pretty
solid,
solid
things
to
go
for
already.
It
becomes
perhaps
a
bit
more
of
an
issue
when
we
talk
about
compositions
of
things
so
yeah
you
have
you've
done
your
build.
You
have
your
library
or
your
application
or
whatever,
but
then
you
have
multiple
libraries
and
applications,
and
you
want
to
put
those
in
one
package.
C
Then
there
is
there,
isn't
really
a
universal
universe
like
hash
or
something
you
could
use
something
like
perl,
for
instance,
or
purl,
or
whatever
it's
called
that
provides
some
sort
of
identifier
for
it,
and
maybe
that's
something
that
that
we
would
do.
I
think
that
was
a
question
or
comment
in
one
of
the
talks
in
the
conference
about
using
pearl
for
that
but
yeah.
C
So
there
are
different
ways
of
connecting
things
together,
definitely
and
yeah,
and
a
lot
of
the
work
in
the
cd
event
specification
is
trying
to
find
a
balance
between
everyone's
different
use
cases,
but
a
good
way
of
doing
that
is
the
hearing
about
everyone's
different
use
cases.
It's
really
good
that
you're
bringing
this
up
yeah.
A
But
I
think
when
we
are
specking
out
the
the
links,
we
should
make
sure
well
we're
not
making
mandatory
to
to
other
links,
because
there
may
be
systems
that
don't
want
to
send
the
links
and
the
other
thing.
I
think
your
comment
was
really
good.
Also
mauricio.
What
can
we
do
in
the
in
the
sdks
to
actually
enable
platforms
to
produce
these
links
in
a
easier
way,
but
yeah,
so
in
in
the
week
in
this
week
talk
we
presented
the
the
work
that
we've
been
starting
to
do.
A
We
are
building
a
poc
and
we
want
to
see
if
you
are
able
to
to
correlate
with
a
with
the
spec
how
it
is
today
like
from
build
to
from
code
change
down
to
deployment
using
the
subjects
and
then
we'll,
I
guess,
get
a
better
feeling
of
what
is
missing
there.
If
there
are
scenarios
where
we,
we
need
more
information
that
we
cannot
just
guess
by
yeah
by
the
by
the
subject.
C
Emily,
could
I
ask
you
for
a
favor
if
you
want
to
first,
you
could
stop
the
sharing.
I
think
if
you
could
dig
up
the
link
to
that
issue
where
we're
discussing
links
and
post
it
in
the
chat
that
would
be
nice
for
everyone
who
is
attending
us,
because.
C
Does
anyone
want
to
provide
any
additional
input
on
the
links
subjects?
Otherwise,
airmen
will
send
a
url
to
the
issue
where
we're
discussing
this.
So
it
would
be
great
if
well
both
if
we
can
get
the
opinions
that
were
stated
here
today
into
that
issue,
and
if
anyone
has
further
comments
and
ideas
as
well
around
that.
A
I
was
wondering,
if
nicholas,
if
we,
if
you
feel
we,
we
answered
your
question,
I
mean
it's.
I
know
it's
a
lot
of
open
things
that
we
are
discussing,
but
I
mean
did
there's
the
is:
there's
a
yeah.
O
Yeah
the
issue,
the
issue
is
perfect,
thanks
for
sharing
that,
I
was
just
wondering
kind
of
on
this
on
this
subject
as
well.
If
there
was
some
thought
giving
to
having
a
a
global,
you
know
id
that
that
relates
to
a
collection
of
events
a
bit
like
you
have
with
tracing.
You
have
three
studies
and
span
ids
so
spanning
these
would
be
event
ids
and
a
trace.
Id
relates
to
a
whole
collection
of
you
know
these
fans
that
relate
to
each
other,
so
is.
Is
there
such
a
concept
like?
O
C
It
so
this
would
relate,
I
think,
to
what
email
mentioned
before
about
a
context
id,
which
I
think,
for
instance,
yeah
peter
I'm
wondering,
should
we
mention
the
context
database,
things
that
we
have
been
so
like
among
the
work
that
data
are
working
on
is
like
a
pipeline
framework.
C
And
what
peter
and
I
have
been
discussing
is
something
we
call
a
context
database
where,
if
the
application
can
just
do
one
thing
through
the
entire
flow,
which
would
then
be
a
context
id
which
again
things
like
captain
and
other
services
already
have,
then
it
would
be
quite
trivial
to
add
an
external
service
where,
for
instance,
the
incoming
event
wouldn't
just
be
sent
to
the
application.
It
could
also
be
put
in
this
context
database
with
that
context,
as
key.
C
So
that
when,
for
instance,
the
sdk,
even
in
the
outgoing
scenario
wants
to
send
links,
then
potentially
you
could,
instead
of
of
the
sender,
telling
the
sdk
what
those
outgoing
links
should
be.
The
sender
can
just
say:
please
go
and
look
up
what
those
outgoing
links
should
be
from
the
context
database.
So
then
the
sdk
when
it
receives
the
event,
could
update
the
context
database,
and
it
could
also
use
it
again
when
it
sends
the
event.
C
I
think
there's
a
lot
of
complexities
to
that
to
actually
make
it
work,
but
I
believe,
monitor
on
your
comment.
How
can
the
sdk
help,
then?
Maybe
that
is
something
that
the
sdk
could
do
to
avoid
having
to
transport
that
data
throughout
the
application
that
receives
some
sense.
The
event
by
having
the
sdk
take
care
of
that
instead.
F
Yeah,
I
think
that,
like
having
something
like
that,
it
sounds
more
like
we
will
need
to
have
like
a
hook
point
for
external
systems
on
the
sdk,
like
that,
you
can
go
and
consume
data
that
it's
going
to
help
you
to
do
something
with
the
events
more
than
having
something
very
specific
to
context
for
context,
I'm
guessing
that
we
will
just
need
another
attribute
somewhere.
That
allows
you
to
reference
that
so
then
you
can
use
that
for
connecting
to
systems
yeah.
F
Definitely
that's
where,
like
the
sdks
plays
a
very
important
role
in
making
life
like
life
of
developers,
easier
and
and
kind
of,
like
enriching
the
information
that
you
already
have
with
external
systems.
Yeah
there
are
like
yeah.
There
are
different
integration
patterns
to
solve
problems
like
that.
So
I'm
really.
I
think
that,
like
that's
kind
of
like
where
we
should
focus
on
maybe
the
apis
for
these
systems
and
maybe
defining
into
the
spec
what
the
context
is
and
where
context
can
be
created,
or
something
like
that
yeah
for
the
use
cases
exactly.
B
To
that
as
well
the
if
we
would
use
contexts
rather
than
links
in
some
scenarios,
then
that
means
that
the
producer
of
the
event
needs
to
include
these
context
id
somehow
in
in
the
in
the
events,
and
that
also
means,
then
that
it,
it
would
be
the
burden
to
the
producer
to
understand
what.
How
would
any
consumer
of
the
event
I'm
sending
want
to
relate
this
to
anything
else
in
the
whole
system.
B
C
Yeah
yeah,
it
would
would
put
her
higher
burden
on
the
receiver
to
know
what
to
do
with
that
context.
It's
true.
B
C
Yes,
any
more
on
this
topic,
nice,
it's
been
a
really
good
discussion.
Do
you
have
any
last
words
on
this
topic?
India,
before
we
to
the
next
one.
A
No
just
one
one:
we
have
this
notes
document.
I
put
a
link
into
the
chat,
but
I'm
not
very
good
at
taking
notes,
while
I'm
thinking
about
something
or
talking
so
what
I'll
do
I'll
anyway,
we
are
recording
this
so
I'll,
go
through
the
recording
after
this
session
and
make
sure
we
have
consolidated
the
notes
and
we
have
all
the
inputs
and
create
the
issues
for
the
for
the
spec.
Based
on
the
discussion
that
we
have
so
that
we
we
capture
all
the
all
the
points
that
were
discussed
today.
F
Yeah,
I
think
this
is
this
is
great,
because
I
do
believe
that
this
is
part
of
our
like
road
map,
but
I
think
that
my
topic
was
roadmap
and
focus
right
like
what
are
we
going
to
focus
like
the
group
until
the
end
of
the
year
and
kind
of
how
the
roadmap
would
look
like
for
for
version?
1.0?
F
C
So
so
we
have
a
roadmap
in
in
our
github
project,
which
hopefully
we
can
get
someday
to
show
in
a
second
here.
I
think
we
call
it
for
version
well.
We
have
both
for
version
one
and
zero
and
but
more
more
originally
for
version
0.1,
so
to
say
what
we
would
like
to
have
before
we
take
the
next
step
so
to
say.
A
So
these
are
things
that
we
have
been
working
on,
but
this
is
what
we
we
try
to
capture
here.
Basically,
the
the
the
minimum
set
of
things
that
we
want
to
do
to
be
able
to
say.
Okay,
we
have
the
first
0.1
release
of
the
specification
right
so
this
and
we
have
things
like
defining
a
schema
for
the
cd
events
body,
so
we
have
a
pr
up
to
start
defining
the
scheme
and
how
it
will
look
like.
We
had
some
interesting
conversation
this
week
as
well.
A
I
think
nicolas
I
was
talking
to
a
colleague
of
yours
about
he.
He
gave
us
some.
Where
is
the
get
some
something
he
gave
me
some
input
about.
A
A
All
the
part
of
the
payload
that
is
specific
to
cd
events
under
like
a
dedicated
entry,
maybe
having
a
metadata
entry.
So
that
is
easy.
Then,
if
you
are
producing
this,
if
you're
an
event
producer-
and
you
want
to
have
your
own
payload
added
into
the
events,
it's
easy
to
have
a
clear
separation
between
what
is
the
part
of
the
city
events
and
what
is
yeah
separate,
basically
and
so
yeah.
So
we'll
keep
iterating
on
these.
A
And
if
you
have
any
specific
input
on
on
this
item
and
yeah,
let
us
know
I
mean
we
will
basically
continue
to
iterate
on
these
and
until
we
we
are
satisfied
with
it
and
that
will
define
how
the
events
look
like
in
the
0.1
version,
with
some
discussion
on
how
the
we're
using
the
the
subject-
and
that's
also
related
to
to
what
we
discussed
today-
and
we
want
to
finalize
that
it's
in
progress.
A
We
need
to
do
some
work
in
expanding
the
documentation
and
the
spec
for
several
of
the
different
buckets
of
events
that
we
have
yeah
capture
the
key
use
cases
in
the
primer
document.
I
think
we've
done
some
of
this,
even
if
it's
marketing
to
do
but.
A
Clarify
the
usage
of
source:
we've
done
some
work
on
that
as
well.
We
had
some
good
discussion
of
what
a
source
looked
like,
but
I
think
it's
it's
important
to
to
make
it
to
everything,
a
way
that
then
makes
sense
for
people
to
say:
okay,
yeah.
This
is
my
source,
so
we
want
to
make
sure
that
we
can
capture
different
application
types
and
special
part.
Specific
instances
like
if
my
source
is
argo
cd,
but
I
may
have
like
10
different
instances
of
argo
cd
running
in
different
environments.
A
So
we
have
some
proposals
how
we
can
codify
that
kind
of
information
and
we
need
to
finalize
those,
and
so
these
are
kind
of
the
the
the
spec
part
and
then
for
the
sdk
we
put
as
a
minimum
requirement
to
to
have
the
the
go
sdk
finalized
under
the
cd
events
github
arc.
So
we
have
the
go.
The
go
sdk
is
hosted
right
now
in
the
sig
events,
repo
github
repository,
since
we
created
the
cd
events,
organization
and
github.
We
want
to
migrate
that
and
we
want
to
migrate
when
we
do
this
migration.
A
We
want
it
to
be,
then
compliant
with
all
the
decision
that
we've
taken
on
the
spec
side
of
things.
So
this
is
the
bare
minimum
set
of
things
that
we
are
targeting
to
say:
okay,
we
can
do
a
0.1
release,
but
yeah.
So
if
there
are
obvious
things
that
seems
to
be
missing,
we
can
extend
the
scope,
and
I
think
this
is
a
good
discussion
to
have
today.
What
is
that
is
really
needed
before
we
can.
F
F
I
think
that
the
advantage
of
having
something
like
the
four
keys
projects
is
that
you
already
solve
the
problem,
so
you
can
know
what
information
is
needed
for
at
least
the
dora
metrics,
making
the
zora
matrix
kind
of
like
priority
for
the
group.
I
think
that
it
it
might
be
kind
of,
like
our
you
know,
our
light
at
the
end
of
the
tunnel
right.
F
A
G
I'll
just
mention
that
tentatively,
we
would
love
to
be
that
poc
and
I
know
you've
done
some
work.
Maybe
we
could,
you
know,
share
knowledge
on
that,
but
I'm
already
planning
to
spend
some
time
creating
a
poc
within
four
keys
that
consumes
cd
events,
so
kind
of
come
at
this
from
both
sides.
A
Oh,
that's
really:
cool
yeah.
We
should
definitely
then
collaborate
on
that
and
yeah.
So,
as
you
work
on
on
on
your
pc
and
you,
you
will
find
missing
bits
and
pieces
here
and
there.
So
we
can
make
sure
that
then
we
we
develop
the
spec
in
a
way
that
enables
yeah
fulfilling
that
use
case
because
at
the
end,
it's
like
really
one
of
the
two
core
use
cases
like
we
said
in
the
beginning
that
we
want
to
have
cool.
A
Another
thing
that
I
I
realize
now
is
not
covered
in
the
in
the
road
map
and
as
another
aspect
that
we
were
discussing
with
with
ben
the
other
day
is
about
versioning,
which
is
a
something
that
we
should
probably
have
an
initial
idea
about
when
we
do
initial
version,
because
yeah
so
so
far
we
we
had
like
we
had
some
discussion
about
it.
A
A
Version
number
sorry,
which
adds
complexity,
but
also
flexibility,
so
we
need
to
to
clarify
a
little
bit
how
it
is
going
to
do
like
when
we
add
a
new
type
of
events.
Do
we
make
a
new
full
spec
version,
a
minor
or
major
rules
line
lined
out
for
for
this
before?
I
think
we
do
so
that
we
don't
then
go
break
expectations.
A
Yeah.
My
expectation
is
that
in
the
beginning
there
will
be
changes
happening
in
the
events.
I
would
obviously
we'll
try
to
make
no
no
breaking
changes,
but
we
may
have
to
you
know
increment
on
the
version
of
the
the
events
and
then
yeah
as
we
go
forwards.
Hopefully,
then
it
will
not
change
that
often
anymore,
but
yeah.
We
will
have
new
events
coming
in
expanding
the
context
I
don't
know.
A
F
Maybe
maybe
like
on
the
sdk
side
of
things
just
trying
to
find
out
if
we
can
just
get
community
members
to
help
us
to
build
other
languages
as
well
and
yeah.
Definitely
we
need
kind
of
like
a
working
group
on
on
kind
of
creating
the
specs
for
the
sdks
as
well,
and
some
kind
of
like
dck,
like
test
kit
for
testing,
that
the
sdks
are
doing
what
they
are
supposed
to
be
doing.
F
F
So
maybe
yeah,
I
think
that
part
of
the
sdk
work
is
making
sure
that
we
understand
the
shape
of
it,
the
requirements
and
also
kind
of
how
are
we
going
to
test
that
just
the
case
of
doing
kind
of
like
a
an
uniform
thing,
and
we
can
rely
basically
on
the
on
the
cloud
events
sdks
that
are
a
little
bit
more.
I
like
are
pretty
complex
in
very
different
ways,
but
at
least
just
follow
up
on
that
and
think
about
extending
those
sdks
in
in
a
way.
C
So
the
way
things
move
forward
is
for
someone
to
find
a
bit
of
time
or
a
bit
of
energy
or
a
bit
of
passion
for
some
specific
topic
and
then
drive
that
and
the
other
people
in
the
community
will
typically
react
to
that
passion
and
join
for
the
discussion
in
subject,
and
then
that
goes
on
for
a
while.
So
there
is
it's
definitely
not
the
case
that
that
anyone
needs
to
like
get
approval
for
some
discussion
or
get
approval
for
some
topic.
C
Just
come
in
in
the
github
project
and
drive
that
discussion
for
a
while,
and
you
will
see
things
happening
yeah,
so
something
I
think
we
should
strive
to
become
a
bit
a
bit
better
at
is
to
making
sure
that
discussions
actually
reach
a
decision
which
is
always
difficult.
C
But
please
anyone
who
has
some
some
passion
for
some
topic
just
come
in
and
start
posting
and
people
will
respond
to
that.
F
That
that's
that's
good,
like
just
to
make
sure
we
focus
on
stuff
basically
and
that
we
can
just.
I
think
that
I'm
a
very
practical
person.
So
if
we
focus
on
implementation
and
making
sure
that
like
if
we
all
agree
that
the
dora
metrics
are
the
thing
that
we
should
be
focusing
on,
then
let's
just
do
that.
Let's
make
sure
that
we
we
get
something
that
pushes
us
closer
to
that,
and
I
guess
that,
like
what
we
can
do
like
in
the
in
the
in
the
regular
meetings,
is
just
do
more
planning
about.
F
How
do
we
get
there
because
it
feels
like
a
lot
of
work,
but
I
think
that
we
can
be
very
strategic
on
on
what
do
we
do?
First
and
and
how
do
we
move
forward
there?
So.
C
F
C
I
don't
misremember,
I
think,
matthias,
who
is
part
of
the
city
events
project
actually
did
a
quite
a
bit
of
work
around
four
keys
as
one
of
our
earlier
proof
of
concepts
he's
not
the
meeting
today.
As
far
as
I
know,
but
definitely
we
should
sync
up
with
him,
because
yeah
he's
done
a
lot
of
thinking
around
it
perfect
yeah.
That
sounds
good.
C
Yes,
so
for
those
of
you
who
weren't
here
in
the
introduction
and
the
way
we're
running
this
community
summit
today
is
anyone
who
has
anything
they
would
like
to
discuss
some
topics,
some
questions
or
anything
like
that.
Just
grab
a
microphone
and
if
your
business
or
those
online
just
unmute
and
state
your
business.
A
In
this,
we
only
had
like
a
cloud
events
player
to
show
the
events
what
is
going
on,
but
I
think
it's
important
really,
then,
that
we
focus
on
the
on
the
devops
metrics.
Do
you
see
now?
Because
we
can
further
develop
this,
this
side
of
things
and
one
of
the
things
that
we
were
also
chatting
with
with
mauricio?
Is
that
to
it
it
would
be
nice
to
have
a
way
to
to
visualize
what
is
going
on.
A
In
terms
of
events,
I
mean
one
thing
can
be
the
four
keys
dashboard
that
is,
but
it's
a
very
aggregated
view
already,
but
even
something
that
allows
you
to
see
the
events
coming
through
in
a
graphical
way,
maybe
using
javascript
or
some
so
yeah.
If
someone
has
passion
about
the
this
kind
of
front-end
technology
and
wants
to
contribute
to
this
kind
of
project
feel
free
to
reach
out,
but
yeah
we're
looking
and
we'll
find
someone
anyways
that
we'll
make
sure
we
find
someone
that
can
can
help
us
building
that
part.
A
Yeah
yeah
yeah,
exactly
that's
that's
why
I
mentioned
yeah
and
it's
building
a
poc
and
people
take
it
and
then
they
made
small
variation
and
add
the
other
tool
and
to
see
how
this
develops.
C
I
have
a
question
actually
on
this
subject,
so
when
we're
talking
about
metrics
and
things
like
that,
to
what
extent
should
we
talk
more
to
the
open
telemetry
team
or
that
project?
So
I
think
that
is
I
I
know
not
that
much
about
it.
It's
more
about
tracing,
I
think,
but
it
seems
like
there
would
be
not
zero
overlap
between
what
we
are
trying
to
achieve
and
what
they
are
trying
to
achieve.
B
Heard
that
the
talk
from
an
open
telemetry,
I
think
it
was
on
tuesday
on
silicon
now,
where
the
presenter-
I
don't
remember
who
his
name,
but
the
presenter
men
should
actually
see
the
events
in
the
end
of
his
talk
as
something
that
could
be
interesting
to
interpret
with
and
for
sure.
I
think
we
should
see
an
interoperability
between
open,
telemetry
and
seed
events
instead
of
making
them
clash
society,
so
one
of
them
could
reference
the
other
or
vice
versa.
B
C
What
has
happened
to
your
code,
commit
all
the
way
from
when
you
merged
it
or
even
created
a
polar
cut
for
it
to
final
release
of
possibly
multiple
products
and
their
cd
events,
in
my
view,
would
have
the
responsibility
of
of
providing
the
data
for
that
view.
But
if
you
sort
of
click,
one
of
those
boxes
like
what
happened
inside
my
build,
for
instance,
then
open
telemetry.
C
B
Exactly-
and
I
know
that's
actually
how
we've
discussed
it
recently
in
ericsson
as
well,
we
we,
I
don't,
think
we
open
telemetry
as
such,
yet
in
the
usk,
something
I'm
thinking
of,
but
in
similar
use
cases
where
we
actually
have
metrics
sent
as
well.
B
We
say
that
we
should
relate
refer
from
the
events
to
those
metrics,
instead
of
vice
versa,
so
it
totally
makes
sense
to
have
the
more
detailed
view
for
certain
sub
parts
of
your
pipeline
in
those
metrics
and
europa
telemetry,
for
example,
and
then
have
the
overall
flow
or
pipeline
and
pipelines
of
say
through
these
city
events
and
stuff.
C
J
C
C
Yes,
so
yeah
and
then
feel
free
to
to
come
grab
any
one
of
us
or
each
other
during
the
break
and
we'll
start
back
up
in
ten
minutes.
Okay,
let's
start
commenting.
P
R
S
S
J
S
N
T
S
S
R
S
C
So
does
anyone
have
any
favorite
topic
they
would
like
to
discuss
next.
C
C
I
have
one
topic
that
I
think
may
be
interesting.
Unfortunately,
I
seem
to
have
uploaded
a
very
wrong
fight
for
that,
and
we
need
to
fix
that
pretty
quickly,
which
is
about
descriptive
versus
prescriptive
events,
which
has
been
a
little
bit
of
a
hot
topic,
partly,
and
just
give
me
a
second
to
fix
this.
S
A
C
C
Is
it
yeah
if
you
scroll
down,
you
will
see
that
it.
It
starts
with
a
blank
page
and
then
it
has
this.
But
when
you
open
it
it
has
entirely
different
content,
which
is
weird
to
me.
C
Some
github
desktop
thing-
I
don't
know,
but
okay
I'll
show
it
from
here
so
right
now,
the
city
events
project
mainly
consists
what
we
would
call
descriptive
events.
These
are
events
that
describe
something
that
has
happened.
C
We
could
also
introduce
prescriptive
events,
so
this
would
be
more
like
commands
saying
that
something
should
happen
and
if
we
take
two
examples,
one
mainly
descriptive
and
one
with
some
prescriptive
elements,
and
we
can
say
that
we
start
with
some
change
being
murd
merged
somewhere.
These
would
both
be
descriptive
events
because
they're
describing
something
that
has
happened,
which
is
a
change
being
merged
in
both
these
cases.
In
the
scenario
I
have,
some
orchestrator
will
pick
up
that
events
and
decide
to
do
something
in
the
descriptive.
Sorry,
you're
sharing
something
sorry.
I
thought.
C
So
in
both
cases
we
had
a
change
being
merged
and
some
orchestrator
picking
that
up
so
and
thus
far
again,
everything
is
descriptive
indicated
by
the
purple
boxes,
because
these
are
something
that
things
that
has
happened
in
a
more
pure,
descriptive
setup,
the
orchestrator
would
say:
okay,
that
has
happened
so
now.
I
will
do
this,
so
it
has
some
opinion
on
what
to
do
next.
C
C
C
C
C
So
that
second
orchestrator
would
then
be
invoking
the
pipeline,
which
I
missed.
Somehow
there
we
go.
C
What
this
means,
I
would
say,
is
that
in
the
first
orchestrator
that
orchestrator
knows
what
to
do,
where
to
do
it
and
how
to
do
it,
so
it
it
owns
the
the
flow
the
whole
flow
in
the
second
setup.
The
first
orchestrator
only
knows
what
to
do,
and
it
just
puts
that
information
about
what
to
do
in
an
event,
and
it
sends
that
out
and
then
that
gets
picked
up
by
some
other
orchestrator
who
actually
knows
where
to
do
and
how
to
do.
C
Yes,
we've
had
a
little
bit
of
discussion
on
this
in
in
the
seed
events
group.
It's
not
at
all
obvious
to
us
that
we
should
have
these
kind
of
of
prescriptive
or
command
events.
C
C
But
yeah
I
I
wanted
to
bring
this
up
as
a
discussion
that
that
we're
having
and
basically
I'm
interested
in
any
opinions
or
pitfalls
or
benefits
or
of
what
what
we're
trying
to
do
does
anyone
have
anything
they
would
like
to
bring
on
the
table
bring
to
the
table
on
this
topic
right
now,
yeah,
there's
a
button
in
the
bottom
here.
Is
it.
T
Hello,
my
name
is
brandon.
I
work
for
amazio,
we
have
an
open
source
like
build
whole
platform
on
kubernetes
called
lagoon,
and
we
are
basically
doing
the
prescriptive
thing
right
now.
Obviously
we
don't
use
cd
events,
so
we
would,
if
you
have
that
available,
we
would
pick
that
path
if
we
went
with
city
events.
T
T
T
It
is
aware
of
the
clusters
that
exist
and
the
initial,
like
you
know
this
project
potentially
can
be
deployed
like
in
this
cluster
of
this
cluster
like
and
then
the
clusters
figure
out.
Well,
if
it's
production,
then
like
don't
worry
about
it,
if
it's
development
do
it
here
so
like
there
is
some
smarts
and
some
descriptive
stuff,
but
also
some
prescriptive
stuff,
because.
C
That
it
brings
an
interesting
question
to
the
table
which
piret
you
were
discussing
yesterday,
like
in
the
scenario
where
the
sender
doesn't
know
who
will
pick
that
up.
C
In
this
setup
at
least
the
first
orchestrator,
the
one
sending
the
event
has
no
responsibility
of
making
sure
someone
actually
does
anything
with
that
event.
Just
send
it.
This
should
happen
so
like
would
we
need
to
to
introduce
a
pipeline
run
request,
acknowledged
event,
so
that
someone
can
say.
Okay,
someone
is
picking
this
up.
C
Probably
that's
not
not
something
that
we
should
do
do
we
need
an
event
store
like
what
they
have
in
eifel,
for
instance,
if
the
second
orchestrator
has
been
down
for
some
time
or
hasn't
been
started
yet,
and
then
it
comes
up
and
would
like
to
see
what
did
I
miss
was.
What
could
I
do
that
I
haven't
done
and
those
kind
of
issues,
but
I
guess
in
in
your
use
case,
you,
wouldn't
you
know
what
clusters
you
have,
so
you
pretty
much
send.
T
It's
probably
like
a
mix
of
that
like
it's,
not,
we
don't
like
fully
direct
things
from
core,
but
it
it
doesn't
like
send
everything
to
everybody.
Yeah.
D
D
So,
for
example,
if
we
have
a
pipeline
run
requested-
and
we
only
want
one
orchestrator
to
react
upon
that,
then
once
one
orchestrator
decides
to
act
upon
that
request,
it
can
just
add.
I
am
going
to
act
upon
that.
I
promise
that
so
that
when
another
orchestrator
in
a
case
where
you
have
several,
would
wake
up
and
also
try
to
act
upon
that,
the
request
would
see.
Okay,
this
is
a
case
where
not
two
orchestrators
should
not
be
acting
on
the
same
event.
M
C
A
A
You
can
have
multiple
ones,
and
we
use
that
in
one
of
the
pocs
like
when
we
have
like
the
receiving
side
getting
the
events
and
also
we
have
like
the
the
cloud
events
viewer,
getting
all
the
events
so
that,
like
a
more
broad
subscription,
so
that
you
can
show
all
the
events
that
are
coming
through
and
yeah.
A
So
in
terms
of
prescriptive
and
descriptive,
I
don't
know
if
it's
something
that
I
wanted
to
say
is
that
at
least
in
terms
of
subjects
or
like
kind
of
the
basic
data
structure
that
we
have.
A
It's
certainly
it's
something
that
might
be
useful
for
prescriptive
type
of
event
to
reuse
where
it
makes
sense,
but
yeah,
I
don't
know
if
they
would
be
in
there,
but
because
we
we
basically
define
a
schema
to
reason
about
changes,
bills,
tests
and
so
forth.
When
you
request
something
has
less
information,
I
guess
about
that.
But
yeah
we
can
still
use
whatever
it's
applicable
in
those
type
of
prescriptive
events.
C
So
two
things
that
have
been
brought
up
in
earlier
discussions
on
this
is,
if
you
look
at
the
cloud
event
specification,
which
I
think
matthias
and
the
team
did,
they
seem
to
favor
descriptive
events
saying
that
cloud
events
isn't
really
meant
to
be
used
as
like
sending
commands.
It's
more
use,
intensive
use
for
showing
what
has
happened,
and
a
second
thing
which
I
think
is
is
interesting
outside
of
just
this
concept
is
what
would
it
mean
to
say
that
you're
compatible
with
cd
events?
C
If
we
introduce
prescriptive
events,
I
don't
think
you
should
be
forced
to
be
supporting
receiving
prescriptive
events
to
be
able
to
say
I
am
compatible
with
city
events.
There
should
be
some
smaller
subsets
saying
yeah.
I
send
the
descriptive
events
that
I
should
based
on
what
I'm
doing,
and
that
should
perhaps
be
enough,
but
it
gets
tricky.
Yes,
since
you
can
get
a
mic
over
to
you,.
S
Representing
kind
of
the
receiver's
end
of
this
spectrum,
I
wouldn't
want
those
descriptive
events.
That's
just
noise.
I
did
say
earlier.
I
want
all
the
data,
but
I
don't
want
those
so
yeah
that
top's
great
for
internal
to
a
system
but
then
to
be
compatible.
From
my
perspective,
you
would
only
need
to
emit
those
descriptive
ones.
C
Yes,
so
the
comment
was
basically
that
for
someone
who
is
more
interested
in
like
calculating
metrics
and
showing
status,
obviously
the
or
perhaps
obviously
the
prescriptive
events
would
just
be
nice.
They
would
not
add
anything
you're
only
interested
in
what
has
actually
happened,
because
that
is
what
will
contribute
to
the
metrics,
so
yeah.
C
B
I'm
I'm
very
much
in
favor
of
descriptive
events,
but
I'm
trying
to
formulate
why
I
am
I
mean
it,
it's
it
in
my
mind.
It
makes
it
easier
to
create
the
decoupled
system
and
when
the
producers
don't
need
to
know
the
producers
of
an
event,
don't
need
to
know
what
happens
downstream
of
me.
So,
for
example,
if
I
create
an
artifact,
if
I
build
something,
I
don't
need
to
know
all
the
kinds
of
tests
that
will
be
run
in
parallel.
B
B
If,
if
all
events
sent
are
just
saying
what
has
happened
and
not
saying,
what
do
I
expect
should
happen
next
and
I'm
for
sure
for
for
the
metrics
use
case,
there
there's
no
reason
at
all
for
prescriptive
events
and
if
there
would
be
both
descriptive
and
prescriptive
events,
in
this
case,
for
example,
triggering
a
pipeline
which
of
those
should
then
be
listened
to.
B
I
mean
say
that
a
pipeline
is
triggered
on
the
source
change,
for
example,
if
it
was
descriptive,
then
only
the
the
source
change
event
itself
was
listened
to,
and
then
the
python
was
started.
If
it
is
pre-scripted,
then
in
some
way
this
will
change.
The
venture
itself
contain
information
on
what
pipeline
to
start,
if
it,
if
they
should
all
be
descriptive
or
if
we
should
combine
them,
as
you
have
here
and
then
with
a
pipeline
requested,
then
what
is
the
actual
trigger
of
the
pipeline
being
requested
there?
B
B
When
does
things
happen
in
the
pipeline?
Maybe,
but
that
I
guess
my
most,
my
main
concern
is
on
on
decoupling
the
systems
and
making
the
producers
of
the
events
not
aware
of
what
needs
to
happen
downstream.
B
But
then,
of
course,
there
needs
to
be
some
overall
system
orchestrator
somewhere
saying
that
this
that
should
have
happened
downstream
didn't
happen.
So
I
need
to
see
what
what
is
wrong
with
that
service.
It
didn't
kick
off
for
some
reason,
but
I
guess
that
that's
a
bit
out
of
the
scope
of
prescripted
descriptive
because
it
it's
it's
interesting
in
either
case.
B
B
B
But
as
you
say
I
I
I
would,
I
would
think
that
we
shouldn't
have
them
in
the
core
respect,
so
that
consumers
would
expect
them
to
be
there
general
consumers,
but
for,
as
you
say,
in
like
an
internal
system,
if
you're
they
kept
in
use
case,
for
example,
they
could
add
the
kept
on
extensions
and
then
they
could
add
some
events
that
could
happen
in
between
them.
In
between
the
cloud
of
sorry,
the
cd
events
there.
A
A
Send
these
events
and
you
can
have
another
system
taking
it
and
say:
okay,
I'm
doing
this
build,
and
then
I
send
the
contacts
back
with
the
result,
and
then
you
know
the
progress
will
continue,
and
so
captain
is
orchestrating
this,
so
it
actually
goes
through
across
systems
and
in
the
initial
plc
that
we
built.
We
had
like
tecton
starting
the
workflow
and
then
triggering
captain,
but
then
captain
was
triggering
tecton
back
through
city
events
and
we
use
descriptive
events
for
doing
this.
A
But
the
thing
is
that
you
need
some
kind
of
layer
always
on
the
receiving
side
that
receives
the
descriptive
events
applies
some
logic.
It
could
be
some
policies,
some
rules,
some
decisions,
extracts
the
data
and
then
triggers
the
next
thing
and
how
it
triggers
the
next
thing
it
can
be.
It
depends
it
can
be.
A
If
you
have
an
api
can
be
an
api
call
directly
in
the
system,
or
it
could
be
again
an
event,
and
in
that
case,
if
you're
using
an
event,
it
would
have
to
be,
in
this
case
a
prescriptive
event,
because
otherwise
you
end
up
in
having
another
system.
That
is,
you
know
so
yeah.
If
you,
if
you're
sending
a
script
descriptive
event,
you
pick
it
up.
You
apply
some
logic
and
you
want
maybe
multiple
system
to
react
to
it.
A
Then
you
could
put
this
prescriptive
event
on
a
bus
again
and
then
mini
will
pick
it
up.
But
the
problem
with
with
this
approach
is,
then,
how
do
you
reconcile
things?
Because
when
you
have
this
prescriptive
event,
normally
you
need
to
have
like,
like
you
said,
an
acknowledgement
back,
that
the
thing
is
fin
and
if
you
have
an
undefined
numbers
of
consumers
of
these
events
that
will
all
have
to
acknowledge.
A
How
do
you
know
that
all
of
them
finished
or
you
need
to
have
some
kind
of
you-
don't
know
how
many
of
them
will
be
there,
for
instance,
and
so
it's
really
hard
to.
C
And
I
think
email
brought
up
something
important
in
before,
so
even
with
descriptive
events,
if
you
want
to
take
some
action
on
descriptive
events,
some
system
somewhere
needs
to
be
able
to
answer
the
question:
do
I
have
enough
next
step?
C
It
could
either
be
something
very
simple
as
like,
as
soon
as
I
have
a
change
merged
event.
That
is
enough
for
me
to
take
the
next
step,
because
I'm
going
to
build
or
run
some
unit
tests
or
something,
but
there
can
definitely
be
scenarios
where
you
need
to
grab
so
there's
the
concept
called
fanout
and
fan-in,
which
I
think
has
multiple
definitions.
Unfortunately,
I
would
describe
it
as
say
that
you
you
make
a
release
of
something
like
an
internal
release
of
an
application,
and
then
you
want
to
include
that
application
in
a
bigger
package.
C
But
before
that
happens,
you
want
to
run
a
number
of
tests
on
it.
So
a
typical
example
from
from
the
domain
me
and
peter
working
is
in
automotive.
Is
you
make
a
release
of
some
software
for
some
computer
in
the
car,
and
you
want
to
do
model
testing
software
testing
and
hardware
testing
on
that,
and
only
when
all
those
things
have
passed?
C
Do
you
want
to
sort
of
let
the
next
level
use
that
component
software,
so
you
would
then
go
to
the
in
a
in
a
visualization
tool
that
might
look
like
you
go
to
the
first
component
release
step
and
then
it
branches
out
into
three
parallel
tracks
where
one
goes
to
a
model
system,
testing
tool,
it
finds
the
model
for
that
application.
It
does
some
fancy
testing
on
that
and
then
it
releases
a
verdict
on
that
and
the
software
downloads,
the
software
downloads,
some
simulator
stuff
sets
everything
up
runs.
C
Some
tests
hardware
finds
the
correct
hardware
rig
where
this
can
be
tested.
Installs
the
software
on
the
actual
computer
does
some
testing
and
then
releases
it,
and
then
you
need
those
three
events
to
to
come
back
in
again
and
that
can
be
quite
complex,
and
that
is
where
something
like
links
that
email
pointed
to
before
can
be
used.
Can
we
trace
this
back
to
the
same
originating
release?
C
Also,
something
like
context
could
be
used
in
the
scenario
where
okay,
we
need
to
make
sure
they
have
the
same
context,
because
then
they
they
spawned
from
the
same
branch
or
they
just
need
to
say.
I
am
a
test
verdict
for
this
version
of
this
release.
That
is
also
sufficient
to
understand
that
they
came
from
the
for
the
same
track.
C
But
what
I'm
getting
at
is
is
that
the
logic
for
when
we
are
ready
to
take
the
next
step
can
be
quite
advanced
so
that
logic
isn't
for
that
specific
use
case.
It's
not
at
all
simplified
by
having
a
prescriptive
event,
because
the
entity
that
sends
the
prescriptive
event
still
needs
to
do
all
that
logic.
C
So
so
I
don't
think
prescriptive
events
reduce
the
complexity
of
using
cd
events.
What
it
does
allow
you
to
do
in
a
more
standardized
way
is
to
split
the
complexity.
A
bit.
As
I
showed
you
before
in
the
picture,
you
can
have
the
box
that
waits
for
enough
things
to
be
available
for
it
to
to
say
that
we
are
ready
to
take
the
next
step
and
the
box
that
actually
takes
the
next
step.
Those
can
be
different
boxes.
C
C
B
C
So
someone
still
needs
to
sit
and
listen
to
say.
Okay,
when
do
we
have
all
the
components
that
should
go
into
this
composition?
When
are
they
ready
when
are
they
tested?
When
are
they
available
for
me
to
do
something,
and
then
that
would
either
be
an
orchestrator
or
it
would
be
an
orchestrator
that
either
explicitly
invokes
the
build
tool
to
say?
Okay,
I
have
verified
that
everything
is
available.
You
can
now
go
ahead
and
start
your
build.
C
Or
the
orchestrator
who
said
in
an
event
saying
anyone
who
who
likes
to
build
docker
images
these.
I
have
now
verified
that
everything
is
available,
so
every
anyone
who
wants
it
can
now
pick
it
up.
But
I
guess
that
again
boils
back
to
like
either
explicitly
invoking
the
build
tool
from
the
orchestrator
or
invoking
it
through
a
request
or
a
command.
B
So
I
think
it
makes
it
more
decoupled
in
that
way,
even
if
such
scenarios
were
used
using
the
descriptive
events
instead,.
C
Yeah,
that's
a
fair
point:
I'm
going
to
go
ahead
and
share
my
screen
once
more
just
to
describe
something
that
so
we
actually
we
built
something
that
is
conceptually
similar
to
this
in
involve,
of
course,
we
had
a
lot
of
entities
producing
various
types
of
events
like
garrett,
in
this
case
maybe,
and
what
we
had
was
we
called
it
a
trigger
system
where
you
could
basically
write
filters
for
events
where
it
said
anytime,
an
event
comes
in
that
matches
this
filter
or
anytime.
C
Multiple
events
come
in
with
the
same
context
that
match
these
filters.
We
invoke
an
http
or
yeah.
We
make
an
http
request
and
these
would
almost
always
go
to
some
jenkins
server
somewhere,
which
then
started
a
job,
and
you
could
pick
out
parameters
from
the
messages
and
put
into
that
http
request.
But
then
it's
exactly,
as
you
said,
email
whenever
we
needed
some
additional
information
in
the
jenkins
job,
we
would
have
to
go
and
update
the
trigger
to
pick
additional
data
out
of
the
message
to
send
in
the
http
request.
C
Yeah
what
it
did
allow
us
was
to
not
have
a
whole
bunch
of
jenkins
instances.
Listening
on
the
event,
bus
to
figure
out
what
to
do
so,
yeah
not
really
prescriptive
events,
but
definitely
this
setup
where
we
had
one
requesting
orchestrator
and
one
performing
orchestrator.
C
C
A
So
what
what
would
you
say
is
the
the
main
advantage
for
having
the
that
kind
of
last
mile
as
an
event
as
opposed
to
an
api
call
or
is
it
to
go?
I
don't
know
it
but
yeah.
What
would
you
say
the
it's,
the
the
main
reason
for
for
that
I'm
trying
to.
T
I
suppose
it's
just
standardization
right
like
I
mean
because
you
know
for
us
we're
already
doing
events
eternally
they're,
just
okay,
they
don't
match
anything
world.
You
know.
Is
it
useful
to
have
like
standardized
prescriptive
events
between
like
tech
in
and
all
these
other
tools,
if
nobody
is
actually
interrupting
between
them,
like
if
they're
only
ever
used
internally?
T
Is
it
useful
to
standardize,
I
don't
know
or
what,
like
once
they're
standardized?
Could
you
find
what
things
appear?
That
would
make
sense
just
be
like,
oh
well,
since
these
two
things
are
happening.
The
same
way,
all
of
a
sudden,
I
see
a
new
metric
I
could
see
or
like
there's
some
new
debugging
thing
or
something
that
stuff
I
don't
I'm
not
sure,
but
I
guess
that
would
be
the
biggest
advantage.
Is
it's
now
standardized
like
everybody's
doing
this
internally
anyway,
but
now
everybody's
doing
it
the
same
way?
C
I
mean
one
one
metric
that
you
could
definitely
get
out
of.
That
is
how
long
does
our
stuff
stuff
that
we
know
should
start?
How
long
does
that
wait
until
it
actually
starts,
because
you
have
the
request
and
then
you
have
the
corresponding
started
event.
It
would
be
harder
for
an
external
observer
to
say.
Oh,
since
we
got
these
three
artifact
published
events,
that
means
that
some
pipeline
should
start
now.
C
We
need
to
wait
for
that
to
actually
start
it's
much
more
more
complex
in
that
sense,
but
I
guess
that
metric
could
also
be
calculated
by
in
this,
where
you
don't
have
events
or
with
where
you
have
events
with
acknowledgement,
it
could
be
calculated
by
the
producer
of
the
request,
because
it
wouldn't
would
then
know
how
long
did
I
wait
until
someone
acknowledged
this
they're
actually
starting,
but
it's
yeah.
If
an
external
observer
were
to
to
try
to
determine
that
then
they're
having
standardized
requests.
Events
would
would
make
that
use
case
simpler.
C
I
think
yes,
are
there
more
thoughts
or
ideas
on
that
topic?
On
the
topic
of
a
prescriptive
events,.
A
A
Yeah,
I
mean
in
if
we
had
like
standard
for
prospective
events
in
the
way
I
and
trying
to
figure
it
in
my
mind,
is
like
if
you
have
like
some
filtering
system
like
eric
was
describing
that
allows
you
to
get
the
descriptive
events
and
take
decisions,
and
then
what
you
could
do
is
then
send
a
prescriptive
events
and
saying
yeah
build
this
artifact
now,
and
you
could
then
then
send
the
same
event,
regardless
of
whether
you're
asking
tecton
or
jenkins
or
shipwright
or
whatever
system,
to
do
that.
A
T
Maybe
one
well:
here's
where,
like
my
lack
of
knowledge,
comes
in,
I
don't
know
exactly
what
events
you
want
to
standardize,
but
for
us
like
internally,
like
we
might
want
to
say,
create
a
prescriptive
event
that
tells
all
of
our
clusters
to
do
something
right
like.
T
But
you
know
I
don't
know
if
I
can't
think
off
top
of
my
head
if
that's
like
build
related
so
like,
maybe
it
wouldn't
even
be
included
in
your
list
of
events,
but
that
would
be
a
thing
that
would
be
like
a
prescriptive
event
that
we
would
say,
like
hey,
go,
build
the
test
suite
like
everywhere,
like
test
all
the
clusters
at
once,
like
maybe
that's
out
of
scope,
but
that
would
be
the
example
that
comes
to
mind
immediately.
For
me,
I
think.
C
That
would
be
in
scope,
so
so
our
four
main
buttons
that
we'll
work
with
right.
Now
we
have
the
core
which
is
like
pipeline
things,
mainly,
I
think
source
code,
continuous
integration
and
continuous
deployment
and
somewhere
on
continuous
deployment,
might
be
at
least
tangentially
related
or
maybe
continuous
integration
to
what
you're,
referring
to
so
yeah
bills
and
deployments
and
tests
and
all
those
things
should
be,
and
it's
a
good
good
thing
to
think
about
as
well
is
we
definitely
haven't.
C
As
far
as
I'm
aware,
we
haven't
limited
ourselves
to
any
particular
scope
for
the
long
term.
We
have
limited
ourselves
short
term,
because
we,
I
would
say
we
tried-
or
I
tried
when
I
joined
the
city
events
project
to
say
here
are
all
my
favorite
events
that
I
would
like
to
have
in
the
spec,
and
I
spent
some
time
describing
all
those
and
the
feedback
I
got.
Was
these
look
really
good,
but
not
right.
C
A
T
No,
it's
definitely
a
read
the
code
kind
of
documentation.
A
Oh
okay,
I
was
one
maybe
for
for
you
or
anyone
working
on
the
project
to
come
to
our
see
events
meeting
and
maybe
do
a
presentation
about
the
type
of
interactions
that
that
you
have.
So
we
can
try
and
capture
that
and
see
maybe
at
least
ever
starting
with
an
issue
to
track
those
the
problem
and
the
kind
of
use
cases
that
you
want
to
address.
A
And
then,
if
you
have
the
interest
to
maybe
build
a
vlc
or
see
what
how
this
would
fit
do
like
analysis
and
see
how
this
would
fit
on
city
events
yeah,
so
that
we
have
like
kind
of
an
actionable
next
step
to
go
forward,
because
I
think
in
general
I
mean
so
on
on
descriptive
events,
but
yeah.
We
could
consider
like
a
special
or
an
extension
or
a
group
of
events
that
you
don't
have
to
implement
necessarily
to
be
cd
events
compliant.
But
in
general
I
mean
cd
events.
A
Compliance
is
one
of
the
topic
that
I
think
we
need
to
refine
in
future
because
we
started
creating
these
different
phases
of
buckets
because
we
expected
that
not
every
system
will
implement
all
the
events
right.
C
Yes,
so
I
might
say
we
have
been
discussing
one
of
your
favorite
topics,
descriptive
versus
prescriptive
events,
for
for
a
while,
yeah
and
and
to
summarize
the
discussion,
I
would
say,
yeah
it's
a
lot
of
differing
opinions
in
the
rooms
where
we've
been
discussing,
whether
that
is
something
that
we
should
standardize
and
if
so,
if
we
should
have
it
in
an
extension
or
or
something
similar,
and
also
in
what
use
cases
prescriptive
events
versus
just
internal
signaling
in
some
framework
would
make
more
more
sense.
C
I
guess
it's
hard
for
you,
since
you
you
weren't
here
for
most
of
the
discussion.
If
you
want
to
give
some
thoughts
on
your
side
on
descriptive
versus
prescriptive
before
we.
F
Yeah,
so
I
think
that,
like
the
main
reason,
why
that's
my
favorite
topic
is
that
like
when
I'm
building
integrations,
sometimes
I
just
to
need
to
trigger
stuff
based
on
the
things
that
are
happening?
I
think
that
if
we
look,
they
look
it
from
more.
Like
the
metrics
point
of
view,
you
are
just
always
collecting
events
you
are.
F
Actually
you
can
react
to
those
events
and
those
things,
but
writing
the
mapping
between
like
an
environment,
was
created,
and
then
I
need
to
deploy
it's
something
that
you
will
need
to
do
in
a
custom
way
all
the
time.
F
So
my
my
question
and
the
reason
why
I
brought
this
topic
was
that
when
building
these
integrations,
that's
kind
of
where
I
was
spending
the
most
time
on,
and
I
thought
okay,
this
might
be
something
that
we
can
also
investigate
into
providing
some
kind
of
solution,
or
at
least
maybe
maybe
the
the
result
is
like
that.
What
we
need
to
do
is
we
create
some
guidelines,
or
at
least
show
some
use
cases
so
developers
adopting
cd
events.
F
F
C
I
presented
it
something
like
this,
so
you
in
the
descriptive
or
purely
descriptive
case,
you
would
have
some
sort
of
orchestrator.
That
knows
both
what
to
do
and
where
and
how
to
do
it,
and
this
could
then
do
internal
signaling
or,
however,
that
would
work,
but
it
doesn't
need
to
to
request
anything
from
anyone,
whereas
in
a
prescriptive
case
you
could
have
one
orchestrator
that
realizes
okay
now,
it's
time
to
do
something,
I
don't
know
how
to
do
it.
C
Yes,
but
as
we
discussed,
I
don't
think
we
want
orchestrators
to
have
to
be
able
to
react
to
prescriptive
events,
to
claim
that
they
are
as
andrea
put
it
to
see
the
events
compliant,
because
that
puts
quite
a
lot
of
burden
on
these
orchestrators
to
not
only
emit
events
but
also
listen
to
events
and
figure
out
how
to
acknowledge
if
they
need
to
that,
they
are
going
to
do
something
or
figure
out
if
they
should
react
on
that
event.
C
So
there's
a
lot
of
interesting
things
to
discuss
there
as
well,
and
there
is
an
issue
for
this
in
our
guitar
project,
which
I
will
put
a
link
to
in
the
chat
in
a
second,
so
yeah
and
as
I
mentioned
in
the
beginning,
though
one
of
the
major
ways
things
happen
in
this
project.
Is
people
popping
into
discussions
and
issues
and
giving
their
thoughts
and
feedback
and
and
putting
through
proposals.
F
I
think
that
one
of
the
things
that
might
we
might
need
to
discuss
here-
and
maybe
you
already
discussed
this,
but
is
this-
is
pretty
related
with
the
the
end
of
my
presentation.
The
other
day
like
yesterday,
was
it
just
no
two
days
ago,
which
basically
was
all
about
that
is
like
how
do
we
build
integrations
with
these
things?
F
So
I
think
that
like
if
we
analyze
the
context
in
where
we
are
going
to
use
these
events
and
what
people
will
be
doing
with
these
events
will
put
us
in
in
that
scenario,
where
maybe
that
orchestrator
what
it
is.
First
of
all,
it's
like
we
need
to
have
something:
that's
not
an
orchestrator,
but
like
more
like
a
transformation
thing
between
cloud
events
and
cd
events,
and
then
what
do
we
do
with
the
cd
events
is
just
up
to
up
to
us
right?
F
Then
we
let
the
one
picking
up
cloud
events
decide
how
they
will
do
the
integrations
and
that's
that
that
might
be
good.
But
I
guess
that,
like
looking
into
that
orchestrator,
I
think
that
it
would
be
a
wrong
assumption
to
think
that
we
will
have
one
for
cd
events
without
like
taking
into
account
all
the
other
cloud
events
that
already
exist
right
like
we
will
live
in
this
environment,
where
we
will
have
city
events
and
normal
cloud
events,
yeah
or
mixed
in
some
way.
C
And
that,
I
think,
is
a
for
me.
It's
the
perfect
segue
of
something
that
I
wanted
this
to
discuss
as
well,
which
is
how
do
we
make
the
world
see
the
events
compliant,
because
I
think
you
might
have
seen
brought
up
to
options
that
they're
not
conflicting
options.
I
think
we
will
need
to
go
for
both
one
is,
is
actively
working
with
existing
projects
to
make
sure
that
they
emit
cd
events
as
part
of
their
core
functionality
and
and
some
projects.
C
We
will
definitely
be
able
to
do
that,
and
I
think
we
can
support
in
a
good
way,
especially
by
building
really
good
sdks
for
it.
But
then
there
are
projects
that
today
emit
either
cloud
events
or
just
any
other
type
of
events
or
like
what
we
did
in
volvo
cars
for
artifactory
way
back.
When
was
we
found
a
rest
api
endpoint
that
we
could
poll
to
see
what
the
latest
changes
in
a
repository
and
whenever
that
was
some
file,
that
we
were
interested
in.
C
We
emitted
an
event
and
someone
could
could
go
react
to
that,
and
that
is
also
something
that
we
could
do
to
help
make
the
the
wider
community
more
seed.
Events
combined
is
prob
by
providing
you
call
it
translators.
I
I
think
that's
a
good
name
or
you
know
like
polling
and
emitting
things
wherever
that
is
needed
as
well,
so
there
I
think
there
is
an.
C
I
was
going
to
say,
infinite
amount
of
work
that
could
be
done
to
just
step
by
step,
make
make
the
world
more
compliant,
but
yeah.
A
So
it
will
never
be
like
okay,
we
as
a
project
go
and
say:
okay,
you
have
to
do
cd
events
because
yeah,
okay,
we
should
get
to
a
place
where
we
people
wants
to
to
use
city
events,
because
if
they
do,
then
there
is
a
return
that
is
valuable
enough
for
them
to
do
but
yeah
to
get
there.
We
there
is
all
this
intermediate
phase
and
I
think
in
through
this
intermediate
phase,
we'll
we'll
have
to
you
know,
work
with
this
adapters
and
for
building
pocs,
but
I'm
not
sure.
A
I
would
like,
like
the
city
events
community
as
a
community,
to
maintain
these
kind
of
adapters
to
become
like
production-ready
piece
of
software
that
we
maintained.
I
would
rather
as
work
in
like
refining
the
spec
and
working
with
the
communities
to
make
sure
that
we
are
creating
value
there.
That
would
be
my.
G
So
yeah
as
someone
who
wants
to
receive
these
things,
what
I'll
say
is,
I
think
it
might
you're
totally
right,
but
it
might
be
worth
having
a
little
carve
out
and
in
particular
I'm
thinking
about
for
like
github,
because
I'm
going
to
have
to
build
a
parser
translator
from
whatever
github
throws
at
me
to
a
cd
event.
I'm
probably
not
the
only
one
and
you
know
jake.
G
I
totally
agree
about
argo
and
all
you
know
all
these
projects
we
can
totally
just
say,
hey
buddy,
build
this
in,
but
for
something
like
github,
maybe
get
lab,
maybe
jenkins,
like
they're,
both
so
widespread
and
so
kind
of
hard
to
just
jump
in
and
make
change
that.
I
think
we
might
want
to
have
an
exception
for
a
couple
of
those
that
we
would
maintain
or
maintain.
I
don't
even
know
what
you
mean
by
that,
but
just
work
together
to
have
that
translation.
F
To
expect
that
they
will
give
us
cloud
events
and
if
they
don't
give
us
cloud
events,
even
if
you
look
at
like
k
native,
we
already
have
something
that
basically
looks
into
git
repositories
and
then
emit
cloud
events.
F
So
I'm
expecting
people
to
build
these
kind
of
things
for
most
of
the
systems
and
I'm
hoping
that
we
as
city
events,
don't
just
duplicate
that
work.
So
we
take
like
us
our
input
for
our
things
like
cloud
events,
and
then
we
just
map
to
our
types.
I
don't
think
that
we
should
be
into
the
space
of
going
and
just
duplicating
the
same
effort
from
other
projects
that
are
already
doing
like
the
cloud
events,
mapping
kind
of
thing,
because
I
do
see
cd
events
like
as
a
higher
level
of
abstraction
on
top
of
cloud
events.
F
So
you
can
imagine,
like
you
know,
very
low
level
events
like
all
the
techno
events
that
are
being
emitted
now
and
then
just
this
is
just
a
bit
up
on
the
stack
and
if,
if
that's
scala,
where
we
are,
if
we
sit
on
top
of
cloud
events,
then
there
is
this
need
for
translation,
and
it
is
a
very
domain
specific
translation
right.
Sometimes
you
create
a
kubernetes
cluster,
and
that
means
an
environment.
Sometimes
you
create
like
an
entire
google
project
and
that's
your
environment
right.
F
So
it's
it's
kind
of
like
a
different
perspective,
depending
on
who
is
defining
what
an
environment
is
or
what
the
service
is
on,
defining.
What's
the
actual
trigger
for
that
event
to
happen,
and
hence
like
this
is
a
very
complicated
like
integration
problem
that
I
think
that
we
can
scope
by
saying
somebody
will
meet
a
cloud
event
and
that
that
will
resort
into
a
city
event
expecting
that
that
someone
emits
a
cd
event.
F
A
A
What
do
we
do
with
features
that
may
require
more
context
than
is
from
the
you
know,
the
the
event
that
we
get
in
right?
So
yeah?
I
don't
know
if
you
want
to
think
about
it,
like
the
links
feature.
Do
we
want
to
have
then
something
built
in
this
translation
layer
that
is
able
to
communicate
with
the
repository
of
events
to
like
enrich
the
events
as
they
as
they
are
translated?
A
It
gets
very,
very
complex.
So
I
think
maybe
it's
also
important,
then,
when
we
define
features
that
would
require
more
context,
that
we
keep
them
as
optional
in
the
beginning
and
say:
okay.
This
is
something
that
it's
like
an
extra
thing
that
we
can
do,
but
always
be
ready
to
say:
okay,
yeah,
we
to
be
like
the
the
core
city
event
spec.
C
Events
like
which
you
mentioned
it
could
be
other
endpoints
or
web
hooks
or
whatever,
and
then
send
seed
events,
and
as
we
do,
that
people
start
building
really
cool
visualization
things,
interoperability,
things
metric
things
on
top
of
seed
events
and
then,
when
those
are
yeah
more
like
stable
and
used
and
valuable,
we
then
go
back
to
the
original
source
of
this
data
and
say
hey
the
data
that
you
are
sending.
We
are
translating
that
to
city
events,
and
people
are
getting.
C
Your
users
are
getting
a
lot
of
value
out
of
that,
because
they
can
can
visualize
things
they
can
do
metrics.
They
can
interpret
with
a
lot
of
things.
We
don't
really
want
to
maintain
this
translator
anymore.
It's
it's
a
lot
of
work
for
us.
Could
you
take
this
over?
Could
you
help
us
do
this?
Could
you
integrate
this
in
your
system?
Is
that
something
that
happens
at
all,
or
is
that
just
a
pipe
stream.
G
I
think
that
some
version
of
that
is
not
a
pipe
dream,
but
a
requirement.
I
mean.
I
see
this
as
a
two-sided
marketplace
and
you
know
we've
got
a
couple
sort
of
800-pound
gorillas
on
one
side
of
the
marketplace
who
are
great
at
github
and
and
get
laughed
I'm
sure
we
can
get
the
ear
of
someone
who
totally
wants
to
make
this
happen.
I'm
sure
they're
going
to
be
severely
constrained
and
it'll
take
them
years
to
make
it
happen
so
yeah.
G
I
think
we
need
to
operate
somehow,
as
like
a
clearinghouse,
I
mean,
I
would
love
to
say:
let's
operate
a
software
as
a
service,
but
no
one's
going
to
use
that
because
the
security
but
making
it
as
easy
as
that
of
like
hey
here's,
how
you
get
your
stuff
from
github
into
a
cd
events
compatible
system
to
put
another
way.
If
this
community
doesn't
work
together
to
make
it,
I'm
gonna
have
to
make
it
and
I'm
gonna,
do
it
badly.
So
I
would
love
to
do
it
together.
T
At
least
in
terms
of
git
lab,
I
know
that
they're
super
receptive
to
changes
in
general.
My
company
has
multiple
commits
fixing
their
web
hooks.
I
don't
know
if
they'd
be
up
for
like
a
complete
new
system,
I'm
also
not
sure,
like
the
cd
events
specify
the
transmission
layer,
or
is
it
just
like
the
event
payload
specification
like
like
are
web
hooks
fine,
as
I
see
the
event,
and
also
like
things
going
straight
into
like
a
rabbitmq.
C
Yeah,
so
I
don't
see
why
webhooks
wouldn't
be
fine
as
long
as
we
just
defined
like
how
would
that
transmission
do
right
now
we
we
only
build
on
cloud
events
as
a
starting
point,
but
what
the
specification
really
provides
as
value
in
my
opinion
is
what
attributes
do
we
have
and
what
do
those
attributes
mean
and
those
could
presumably
be
sent
just
as
well
over
a
web
book
as
they
could
over
something
else?
If
we
just
define
the
packaging
for
that,
whatever
you
want
to
call
it,
and.
A
A
If
you
use
the
the
cloud
events
sdk,
you
can
basically
configure
them
to
send
events
over
http
with
json
payload
or
you
can
send
them
in
nuts
or
you
can
send
them
in
nqtd,
and
I
think
they
they
have
a
spec
for
web
books
on
cloud
event
site
as
well.
Now
so
you
know
it
could
so
what
we
we
focus
on
is
really
like
the
payload
and
how
we
bind
into
this
kind
of
transport
but
yeah.
So
that's
about
gitlab.
We
have
some
connection
with
gitlab.
A
Actually
there
is
in
on
the
on
the
gitlab
upstream
tracking
system.
There
is
a
discussion
on
going
about
city
events,
adoption
that
has
been
going
on
for
maybe
a
couple
of
months,
so
there
is
interest,
at
least
I
know
one
person
kevin
on
gitlab
side.
That
is
very
interested
in
having
events.
But
of
course
I
mean
everything
is
based
on
other
technologies
right
now,
so
there
is
a
lot
of
inertia
there
and
you
know
you
need
to
show
value
for
things
to
to
happen,
but
yeah
we,
we
started
the
discussion.
T
I
mean
the
biggest
issue
for
all
these
big
players.
Is
they
can't
just
get
rid
of
their
current
like
web
hook
system
yeah?
So
like
we're
asking
them
to
maintain
two
things,
then,
in
parallel,
if
we
were
to
say
like
hey,
you
need
to
support
cd
events
yourself
versus
like
if
there
was
a
community
tool
that
translated
like
their
native
web
book
system
into
cd
events,
that
they
then
like
sponsored
or
took
over
or
like
put
core
resources
to,
I
think
they
would.
T
C
C
So
I
think
we're
gonna
probably
going
to
have
to
put
a
little
bit
of
extra
effort
in
ourselves
in
the
beginning
just
to
get
things
connected
and
then,
when
we
can
show
value
more
clearly,
then,
as
you
said,
having
those
players
sponsor
or
even
drive
those
like
community
translation
layers
would
be
great
and
they
could
help
with
the
maintenance,
because
it
provides
their
users
with
a
lot
of
value.
Yeah,
so
yeah
and
I
think
that's
probably
an
area
where.
C
It
feels
like
me
that
these
translators
don't
necessarily
have
to
be
super
complex.
Obviously
you
need
to
understand
the
source
of
the
data
and
you
need
to
understand
seed
events,
but
those
both
those
two
things
should
be
reasonably
well
documented.
So
I
think
this
could
be
I'm
thinking
like
something
like
google
summer
of
code.
C
If
that
is
an
area
where
those
translation
things
some
of
those
could
be
built
or
just
pretty
nice
startup
tasks
for
people
wanting
to
join
open
source
if
they
have
like
some
programming
skills
and
would
like
to
work
on
such
a
translation
layer,
because
probably
we're
going
to
need
quite
a
lot
of
them
to
to
show
value,
and
we
should
definitely
figure
out
yeah,
which
ones
do
we
need
first,
and
how
do
we
prioritize
the
work,
but
there's
plenty
of
exciting
things
to
work
on
there.
I
think
yeah.
A
No,
I
was
just
going
to
say
like
yeah,
we
are
a
very
small
community
and
we
are,
you
know,
striving
to
to
come
to
work
on
the
spec
and
that's
the
sdks,
and
you
know
I
mean
we
can
add
more
the
translation
layers
and
we
can
add,
like
common
filtering
mechanism.
But
you
know
we
increase
the
scope
a
lot,
but
the
number
of
people
that
we
are
working
on
it
doesn't
grow
so
and
yeah.
A
So
definitely
I
mean
we
can
try,
we
we
will
reach
out
and
see
if
we
can
do
like
google
summer,
of
course,
or
also
we
have
other
connections
to
get
more
people
young
people
working
with
us
on
these
things.
A
Yeah.
But
really.
The
hope
is
that
we
generate
also
enough
interest
like
coming
here
to
conferences
advocating
about
these.
Discussing
with
the
folks
to
you
know,
get
some
some
people
involved
and
really
contributing
to
where
it
makes
sense
for
them
to
drive
this
like
projects
within
city
events
and
this
tooling,
and
this
translation
layers
and
all
the
things
that
like
mauricio,
said
at
the
end
of
the
day.
A
G
Just
mention
it
like
a
strong
plus
one
to
like
ruthlessly
prioritizing,
because
we
are
obviously
of
limited
resources.
G
I
I
I
would
encourage
us
not
to
let
the
enormity
of
the
number
of
things
we
could
build,
distract
us
from
getting
the
first
one,
because
I
mean
honestly,
for
my
sake,
I
don't
really
care
about
having
50
adapters.
I
care
about
having
maybe
two.
So
if
we
can
really
prioritize
those
two,
maybe
we
can.
C
Yes,
really
good
discussion.
We
have
about
20
minutes
left,
so
I
wanted
to
just
ask
everyone
in
the
room:
if
there's
anyone
here
now,
who
feels
that
like?
Oh,
why
did
you
discuss
all
this
boring
top
topics?
I
wanted
to
discuss
this.
If
you
have
any
such
things,
please
let
us
know
or
just
yell
out,
because
we
have
some
time
and-
and
we
can
definitely
take
on
another
topic
or
two.
If
anyone
has
anything
they,
they
are
passionate
about.
U
Now
I
will
go
back
and
refer
to
standardization
topics,
not
specific
to
descriptor,
descriptive
or
prescriptive
events
like
I
am
coming
from
telco.
I
have
background
in
telco
and,
as
you
know,
especially
what's
happening
with
taiko
industry
with
all
this
virtualization
cloud
native
desegregation,
openness,
how
things
are
getting
pretty
interesting
there
and
it's
probably
similar
with
other
industries
as
well.
Some
of
them
are
ahead.
Some
of
them
are
behind,
but,
as
you
all
know
like,
the
open
source
became
the
product
development
for
many
different
companies.
Many
different
industries
like
in
the
past.
U
Those
companies
have
been
developing
their
products
purely
internally
with
all
this
property
hardware
and
software,
but
things
are
changing
and
open
source
communities
are
considered
part
of
the
product
development,
so
the
development
is
also
shifted
left.
It
doesn't
start
in
company
premises,
it
starts
on
upstream
communities
and
when
we
think
about
the
cicd
aspects,
how
to
ingest
open
source
software,
how
to
consume
that
with
all
this
you
know
security
issues
like
supply
chain
topic,
which
is
hot.
U
U
That
could
actually
make
a
big
difference
with
everything
that
happens
in
enterprises
like
all
this
end-to-end
flow,
like
the
enterprises
don't
need
to,
you
know,
consume
github
events
or
google
sources
or
gitlab
events.
They
are
all
different
from
each
other,
but
if
there
is
some
kind
of
de
facto
standard
in
place
that
could
actually
tie
things
from
the
field
back
to
open
source
repositories,
it's
kind
of
like
again.
U
This
is
maybe
a
big
dream,
or
it's
maybe
impossible.
I
don't
know
just
because
this
is
happening,
and
I
think
it
is
right
time
to
continue
pushing
this
and
again
what
eric
you
said
and
what
project
said
like:
let's
focus
on
small
things,
first,
get
the
project
out
there,
the
point
one
version,
but
I
think
the
opportunities
are
limitless.
You
know
it's
like
what
about
having
some
supply
chain
type
of
stuff.
In
this
thing,
talking
about
like
I
want
not
able
to
publish
like,
I
think
I
highlight
this
link
webinar
you
had
few
weeks
ago.
C
Yeah,
I
think
that
there
is
an
or
I've
had
a
thought
for
a
while
regarding
this.
So
I'm
not
sure
how
everyone
in
this
room
does
it.
But
if
I'm
running
a
project-
and
I
want
to
understand
that
one
of
my
dependencies
has
gotten
a
new
version-
I
don't
really
have
a
very
good
strategy
for
how
to
discover
that
I
typically
either
discover
it
by
accident
or
I
receive
an
email
or
there's
a
cv
connected
to
it.
C
And
I
get
a
panic
and
I
need
to
update
something
that
that
just
seemed
interesting
to
me
as
a
concept
would
be
what,
if
we
have
a
global
cd
events,
message:
bus
for
all
these
open
source
projects
that
deploy,
and
then
it
doesn't
matter
if
the
deployment
is,
it
goes
into
some
artifactory
or
nexus,
or
it's
a
hub
release
or
a
git
lab
release
or
whatever
it
is.
C
But
they
all
emit
events
saying
that
now
there
is
a
new
artifact
version
for
this
artifact
and
then
that
would
go
into
like
a
central
message:
bus
that
anyone
in
the
world
could
connect
to
and
set
up
filters
for
receiving
stuff,
so
that,
when
log4j
releases
a
new
version
of
their
library,
I
can
pick
that
up
immediately
when
it's
released,
and
I
can
do
my
testing
whatever
I
want
to
do
on
it
and
see.
If
I
want
to
include
that
in
my
in
my
application.
C
E
Yeah,
I
have
a
colleague
he
just
finished,
putting
out
j
releaser,
which
that's
one
of
the
problems
spaces
that
he
was
trying
to
solve
is
how
do
you?
Let
people
know
that
you've
got
a
new
release
for
your
project
or
your
library,
and
I
think
what
we
do
right
now
is
just
you
know,
don't
specify
the
the
version
so
that
we
get
the
latest,
which
is
you
know,
causes
all
kinds
of
other
problems.
M
E
C
Exactly
because,
if,
if
I
got
an
event,
I
could
trigger
my
own
pipeline
to
introduce
that
new
dependency
version
do
all
the
testing,
and
then
I
get
a
pop
up
in
my
slack
channel
saying.
Oh,
there
was
a
new
release
of
this
library.
All
the
tests
passed.
You
can
now
decide
if
you
want
to
include
it
or
not
or
make
a
new,
proper
release
of
your
system
or
not
so
there's
some
interesting
stuff
that
can
be
done
there
as
well.
I
think.
F
There
is
something
happening
with
that
that
that
already
right
like
in
github
nowadays,
you
get
notifications
if
one
library
has
a
vulnerability
and
you
get
a
pull
request
just
to
update
that
library.
That's
pretty
advanced,
to
be
honest,
so
like
tapping
into
the
systems
that
already
exist,
mostly
for
for
like
front-end
like
javascripty
thingy
but
yeah.
I
think
that
that's
that's
coming.
Definitely
yeah
it's
coming
because
the
capability
is
there.
Now,
how
do
you
integrate
with
like
a
global
ecosystem?
F
That's
you
know,
yeah
and,
and
everybody
is
like
in
a
different
level
of
maturity.
Right
like
I
was
like
surprised
when
I
moved
from
from
java
to
go.
For
example,
it's
like
you
have
like
you
have
maybe
like
an
sonotype
with
their
like
massive
repositories
that
they
are
maintaining
for
the
entire
community.
F
But
when
you
go
to,
like
you
know
like
javascript
or
like
even
go
like
that's
a
completely
different
ecosystem,
so
like
not
like,
we
are
just
trying
to
tackle
like
like
the
unification
of
all
the
ecosystems
using
events,
so
that's
kind
of
like
an
interesting
problem
to
solve,
and
I
think
it's
going
to
come,
but
yeah,
it's
like
finding
out
kind
of
where
each
community
is
and
how
do
you
actually
unify
like
what
you
were
describing
at
the
very
beginning
like
what
the
package
is?
F
C
But
I
think
it's
it's
fun
to
be
be
part
of
a
project
where
there
is
no
limit
to
what
could
be
done.
As
fatty
said,
I
mean
you
can
dream
for
for
as
much
as
you
want
here
and
there's
always
another
use
case
for
using
events
at
the
same
time.
It's
a
challenge
because
as
sunday
I
said
we're
not
that
many
in
the
community
today
and
definitely
we
can't
afford
to
all
pull
in
different
directions,
because
then
we
will
have
21
20th
done
solutions
rather
than
having
one
done
solution
so
yeah.
I
think
yeah.
U
Is
like
now
again
if
you
could
put
like
0.1
something
there
if
people
could
start
playing
with
experiment
experimenting
with
something
stable.
That
would
make
even
more
interesting
and
we'll
get
even
more
people
happening
with
this,
so
we
can
discuss
and
dream
as
long
as
we
want,
but
we
have
to
get
this
out
there.
You
know.
G
I
thought
we
were
dreaming
today,
but
yes,
but
are
folks
familiar
with
open
source
insights
depth.dev,
it's
a
it's
a
sort
of
by
google,
but
it's
it's
really
meant
to
be
a
community
thing
and
it's
like
a
massive
database
of
open
source
packages
and
versions
and
such
and
such
you
can
query
it
as
a
public
data
set.
I
don't
think
it
provides
any
sort
of
like
event
stream,
but
that
might
be
an
opportunity,
and
certainly
you
know
it's
the
kind
of
thing
that
google
could
has
the
infrastructure
to
support.
C
C
Nice,
okay,
what's
our
next
topic
or
who
has
the
next
topic
what's
next?
C
That
is
a
very
good
topic
to
to
round
out
on,
I
think
very
good
choice,
so
topic
is
what's
next,
so
obviously,
from
from
the
cd
events
project,
we
are
going
to
work
with
the
0.1
roadmap
that
andrea
showed
before,
which
again
contains.
C
Basically,
I
would
say,
filling
in
some
gaps.
It's
not
really
about
introducing
new
events.
What
I
can
remember
it's
more
about
getting
the
events.
We
have
to
have
a
proper
schema
to
have
some
some
more
clarification
on
how
to
use
cloud
events,
attributes
and
such
things,
but
that's,
of
course,
only
part
of
the
work
we
are.
As
we
said,
we
have
a
go
sdk,
which
I
I'm
not
sure.
If
it's
entirely
up
to
date,
I
think
it
may
need
to
change
a
little
bit.
C
The
job
sdk
is
maybe
the
one
seeing
most
active
development
right
now:
python
sdks.
What
it's
you
mentioned
needs
to
be
built
as
well,
not
necessarily
for
0.1,
but
definitely
quite
soon.
C
But
then
there
are
a
lot
of
open
discussions
in
our
github
project
regarding
new
events,
types
regarding
additions
to
existing
events
regarding
how
to
you
know,
like
I
mentioned
version
and
package,
and
release
our
specification
in
our
sdks,
so
yeah,
as
always,
one
of
my
hopes
is
that
that
we
get
yeah
continue
to
have
some
activity
in
our
discussions,
because
that,
based
on
what
I
see
in
combination
between
our
discussions
and
our
meetings,
is
where
things
happen.
C
I
think
I'm
not
sure
if
you
would
agree
andrea,
but
I
think
the
way
decisions
has
typically
happened
before
is
that
we
use
the
discussion
between
the
meeting
to
let
things
mature
and
to
bring
everyone's
perspective
in
and
but
the
actual
decisions
tend
to
be
taken
in
the
meeting,
mostly
because,
to
be
honest,
we
realized
that.
Oh,
we
never
finished
this
discussion.
Let's
finish
it
here
to
get
a
decision,
I'm
sure
there's
a
better
way
to
do
it,
but
that's
where
we
are
right
now
and
yes.
A
Yeah,
so
I
think
all
that-
and
I
think
we
have
a
couple
of
two
or
three
actionable
streams-
that
I
would
like
very
much
to
follow.
One
is
the
the
dorametrix
poc
because,
as
they've
mentioned,
they're
going
to
work
and
separating
the
queries
from
the
sources,
and
so
we
can,
you
know,
benefit
very
much
from
that
see.
What
is
the
the
data
that
we
need
to
have
in
the
spec?
A
So
that's
one
thing:
we
got
some
some
feedback,
some
issues
created
by
yeah
colleagues
from
from
apple
that
they
started
looking
at
spec,
and
so
I
think,
that's
a
very
actionable
thing
to
look
at
and
can
spawn
new
discussion
and
we
can
try
and
include
those
in
the
series
of
one
version.
A
I
had
this
week
also
some
interesting
discussion
with
the
team
at
fidelity.
They
are
very
interested
in
adopting
cd
events.
So
again,
this
is
something
that
we
can.
I
will
do
like
try
to
do
work
with
them
to
make
sure
that
what
we
do
in
0.1
doesn't
mean
and
doesn't
miss
things
that
they
need
at
least
for
an
initial
poc
on
their
side
yeah.
Unfortunately,
they
could
not
join.
Today,
but
we
will,
we
can
have
further
discussion
with
them.
A
So
I
think,
hopefully
all
this
gives
us
enough.
You
know
starting
to
get
some
more
critical
mass.
You
know
like
events,
if
you
have
cd
events
used
in
something
like
four
keys
cd
events
used
by
a
customer,
we
get
like
good
figure
feedback
from
people
start
using
it
that
helps
us
like
try
and
0.2,
and
the
next
versions
and
so
forth,
and
maybe
from
one
other
thing
that
I
got
from
all
the
discussion
today.
Is
that
something
that
maybe
we
should
prioritize
as
well
is
like
a
github
adapter.
A
But
yeah,
so
it's
that's
even
better
if
it's
small
effort,
but
it's
I
think
it's
something
that
I
would
like
to
see
like
in
the
list
of
high
priority
things
that
we
need
to
follow
up
in
the
next
weeks
and
months.
But
yeah.
C
That,
of
course,
cannot
translate
into
everyone
getting
involved
in
seed
events,
because
people
have
other
things
that
they
need
to
work
on,
but
there
is
an
interest,
and
there
is
a
belief
somehow
that
this
could
become
interesting
and
that's
why
people
are
here
in
the
room
today
as
well,
and
somehow
we
need
to
not
drop
the
ball
on
this,
so
that
we
we
keep
people's
interest
peaked.
It's
always
a
bit
dangerous
over
the
summer,
because
people
tend
to
take
vacation
and
things
tend
to
slow
down
a
bit.
C
But
maybe
that's
the
perfect
time
for
for
people
who
have
time
and
drive
over
the
summer
to
get
some
things
moving
forward,
and
then
we
can
come
back
in
the
fall
with
with
full
attention
on
this
emil.
I'm
not
sure
if
you
would
like
to
to
say
a
few
words
on
your
side.
What
do
you
think
the
way
forward
would
be
for
the
project.
B
No,
I
think
you
explained
it
quite
well.
I'm
I'm
a
bit
concerned
that
it's
a
bit
fussy
around
the
line.
Still
what
on
the
edges,
I
would
say:
well
what
should
how
much
work
is
actually
left.
B
I
mean
it's
not
clearly
defined
what
we
actually
need
to
do,
but
that
I
believe
that
needs
to
be
set
very
soon,
but
what
I
was
about
to
say
before
was
also
that
we
we
currently
have
one
week
in
one
meeting
every
week,
so
every
two
weeks
we
have
a
sikh
meeting
where
we
have
more
like
administrative
discussions,
mostly
talking
about
conferences
coming
up
and
having
presentations
as
well
from
the
community,
and
then
we
have
the
vocabulary
meeting
every
other
week
where
we
discuss.
B
We
try
it
like
this
to
help
keep
those
meetings
more
to
discuss
the
actual
protocol
and
issues
we
see
there
and
such
things.
So
I
guess
in
both
of
these
meetings,
we
all
need
to
focus
on.
How
can
we
finalize
the
work
on
the
0.1
vocabulary
or
the
specification
itself,
and
then
how
can
we
get
it
out?
What
do
we
need
to
document
and
how?
What
needs
to
be
in
place
surrounding
it
so
say:
that's
neat.
That
needs
to
happen.
B
C
Yeah
well,
and
I
think
I
really
don't
think
it
is
that
much
more
it's
not
it's
not
an
impossible
task
to
reach
0.1.
There
are
some
some
discussions.
We
need
to
close
and
some
choices
we
need
to
make,
and
I
guess
especially
those
kind
of
choices
that,
if
we
don't
make
them,
they
may
lead
to
radical
backwards,
incompatible
changes
to
the
specification
later
on.
C
So
if
it's
on
only
about
adding
new
events,
that's
still
very
much
backwards
compatible.
But
if
it's
about
changing
the
structure
of
existing
events
in
a
major
way,
that
can
be
quite
tricky,
then
again.
We
can't,
of
course,
lock
us
down
to
never
making
any
changes,
but
thinking
some
of
those
things
through
us
through
would
be
very
beneficial.
C
B
Think
we
shouldn't
be
too
afraid
of
seeing
that
we
might
have
like
non-bachelor's
compatible
changes
in
the
future
or
quite
soon
I
mean
it's
a
0.1
release.
We
talked
about
it's,
not
the
1.0
release,
yet
I
think
it's
it's
more
important
to
get
the
01
release
out
in
some
shape
or
form
than
getting
the
full
glancing.
Some
say
a
specification
that
we
think
will
never
change
until
1.0
or
something
yeah.
That's.
B
Yeah,
so
we
need
to
find
the
balance
there
and
quite
soon,
yeah.
C
That's
all
yeah,
it's
this
balance
of
making
life
easy
for
us
by
allowing
ourselves
to
make
any
changes
we
want
versus
making
or
keeping
the
trust
of
of
whoever
uses
the
specification,
because
if
it's
seen
as
something
oh,
they
change
everything
every
release
and,
of
course,
that's
not
good,
either
so
yeah.
Anyone
who
has
input
on
that
balance
we're
very
happy
for
to
hear
your
thoughts
on
it.
I.
A
Think
after
this
this
event,
today
I'll
go
back
and
on
the
on
the
github
project
for
the
roadmap,
there
are
a
couple
of
things
that
we
need
to
add
from
the
discussion
today
and
maybe
then
the
next
meeting
we
can
review
it
together
and
like
nail
down
more
clearly.
What
is
the
scope
like
emily
was
saying,
so
we
have
a
clear
understanding
of
what
it
is
that
we
want
to
do
before.
0.1.
C
Yes,
we
have
about
two
minutes
left
of
the
scheduled
time.
What
I
would
be
interested
in
hearing
is
is:
does
anyone
in
the
room
have
like
a
used
case
where
you
think
it
would
be
really
cool
if
I
could
use
cd
events
to
do
this?
That
we
haven't
already
talked
about
just
to
give
us
some
some
input
on
that
we've
talked
about
the
four
keys
we've
talked
about
like
possibly
replacing
or
standardizing
internal
events.
We've
talked
about
integrating
these
massive
projects
together,
but
there
is
a
very
wide
variety
of
use
cases
we
could
have.
C
C
A
So
we
have
a
mailing
list:
twitter
account.
We
have
github
and
the
link
to
the
slack
as
well.
So
there
are
a
few
ways
to
find
a
platform
choices
that
you
can
use
to
get
in
touch
with
us
and
yeah
for
the
notes
I
mean
they're,
not
complete
yet,
but
we
have
this
hack
and
d
that
we
created
for
the
document
it's
shared
in
the
chat
on
bevy
and
also
in
the
onslack,
but
something
that
I
I
like
to
do
with
this.
A
This
kind
of
events
is
get
feedback
about
how
the
event
logistics
structure
agenda
was
in
general,
so
that
we
can
next
time
we
make
a
community
summit
for
city
events.
We
can
do
it
better,
so
I'll
add
a.
A
Feedback
session
here,
a
feedback
section,
and
if
you
have
comments
yeah,
please
let
us
know
so
that
we
can
yeah
continue
improving
for
next
time.
C
We
would
like
to
thank
you
for
so
much
for
attending
and
for
all
the
great
discussions
and
for
all
the
great
topics
that
you
brought
up
andrea.
You
said
you
will
have
a
look
at
the
recording
and
try
to
update
the
notes
based
on
that
yeah.
Let
me
know
if
you
want
to
help
with
that
and
yeah.
The
discussion
will
continue
in
in
our
meetings,
in
our
slack
and
in
our
github
discussions
there
and
yeah,
I'm,
as
I
mentioned
before,
hinted
at
before.
C
I'm
personally
been
I'm
personally
leaving
this
conference
with
a
high
spirits,
because
I
think
both
the
reception
to
our
talks
and
the
reception
to
see
the
events
in
general
has
been
been
positive.
I
it
makes
it
a
fun
project
to
work
on,
even
though
it's
difficult
to
it's,
like
herding
cats,
getting
everything
together
and
getting
everyone
something
opinion
represented
in
the
specification
but
yeah
I
I
have
really
enjoyed
it.
C
Oh,
that's
good
awesome,
but
then
again
thank
you
all
for
attending.
I
hope
you've
enjoyed
this
session
and
we've
really
benefited
from
your.
Your
input
and
yeah
enjoy
the
rest
of
the
day
and
thank
you.