►
From YouTube: CDEvents Working Group (EMEA/AMERICAS) - Feb 7, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
D
With
redesign
in,
if
you'd
like
to
in
the
meanwhile
just
sharing
a
link
to
the
notes.
D
Right,
it's
very
fast,
so
let's
get
started.
What's
the
main
one
to
the
City
events
working
group,
my
name
is
Andrea
brittali
I
work
for
IBM
I'm
in
GNT,
so
we
have
a
few
things
on
the
agenda
for
today.
So
let's
get
started
first
I've
seen
in
the
link
to
the
roadmap,
someone
added
should
we
use
the
GitHub
roadmap
View.
E
Yeah
I
thought
it
was
released
just
a
week
ago
or
something
from
GitHub,
so
a
new,
a
new
view
in
the
project
part
of
the
GitHub
project.
So
today,
which
might
be
useful
to
see
the
the
burn
down
or
whatever
we
call
it
for
certain
release.
D
D
Oh
okay,
I
did
not
see
any
specific
action
item
from
last
week.
E
I,
don't
remember
if
I
did.
Let
me
check
that
and
comment
on
it
afterwards.
B
We
also
had
the
I
think
the
meeting
last
week
right
for
for
the
GitHub
RFC
for
Spinnaker.
That
was
an
action
item.
I,
don't
think
it
was
for
last
week,
but
it
was
a
week
prior.
It
just
took
me
a
little
bit
to
set
up
that
meeting
and
then
what
else
yeah
I
haven't
heard
too
much
from
jillander
about
it
about
actually
addressing
the
the
feedback
that
we
had,
but
but
yeah
we
we
did
have
that
meeting.
It
was
went
pretty
well.
D
Yeah
thanks
man,
I
don't
know,
do
you
want
to
do
say
a
couple
of
words
about
yeah.
B
Give
it
a
quick
summary
yeah
yeah,
so
we
had
a
a
meeting
to
integrate
or
start
thinking
about
the
integration
of
CD
events
within
Spinnaker.
B
If
you
guys
aren't
familiar
with
what
Spinnaker
is,
it
is
a
continuous
deployment
service
and
jillander
is
also
part
of
the
city
of
EDS.
Was
writing
a
spec
in
RFC
that
that
me
and
a
few
others
at
Smacker
were
reviewing?
And
oh,
we
decided
to
have
a
meeting
to
kind
of
get
an
idea
or
to
kind
of
Drive
what
we
were
expecting
from
the
RFC,
because
it
felt
like
there
was
a
little
bit
of
talking
and
things
kind
of
like
going
past
one
another.
B
So
we
kind
of
cleared
everything
up
and
we
simplified
it.
Rather
than
being
this
massive
RFC,
where
we
need
to
introduce
this
idea
of
event
bus,
it's
going
to
be
limited
to
an
event,
type
called
CD
event
type,
that's
gonna
live
in
one
of
the
or
that
needs
to
be
defined
in
one
of
the
services
which
that
service
is
called
Echo,
but
the
CD
event
type
would
be
able
to
ingest
any
whatever
CD
event
and
then
do
the
procreate
action.
B
So
that's
what
kind
of
came
out
of
that
meeting
as
before
it
was
kind
of
the
the
RFC
didn't
really
talk
about
how
things
were
going
to
be
integrated
with
Vince
America.
So
this
was
a
huge
step,
so
we're
just
waiting
for
that
RFC
to
be
updated
and
once
it
is,
is
updated.
We
should
be
able
to
start.
B
You
know.
I
I
can
get
that
ball
rolling
to
get
that
merged,
and
then
we
start
looking
at
actually
implementing,
which
will
be
a
pretty
big
win
for
both
CD
events
and
Spinnaker.
So
I'll
find
you
the
link
to
to
put
in
there.
D
Thanks
Ben
did
we
try
to
remember?
Do
we
agree
on
generating.
C
Events
I'm
sorry,
I
I
just
had
a
quick
question
about
that.
Hey
Ben
question
for
you:
what
is
what
does
that
do
for
Spinnaker
users,
I'm
playing
kind
of
Colombo,
dumb
here,
I
think
I,
know
the
answer
to
this,
but
I
wanted
to
understand
what
does
that
do
for
Spinnaker
users,
so.
B
C
Well,
it's
actually
both
I
mean
they're,
both
stakeholders
in
Spinnaker,
right
and
but
I.
Imagine
it's
probably
the
Spinnaker
administrators
that
are
really
interested
in
that
right.
B
Right,
okay,
so
kind
of
give
so
yeah
really
two
questions
here
for
each
for
each
party,
so
I'll
go
with
the
first
one,
which
is
the
end
Spinnaker
users.
The
guides
are
deploying
the
software,
because
I
feel
like
it's
probably
going
to
be
a
little
bit
more
transparent
there,
but
the
benefit
the
main
benefit
there
is
that
they
can
plug
in
any
system
in
their
ecosystem
that
uses
CD
event
to
be
ingested
by
Spinnaker.
B
So
if
they
have
some
CI
system,
for
example,
that
uses
CD
events,
it
would
be
able
to
send
it
to
Spencer
and
just
be
able
to
use
it,
and
you
know
which
is
kind
of
the
same
benefit
for
for
the
actual
administrators
of
maintainers,
is
that
we
now
or
Spinnaker
is
now
able
to
talk
to
or
the
goal
is
to
be
able
to
talk
to
more
systems
without
much
more
effort.
Is
the
end
goal
there.
B
So
if
we
get
CD
event
into
things
like
you
know,
like
other,
like
Jenkins,
for
example,
GitHub
we
don't
have
Spinnaker
maintainers,
don't
have
to
do
anything,
it's
just
automatically
supported
by
this
new
endpoint
that
supports
CD
events.
B
So
that's
the
end
goal
is
being
able
to
not
really
have
to
add
a
new
layer
for
every
new
service
that
that
wants
to
be
able
to
talk
to
Spinnaker,
so
that's
kind
of
like
what
it
comes
down
to
because
right
now,
if
I
don't
know,
if
you're
familiar
with
the
code
base,
there's
a
GitHub
type,
there's
a
kubernetes
type,
there's
a
Jenkins
type.
B
You
know
so
there's
all
these
different
types,
but
the
goal
is
kind
of
like
have
all
these
different
stakeholders
or
these
CI
systems
talk
the
same
language
for
for
Specter
to
be
able
to.
You
know
you
know
be
able
to
do
what
it
needs
to
do
so
that
that's
kind
of
the
goal
for
for
both
fronts.
There.
C
Okay,
that
makes
perfect
sense,
so
this
will
be
Spinnaker
listening
for
CD
events
and
then
doing
a
thing:
okay,
so
that
presupposes
or
or
requires
that
you
mentioned
GitHub,
I,
assume
GitHub
actions
and
Jenkins
sending
CD
events,
messages
right
right.
B
C
Okay,
all
right
makes
perfect
sense.
I
I
can
very
much
appreciate
the
Bob
Metcalf.
Well,
what
was
it?
The
Metcalf
law?
It
was
n
to
X
or
something
like
that.
Something.
C
E
B
There
yeah
so
this
RFC
is:
we
decided
to
make
it
a
lot
smaller
as
a
first
step.
So
this
is
this
going
to
be
speaker
ingesting
and
then
once
that
gets
you
know
approval,
because
I'd
rather
work
in
chunks
first,
rather
than
try
to
submit
this
whole
RFC
where
people
are
trying
to
poke
and
dealt
with
ideas,
I'd
rather
get
this
part
right
and
then
expand
on
it.
So
that's
kind
of
that's
kind
of
the
the
starting
point
and
then
yes,
you're
absolutely
right.
B
The
goal
is
eventually
is
to
have
cd
events
across
all
the
microservices
within
Spinnaker,
where
they're
able
to
do
all
these,
you
know
they
could
plug
in
whatever
microservice
that
they
want,
or
you
know,
use
whatever
pipeline
orchestrator
that
they
need
and
and
be
able
to
do,
the
things
that
they
need
to
do.
But
yeah
I
feel
like
that's
a
little
bit
longer
in
the
future,
so
I
wanted
to
start
small
and
so
that's
kind
of
the
plan.
Yeah.
C
Build
momentum
get
a
quick
win,
hey
so
Jenkins
I
I
heard
from
another
meeting
another
CDF
meeting
that
there
is
a
Jenkins
plug-in
for
CD
events.
Is
that
true.
D
There
is
a
Jenkins
plugin
for
cloud
events,
not
for
CD
events,
but
there
is
an
interest
from
end
user
from
fidelity.
Today's
investment
is,
they
use
Jenkins
and
they
use
events,
so
they
are
interested
in
adopting
City
events
and
possibly
contributing
a
City
events
plugin.
D
So
yeah
I
need
to
sync
with
Jared
on
that,
and
one
thing
that
we
were
discussing
as
well
since
there
is
a
Jenkins
submit
in
an
application
to
be
a
mental
Organization
for
gsoc.
D
D
D
It's,
of
course,
that
we
could
yeah.
We.
Of
course
we
could
have
some
one
from
from
our
team,
but
if
Fidelity
is
interested
in
in
this,
maybe
they
could
be
interested
in
mentoring
as
well.
C
B
Yeah
definitely
I'm
interested
anything.
You
know
that
we
can
expand
to
make
it
useful
for
Spinnaker.
You
know
and
other
CI
tooling.
You
know
I'm
all
I'm
all
about
it.
So
yeah.
E
D
Yeah
since
I'm
in
both
communities
and
definitely
will
will
drive
that
right
now,
the
the
main,
the
main
limitation,
is
really
to
have
someone
to
implement
it.
So
I
brought
the
I
brought
the
discussion
up
some
time
ago
and
said
that
it
would
be
interesting
to
Implement
City
events
and
the
feedback
was
was
positive
at
the
time.
So
I
don't
think
I
I
would
not
expect
any.
You
know
pushing
back
on
on
on
this,
but
yeah.
D
It's
mainly
a
matter
of
having
someone
focusing
on
implementing
that
feature
which
I
really
would
like
would
like
it
to
be
me
since
I've
done
quite
some
work
around
that
area
of
Eventing
inter
but
right
now,
I
find
myself
a
bit
short
in
time.
D
E
D
A
D
Was
great
so
definitely
you
know
things
going
on
for
the
different
projects
just
to
complete
the
list,
the
janky
necks.
There
was
some
interest
expressed
in
implementing
City
events
as
well,
but
yeah
I've
not
heard
anything
since.
D
Says
Jenkins
also
relies
on
tecton
there's
there
might
be
a
dependency,
not
necessarily
but
I
think
there
could
be
a
dependency
to
the
implementation
on
techno
site
or
we
could
collaborate.
So
that's
something
we
we
could
admit
some
way.
We
could
find
someone
to
work
on
this.
E
D
E
Someone
has
edited
it
I,
don't
know:
Brad,
oh
Brad
mccoyed.
It
yeah
good.
D
D
All
right
anything
else
on
projects
and
City
events.
D
D
There
is
a
new
version
of
the
pr
from
OLED
I
hope.
That's
the
right
pronunciation
of
his
name.
So
I
did
that
sorry.
D
So
I
did
an
initial
review
and
I
think
the
dental
model,
the
model
that
they
are
proposing.
There
looks
okay
to
me:
I
need
to
have
a
deeper
look
into
the
Json
schemas.
B
B
So
if
we
do
decide
to
go
with
abort,
we
probably
want
to
make
sure
that
anywhere
that
we
have
like
pending
or
canceling,
or
you
know
things
are
synonymous
with
that
word.
We
probably
should
make
sure
they're
all
the
same.
D
Okay,
yeah
thanks
thanks
Ben.
Would
you
yeah
I
can
I
can
add
a
comment
mind,
adding
a
comment
on
on
that
yeah
I'm
all
for
consistency,
so
that's
totally
yeah,
but
basically,
if
anyone
else
is
interested
in
in
reviewing
either
I
need
more
comments.
D
So
hopefully
we
can
make
progress
on
these
as
well
offline,
and
maybe,
if
be
ready
for
for
the
next
meeting
and
I
know
the
test.
Cube
guys
are
interested
in
implementing
the
SDK
side
of
things
at
least
for
go.
D
D
Okay
next
thing-
and
this
is
part
of
the
plan-
features
for
the
next
release-
is
the
incident
events,
so
yeah
made
a
new
version
of
the
pr,
including
the
feedback
from
the
we
discussed
previously
yeah
I
think
there
is
some
rewarding
that
then
it
still
need
to
address
here
in
the
in
this
chapter,
based
on
your
on
your
feedback
demo.
E
We
talked
about
how
to
associate
one
or
multiple
detected
events
with
maybe
one
reported
or
one
resolved
event.
Yeah.
D
D
Sorry
I
got
a
bit
of
a
cold
I.
Think
yeah,
you
make
a
great
Point
ml
that
we
need
to.
D
D
I,
don't
know
that
this.
This
is
something
that
we
need
to
solve
in
this
first
iteration
of
The
Coincidence
events,
but
also
would
be
for
now
to
just
make
this
paragraph
more
specific,
and
then
we
can
improve
on
the
incidence
events,
add
more
yeah.
D
E
D
D
But
for
now
we
don't
have
knowledge
into
the
events
about
that.
So
the
only
way
you
can
associate
events
is
that
you
can
have
a
reported.
It's
a
reported
event
which
links
to.
A
E
E
D
C
D
Apart
from
that,
I
mean
I've
done
a
few
extra
things
in
this
PR,
which
I
think
would
be
good
to
then
reuse
and
extending
the
in
the
rest
of
the
events.
So
in
the
schemas
I
started
using
the
ERI
reference
format
in
the
Json
schema
like
we
discussed,
and
we
have
the
type
within
the
content.
I
said
because
it
takes
a
specific
value.
D
Yeah
I
think
these
are
the
two
things
I
I
added
in
the
schema
and
the
other
thing
that
I
added
is
this
examples
folder,
where
basically
provide
one
full
example
for
every
event,
type
based
on
some
feedback
as
well?
We
we
got
that
it
would
be
useful
to
have
more
examples
of
City
events.
D
D
Okay,
so
I'll
probably
update
pretty
soon
there's
this
paragraph
As
we
discussed,
and
hopefully
we
can.
We
can
move
right
with
a
with
a
PR
and
then
the
next
step
would
be
to
for
me
to
implement
this
in
the
on
the
SDK
side,
so
that
we
are
able
to
produce
these
in,
at
least
for
the
gelastic
cape.
D
D
D
D
That
could
be
several
workflows
identified
that
may
might
intersect
and
overlap,
and
so,
depending
on
the
level
of
obstruction
that
you're
looking
at
things,
you
may
see
different
workflows,
so
you
can
have
a
cicd
workflow.
That
starts
from
a
change
and
you
know
test
and
build
and
and
deployment,
but
you
might
have
a
different
workflow,
a
more
extended
one
that
starts
from
the
business
idea
or
yeah.
D
And
motivation
when
we
have
this
is
today
we
have
a
subject
and
predicate,
but
this
is
not
necessarily
enough
to
there's
not
enough
information
to
identify
these
workflows
in
the
last
show
and
goals
will
be
basically
specified.
What
are
the
changes
required
to
contact
subjects
and
bindings
describe
workflows
in
the
primer,
identify
type
of
workflows
that
we
want
to
support?
So
what
are
the
use
cases
that
we
want
to
address
for
this?
Connecting
events
and
include
examples,
known
goals
would
be
to
develop
an
optimal
event,
selection
logic
or
to
support,
centralized
workflows,
orchestrator.
D
Yeah
so
I
got
some
use
cases
and
requirements
requirements.
A
workflow
May
spawn
multiple
tools.
A
workflow
is
not
limited
time.
D
If
a
producer
includes
event
receiving
capabilities.
The
event
receipt
must
provide
enough
information
to
produce
new
events,
that
propagate
existing
workflows
and
an
event
may
be
long
not
below
below
to
multiple
workflows
and
work
was
made
final
out.
D
And
related
work
is
the
activity
linking
from
iPhone,
of
course,
and
also
include
the
distributed
tracing
over
Cloud
events.
Maybe
something
that
we
could
do
you
use.
D
And
yeah,
and
so
I
think
there
there
are
a
few
Alternatives.
There
are
a
few
ways
we
could
address
this.
The
first
alternative
is
to
reuse,
Something,
Like,
Trains
context,
Trace
context,
so
Trace
context
is
a
w3c
recommendation
that
defines
ways
to
propagate
a
trace
over
HTTP,
and
there
are
specific
address
defined
for
cloud
events
to
do
that.
To
do
that,
and
so
we
could
reduce
something
like
a
Trace
or
City
events.
D
D
Yeah,
so
there
are
some
limitation
there
and
the
other
limitation
that
I
have
not
written
down
yet
is
that
basically,
this
would
rely
heavily
on
the
cloud
events
binding,
so
it
will
be
undefined.
What
happens
when
we
move
to
other
kind
of
Landings
foreign.
D
D
But
but
again
the
idea
with
these
ideas
would
be
that
if
an
event
producer
receives
events
that
can
play
contain
workflow
IDs,
then
it
must
include
them
in
the
outgoing
messages
and
we
could
have
a
concept
of
also
a
semantic
Associated
to
this
to
specify
what
is
the
relationship
between
input
and
output,
or
we
could
just
have
like
a
plain
list.
B
Yeah,
and
also
in
addition
to
that,
one
thing
that
I
think
that
would
be
nice
to
have
is
potentially
having
the
the
things
that
you
want
to
support
like
the
fan
in
fan
out
type
of
use
cases
and
what
the
end
result
is
expected.
So,
if
we
fan
out-
and
we
fan
in
what
does
the
CD
event
that's
being
received,
what
does
that
look
like
what
I
mean
by
that
is
like?
Does
it
have
all
the
the
things
I
fanned
out
like?
What
does
the
fan
out?
B
Look,
like
you
know,
does
it
call
all
contain
IDs
as
well
so
I'm,
just
kind
of
curious,
like
what
the
end
goal
for
for
the
individual
use
cases
like
what
we
expect
them
to
look
like.
A
D
Yeah
yeah,
that
makes
sense
so
I
think
in
a
way
this
is
a
similar
to
the
oh.
It
goes
a
little
bit
towards
the
iPhone
links
concept.
D
The
main
difference
here
is
that
the
link
is
not
to
an
event
ID
rather
to
a
third
kind
of
ID,
which
is
this
new
workflow
ID,
so
that
is
kind
of
shared
knowledge
across
the
the
the
tools.
D
So
that
means
that
the
tools
may
decide
then
to
start
a
new
workflow
by
generating
an
ID.
If
there
is
none
or
it
might
also
start
a
new
workflow,
even
if
there
is
already
a
workflow
that
wants
to
start
the
original
one
or
if
a
tool
and
I'm
receiving
events
from
multiple
sources
and
I
want
to
generate
a
single
event,
I
could
include
all
the
workflows
IDS
in
there
but
yeah.
So
the
reference
is
is
not
to
the
event
ID
as
it
is
in
in
the
case
of
iPhone.
E
D
Yes,
I
think
it
is,
it
is
basically.
B
So
one
thing
that
I
might
do
Andrea
is
maybe
post
some
images
of
like
this
is
a
request
going
in
and
being
fanned
out.
What
do
we
expect
when
the
things
fan
in
to
look
like
you
know
and
and
just
get
some
discussion
around
that
because
I'm
kind
of
curious
like
what
what
we're
thinking
the
the
end
result
of
the
Fanning
in
portion
is
going
to
look
like.
D
Right
I
mean
for
an
example
of
fanin
I
think
we
had
some
presentation
from
the
SAS
folks
presenting
how
they
use
events
today
and
then,
basically,
they
have
one
piece
of
software
that
they
use
to
orchestrate
events
and
it
allows
them
to
to
express
policies
the
goal
across
events.
So,
let's
say,
if
I
received
an
event
about
I,
don't
know
a
certain
piece
of
code
being
merged
and
also
I
received
an
event
about
a
test
being
executed
successfully
and
I
received
an
event
about
an
artifact
being
signed.
D
B
Okay,
interesting
so
there
they're
going
to
be
waiting
for
three
events:
okay,
yeah
I'll
have
to
think
about
because
it's
kind
of
it's
kind
of
an
interesting
use
case,
because
I'm
just
wondering
like
again
like
how
CD
events
is
gonna
work
with
that.
But
yeah.
E
E
E
D
Okay
and
one
one
characteristic
of
this
approach
is
that
it
relies
on
one
or
more
events
which
are
available
locally
to
to
the
producer
and
and
their
Global
IDs.
But
it
does
not
require
to
have
access
to
to
a
database
like,
let's
say,
of
all
the
event,
with
their
IDs.
D
The
the
last
case
is
that
we
use
event
links
like
similar
to
what
iPhone
does
so,
instead
of
including
a
link
to,
instead
of
including
a
global
ID
that
we
we
find
we
receive
from
our
incoming
messages.
We
include
the
ID
of
the
incoming
message
into
the
outgoing
message
and
Associates
semantics
to
it,
so
it's
very
similar.
D
It
requires
the
event
IDs.
Of
course,
it
only
requires
the
IDS
of
the
events
that
are
associated
with
the
outgoing
event,
so,
in
terms
of
context,
is
also
similar
to
the
the
previous
case.
So
it
would
be
interesting
to
to
better
understand
what
are
the
differences
and
advantages
and
disadvantages
between
the
two
approaches,
and
so
I,
don't
know
if
you
Emil
or
Ben
Robert
have
any
context
or
any
further
ideas
on
this.
B
Okay,
yeah
that'd
be
really
help
because,
like
I'm
very
familiar
with
how
tracing
works
with
this
Trace
ID,
spanneries
and
whatnot,
but
I
don't
have
too
much
context
on
Eiffel,
which
I
know
you've
worked
on
quite
a
bit
of
meal,
so
yeah
I
can
once
you
fit
write
that
portion
I
can
I
can
read
it
in
and
kind
of
think
about.
Some
pros
and
cons
between
the
two
yeah.
D
Sorry,
I'm,
muted
and
talking
to
myself,
so
there
is
a
link
to
activity
linking
in
iPhone.
That's
also
some
related
work.
If
you
want
to
start
looking
at
that,
then
it
already
provides
some
good
context
about
about
this,
but
yeah
cool
cool,
we'll
take
a
look
so
foreign.
D
I
would
really
like
for
us
to
to
be
able
to
decide
at
least
for
minimal
approach
forward,
step
forward
on
this.
D
It
could
even
be
that
we
support
both
approaches-
foreign
but
yeah
yeah,
exactly
I
would
prefer
one
if,
if
we
see
that
one
does
not
work
for
all
the
use
cases,
we
definitely
need
to
have
more
than
one
we.
We
could
consider
it,
but
yeah
I
would.
B
Yeah
I
was
gonna,
say,
let's,
like
so,
let's
say
next
Sig
meeting
we'll
make
we'll
have
a
meal
right,
his
section
on
with
Eiffel.
We
can
then
discuss
the
two
different
implementations
and
designs
and
then
the
following
Sig
meeting.
We
can
make
a
final
decision
I
think
that's
an
adequate
amount
of
time
between
choosing
the
two
and
it'll
give
me
enough
time
to
read
up
on
I4
as
well
as
look
at
Emil's
notes
and
his
explanations.
If
that
works
for
you
Andrea
and
a
meal.
E
Yeah
I
hope
I
will
be
able
to
to
provide
that
in
the
needed
time
frame
and
I
can
just
note
that
the
private,
the
main
way
to
connect
events
is
using
these
links,
but
then
there
are
also
some
kind
of
context.
Ids
there
as
well
so
I
mean
we
have
the
in
some
of
the
events.
At
least
we
we
use
contexts
which
we
don't
call
it
context,
but
anyway
as
well
to
some
to
relate
to
other
objects
or
subjects
we've.
E
B
Cool
cool,
so
what
do
you
think
Andrea
so
like
within
two
Sig
meetings
from
now?
We'll
actually
have
a
choice
on
Trace
context
versus
ifills
links
proposal
and
go
that
route
I'd
rather
have
like
a
good
deadline
because,
like
I
I,
you
know
don't
like
saying
you
know
like:
oh,
you
know
we
need
to
make
a
choice
and
then
you
know
four
weeks
comes
out
and
we
still
haven't
made
a
choice.
So
I
I
like
to
at
least
have
a
deadline,
so
we
can
kind
of
at
least
shoot
for
it.
B
D
Yeah
no
I
mean
that
it
works
for
me.
I
think
we
have
been.
We
have
this
open
discussion
for
for
quite
some
time
now,
and
I
would
really
like
for
us
to
to
proceed,
and
you
know
take
at
least
initial
decision,
so
we
can
start
experimenting
with
it.
You
know
building
some
pocs
integrating
in
into
some
tools
and
you
know,
and
if,
if
we
find
out
that,
unfortunately
we
took
the
wrong
direction,
we
can
change,
but
we
need
to.
We
need
to
make
a
decision
to
be
able
to
start,
and
you
know.
E
For
experimenting,
it
will
be
possible
to
use
our
Custom
Custom
data
right.
It's
called
that
object.
In
the
events
I
mean
we
could
include
something
that
we
call
a
link
or
something
or
a
workflow
ID
in
the
custom
data
section
and
thereby
try
it
out.
If
you
would
have
some
SDK
that
supports
that
that
custom
data
this
would,
of
course,
be
optional
to
use,
and
then
we
shouldn't
expect
consumers
to
understand
it
since
it's
custom,
but
if
we
want
to
play
around
with
it,
it's
I
mean.
D
Yeah
yeah,
that's
true,
and
indeed
I
mean
we
could
decide
that
we
want
to
start
with
a
certain
approach
and
we
could
include
it
in
the
in
the
custom
data
to
begin
with
and
there's
some
support.
Maybe
some
experimental
feature
in
the
in
the
SDK
that
allows
you
to
to
use
it
for
the
SDK,
but
it
actually
lands
into
the
custom
data.
E
D
D
D
E
E
B
B
But
if
we
want
you
to
expedite
this
and
make
it
for
the
next
Sig
meeting
and
then
make
it,
the
following
meeting
I
can
make
it
I
I
can
you
know,
take
you
know,
make
sure
that
I
attend
that
I
mean,
but
I
can't
attend
that
meeting.
Basically
like
every
single
way,
it's
gonna
destroy
my
sleep
schedule,
but
but
if
we
do
want
to
expedite
this
I'm
totally
okay
with
doing
that,
yeah.
A
B
Okay,
let's,
let's
do
the
two
weeks,
then
let's
do
the
following
Sig
meeting
and
then
the
next
week
sign
being
so
two
weeks
from
now.
Does
that
does
that
work
for
a
meal
and
Andre
I
know
I
I'm
pointing
out
a
meal
because
he
actually
has
to
write
the
section?
So
that's,
why
I
wonder
it's
more
contingent
on
him
than
anything
else,
but
wanted
wanted
him
to
at
least
be
able
to
say
that's
enough
time.
E
So
then
you
mean
the
ordinary
Sig
meeting
that
we
have
on
Monday.
Where
are
we
right
right?
We
have
already
for
that
meeting
we're
playing
the
presentation,
I
believe
from
Cube
shop
on
the
is
testing
events
another
way
to
use
those
events,
so
we
will
not
have
such
a
in-depth
vocabulary
or
City
events.
Discussion
on
that
meeting,
it
will
be
more
on
such
a
big
level
on
events
in
general,
probably,
but
we
can
maybe
touch
upon
it
a
bit,
but
not
too
much
time
right.
E
B
E
B
Think,
as
long
as
we
have
like
a
little
bit
of
time,
like
five
minutes
to
talk
about
it,
to
give
a
quick
brief
update
on
what
you've
written
a
meal
that's
more
than
enough
and
then
the
following
week,
we
can
then
make
a
decision.
Does
that?
Does
that
sound
good,
we'll.
B
Okay,
perfect
all
right,
I'll,
just
my
calendar,
then.
D
All
right,
yeah
thanks,
that's
great!
Let's
try
at
least
and
let's
see
how
it
goes.
Hopefully
we
can
get
some
progress
on
this
all
right.
We
have
five
minutes.
Sorry,
four
minutes
left
so
in
terms
of
SDK
updates,
yeah.
We
don't
have
anyone
from
java
python
sdks
here
so
I
know
that
the
Java
SDK
PR
is
progressing,
but
it's
still
open
and
I.
Don't
know
if
anyone
has
any
other
information
about
that.
D
Yeah
for
the
golang
SDK,
there
is
no
update
right
now.
As
soon
as
we
get
some
progress
on
incidents
and
test
events.
I
was
planning
on
updating
that
accordingly
and
yeah,
so
python,
SDK
I.
Guess
we
still
waiting
for
Eric
to
let
us
know
if
there
is
any
any
progress
on
that.
D
D
Think
it
was
great
and
something
so
I'm
really
happy
to
see
us
doing
good
progress
and
every
working
group,
so
yeah
thanks
everyone
thanks
Robert
for
joining
us
today,
and
thank
you
good
to
see
everyone.