►
From YouTube: CDEvents Working Group (EMEA/APAC) - Feb 13, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
C
Guys
yeah
I
saw
the
so
the
update
the
the
design
doc
proposal
for.
B
I
haven't
finished
it
yet,
but
I
started
this
too.
Oh.
C
Okay,
cool
cool,
maybe
maybe
I'll,
hold
my
questions
and
because
I
noticed
that,
like
it
is
kind
of
similar
that
it
does
reference
past
events,
so
this
actually
might
be
preferable
to
like
Trace
context
and
whatnot.
So.
B
B
To
do
it
for
iPhone,
we
didn't
really
finish
that,
but
I
think
that
would
be
valuable
to
have
for
all
these
three
or
I.
Don't
know
if
you
would
have
more
more
variants
so
because
that's
easier,
maybe
to
discuss
around
when
we
are
really
100.
C
No
worries
do
good.
How
are
you.
D
Yeah
yeah,
it's
Monday,
so
yeah,
it's
fine
a
long
week,
okay
right,
but
that's
fine
yeah
so
all
mentioned
in
the
channel
that
he
won't
be
joining
today.
So
I
guess
we
won't
discuss
test
events.
D
Shall
we
shall
we
get
started?
Okay,.
A
D
B
A
D
D
All
right
would
it
make
sense
to
go
quickly
through
the
other
things
and
updates,
and
then
we
start
with
a
roadmap
review
then
sounds
good.
D
Okay,
all
right,
so
the
only
action
items
that
I
found
was
that
when
you
commented
already
ml
we
can
document
in
the
primary.
That
is
our
risk
of
coefficient
between
object
and
it's
execution.
We
should
append
run
to
the
subject
that
we
discussed
last
time
and
yes,
that's
it
really
an
issue
for
that.
So
thanks
for
that
little
pipe
right.
We
can
put
a
meeting.
D
So
for
test
events,
there
were
some
updates
and
some
further
comments,
as
I
was
saying.
I'll
mentioned
that
he's
not
able
to
join
today,
so
he
will
preview.
The
latest
comments
on
the
VR
and
that's
next
step
with
that.
B
I'm
not
sure
how
far
we
are
off
from
being
able
to
finalize
that
I
think
I
haven't
reviewed
it
fully
myself.
Yet
there
are
quite
some
changes
there,
I'm,
not
sure
I
mean
we
haven't
said
before
that
it
needs
to
be
in
zero
two,
but
if,
if
possible,
then-
or
if
it's
there,
of
course
in
that
time
frame,
we
could
include
it
or
should
we
strive
for
having
it
there
and
therefore
delay
the
the
release.
You
think.
D
Yes,
so
I
guess,
depending
on
what
part
we
get
when
I
think
the
release
is
there
we
can
decide
I
mean
if
it's
a
matter
of
a
few
days
we
can
stretch
and
include
it
in
the
release.
I
think
it
will
be
great
and
I.
Think
from
my
perspective,
you
know
they're
getting
quite
close
to
B
to
being
ready,
but
of
course
let
me
love
it.
I
would
like
to
see
your
review
as
well.
Sorry,
we
can
have
multiple
point
of
view,
points
of
view.
C
D
That's
what
we
planned
before
Christmas,
I,
think
or
but
we
that's
what
that
was
mentioning
in
the
beginning
that
we
might
want
to
to
reschedule
it.
So
we
wanted
to
go
through
the
roadmap
today,
right.
C
C
What
do
you
guys
usually
finalize
I
guess
my
question
is:
is
you
guys
usually
finalize
something
like
a
few
days
before
or
like?
What's?
What's
the
process,
I
guess
giving
something
into
like
the
release,
candidate,
I?
Guess
it's
not
code,
it's
more
specs!
It's
not
as
big
of
a
deal
but
I'm
just
kind
of
curious.
Like
is
it
generally
like
you
guys
do
like
the
full
review
and
the
things
that
look
good.
It
makes
it
into
the
to
the
this
point
to
release,
even
if
it's
day
like
Daya,
for
instance,.
D
Yeah
I
think
we
only
did
one
release
until
now,
so
we
don't
have
like
a
very
formalized
set
process
for
that
I
think.
As
long
as
we
are
in
early
releases
in
zero
Dot,
we
can
probably
try
to
be
quite
awake,
so
I
mean,
of
course
we
want
to
review
and
everyone
discussing
it,
but
I
wouldn't
be
too
concerned.
If
there
is
a
change
done
shortly
before
the
release
but
yeah
in
future,
we
might
want
to
be
more
careful
as
soon
as
we
start
getting
also
more
adoption
and
you.
A
B
B
Yet
at
least
of
doing
such
changes,
so
so
I
think
it's
quite
okay
to
get
something
out
there
and
get
people
starting
to
use
it,
and
then
we
can
reevaluate
if
that
was
a
bad
idea
or
not
or
if
we
need
to
change
something
for
the
next
release
before
we
get
to
one
or
two,
of
course,
when
we
have
one
or
two,
then
we
need
to
have
a
more
formal
process
and
probably
get
a
larger
group
of
people
reviewing
it
I'm
accepting
it
before
getting
it
into
the
new
release
and
so
on.
C
D
We
can
create
an
issue
foreign.
D
D
D
Or
the
incident
events
I
think
I
feel
like
we
are
converging
to
at
least
initial
set
of
events
and
predicates
and
formulation.
That
looks
okay
and
there
is
one
comment
from
Matthias
that
is
not
addressed
right
now
and
that
I
wanted
to
discuss.
But
yeah
is
not
here,
but
maybe
can
get
your
opinion
on
that
and
it's
regarding
the
type.
D
D
Basically,
now
that's
the
way
at
least
to
go.
Sdk
works
and
that's
how
it
is
documented,
I
believe
in
the
wrote
spec,
but
the
type
has
not
been
included
in
the
schemas
till
now.
I
think
no,
actually,
the
type
is
in
the
schemas
as
well,
but
the
right,
the
the
value
of
the
type
is
not
really
included
in
the
schema
as
well
yet
and
the
type
is
not
in
the
markdowns.
D
So
if
you
look
at
an
incident
detected,
for
instance
now
this
is
one
of
the
new
ones,
but
it's
the
same
for
everyone.
Sorry,
if
you
look
at
the
incident,
there
is
ID
Source,
the
other
fields,
but
we
don't
include
the
type
and
that's
it's
true.
If
you
look
at
other
existing
things
as
well,
so
material
is
saying
yeah
that
people
will
look
at
the
markdown,
not
the
schemas
and
because
the
type
is
not
in
the
markdown.
So
we
are.
We
will
be
effectively
adding
the
type.
A
D
Personally,
I
disagree:
I
think
I
mean
we
agreed
on
on
that
in
the
past,
and
we
we
have
the
SDK
producing
the
type
and
it's
in
the
examples
we
don't
have
many
examples,
but
at
least
in
the
world
we
have
so
I
believe
the
type
is
part
of
the
event
today,
but
I
wanted
to
get
some.
C
D
A
D
D
D
D
And
it
has
an
optional
service
and
an
optional
type,
and
the
only
reason
that
the
type
is
optional
is
because
content
for
some
events
may
be
empty.
So
if
the
content
is
empty,
you
don't
need
to
specify
a
type,
even
though
we
could
I
would
argue.
We
could
we'll
see
the
moving
this
to
mandatory,
but
that's
another
discussion.
C
D
A
D
If
I,
if
I,
read
Matthias
comments
correctly,
is
that.
D
D
C
I
think
I
think
I
think
if
it
was
required,
I
would
agree
with
Matia.
If
that's,
if
that's
his
name,
I
I
I'm
not
familiar
with
who
that
is
but
but
if,
if
it
is
optional,
then
I
think
as
long
as
we
mention
it
somewhere.
You
know
like
we
already
do
in
the
course
spec.
C
It's
it's
fine
in
my
my
opinion,
because
because
it
is
optional,
but
if
we
do
decide
to
make
it
actually
more
of
a
like,
you
were
saying
like
move
it
and
actually
have
it,
be
more
of
a
formalize
and
actually
be
required.
For
example,
if
content
is
present,
then
I
would
move
to
say:
okay,
that
probably
needs
to
be
in
the
markdown.
Then.
B
I
I
think
what
I
mean
as
a
reader.
It
might
be
confusing
to
see
an
event
in
Json
format
and
then
trying
to
understand
what
all
these
different
fields,
of
course
in
the
schema
they
are
seen,
but
there's
no
description
there,
what
they
mean
and
then
the
the
obvious
way,
but
then
go
to
the
documentation
for
that
specific
event
and
see
well.
What
does
it
mean
then?
B
In
this
event,
documentation
and
then
it
doesn't
say
there
either
or
the
other
fields
are
there,
but
not,
then
the
optional
ones
and
is,
if
you
have
to
type
so
I,
would
agree
that
it
should
either
be
explicitly
stated
there
or
there
should
be
at
least
a
reference
to
where
the
general
or
common
fields
are
and
then
we
might
not
even
need
to
have
the
ID
and
subject
Allied
your
Source
there
either.
They
could
also
be
referenced
to
the
course
back.
C
Right
and
I
agree:
it
is
a
little
bit
confusing,
but
I
think
it
being
optional.
Is
the
big
thing
here
because,
like
you,
don't
even
have
to
send
it
at
all
technically
right
and
if
we
find
that
people
are
you
know
if
people
are
asking
for
this
feature
more
I
think
we
could
actually
move
it
from
optional
to
actually
required
and
then
actually
document
it
as
well.
C
But
I
do
agree
to
Neil's
point
that
we
should
probably
link
somewhere,
maybe
even
in
the
markdown
pages
of
of
of
these
optional
fields
or
these
fields.
The
standard
in
general.
B
B
B
B
C
Well,
I
think
the
goal
right
is
to
make
it
as
easy
as
possible,
and
you
know
and
like
I
said,
the
the
nature
of
this
field
being
optional.
I
think
you
know
I'm
leaning
more
of
like
leaving
it
out
because
it
doesn't
seem
too
important
just
now,
but
if
you
want
peop,
so
it
depends
on
what
your
guys's
goal
is.
If
you
want
people
to
actually
you
know
like
look
at.
B
A
B
Andrea
that
this
has
been
there
for
some
time
in
the
Json
files,
but
not
in
the
markdown
file.
So
it's
not
really
the
and
also
I,
think
it's
not
required
for
this
specific
PR
to
add
it
everywhere.
So
maybe
there
should
be
a
separate
issue
or
appear
on
that
if
we
should
change
things,
so
this
one
could
do
it
as
has
been
done
until
now,
but
we
should
probably
I
think
it
would
be
valuable
to
have
that
in
zero.
B
So
you
can
see
those
examples
that
you
showed
there
from
the
beginning.
Where
type
is
part
of
the
subject,
I
would
expect
to
be
able
to
go
to
the
that
event
documentation
and
find
information
about
all
those
fields,
including
the
type,
but
it
could
be
from
a
link
to
somewhere
else,
of
course,
but
anyway,.
D
Yeah,
okay,
yeah
I,
think
it
all
makes
sense.
I
agree
that
we
should
keep
things
easy,
but
I
also
agree
that
is
replicated
to
a
face
documented
in
0.2
I'm,
trying
to
remember
I
about
the
go
SDK.
D
I
I
will
need
to
test
whether
the
SDK
actually
expected
expected
or
not,
because
when
we
designed
this,
we
designed
it
so
that
the
type
is
was
to
be
there
because
then
it
makes
it
easier
to
parse
the
content,
but
I
don't
remember
it
because
the
cave
it.
Actually
we
rely
on
that
or
not
so
there
might
be
some
need
to
to
update
the
SDK
to
make
sure
we,
because.
C
Out
of
curiosity,
why
did
we
make
it
optional?
It
seems
like
it's
a
pretty
important
required
field,
even
right
because
like
if
it
comes
in
and
the
payload
is
just
whatever
even
just
me
looking
at
the
raw
data,
if
I
see
a
payload
coming
in
and
there's
no
type,
how
am
I
going
to
make
sense
of
it
like
it
seems
it
seems
like
it
should
be
a
required
field.
I
mean
this
is
a
different
discussion,
but
I'm
just
kind
of
curious
like
why
it
was
decided
to
be
optional.
B
So
if
you
parse
it
with
your
eyes,
you
would
see
the
event
factor
and
then
you
can
understand
what
what
those?
What
are
the?
What
is
the
subject
for
this
event,
sorry.
B
C
B
And
or
I
mean
it
might
be
perfectly
fine
to
just
link
to
the
course
back
here.
That's
I
think
that's
okay
for
things
that
are
the
same
for
all
of
that,
but
I
think
that
goes
for
the
mandatory
ones
as
well.
Yeah,
definitely.
D
Okay,
so
I
think
I
got
a
plan.
I
will
update
this
PR
to
document
it
for
incident
types
and
then
I
will
make
a
follow-up
PR
to
extend
that
to
the
other
events
and
we'll
have
some
link
to
the
course
pack.
D
All
right,
yeah,
thanks
for
that.
B
D
Yeah
sure
yeah
I've
not
done
any
dramatic
change.
To
be
honest,
I
mean
there
is
some
copy
paste
issues,
Matthias
identified
and
affixed
those
there
is
some
text
on
the
top
and
I
basically
took
your
proposal
for
that
and
I.
B
D
All
right
moving
forward
on
connecting
events
is
there
any
updates
that
we
want
to
discuss
today
on
this
topic.
B
I
went
there
to
to
start
introducing
some
information
from
when
it
comes
to
linking
events
here,
using
the
links
that
there,
as
we
call
them
in
Eiffel,
that's
not
by
any
means
done
yet,
but
I
started
at
least
and
I
added
an
example
section
there
below
where
I
intend
to
have
a
I
mean
I'm.
Sorry,
if
that's
the
best
example
I
started
with
there,
the
it
was
an
artifact.
B
Yeah,
the
earthquake
published
notification,
corresponding
events,
how
they
would
look
if
you
will
reduce
links
and
stuff
I'm,
not
sure,
maybe
that's
something
we
can
just
discuss.
What
are
the
best
examples
of
events
we
would
like
to
see
here.
I
think
it
makes
quite
good
sense
to
have
real
Json
formed
examples,
so
we
can
see
what
they
look
like,
but
I'm
going
to
start
this
one
about
artifacts
is
the
best
one.
B
B
A
C
Which
you
know
because
I
read
through
this,
you
know
right
before
the
the
Fig
here
is.
How
do
we
compose
this
graph
again,
let's
say
like
I
want
to
see
what
happened
like
as
a
graph
right,
how?
How
would
I
go
about
doing
that
with
the
event
links
because
it
sees
it
shows
just
like
pointing
back,
but
it
doesn't
tell
like
how
each
of
these
links
like
relate.
C
B
Yeah,
so
so
one
event
here
in
this
example
here
we
see
the
links
section
there
on
162..
It
contains
a
reference
which
is
called
Target
here
then,
to
something
a
two
three,
four
one,
three
four
and
so
on,
and
that's
the
event
ID
of
the
previous
event.
So
you
would
create
that
graph
by
traversing
or
looking
up
that
event
by
its
ID.
B
Instead
of
looking
for
all
events
with
a
certain
context,
ID,
you
would
then
for
each
event,
you
find
look
at
their
links
and
then
go
the
next
step
and
by
an
event
graph.
Of
course,
if
you
have
a
graph
database,
that's
an
easy
task
to
just
get
the
full
chain
of
events
from
one
route
to
all
its
ancestors.
C
Okay,
cool
cool,
so
this
I
I,
yes,
I,
guess
what
my
question
is
is
then,
if
we
have
like
cycle
like
graphs
for
instance,
or
like
let's
say
we
have
links,
we
have
this
array
of
links
and
we
have
links
that
can
links
reference
each
other
in
in
the
links.
B
No
I
mean
I
mean
it's
quite
natural.
When
you
have
a
pipeline
of
things
happening,
they
happen
in
a
certain
order
and
right
right,
there's
no
way
that
something
that
happens
now
would
reference
something
that
happens
later.
I
mean
the
idea
with
these
things
is
to
reference.
What
has
happened
later,
so
you
don't
need
to
include
all
that.
C
B
C
Okay,
that
that's
all
I
was
wondering
if
that
was
possible.
Yeah,
just
it
being
in
the
past,
makes
makes
all
sense
and
then
with
a
graph
database,
because
my
concern
is
like
how
efficient
this
is
like
to
build
this
but
and
then
like
going
back
like
so
there's
two
questions
here:
how
efficient
you
know
graph
database
that
that
might
solve
the
issue
with
my
concern
of
because
we
might
have
you
know
thousands
potentially
tens
of
thousands
of
machines
trying
to
hit
this
graph
database
endpoint.
C
You
know
building
these
graphs
out
right
and
then.
My
second
question
is
this
event
is
still
or
this
idea
is
still
going
to
have
this
Global
ID,
where
we
can
kind
of
group
all
these
things
together.
So
it's
kind
of
two
questions
there
is
the
efficiency
part
like
how
do
we
plan
on
tackling
that
as
well
as
or
what
can
we
do
to
improve
that
or
make
that
easy
and
so
on
and
so
forth
and
the
second
one
is.
B
To
me,
there
are
many
use
cases
which
are
hard
to
to
really
hand
them
through
just
the
context,
a
global
context,
study
or
a
self-talk
global
context,
IDs,
but
that's
something
we
should
elaborate
on
a
bit
when
what
kind
of
use
cases
do
we
see
these
references
for
all
of
these
different
connected
connecting
events,
references
for,
but
according
to
I
mean
regarding
the
the
efficiency
thing
there
I
mean
we
have
used
this
for
for
years
in
Ericson
already,
and
we
have
thousands
of
these
links
to
many
of
the
events.
B
I
mean
the
chain
of
event.
Is
you
have
thousands
in
the
windows
chains
and
we
actually
don't
use
a
graph
database?
Yet
we
have
discussed
it
for
long
that
we
should
switch
out
our
accounts
mongodb
database
to
the
graph
database,
but
so
far
we
haven't
seen
the
real
urgent
need
for
it,
because
the
mongodb
database
we
have
is
currently
solving
our
our
issues.
I
mean
it
handles
our
requests
for
many
many
queries
per
second,
in
some
cases
and
since
these
event,
IDs
are
then
indexed
efficiently
in
the
database.
B
So
this,
the
ID
that
is
referenced
here,
is
always
on
the
same
location
in
each
event
that
is
sent
so
that
field
is
always
indexed
in
this
database
in
the
mongodb
database
that
we
use
the
document
database
done
then
it's
very,
very
quick
to
find
those,
and
we
have
internal
like
database
functions
built
into
our
mongodb
instance,
which
does
this
graph
traversals
done,
but
based
on
document
data,
and
that's
quick,
quick
I
would
say
so.
I
don't
see
any
of
any
problems
there
really.
B
So
that's
what
at
least
for
the
when
you
do
the
Upstream
searches,
because
then
you
search
for
proper
IDs.
Just
with
your
index.
When
you
do
a
downstream
search,
it's
we
don't
have
a
huge
problem
there
either,
but
that's
potentially
a
thing
whether
the
graph
database
would
be
a
lot
more
efficient
when
you
Traverse
the
graph
Downstream,
because
then
you
would
need
to
ask
give
me
all
events
which
has
its
ID
as
its
event.id
field
or
something
and.
C
A
B
Not
a
big
problem-
really
it's
I
mean
with
our
experience
at
this.
So
but
of
course
we
should
look
into
it,
and
I
would
very
much
look
forward
to
having
a
graph
database
instead
or
maybe
we're
looking
into
multi-model
databases
like
orango
DB,
which
is
both
a
document
database
and
the
graph
database
in
in
the
same
which
I
think
is
very
good
for
this,
because
we
would
always
always
want
to
look
at
the
document
lookups
as
well
or
say:
property
lookup,
so
not
just
graphs.
B
C
Because
I
think
this
goes
back
to
the
global
ID,
like
the
benefit,
there
is
being
able
to
look
up
everything
for
a
particular
you
know
span
or
an
event
is
just
being
able
to
search
without
needing
you
know
to
do
this
one-off,
like
traversal,
every
single
time
you
know
Downstream.
A
B
That
you
get
a
bag
of
events
back
and
they
own
the
way
you
can
arrange
those
events
internally
within
that
bag
is
just
ordering
them
by
time.
You
don't
have
any
relations
in
between
those
events.
All
of
them
just
contain
the
same
Global
ID,
and
then
it's
up
to
you
to
make
the
best
sense
of
how
they
internally
are
connected
to
each
other.
What
happened
in
in
what
what
happened
in
parallel?
What's
happening,
Syria
and
what
happened
because
of
what
well.
C
I
mean
TR
like
how
tracing
works
right.
You
have
a
trace
ID,
which
is
the
global
ID,
and
then
you
have
a
span
ID
right,
which
right
now
you
just
have
the
span
ID,
so
I'm
wondering
like
if
we
need,
if,
if
we
want
to
use
Eiffel,
we
might
need
I
mean
if
we
want
to
use
Eiffel
within
CD
events,
we
might
need
something
like
a
global
ID
or
in
this
case
kind
of
like
the
same
thing
as
a
trace
ID.
If
you
will
to
kind
of
make
sense
of
these
long-running.
C
B
I
would
be
interested
to
see
that
use
case
what
what
I
mean,
what
it
would
look
like
really
and
that's
a
perfect
scenario
to
look
into
how
will
that
use
case
be
solved
with
the
global
IDs
or
spam
IDs
or
a
combination
of
them
or
build
links,
or
maybe
a
combination
of
these
context,
IDs
and
links?
C
Yeah
definitely
I
mean
you
know
I'm
not
too
concerned
with.
You
know
what
what
you
know
we
do
to
solve
it.
I
just
think
we
we
need.
We
need
a
global
ID
somewhere,
where
we
can
kind
of
reference.
You
know
all
these
events
together
and
you
know
if
it's
a
combination
or
if
it's
you
know
modifying
Eiffel,
you
know
whatever
that
solution
is
I.
I
think
is
fine.
C
It's
just
that.
We
need
to
have
it,
though,
and
I
really
need
to
put
the
emphasis
on
on
need,
because
you
know
like
when
we're
talking,
because,
like
my
concern
is
like
me
being
at
Apple
like
we,
we
have.
You
know
a
thousand
I'm
like
we're
talking
like
hundreds
of
thousands
of
machines,
right
that
are
gonna,
be
potentially
asking
for
these
links
Downstream.
C
So
we
need
to
make
sure
that
this,
you
know,
there's
an
easy
way
of
querying
this
I
think
a
global
ID
solves
that
and
and
I
think
what
I
could
do
is
I
could
add
to
the
document,
potential
use
cases
for
the
global
ID
and,
and
we
can
kind
of
figure
out
which
proposal
works
best
or
with
which
yeah
I
guess,
which
proposal
we
have
three
in
here
works
best
and
if
Eiffel
can
handle
this
particular
use
case,
which.
B
Look
forward
to
that,
it
would
be
great,
so
I
think
those
use
cases
could
describe
be
described
on
a
general
level
on
this
document
on
how
to
connect
events,
what
we
need
to
collect
events
and
then
these
three
different
options
or
if
we
find
more
we're
done
reference.
How
can
we
solve
those
use
cases
by
the
different
types
of
the
connecting
references
that
we
provide
here.
C
Cool
yeah
definitely
don't
make
that
an
action
item
for
me,
then
to
add
a
few
use
cases,
and
then
we
can
I
think
for
the
next
for
next
week.
We
can
then
discuss
you,
know,
potential
options
for
for
each
of
the
sub
proposals
within
this
proposal
and
then
kind
of
go,
go
start
making
a
decision
and
then,
with
that
being
said,
I
think
this
Andre
I,
don't
this
is
not
going
to
make
February
16th,
unfortunately
yeah,
so
we're
probably
gonna
push
this
out.
Yeah.
D
And
then
that's
clear,
but
yeah
no
I
think
it's
it's
great
discussions.
There
are
a
couple
of
things.
I
I
think
I
wanted
to
to
add
as
well.
D
So
one
thing
is:
there
are
two
use
main
use
cases
that
we
have
in
in
mind
and
one
is
like
one
tool
triggering
another
tool
or
a
chain
of
that,
and
the
other
use
case
is
multiple
tool,
doing
their
things
and
sending
events
and
someone
collecting
all
the
events
and
using
those
events
or
that
event,
data
to
show
a
graph
calculate
metrics
or
whatever
I
would
call
it
kind
of
observability
type
of
use
case
and
I.
Think
in
the
in
the
Second
Use
case.
D
We
can
assume
that
we
have
a
database
with
all
these
events
stored
in
the
first
use
case.
D
We
cannot
necessarily
assume
that
so
and
I
think
that's,
maybe
something
that
we
need
to
differentiate
and
when
we
consider
the
use
cases
so
the
chest
I
wanted
to
add
that
I
think
for
what?
What
it
feels
to
me
like
is
that
there
are
things
that
links
can
accomplish,
of
course,
that
Global
ID
cannot
and
the
other
way
around
so
like
it.
It
feels
to
me,
like
we've,
been
going
towards
a
scenario
where
we
would
support
Global,
IDs
and
links
which
goes
a
bit
against
what
we
said
in
the
beginning.
D
We
want
to
keep
it
as
simple
as
possible,
but
reasons
going
back
to
the
to
what
we
were
you
were
discussing
earlier.
D
D
If
you
will,
because
we
don't
have
this
Global
ID,
that
starts
at
some
point
and
ends,
and
some
other
points
so
I
think
that
dude,
it
seems
to
me
like
there
are
features
in
in
both
of
these
two
that
do
not
exist
in
the
other
one.
D
B
I
think,
because
for
the
Eiffel
version
of
this
I
mean
we,
we
don't
use
really
any
Global
event.
That
is
anywhere
and
that's
perfectly
fine
with
use
cases
we
are
so
yeah.
B
Maybe
we
can
describe
the
needs
that
you
see
for
Global
IDs
using
these
links
as
well,
and
maybe
those
the
description
would
then
re
assume
things
that
we
might
not
agree
on
the
industry,
the
advanced
project
that
we
want
to
have
so
so
that
it
would
be
very
good,
I
think
to
to
nail
down
the
the
actual
use
cases
and
see
it
would
be
good
to
have
maybe
just
one
of
these
Solutions
and
not
have
two
ways
to
do
the
same
thing
if
we
consider
it
the
same
thing
but
yeah
so
I
think
looking
at
what
use
cases
we
have
for
this
connected
events
is
very
important.
C
Yeah
yeah,
definitely
and
I
would
say
that
Global
IDs
aren't
really
two
ways
of
solving
the
problem.
It's
it's
you're,
taking
a
given
solution
and
giving
it
the
necessary
information
to
solve
another
particular
issue
right.
It's
so
it's
like
it's
giving
like
just
having
a
global
ID
by
itself
like
you
can
get.
You
know,
like
all
the
events
that
happen,
but
there's
no
way
to
like
construct.
C
You
know
the
dad
for
this
right,
but
like
with
links,
you
can
at
least
construct
a
dag
right,
and
the
whole
goal
with
like
connecting
events
is
to
be
able
to
construct
some
sort
of
dag
representing
how
these
things
relate
to
one
another,
and
a
global
ID
doesn't
really
do
that.
C
It
only
relates
to
the
actual
Global
event
that
occurred
right,
so
I
I
think
it's
solving
two
very
different
problems,
but
the
global
ID
in
the
context
of
links
gives
it
the
ability
to
one
search
more
optimally
when
you're
going
Downstream
and
then
secondly
be
able
to
group
things
in
a
way
where
you
now
know
the
beginning
and
the
end
of
a
of
you
know
whatever
we
want
to
call
this
a
span.
C
If
you
will
or
or
a
whole
event,
so
so
I
I,
don't
want
to
say
that
there's
two
there
are
two
different
ways
of
solving
the
same
problem,
because
I
think
I
think
Global
ID
is.
C
B
And
I
think
if
you're
fine
with
I
mean
if
we
would
be
able
to
prove
that
the
link
traversal
is
efficient
enough,
regardless
of
what
is
how
many
events
are
connected,
then
this
Global
ID
could
actually
just
be
part
of
the
the
first
event
in
that
chain,
and
then
you
have
it
I
mean.
Then
you
can
look
up
that
first
event
using
the
global
ID
and
then
you
get
the
full
chain
of
events
using
those
links.
Is
that.
C
Yeah
or
I
mean,
or
we
could
just
change
the
links
to
be
like
a
link.
Links
to
be
linked,
like
the
link
links,
may
be
being
an
object
with
a
global
ID
at
the
top,
and
then
an
array
like
for
the
actual
links,
so
that
might
be
an
option
as
well.
Yeah.
B
But
one
thing
here
is
that
it's
not
really
up
to
the
producer
to
know
all
the
circumstances
in
which
it
has
been
run.
So
sorry
to
me
at
least
I
mean
yeah.
This
I
could
see
in
multiple
cases
where
a
global
array
would
be
added
on
top
of
some
events
as
an
after
construct
I
mean
now.
We
also
want
to
group
these
events
before
we
want
to
know
some
some
new
kind
of
information,
and
then
I
mean
that
that
information-
those
IDs,
are
not
there.
Yet.
C
Sense,
yeah,
yeah,
yeah,
no
I
get
what
you're
saying,
but
the
thing
is
is
like
when
you're
introducing
a
global
ID.
That's
the
very
that's
the
thing
right.
The
global
ID
needs
to
be
passed
down
to
these
to
these.
Well,
they
don't
need
to
technically
be
passed
down
to
these
links
right,
but
it's
the
producer
that
knows
about
this
Global
ID.
B
Somehow
and
then
there's
been
multiple
ideas:
I
guess
your
show,
then,
in
the
topic
that
there
are
multiple
in
the
in
the
document
there
that
there
are
multiple
different
types
of
workflows,
as
you
call
them
then
and
I
assume
all
those
workflows
would
have
their
own
Global
ideas
of
work
provides
in
your
lingo.
B
B
But
then
there
is
not
much
sense
of
having
it
is
it
I
mean
one
I,
don't
I,
don't
really
get
it.
What
would
that
be?
If,
if
you
related
to
okay,
say
a
storage
change,
then
the
new
source
change
comes
in
and
you
build
and
you
start
a
full
pipeline
is
that
is
the
global
idea.
Then
it
started
from
that
Source
by
The
Source
in
summer,
it
connected
to
it
and
then
the
next
two
versions
within
within
a
new
globally.
Is
that
the
use
case
you
see
then
or.
C
Yeah
I
mean
similarly
like,
like
Tracy
right,
like
it's,
it's
very
much
very
similar,
so
like
yeah
like
an
artifact
chain,
whatever
it
is
to
start
the
whole.
You
know
since
we're
talking
about
you,
know
continuous
integration
and
delivery
that
whole
process.
The
very
first
entry
point
right
in
every
system.
There
is
an
entry
point
right,
and
in
this
case
you
know
it
might
be
an
artifact
changing
it
might
be.
C
You
know
like
a
pull
request,
starting
a
whole
group
of
things.
You
know,
which
is
also
an
artifact,
so
yeah
it
could.
It
could
be
very
well
just
be
an
artifact
changing
that
creates
This,
Global
ID
and
then
propagates
it
down
right,
but.
B
But
if
you
want
to
reference
things
that
happened
before
that
well,
what
was
that
artifact
built
of
then
you,
you,
don't
know
that's
there.
Then
you
need
to
include
the
the
chain
of
things,
reactions
or
events
that
happened
before
that
artifact
was
built
as
well.
When.
C
This
order,
whatever
this,
whatever
the
starting
event,
was
that
that
would
create
the
global
ID
and
if
the
artifact
that
was
created
doesn't
have
a
global
ID,
it
would
create
a
global
ID.
At
that
point,
then.
B
A
B
B
C
No
because
bits
argue
the
same
thing
for
tracing
the
very
same.
You
can
say
that
same
argument
like
with
tracing
when
you
say
oh,
but
this
Trace
ID
could
exist
10
years
ago
and
propagate
debt
tracing
solved.
This
problem
right.
This
is
a
completely
feasible
solution
to
being
able
to
group
things
with
with
the
global,
ID
and
I.
Think
things
like
you
know,
oh,
when
does
it
start?
You
know,
and,
and
whatnot
is
it's
just?
C
However,
you
know
your
system
is
designed
right
and
in
in
place
in
cases
with
lib
see
they
might
decide
that
hey
our
events
start
at
when
we
create
the
artifact.
You
know
that
that's
up
to
the
the
the
the
the
system,
administrators
right
or
whoever's
designing
the.
C
I
I,
don't
think
you
know
that
example,
because,
like
I
said
you
know,
for
me,
is
your
example
or
any
example
that
we
come
up
with
needs
to
be
a
an
example
that
tracing
you
know
also
cannot
do
and
tracing
does
the
whole
Lipsy
thing.
It
knows
when
things
start,
it
knows
when
things
you
know
finish
and
and
CDU
events
like
it's
not
tracing,
but
it
has
the
same
flow
of
you
know.
Well
at
least
for
links.
C
It
should
have
the
same
flow
of
being
able
to
represent
how
things
are
connected
and
how
things
are
queried.
In
my
opinion,
mostly
because
we
we
want
things
to
be
efficient
and
we
want
to
know
you
know
like
if
I'm,
if
I'm
a
consumer,
we
want
to
know
when
things
begin
and
end
right.
We
we
need
some
sort
of
way
of
of
of
representing
that
and
then
having
them
just
Traverse
a
graph
like
if
you
have
multiple
systems
that
are
doing
this,
like
it's
not
going
to
scale.
B
Yeah
yeah
for
sure
it
will
be
heavy,
but
if
you
consider
that
the
case,
for
example,
if
you
find
a
vulnerability
in
libsy-
and
you
would
like
to
know
where
is
this
Library
included
in
what
software-
what
software
is
vulnerable?
Due
to
this
vulnerability,
we
found
now
I
mean
to
me:
that's
Trace
traceability
to
be
able
to
find
Downstream
botless
what
has
included
this
version
of
libc
Downstream,
and
then
it's
totally
out.
B
Event
bucket
with
with
no
interconnections
internally
at
all-
it's
just
the
so
but
I
must
admit
that
I'm
not
too
familiar
with
how
the
open
Telemetry,
Trace
context
and
Trace
IDs
are
really
set
up.
I
assume
that
there
is
some
good
way
of
hierarchically
setting
up
Trace
context
and
Trace
studies,
hierarchically
Downstream
there.
So.
B
I
assume
that
there
is
a
good
way
to
do
it
and
I
would
look
forward
to
seeing
how
that
would
look
like.
So
it's
just
I
mean
I,
don't
think
we
have
just
one
Google
Global
ID.
We
have
multiple
IDs
here
in
the
play
and
probably
a
hierarchical
view
of
ID
sum
up
both
the
article
and
multi-dimensional,
as
you
mentioned
earlier,
on
the
different
scenarios
as
well.
C
Okay,
so
so
from
what
I
hear,
so,
let
me
let's
I,
want
to
take
a
little
step
back
real,
quick,
because
I
think
we
kind
of
like
jumped
the
gun
too
quickly
a
little
bit.
C
So
from
what
it
sounds
like
okay,
so
this
is
actually
my
fault,
because
I
just
I
made
the
Assumption
that
people
were
familiar
with
with
tracing,
which
is
not
the
case
and
that's
my
fault,
so
I
think
I
should
probably
write
because
you
did
a
great
job
meal
with
writing
your
section
with
Eiffel
I
think
I
should
spend
a
time
or
maybe
Andrea,
because
I
know
Andre
you're
a
little
familiar
with
tracing.
C
How
tracing
works
as
well
is
write
this
section
on
how
tracing
handles
events
with
the
global
ID
of
Trace
ID
and
a
span
ID.
That
way,
we
all
have
the
necessary
information
to
make
to
make
the
decision
of
what
to
go
using
or
what
to
use
going
forward.
Does
that?
Does
that
sound
good?
Absolutely.
B
C
C
Yes,
so
okay,
cool
cool,
so
yeah,
we'll
we'll
definitely
yeah.
We
definitely
need
to
add
that
and
then
next
week,
yeah
I
will
add
the
use
case
for
Global,
ID
and
then
yeah
see
Andrea
will
add
the
details
for
Choice
context
and
then
yeah.
C
We
can
compare
the
two
and
then
hopefully
finalize
I
think
we're
still
going
to
be
a
little
bit
of
Purgatory
in
in
the
deciding
Rome
next
week,
but
I
I
definitely
think
we'll
have
a
lot
more
information
to
start
funneling
down
like
a
more
correct
solution
or
the
best
solution
for
for
CD
events.
A
D
I
wanted
to
to
add
one
thing
to
the
use
case
of
what
is
lip:
C,
that's
really
mentioning
email
and
so
I
I.
Think
one
thing
to
consider
is
what
is
the
the
scope
or
availability
of
the
database
of
events
and
what?
What
assumption
do
we
want
to
make,
because
if
we
think
that
database
exists
within
an
organization
or
if
you
want
to
consider
connecting
events
coming
from
outside
organizations,
then-
and
we
assume
that
this
event's
IDE
will
be
known
by
other
organization
as
well.
B
No,
oh
absolutely
I
didn't
add
that
detail
to
my
example,
but
for
sure
no
there
will
be
no
single
database.
No
one
of
all
events
in
the
world,
of
course,
but
there
will
be
references
to
the
different
organizations
or
domains
as
I
would
call
them.
It
could
be
stores,
groups
or
whatever,
which
and
and
through
those
domains.
Then
you
should
be
able
to
to
be
able
to
query.
B
Is
some
other
database
to
continue
this
chain
upstream
or
Downstream
further
and
then,
of
course,
it's
up
to
the
organization
that
has
created
that
event
chain
if
they
are,
if
they
are
fine
with
exposing
that
data
or
not,
and
that's
totally
their
concern,
if
they
don't
feel
like
exposing
their
internal
event,
data
through
your
database,
then
that
then
they
eventually
will
not
be
public
and
not
possible
to
Traverse
into
their
organization.
B
D
B
It's
somehow
maybe
relates
there
and
that's
something
that
we
have
been
discussing
each
other
as
well
now,
when,
when
this
bombs
has
been
more
more
of
a
thing
starting
to
get
more
interesting,
maybe
there
is
something
there
that
we
should
try
to
relate
to
as
well
and
maybe
replace
what
we
do.
You
know
with
such
references
instead
and
that's
perfectly
fine
then,
but
I
need
we
at
least
we
need
to
have
an
idea
on
how
to
to
trace
all
the
way
I
would
say
and
I'll
use.
B
D
Oh
yeah,
no
I
think
it's
again.
It's
it's
important
that
we're
having
clear
what
other
use
cases
we
want
to
address
and
but
yeah,
maybe
maybe
we
can
think
of
having
some
conversations
with
other
groups
about
this.
A
D
See
what
what
they're
doing
in
terms
of
you
know
this
traceability
of
artifacts
and
yeah.
A
D
A
D
I
think
I'm
really
happy
to
to
actually
move
forward
on
these
conversations
about
connecting
events
as
one
of
the
key
features
on
the
protocol,
I
think
and
which
would
really
I'm
really
happy
to
see
if
we
can
make
some
progress
there.
So
I
think
that
this
time
very
well
spent
to
me
yeah.
So
we
can
try
and
go
through
the
roadmap
next
time.
I
think
in
the
meanwhile
I
mean
it's
clear
that
the
release
will
not
happen
in
on
the
16th.
D
B
D
B
Think
so,
yeah
together
then,
and
maybe
for
that
reason-
pause
the
connecting
events
before
until
we
get
the
incident
events
done.
So
we
try
to
get
that
out
as
soon
as
possible,
but
I
know,
of
course,
at
the
same
time,
if
we
have
time
to
continue
with
connecting
events
in
the
meantime.