►
From YouTube: SIG Events Meeting - Jan 25, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
A
C
So
I
I
wrote
a
note
in
the
channel.
Unfortunately,
today
there
is
some
forcing
circumstances
I
need
to
drop
early,
so
maybe
it
will
be
until
4
20
and
we
can
keep
it
short,
yeah,
yeah
yeah,
but
yeah.
No,
you
always
can
continue
after
a
gun.
Don't
have
to
don't
want
to
to
break
the
discussion,
but
unfortunately.
A
A
C
C
All
right
should
we
get
started.
Is
that
all
right.
C
Okay,
so
the
first
thing
I
just
wanted
to
mention-
and
you
know-
maybe
we
just
should
say-
okay-
welcome
to
sick
events-
vocabulary
discussion
meeting
today
is
january
25th
and,
if
you
like,
add
your
name
to
the
participant
list
in
the
agenda,
and
I
hope
you
have
access
to
the
agenda.
Otherwise,
you
just
put
the
link
in
the
chat.
C
And
yeah,
so
the
first
thing
I
just
wanted
to
do
with
a
brief
reminder
is
that
we're
working
with
the
cf
marketing
pr
plan,
which
I
put
the
link
in
here.
So
we
have
some
content
already,
but
yeah
review
and
contribution
are
very
welcome
and,
of
course,
one
of
the
things
that
we
benefit
from
is
supporting
quotes.
So
if
your
company
you
work
from,
for
you,
know
some
company
that
would
like
to
give
a
supporting
quote
to
the
city,
events
project
feel
free
to
add
it
to
there.
C
Okay,
any
question
on
that:
what's
the
announcement
for
kinda
like
what's
the
so
the
announcement
is
the
city
events
project,
basically,
okay,
so
the
city
events
project
has
been:
let's
join
the
the
city
foundation
as
the
incubating
project
and
yeah.
So
we
want
to
make
a
bit
of
a
splash
announcement.
C
Then
you
know
spread
the
word
about
city
events.
At
the
end
of
the
last
year,
the
leadership
summit.
There
were
some
discussions
as
well.
I
was
not
there,
but
steve
and
tracy
were
there
and
kind
of
promoted
cd
events
and
cdf
recognized.
The
events
are
strategic,
so
we
wanted
to
put
some
stress
and
and
focus
on
it
so
to
say
so,
but
we
need
to.
C
We
would
like
to
get
more
contributions
to
the
project,
at
least
in
terms
of
use
cases
really
largest
cases
of
people
using
events
in
their
cities
and
maybe
contributors
to
the
spec
and
to
the.
C
Sdks,
that's
the
background
perfect.
C
Okay
quickly,
I
wanted
to
mention
the
next
one
we
discussed
about
setting
up
a
roadmap
for
the
project.
It's
part
of
the
requirements
for
incubating
project
in
the
cdf.
Sorry
about
my
voice,
so
I
created
a
pr
and
what
I
proposed
a
roadmap
for
this
year
and
yeah.
So
I
already
sorry
I'm
not
going
to
go
for
the
for
it
now,
but
I
already
got
some
comment
and
replied
and
updated
the
spec.
Sorry,
the
the
roadmap
a
few
times.
C
I
just
wanted
to
to
ask
if
anyone
had
any
thoughts
about
it
or
just
asked
to
if
you
could
review
so
that
can
merge
it
sooner
than
later
or
if
there
is
any
concern
with
the
current.
C
A
A
C
C
C
Yeah
so
thanks
we
have
used
cases,
so
we
wanted
to
basically
go
through.
C
Different
use
cases
that
we
have
listed
and
proposed
for
poc,
if
you
don't
mind
it
just
before
we,
because
I
may
run
out
of
time,
just
wanted
to
say
two
words
about
the
the
next
two
items
in
the
agenda.
C
I'm
just
saying
that
I've
I
created
a
couple
of
items
for
design
discussions
which
are
issues
number
10
and
11.
If
folks
are
interested
in
want
to
leave
some
comment
and
the
last
one
I
set
up
a
project
so
get
a
project
and
created
a
0.1
milestone
for
the
spec,
and
so
I
started
basically
setting
up
a
kind
of
planning
exercise
to
see.
What's
what
we
think
should
be
in
scope
for
the
initial
version
of
the
spec
again,
I
don't
want
to
spend
time
in
this
meeting
going
through
the
planning.
C
But
if
folks
are
interested
in
want
to
have
a
look,
then
we
can
discuss
it
in
more
details
during
the
meeting
next
week.
C
C
All
right
so
for
the
use
cases,
whenever
you
want
to
present
the
decay
native
space,
you
want
to
take
over
sharing
or.
A
I
think
that
we
have
like
yeah,
we
have
issue
here
haitian.
Do
you
want
to
quickly
introduce
yourself
if
you
can,
of
course,.
B
A
Yeah
yeah
and
he's
doing
all
kind
of
like
the
implementation
of
the
controller
here.
So
I
think
that
the
main
idea
around
this
is
just
to
create,
like
a
canadian
controller,
for
that,
we'll
be
able
to
emit
cd
events
and
consume
cd
events
as
well.
The
problem
that
I
see
every
time
that
we
want
to
integrate
a
new
project
into
like
using
consuming
and
producing
cd
events
is
basically
usually
like.
A
We
first
need
to
come
up
with
a
use
case
that
makes
sense
and
kind
of
like
a
couple
of
tools
that
can
integrate
by
using
canon
in
this
case
like
cloud
events.
So
we
started
kind
of
like
based
on
this
issue
kind
of
like
with
two
use
cases
in
mind,
and
both
using
use
cases
can
like
include
tecton,
because
tecton
was
already
included
there
in
the
plc
in
the
previous
plc
that
we
had.
A
A
So
what
is
doing
now
is
basically
creating
a
controller
that
can
consume
and
produce
cloud
events,
and
I
think
that
we
pretty
much
have
that
already
right,
like
I'm.
Using
the
you
know
the
cd
events
sdk
and
that's
kind
of
like
working,
but
I
think
that
it
was
like
something
that
we
need
to
do
is
we
need
to
come
to
this
group
just
share
that
we
are
building
this
and
get
external
feedback,
so
we
can
actually
come
up
with.
A
Okay,
let's
like
bring
another
project
that
it's
not
integrated
with
cd
events
yet
and
then
just
include
it
kind
of
like
in
this
kind
of
like
use
cases
so
yeah
I've
cleared.
This
issue
edition
is
creating
the
implementation.
A
What
we
need
from
the
from
the
group
here
is
just
to
some
validation
on
the
use
cases,
some
feedback
on
the
use
cases
and
then
help
to
set
up
things
together
right,
like
the
same
thing
that
we
did
on
the
plc
for
for,
like
I
don't
know,
what's
like
city
summit
and
and
kubecon
right.
C
Right
yeah,
try
to
remember
we
discussed
about
where
to
store
pocs
yeah
we
could
have.
We
have
not
set
it
up
yet,
but
I
think
we
could
have
one
one
repo
under
the
cd
events
organization,
where
we
we
take
all
the
the
pocs
in
one
place.
That's
the
thing
that
we
discussed
earlier
that
we
would
do
yeah
and
yeah.
We
can
keep
permissions
pretty
lightweight.
C
C
A
C
A
Yeah,
I
think
that
will
make
sense
if
you
scroll
down
a
bit
a
bit
more.
You
will
see
that
I've
got
like
a
diagram
and
the
kind
of
events
that
kind
of
like
this
component
will
be
emitting
and
consuming,
and
I've
also
raised
like
some
questions
about
like
from
the
consuming
side,
when,
basically,
each
implementation
will
need
to
define
how
to
map
a
cd
event
to
an
action
inside
that
kind
of
specific
project
or
platform.
A
I
think
that
we
can
come
up
with
a
solution
for
that
as
well,
maybe
not
as
part
of
the
plc,
but
I
think
that
for
this
group
we
should
be
thinking
about
that,
because
one
thing
is
creating
a
component
that
emits
cd
events,
that's
perfectly
fine,
but
the
semantics
on
consuming
cd
events
and
mapping
that
to
specific
actions
or
or
calling
specific
endpoints
and
all
that
stuff.
A
So
maybe
we
can
just
follow
there
like
the
discussion
in
the
in
the
comment,
but
I'm
really
curious
from
hearing
people's
thoughts
about
this
kind
of
stuff,
because
I
I
do
see
this,
you
know
as
one
of
the
main
problems
for
adopting
this
stuff
like
the
cd
events
in
general,
not
the
emitting
city
events,
but
the
consuming
side
of
things.
C
C
Yeah,
I
think,
in
the
initial
plc
as
well,
we
have
some
custom
code
that
we
had
to
write
for
the
consuming
site.
So
definitely
there
is
some
some
work
to
be
done.
I
think
what
I
would
love
to
see
is,
as
you
work
on
this
and
you
hit
maybe
more
specific
issues
for
a
specific
field
that
maybe
we
have
a
dedicated
issues
so
that
we
can
say
okay,
this
bit
of
information,
how
we
can.
C
How
can
we
share
it,
or
can
we
structure
the
protocol
in
a
way
that
it
serves
your
use
case
and
then
on
the
spec
side?
I
would
like
I
started
creating
some
issues,
because
I
think
I
would
like
to
to
track
in
the
in
the
spec
itself.
When
we
have
some
description.
Oh
did
we
have
this
field
in
the
protocol,
then
we
can
link
it
back
to
use
cases
and
say
well.
We
have
this
field
in
the
protocol
because
it
serves
these
use
cases
and
we
have
some
pocs
implemented
as
well.
C
A
So
as
next
steps,
andrea
and
tim,
I
would
say
that,
maybe
with
with
each
and
we
are
going
to
define,
can
like
these
events
and
probably
go
to
check
if
the
sdk
is
already
containing,
collect
the
structures
for
for
a
meeting
for
being
able
to
emit
and
produce
these
events.
C
Yes,
maybe
you
can,
as
I
said,
create
some
issues
and
then
also
the
pr
associates.
So
we
can
have
some
some
discussion
on
it
for
the
sdk
so
right
now
there
is
the
sdk
in
sig
events,
as
you
know,
because
you
wrote.
B
C
Yeah,
so
there
is
some.
We
had
some
discussion
in
the
meanwhile
about
how
we
want
to
do
the
binding
to
cloud
events,
and
things
may
be
changing
a
bit,
but
I
think,
as
you're
working
actively
on
this
poc,
you
don't
need
to
wait
on
that.
I
think
you
can
work
with
the
p
with
the
sdk
as
it
is
now
and
then
at
some
point.
A
Perfect
yeah
make
sense
at
the
same
time
we
will
as
soon
as
we
have
like
a
small
plc
where
we
can
show
like
some
integration.
We
will
try
to
donate
the
controller
to
the
k
native
sandbox
organization,
so
hopefully
it's
like
in
tecton,
like
like
an
experimental
component
that
the
community
can
pick
up
and
use,
and
I
guess
that's
where
kind
of
like
we
might
be
interested
in
just
showing
this
to
more
people.
So
people
is
aware
that
we
are
working
on
this
and
if
somebody
else
wants
to
join,
they
can.
A
D
When
it
comes
to
dealing
with
how
to
consume
events
and
take
action
on
it,
I
wonder
if,
if
matthias
or
emil
at
some
point
have
thoughts,
they
can
share
from
the
eiffel
community
when
it
comes
to
that,
because
there
I
believe,
things
have
matured
a
bit
when
it
comes
to
to
consuming
event
and
taking
action
on
it.
Matthias,
I'm
not
sure
if
you
have
any
comments
on
that
now
or
well,.
E
Yeah,
it
was
actually
interesting
to
know
a
little
bit
more
about
the
consumption
so
on
in
my
head.
If
I
get
things
right
now,
the
reason
that
most
of
the
consumption
of
events
is
up
to
the
the
like
user
itself
is
because
it's
the
way
that
you
set
up
the
pipeline
so,
for
example,
it's
not
always
that
you
get
if
you
publish
an
event
what
happens
after
what
happens,
for
example,
if
you
publish
an
artifact
what
happens
after
that?
E
One
is
in
my
head
up
to
the
user
to
decide,
because
that
depends
on
the
pipeline
they're
running.
Of
course,
we
can,
of
course
like
have
generic
pipelines
and
so
on,
but
that
would
probably
be
a
generic
pipeline
and
a
part
of
the
protocol.
A
I
think
that
I
yeah
yeah
matias.
I
think
that
I
do
agree,
but,
for
example,
for
like
for
for
k
native
for
tekton
for
captain,
it's
like
each
of
these
tools
are
kind
of
like
a
black
box
that
can
perform
different
actions
right,
like
that,
you
can
just
call
services
and
do
certain
things
and
stuff
will
happen.
A
Okay.
This
is
a
black
box
that
has
these
inputs,
and
then
you
know
these
are
the
events
that
are
going
to
be
produced
by
when
we
create
resources-
and
maybe
that's
true,
like
that's
just
the
default
behavior,
but
at
least
there
is
something
where
you
don't
really
need
to
go
and
write
something
from
scratch.
E
Yeah
I
mean
if
you
have,
for
example,
a
connective
certain
component,
then
of
course
they
will
listen
for
for
probably
for
published
events
for
docker
containers,
and
then
you
would
probably
deploy
those.
So
in
that
case
it
makes
sense
to
have
something
out
of
the
box.
A
Yeah
yeah
yeah,
I
think
that's
kind
of
like
one
of
the
use
cases
that
we
want
to
implement,
but
it
still
feels
like
we
will
just
hit
this
problem
again
and
again,
and
it's
not
clear
like
the
semantics
of
the
events
from
the
consuming
side
of
things,
they
are
not
as
clear
as
from
the
producer
side
of
things
right
like
it's
pretty
clear
to
me.
What
can
any
like?
What
are
the
events
that
kenya
can
produce?
A
But
it's
not
clear
to
me
with
the
current
events
that
we
have
defined,
which
are
the
events
that
natives
should
be
interested
in.
If
you
know
what
I
mean
which
push
you
to
that
kind
like
other
side
of
saying,
okay,
just
use
the
sdk
and
just
write
your
own
crazy
thing.
You
can
listen
to
whatever
you
want
to
be
honest
and
then
execute
whatever
you
want
inside
canadian,
which
is
pretty
broad
and
pretty
generic.
E
Yeah
so
thinking
loud
a
little
bit.
So
in
one
thing,
when
we,
when
we're
defined
in
events,
I'm
thinking
about
the
the
cloud
event
spec,
I
should
probably
paste
a
link
also
to
what
I'm
reading.
E
So
here-
and
this
is
an
event
part
sorry-
I
should
have
like
directed
that
one
where
an
event
is
a
data
record
express
an
occurrence
on
its
context.
E
So
you're
talking
about
is
basically
describing
of
of
what
should
happen
after
you've
received
something.
A
E
Yeah,
so
that's
more
like
a
description
of
of
like
a
service
description
of
what
events
does
this
service
support,
something
like
that?
Yeah
yeah
yeah,
something.
E
At
least
when
you're
browsing,
if
you're,
for
example,
browsing
a
bunch
of
components
on
there,
they
would
help
you
to
know.
Okay.
If
I,
if
I,
what
does
this
service
support
for
events,
so
that
would
help
you.
A
So
there
is
a
correlation
there
that
we
can
say
something
like
you
know.
This
component
is
more
on
the
deployment
side
and
it's
going
to
emit
these
events
and
also
it's
going
to
consume.
Or
it's
going
to
be
interested
in
these
events
by
default
right
and
that
might
be
kind
of
like
the
way
for
us
to
describe
the
default
behavior
of
the
component.
And
then
you
can
just
extend
that
by
using
the
sdk.
E
Yeah
so
I
open
up
sidetracking
now,
but
eric
you
were
part
of
the
interrupt
sig.
Last
week
we
discussed
pull.
E
Mary
something
marie
yeah
is
working
at
reddit.
I
think
where
she
is
starting
to
define
terms
for
pipeline
stages
and
pipeline
steps,
and
maybe
I
should
try
to
find
that
pr,
where
she's
kind
of
like
okay,
this
is
input
to
a
step,
and
this
is
an
output
step.
A
D
Just
open
the
file:
what
tricky
anyway,.
D
Yeah
so,
basically,
sorry
defining
all
these
different
steps
that
we
could
have.
This
is
really
slow.
D
So
we
have
been
discussing
like
do.
We
have
concrete
activity,
events
or
abstract
activity
events
if
we
want
to
have
concrete
events
for
all
this,
we
have
a
lot
of
events,
but
I
mean
that
could
be
possible
as
well,
but
it
could
at
least
help
as
we
were
discussing,
help
services
and
tools
that
want
to
react
to
these
events
understand
what
what
types
of
events
could
be
spent
and,
of
course
there
would
be
a
mapping
then,
between
this
and
what
actual
cd
events
events
we
send
for
these
and
pipeline
steps
and
stages.
E
Yeah
precisely
so,
for
example,
there
is
some
deploy
stage.
I
think's
further
down
for
provision
a
deploy
or
provision
here.
Maybe
it's
something
like
this
that
we're
actually
discussing
in
k
native.
A
A
Yeah,
I
think
so,
yeah
deploys
and
provision
yeah
and
verify
deployment,
maybe
as
well
and
yeah,
so
we
are
going
to
be
meeting
events
around
all
this
stuff.
The
problem
is
again
on
the
consuming
side
of
things.
How
do
we
define
those
semantics
and-
and
those
might
not
be
events,
as
you
mentioned,
it's
not
an
event.
What
we
are
defining,
it's
more
just
it's.
It's
called
the
events
that
we're
interested
in
to
perform
certain
actions.
E
Yeah
anyways
yeah,
but
it's
it
sounds
interesting.
What
you're
discussing?
I
was
just
referring
back
to
this
so,
for
example,
in
deploy
here.
If
you
would,
for
example,
define
a
deploy.
Is
you
listen
for
these
events
and
you
send
these
events,
and
then
you
at
least
would
have
that
mapping
and
we
call
that
deploy.
E
You
would
have
something
more
than
than
just
listen
for
any
events.
So
it's
a
little
bit
more
defined.
A
Perfect
folks,
I
need
to
drop
because
I
have
another
meeting,
but
thank
you
very
much.
I
think
that
mission
we
should
be
joining
these
meetings
from
time
to
time,
so
we
can
show
some
progress.
Do
you
have
any
other
thing
that
you
want
to
share.
D
Nice
yeah
thanks
for
joining,
thank
you.
So
should
we
spend
some
time,
I'm
sure
what
these
issues
are
actually
and
that
they
are
linked
in
link
produced
events
to
consume
events,
so
this
might
be
related
to
the.
I
wonder
if
this
is
the
same
type
of
linking
that
eiffel
has
I'm.
D
D
D
We
define
a
starting
point
for
a
pipeline
and
at
that
starting
point,
we
create
a
unique
identifier
and
that
unique
identifier
is
always
available
throughout
every
message
that
I
sent
as
part
of
that
pipeline.
I
wonder
if
this
is
the
same
as
flow
context
in
iphone,
because
flow
context
is
basically
created
once
in
the
beginning,
when
you
sort
of
do
the
first
thing
in
a
flow
right.
E
Yeah
and
then
you
refer
to
that
full
context
with
the
rest
of
the
developments
yeah,
but.
D
D
E
But
I
think
that
the
the
three
new
ones
that
they've
introduced
there
that's
the
link
basically
in
our
world,
so
basically
yeah,
not
everyone
knows
eiffel,
but
in
eiffel
we
have
links,
so
we
can
link
to
other
events
and
then
we
have
a
link
type
and
then
we
have
basically
just
an
id,
and
that
is
the
id
field
to
the
previous
events.
E
D
Here
where
we
have
the
type
of
the
event
that
we're
sending.
But
I
would
like
the
event
that
we
reacted
on
as
well
like
did
we
start
from
a
something
being
deployed,
or
did
we
start
from
a
source
change
or
something
like
that?
That's
overkill
from
a
functionality
perspective,
because
if
you
have
a
database
with
all
events-
or
you
really
need
this
part
and
you
can
find
exactly
what
you're
you're
looking
for
so
the
event
type
would
be
just
as
a
human
trying
to
understand.
E
Yeah,
I
I
get
the
point
for
type.
I
guess
the
the
link
type
gives
a
little
bit
more
information
because
then
in
so
again
I'm
referring
back
to
eiffel
sorry
for
those
who
are
not
comfortable
with
it.
We
have
link
types
on
the
iphone
describing
and
those
link
types.
E
It
depends
on
not
all
link
types
of
valid
by
between
all
the
events,
so
by
looking
at
the
the
link
type,
you
can
actually
see
what
event
we're
actually
dealing
with.
D
I'm
thinking
like
here,
for
course,
we
have
legal
targets
any
so
so
this
could
literally
be
any
event
and
the
only
way
you
can
figure
out
what
type
of
event
it
was
is
by
following
that
identifier
into
some
database
or
some
service
that
has
all
the
events
and
asking
it.
What
type
of
awareness
was
this.
D
Yes,
but
that
would
literally
only
help,
though,
who
are
just
looking
at
the
raw
events,
and
no
one
will
be
using
that
or
will
be
doing
that
in
a
functional
system.
Then
they
will
always
go
through
this
database.
That
has
all
the
events,
and
that
will,
of
course
tell
you
exactly
what
what
it
was.
So,
I
think
yeah.
Maybe
it
is
something
that
we
could
have
that
could
be
turned
off
somehow
we
could
use
it
for
when
we
ourselves
are
like
building
building
things,
and
then
we
can
turn
it
off
in
production.
E
Yeah,
that's
also
a
data
race,
but
yeah.
E
D
D
D
D
I
wonder
if
subject
is
a
mandatory
field
in
cloud
winds?
Do
we
know
that.
D
So
so
you
can
understand
where
event
should
go
without
looking
into
the
data.
Maybe.
D
D
D
Question
yeah,
I
think,
probably
yeah.
We
probably
shouldn't
spend
too
much
time
trying
to
understand
what
andrea
is
after
when
he's
not
here,
but
we
could
do
this,
then
that
we,
we
put
our
comments
in
this.
These
two
issues
and
let
andrea
clarify
things,
but
I
mean
both
of
them
seem
reasonable
to
me.
D
E
But
I
prefer
to
have
the
previous
events
only
like
one
one
step
back.
D
E
So
if
I,
if
I
got
the
idea
from
from
captain,
they
want
to
have
a
context
that
follows
the
whole
chain
through.
So
you
basically
have
one
context
and,
like
you.
E
Id
or
something
and-
and
that
was
part
of
the
whole
entire
flow,
and
so
they
wanted
to
create
a
context,
and
then
I
think
it's
using
that
context
to
group
all
the
events
together,
but
in
my
head
at
least
it
becomes
a
problem.
If
you're,
if
you're
doing
fanning
and
fan
outs,
we
have.
We
have
created
an
example
of
that
one
in
the
use
case,
page
on
the
hackie
md
document,
the
use
case
page
of
the
founding
fan
situation,
which
we
don't
really.
D
That
was
finished
that
I
need
to
wait
for.
Was
that
part
of
my
fan
out,
or
was
it
some
other
one's
final
and
the
way
I
would
do
that
is?
I
would
require
all
the
funny
things
to
share
the
same
context,
identifier
that
that
I
have
so.
I
will
ignore
anyone
that
has
a
different
context,
identifier,
because
that
was
not
part
of
my
fan
out.
D
E
Yeah,
okay,
so
for
you
it
was
it
was.
You
want
to
get
the
oh
yeah,
which
events
are
grouped
together.
Basically,.
E
Yeah,
that's
interesting,
so
I've
pasted
a
link
there
to
the
use
case
document.
D
E
So
here,
for
example,
we
have-
this
is
a
situation
where
you
have
a
bunch
of
of
like
libraries,
integrating
into
other
libraries
and
then
projects,
and
then
you
have
consuming
projects
here
and
and
at
this
situation
we
don't
know
where
we
would
use
a
context.
E
But
here
we
see
we
we
need
to
have
links
in
order
to,
because
it's
very
hard
to
say,
okay,
which
context
should,
for
example,
like
the
pipeline
from
libraries.
Three
should
I
have
libraries,
one,
the
library's
two
contexts
and
so
on.
D
D
And
then
internally,
it
decides
yeah
for
efficiency's
sake.
I
can
do
these
things
in
these
three
things
in
parallel,
but
I
don't
want
to
continue
until
all
these
three
things
are
done
and
then,
if
you
have
like
one
instance
of
of
library,
three
project
pipeline,
starting
because
library,
one
project
pipeline
is
done
and
another
starting
because
library
two
project
cycle
is
done.
D
You
don't
want
to
because
now
you
have
six
activities
running
in
parallel,
three
in
in
one
group
and
three
in
the
other,
and
you
want
to
make
sure
that
that
when
you
wait
for
something
to
fan
in,
they
actually
have
to
come
from
the
same
group,
and
that
is
where
that
context
makes
things
a
little
bit
simpler.
But
of
course
you
could
also
do
it
by
tracing
backwards
by
yeah,
looking
at
parent
events
or
source
events
until
you
reach
their
common
starting
or
reach
their
fan.
Art
point.
E
In
that
situation
yeah,
I
I
get
both
ideas,
but
I
hope
I'm
not
sounding
like
I'm
trying
to
cut
myself
now,
but
it
feels
more
logical
to
have
some
kind
of
that.
The
events
coming
from
one
pipeline
will
will
have
some
kind
of
common
identifier,
so
you
listen
for
them.
D
Different
aspect
of
fan
out
and
findings,
yeah.
E
And
put
it
there,
because
that
would
be.
That
would
be
good.
D
Yes,
yeah,
that's
good,
that's
good,
because
this,
both
or
if
they
are
different
types
of
fan
and
finite,
which
I
think
then
both
are
things
that
need
to
be
considered
and
would
be
interesting
to
have
nice.
Let's
see
yeah
good.
So
is
there
anything
more
we
would
like
to
go
through
today.
I
think,
as
I
said
not
too
much
point
digging
deep
into
these
issues
when
andrea
is
not
here,
but
we
can
instead
do
homework
and
prepare
some
questions
for
him.
Okay
and
later.
E
Yeah
did
you
go
through
the
last
thing?
Okay,
I
was
late
into
the
meeting
because
I
wasn't
technically.
D
Very
no,
we
didn't
actually
go
through
it
andre.
I
just
mentioned
it
and
he
said
he
didn't
feel
that
we
needed
to
go
through
it,
but
or
that
he
didn't
need
to
go
through
it
because
he
had
not
so
much
time,
but
this
is
basically
it
so
this
I
haven't
used
this
part
of
github
before,
but
it's
part
of
some
project
planning
type
thing.
D
So
yeah
and
andrea
has
added
that
to
the
roadmap.
Now
it
doesn't
necessarily
need
to
go
into
the
v0.1,
but
it's
part
of
the
2022
roadmap.
E
Yeah,
so
that's
good
yeah,
just
thinking
out
loud
here
we
talked
about
how
the
events
are
shuffled,
putting
data
inside
the
data
object
and
not
in
the
in
the
root.
Yes,.
D
E
D
E
D
B
D
Yeah,
so
if
there's
nothing
else
for
today,
then
I
suggest
that
we
wrap
up
and
try
to
have
a
look
at
these
issues
and
roadmap
on
our
own
time.