►
From YouTube: CDEvents / SIG Events Vocabulary - Nov 15, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
C
Yeah
as
I
hello,
everyone,
as
I
mentioned
on
the
on
slack.
Of
course,
there
can
only
be
here
for
about
20-25
minutes
today,
I'm
happy
to
facilitate
until
then,
and
if
you
have
anything
that
you'd
like
to
discuss,
please
feel
free
to
add
it
to
the
agenda.
D
C
Over
it,
let's
get
started
and.
B
Links
yeah
I
added
that
based
off
of
what
we
we
talked
about
last
week,
Andrea
yeah,
so
give
it
a
little
context.
So
I've
been
you
know,
thinking
about
links
for
for
a
while,
now
and
kind
of
like
wondering
you
know,
like
various
different
use
cases
and
on
in
talking
with
Andrea.
It
looked
like
one
of
the
things
that
was
kind
of
missing
was
knowing
some
of
these
use
cases.
B
So
I
I
went
ahead
and
you
know
kind
of
started
thinking
about
some
and
and
the
biggest
use
case
for
for
links
that
will
be
useful
for,
for
us
at
least,
is
the.
So
if
you
had
an
overarching
system
that
requires
knowledge
of
like
how
things
are
related.
You
know
like
related
based
off
of
like
events
like
you
know
that
have
like
semantic
meaning
the
links
is
actually
a
very
powerful
tool.
B
So,
if
you
have
like
a
you
know,
maybe
like
a
front
end
or
you
know
some
sort
of
like
graph
looking,
you
know
graph
front
end.
This
would
absolutely
be
useful
in
you
know,
being
able
to
represent
those
correlations
and
relationships.
So
one
of
the
things
that
so
I
I
think
that's
really
important.
B
You
know
being
able
to
give
people
the
ability
to
make
their
own
front
ends
like,
for
instance,
like
AWS
right
they
have
their
own
console.
It
would
be
nice
if
they
were
able
to
use
CDE
events.
You
know
to
show,
like
you
know,
causal
relationships
between
like
the
different
Services
very
easily.
So
so
I
went
back
to
the
GitHub
issue
to
kind
of
like
see,
you
know
what
was
talked
about.
B
What
was
thought
about,
and
one
thing
that
I
think
that's
kind
of
missing
is
the
is
kind
of
like
a
global
identifier.
To
kind
of
you
know
to
be
able
for
the
front
end
to
make
a
query
to
say:
hey
I
want
all
events
for
this
specific
identifier.
Rather
than
trying
to
you
know
back
propagate
or
you
know
back
Trace.
You
know
to
find
all
these
relationships.
B
I
think
overarching,
Global
IDs
is
absolutely
needed
for,
for
you
know
you
know
I,
guess
being
able
to
get
that
information
to
that
system
to
this
overarching
system.
So
that's
kind
of
like
where
I
kind
of
started
and
kind
of
like
where
I
ended
up
so
I
wanted
to
kind
of
get
your
guys's
thoughts,
especially
I,
know.
I
know
a
few
of
you
have
been
kind
of
back
and
forth
on
that
on
that
links,
discussion,
so
I
just
wanted
to
kind
of
get
everyone's.
B
You
know
thoughts
behind
it.
What
you
know
what
their
vision
for
it
is
and
and
kind
of
go
ahead,
and
you
know
potentially
add
to
it
right.
C
Thanks
Ben
so
about
the
global
identifier.
So
what
we
have
today
is
an
ID
field.
In
the
context,
I
mean
the
the
requirement
that
we
have
for
these
ID
field
is
that
it
should
be
unique
within
the
source
of
the
event
as
it's
hard
to
require
for
you,
you
for
an
ID
to
be
globally
unique,
but
at
least
the
combination
Source
plus
ID
is
meant
to
be
globally
unique.
C
That
helps
what
you
can
do
today
in
terms
of
correlating
events
is
using
the
subject.
So
let's
say,
if
you
have
events
about
certain
artifacts
and
the
artifact
as
an
artifact
ID,
then
you
can.
You
know
from
a
front
end.
You
could
look
up
all
the
events
related
to
a
certain
artifact,
but.
C
Yeah,
so
that's
of
course,
and
is
not
as
a
tight
correlation
as
you
could
get
from
yeah
yeah,
direct
links
and
and
that's
I,
think
why
we
we
considered
having
the
link
feature
so
I
think
the
reason
we
kind
of
postponed
at
this.
From
my
perspective,
the
work
on
that,
but
definitely
not
excluded,
is
that
yeah.
Providing
these.
These
links
puts
kind
of
a
stronger
requirements
in
terms
of
adopting
City
events
from
a
platform,
because
the
platform
needs
to
to
have
knowledge
about
this.
C
C
So
what
what
we
discussed
back
in
the
CD
events,
Community
Summit,
was
that
we
would
introduce
links,
but
as
an
optional
picture
of
the
of
the
protocol,
so
that
if
someone
wanted
to
have
events
links
in
their
events,
they
could
do
it
and
they
could
do
it
across
the
board.
So
for
all
type
of
events,
of
course,
but
not
put
it
as
a
mandatory
feature
of
the
protocol,
so
I
think
that
was
what
we
discussed
in
the
ecd
event:
Community
assignments,
but
yeah
I
think
I've
talked
enough,
so
I.
Let
everyone
else.
B
As
well
and
just
real
quick,
this
idea,
since
we're
already
on
this
page,
if
I
have
two
separate
CD
events
or
say
CD
events
service,
a
call
service
or
you
know,
send
the
CD
event
to
essentially
service
B.
Is
this
ID
gonna
be
the
same
or
are
they
going
to
be
different.
B
Okay,
so
yeah,
that's
that's
where
I
think
the
the
difference
is
is
when
I
say
Global,
ID
I
mean
like
a
global
ID
of
the
starting
event
gets
propagated
all
throughout.
You
know
to
all
the
other
events.
Essentially,
so
when
you
receive
event,
you
know,
n,
you
know
n,
plus
one
you
have
this
Global
identifier
and
whatever
system
is.
B
You
know
ingesting
that,
like
this
overarching
front-end
system
they'll
be
able
to
easily
tie
and
look
up
information
based
off
that
ID,
rather
than
trying
to
figure
out
like
how
everything
is
connected
right.
So
that's
that's
the
one
suggestion
that
I
think
that's
absolutely
needed
for
for
for
links
or
links,
or
maybe
in
the
spec
I,
don't
know.
A
I
mean
that's,
not
the
references
between
events,
it's
more
of
a
common
context,
ID.
Maybe
we
should
use
the
term
context,
but
I
would
rather
call
that
a
well
context
ID,
but
we
already
said
that
we
already
did
Define
that
term
yeah,
and
so
it's
a
common,
a
common
idea
across
all
events.
A
There
are
a
number
of
issues
with
that
I
would
say-
or
at
least
a
few
I
mean,
then
that
means
that
each
producer
of
these
events
needs
to
be
aware
of
that
specific
context,
which
is,
might
be
a
problem
in
itself
that
then,
that
context
needs
to
be
propagated
in
the
in
the
system
which
sums
all
these
events
to
each
of
the
event
to
the
same
same
ID
and
another
one.
Is
that
if
you
would
like
to
reference
a
very
old
event
and
long
time
ago,
how
could
you
know
that
now
I.
F
Yeah
you're
starting
much
because
because
it
doesn't
remove
the
fact
that
you're
going
to
have
the
original
ID
for
the
event.
So
if
you're
one
of
the
reference
an
old
event-
and
you
were
aware
of
that
event-
you'd
still
be
able
to
do
that.
I
think
what
he's
talking
about
is
more
of
a.
We
need
to
tie
a
bunch
of
events
together
to
represent
a
complete
system
or
an
end-to-end
pipeline
flow,
and
you
can
build
the
graph
through
links.
A
F
F
All
these
together
at
once,
the
challenge
here
is:
how
do
you
represent
a
the
inner
working
of
a
massive
system
of
CI
CD
workflows?
F
A
A
It
would
not
work
to
have
one
single
context
ID
for
all
events,
because
you
cannot
know
I
mean
you
might
want
to
do
group
the
events
in
different
ways
depending
on
what
consumer
you
are,
so
you
can't
say
when
you're
producing
something
you
can't
say
for
any
coming
consumer
of
this
information.
How
would
it
want
to
group
these
events?
What
context
is
relevant
when
grouping
these
events?
It
depends.
B
I
think
I
think
that's
fair.
You
know
you
can
group
them,
however,
but
I
think
the
main
use
case
of
like
how
people
are
going
to
group
things
is
the
starting
event
is
usually
gonna,
be
the
thing
that
how
is
gonna
propagate
and
that's
what
most
people
are
concerned
with
right
is
how
do
we,
you
know
associate
you
know
the
starting
event
to
this
end
event
right
and
you
do
that
with
well.
You
can
easily
do
that
with
I.
Think
a
unique,
a
global
identifier,
yeah.
A
But
but
there's
not
just
one
starting
event
and
one
finish
event.
So
of
course
you
probably
have
say
one
a
source
code
event,
probably
saying:
if
you
push
a
pull
request
to
GitHub,
then
then
that
is
in
some
way
a
start
event
for
your
flow,
but
that
could
eventually
trigger
thousands
of
different
artifacts
being
built.
So
then,
all
those
artifacts
should
have
the
same
Global
ID
and
then
some
of
those
artifacts
will
have
get
sources
from
otherwear
other
places
as
well.
A
F
That
would
be
a
different
flow
right,
because
if
you
said
that
this
would
be
building
those
thousands
of
artifacts
based
on
that
original
commit.
So
if
something
else
you
know
there
was
another
commit
that
started
another
build
of
a
thousand
new
artifacts,
even
snapshots.
That
would
be
another
event.
You.
A
A
F
D
A
A
Say
Downstream
to
Upstream
unable
to
reference
that
way.
F
As
well,
but
it
doesn't
remove
the
ability
to
do
that.
Having
that
Global
context
for
this
initial
end-to-end
build,
doesn't
remove
your
ability
to
use
the
other
IDs
that
are
already
in
the
spec.
This
is
only
an
introduction
of
a
way
to
do
something
Global
and
do
a
global
tracking
of
an
event
that
propagates
throughout
the
an
entire
system
right.
F
F
You
know,
I
can
have
one
CI
CD
process
like
you're,
saying
build
an
artifact,
but
what
if
those
artifacts
are
coming
from,
you
know,
different
business
entities
exactly
or
and
I
still
want
to
know
that
they
were
triggered
by
you
know,
entity
X,
but
that
also
had
Y
and
Z
do
builds
as
well
to
be
deployed
in
some
teams.
Environment
someplace
else
completely
different
right
and
it
just
is
gives
me
the
entire
context
of
especially
from
a
costing
perspective
right.
I
can
now
say:
okay,
this
event,
this
entire
event
costs
this
much.
G
G
References
and
then,
if
you
need
to
interpret
the
whole
context,
you
need
to
actually
go
through
and
reference
all
of
the
annotations
to
see
where,
where
it's
been
and
what's
happened
to
it,.
F
And
it's
really
for
the
analysis
side
of
it
right
and
the
visualization
side
of
it,
because
if
I
wanted
to
also
carry
that,
you
know
context
between
different
platforms
and
be
able
to
see.
What's
going
on
in
another
platform,
it'll
be
a
lot
easier
for,
like
a
UI
team
to
look
for
the
single
ID,
then
I
have
to
go
to
each
system
figure
out.
If
you
know
that
event
was
there
looking
at
the
links
and
and
it's
easier
for
them
to
logically
group,
what
they're
doing
in
their
mind
as
they're.
C
B
I
was
just
gonna
add
a
little
bit
here
as
well.
Is
that
the
this
goal?
Id,
isn't
necessarily
part
of
links
like
what
you
said
suggested
in
the
middle,
like
the
the
links
was
like
a
necessity
for
for
a
front-end
system
to
make
sense
of
links
essentially
without
needing
to
back
propagate.
So
I
just
wanted
to
make
that
clear,
because
you
did
make
the
distinction
that
they
are
two
very
different
things.
B
Sorry,
oh
wasn't
a
question.
I
was
just
making
sure
that
you
know
that
you
know
we
agree
that
links
is
a
different
thing:
Than
This
Global
ID,
because
I
I.
G
F
B
A
I
think
I
would
just
as
a
reference.
There
is
something
called
I
think
it's
called
context
in
the
earth
CTX
in,
like
the
captain
event
protocol,
which
is
more
or
less
I,
think
what
you're
describing
that
all
the
events
sent
within
a
captain
context
with
will
have
the
same
context
ID
on
them,
if
I'm
not
mistaken,
yeah
and.
A
That
long
long
time
back,
if
we
should
have
the
same
instead
events,
but
we
didn't
at
that
time
at
least
include
it
for
now,
but
then,
of
course,
we
have
also
the
possibility
to
add
custom
data
through
events
and
it's
possible
to
have
this
already
as
a
producer.
So
they
don't
now.
If
you
have
a
certain
group
of
consumers
or
the
events
that
would
like
to
have
this
idea,
then
it's
perfectly
fine
to
edit
there.
B
And
and
and
I
think,
it's
really
important
so
like
tracing
has
solved
a
lot
of
like
these
issues
with
like
IDs
and
whatnot
and
I
think
we
could
really
benefit
from
like
getting
inspiration
from
like
how
they
solve
these
problems,
because
you
know,
if
tracing
didn't,
have
this
Global
ID
they
could
absolutely
do
back
propagation
right
or
you
know
back
tracing,
but
why
do
they
not
do
that
because
inefficient
right?
So
so
that's
why
they
have
this
Global
identifier
to
make
things
easy.
So.
A
B
Yeah
well
yeah,
there's
different
spans,
but
you
still
have
a
parent
ID
right
like
there's
still
This
Global,
there's
still
This
Global
identifier
somewhere
right,
whether
that's
it's
usually
like
in
the
actual
Trace
ID
itself
right.
The
first,
like
n
number
of
bytes,
is
actually
the
start
of
the
event.
If
you
will-
and
you
know
spans
just
kind
of
like
add
to
it
so
so
yeah,
but
you
know,
like
I,
said
that's
kind
of
different.
B
You
know,
like
we're
kind
of
you
know
going
off
in
the
weeds
here,
but
I
just
want
to
say
you
know
like
when,
when
we're
looking
at,
you
know
potentially
solving
this
problem.
Since
tracing
has
already
done
this,
it
might
be
a
good
idea
to
get
inspiration.
A
I
wouldn't
say
that
they
have
solved
the
whole
problem
there,
but
there
is
one:
that's
one
way
to
deal
with
with
regrouping
events
on
the
consumer
side
to
have
a
generic
spam.
Id
sure
that's
when
we
are
doing
it
I.
Don't
think
that
that's
so
delicious
that
we
want
to
solve
with
this
traceability
use
case
here,
but
maybe
we
should
have
a
separate
issue
for
for
that.
We
should
call
it
the
sperm
ID
to
not
conflict
it
with
the
complex
terms.
B
Yeah
yeah
definitely,
and
if
you
want
I,
can
go
ahead
and
create
that
issue,
because
I
I
agree
100
meal
it.
It
is
different
and
I
think
it
should
be
tracked
separately.
So
so
we
can
definitely
get
some
good
discussion
out
of
that
issue
as
well.
Perfect
yeah.
C
G
E
C
Think
it's
quite
clear
that
we
have
links
and
we
have
the
global
contact
or
spend
I
mean
we
can
decide
in
a
name,
I
think
for
the
context
span.
C
There
would
be
some
like
behavior
and
kind
of
conformance
as
well
that
we
would
need
to
identify,
because
if
that's
a
feature
that
you
need
to
rely
on,
then
we
would
need
to
have
a
system
and
say:
okay,
this
system
supports
City
events
or
the
system
supports
the
events
with
context,
because
you
know
it's
it's
different.
If
you
can
rely
on
the
context
that
e
being
propagated
or
not
being
propagated
right.
So
if
it's
something
that
is
there,
if
it's
something
that
you
want
to
use,
you
need
to
be
able
to
rely
on
it.
C
But
on
the
same
time
we
don't
necessarily
want
to
make
it
like
a
mandatory
feature
of
the
protocol.
So
I
guess
we
maybe
need
to
Define
different
profiles,
but
okay
I
mean
so
I
would
say
it's,
let's
start
with
an
issue,
and
if
you,
if
you
have
actually
a
proposal,
if
you
want
to
work
on
a
proposal,
then-
and
maybe
you
know-
highlight
some
the
make
a
use
case
and
show
how
the
this
could
look
in
the
protocol,
the
spec
and
how
it
would
solve
certain
Problems
by
any
means.
B
Yeah
yeah,
you
know
I'll
see
like
you
know
what
time
allows
me
to
do,
but
and
then
you
know,
and
then
aside
from
Like
This
Global
identifier
being
needed.
You
know
this
also
I,
think
kind
of
highlights
the
importance
of
links
also
being
needed
as
well.
You
know,
like
I,
said
that
overarching
system
needs
links
to
make.
B
You
know
to
make
those
relationships
because,
like
I
said
like
it
seems
like
like,
when
I
was
talking
with
you,
Andre
I
might
have
gotten
the
wrong
feeling,
but
it
sounded
like
it
was
kind
of
up
in
the
air
whether
or
not
links
was
still
a
viable
option.
So
I
just
wanted
to
make
it
clear.
It
is
a.
It
is
a
good
use
case
for
us.
C
Right
yeah,
yeah
I
would
need
to
to
think
a
bit.
You
know
what
what
what
are
the
specific
different
use
cases
that
you
can
solve
with
context
and
links,
so
that's
something
that
we
can
try
to
flesh
out
in
the
in
the
issues
as
well,
but
yeah
I
think
they're
they're
both
they
both
look
like
interesting
options.
C
As
I
said,
I
feel
like
they
put
like
a
stronger
set
of
requirement
on
the
implementing
platform,
but
they
also
sure
give
a
much
richer
set
of
features.
So
you
know
it's
so
they
I
think
they're.
Definitely
both
interesting,
but
especially,
if
you're
going
to
to
adopt
one
or
the
other
or
both
I
think
it.
C
We
need
to
make
sure
that
it's
clear
which
of
the
of
the
feature
is
achieves
which
specific
use
case,
and
why
do
we
need
both
or
you
know
so
that
we
we
give
like
a
clear
message
to
adopters
that
want
to
implement
this.
You
know
what
to
use
which
failed
for
what,
but
yeah,
definitely
cool
yeah.
Thanks
for
bringing
this
up.
B
C
All
right,
yeah,
unfortunately,
I
need
to
drop
from
the
meeting
for
today,
but
there
are
a
few
more
things
on
the
agenda.
If
you
would
like
to
continue
the
the
discussion
so
basically
one
the
first
item
that
I
had
in
there
is
like
versioning
I
mean
been
discussing
these
offline
a
bit
so
I
think
we
probably
reached
an
agreement
on
way
forward.
So
I
don't
know
if
you
wanted.
We
want
to
discuss
this
further
in
the
meeting
and
then
updates
on
the
Java
on
the
various
sdks
I.
C
Don't
know
if
there
are
any
updates
on
the
GitHub
action
and
then
finally
I
had
an
item
about
zero
to
deep
learning,
at
least
what
I'm
planning
to
work
on
on
the
short
term:
yeah,
yeah,
I'm,
really
sorry,
unfortunately,
I
have
to
leave
I,
don't
know
Emil.
Would
you
be
happy
to
continue
from
here
yeah
absolutely.
C
A
A
So,
let's
just
try
to
conclude
the
discussion
there
on.
What's
what
are
the
next
steps
for
this
discussion
about
context,
IDs
versus
links
or
and
or
suggestions?
I
think
it's
it.
All
of
these
are
more
or
less
under
this
sub
topic
right.
It's
a
topic:
yeah,
yeah,
okay!
So
something
like
this
instead
changing.
H
E
A
It's
not
so,
let's
go
like
this.
A
So
I
don't
know
if
you
should
call
in
context
IDs
or
span
it's
bin
IDs,
but
whatever.
A
If
you
would
be
happy
going
to
write
an
issue
about
this
or
I
mean
the
current
issue
we
have
on
links
is
quite
long
already
and
yeah
tons
of
focuses
on
the
actual
links
itself
intervent
linking
yeah
yeah.
If
you
would
now
instead
have
a
Global
span,
ID
discussed.
We
could
maybe
have
that
as
a
separate
issue.
But
of
course
they
are
very
much
related.
I
still
understand
that
so.
B
A
A
Of
course,
we
could
discuss
it,
but
I
don't
know.
Maybe
we
should
instead
keep
that
discussion
within
the
pull
request
itself.
There
is
some
awesome
information
here
that
MDA
has
written
and,
if
you're
interested
in,
how
are
we
provide
the
version,
the
version
field
and
so
on
in
the
events
themselves.
Please
involve
yourselves
in
this
this
issue
on
the
relative
pull
request
when.
B
B
A
For
each
of
the
event
types
and
each
of
the
event
types,
they
have
individual
event
type
versions
in
their
schema.
So
if
we
add
a
new
field
or
remove
something,
we
we
select
the
version
of
that
event,
type
schema,
okay,
cool.
Then
we
also
have
a
spec
version,
which
is
so
the
overall
version
for
all
event
types
in
the
City
events
protocol.
So
there
we
do
releases.
We
recently
released
the
zero
to
one
version
of
the
spec,
which
contains
a
lot
of
different
sub
versions
than
for
each
event
type.
A
A
So
in
this,
for
example,
there
is
a
schema
ID
or
a
reference
there
to
where
we
can
see
the
artifact
packaged
event,
and
this
term
uses
a
URL
on
the
series.f
site,
which
has
a
spec
version.
So
this
is
for
the
overall
spec
and
within
that
spec
there
is
each
of
the
event
types
other,
and
if
you
retrieve
this
URL,
you
will
get
this
certain
individual
event
schema
for
this
packaged
event.
A
So
it's
not
about
the
the
the
versions
of
the
Arctic
Vector.
Anything
like
that
within
the
outfit
published
or
created
events,
or
thank
you,
students,
sorry
about
the
schemas
themselves,
but
I
think
if
there
are
no
real
concerns
there
or
things
you
would
like
to
discuss
openly
in
the
group,
we
can
more
or
less
just
have
it
in
the
English
and
pull
request
itself.
I,
don't
know
area
you're,
not
clear
anymore.
A
D
Yeah,
so
this
one
we
initially
planned
for
version
0.1,
but
with
some
other
priorities
comes
in,
like
we
couldn't
start
with
the
Java
SDK
update
with
the
latest
specification
yeah.
But
definitely
we
actually.
We
started
now
like
comparing
with
the
old
spec
to
the
new
spec
and
starting
updated,
as
per
the
latest
specification.
D
So
this
work
is
going
on
so
that
we
have
started
it
will
take
like
a
week
or
more
so
will
will
be
raising
a
PR
for
this
change
and
and
also
we
have
a
plan
to
update
the
CD
events
POC
as
well,
so
that
currently
is
taking
the
an
old
specification
event
types
so
that
we
wanted
to
update
with
the
latest
specification
for
go
and
Java
SDK,
so
that
is
currently
being
used
with
the
CD
events,
POC,
so
yeah,
so
that
that's
what
we
have
planned
about.
Java
SDK.
D
Yeah
I
went
so
initially
we
have
a
broker
concept
to
show
like
initially
it's
taken
between
two
components:
the
techton
and
Captain.
So
it
just
shows
like
how
the
events
goes
from
one
component
to
another
component
in
the
cicd
flow,
one
Builds
an
artifact
and
another
approves
yeah.
So
this
is
the
flow.
Actually,
it
goes
in
the
POC,
so
different
components
involved
to
have
this
proof
to
show
like
how
exactly
the
CD
events
works.
So
this
is
initially
developed
because
it
is.
D
That
is
why
it
uses
the
old
specification
that
we
have,
but
after
that,
like
so
many
discussions
and
things
like
that,
so
we
have
identified
like
something
the
specification
is
different
now,
so
that
needs
to
be
updated
for
this,
as
well
as
the
Java
SDK
that
is
developed,
I
mean
implemented
earlier.
B
Okay,
that's
what
I
was
just
gonna
ask:
I
was
like
okay.
That
link
is
different,
so
are
we
planning
on
moving
once
we
update
this
to
the
okay
cool
cool,
because
I
was
like
this
is
a
really
useful
graph,
so
I'd
really
be
able
to
like
to
reference
that.
So
that's
awesome.
A
And
I
don't
believe
we
have
created
any
Pork
yeah,
but
there
will
be
I
guess
we
will
more
or
less
move
whatever
is
is
in
here
in
this
subfolder
or
move,
but
we
will
of
course
migrate
to
the
series
one
version
and
at
the
same
time
move
it
to
a
new
repository
in
the
City
events
organization,
sure
yeah.
That
makes
sense.
Yeah.
A
D
So
with
me,
Adam
he's
working
on
from
my
team,
so
he
started
with
the
SDK
updation
so
and
together
we'll
be
working
on
the
POC
once
the
SDK
is
done
so
because
we
see
go,
SDK
is
already
updated
with
the
latest
specifications,
so
we
can
use,
as
is
in
the
POC,
but
yeah
so
Java
SDK
will
update
so
it
can
be
consumed
by
other
parties.
Also,
like
here
mentioned
right,
so
I
think
someone
is
also
looking
for
the
Java
SDK
I
guess.
A
A
A
E
A
I
believe
this
was
okay,
it's
not
it's
disgusting
when
I
was,
but
there
was
some
more
personal
I.
Think
involved
in
this
story
shown
interest
in
maybe
helping
out
here
as
well.
I
can't
remember
now
who
it
was,
but
if
you
make
a
comment,
maybe
get
on
your
head
and
say
that
you
intend
to
work
on
this
yeah
sure,
okay,
I
mean
we
might
get
done
with
some
help
from
someone
else.
He
was
sort
of
looking
through
this
one.
H
H
Yes,
so
current
status
is
pretty
much
the
same
as
last
time.
I
haven't
had
any
time
to
to
improve
it,
but
so
there
is
a
pull
request
up
now,
where
the
SDK
can
currently
be
used
to
send
events
that
are
are
compliant
with
the
spec.
It's
not
sufficiently
documented.
There
are
some
examples
on
how
to
do
it,
but
there's
quite
a
bit
of
work
remaining
there.
H
What
I'm
planning
for
0.1
is
to
switch
to
pedantic
for
the
data
models
which
would
allow
us
to
basically
parse
an
incoming
event
as
well.
Not
just
send
events
but
I
have
an
open
question.
I
must
admit
this
is
not
an
area
of
python
that
I've
done.
That
much
work
is
pedantic.
The
the
correct
Choice
here
if
I
want
to
be
able
to
both
send
and
parse
Json
events,
or
is
there
something
else
that
is
better,
that
I
don't
know
about
the
pardon.
The
case
was
Cloud.
H
H
I'm
not
sure
it
depends
if
we
want
to
send
Cloud
events
as
like
Photon
Json
objects
on
a
message.
Bus,
then
I
think
I
will
get
help
from
the
cloud
events
pedantic
thing
if
we
send
it
as
where
the
cloud
event
stuff
is
in
HTTP,
headers
and
CD
event
is
in
adjacent
payload,
then
I
don't
think
I
will
get
any
help
from
pedantic,
but
or
not
for
the
cloud
events.
Part
I
would
still
get
help
for
the
CD
events,
part
with
pedantic
server,
I'm
inclined
to
use
it.
For
that
reason,.
H
H
Some
decorators
and
I
should
be
fine
yeah,
so
hopefully
get
that
pretty
much
for
free.
But
as
I
wrote,
there
should
be
straightforward
trademark,
I'm
sure
something
will
go
wrong
when
I
tried,
so
but
then,
after
that,
some
verification
and
documentation
and
then
making
a
release.
H
I
did
have
a
question
which
I
added
at
the
bottom
there
previously
the
go
SDK
had
a
CLI
so
which
made
it
really
easy
for,
like
bash
scripts
and
stuff
to
send
CD
events
now
I,
don't
think
it
has
that
anymore
and
I
think
we
should
pick
one
of
the
sdks
to
have
a
CLI.
I
would
probably
go
for
the
go
SDK
because
it
tends
to
be
first
out
the
door
every
time,
but
yeah,
basically
a
discussion
what
CLI,
sorry,
what
what
SDK
should
have
a
CLI
connected
to
it.
B
So
I
think
the
SDK
doesn't
matter
as
much
when
discussing
like
a
CLI
I.
Think
it's
more
of
like
Distributing.
The
CLI
is
like
so
my
my
concern
is
like:
if
whoever's
gonna
maintain
this
Distributing
and
releasing
go,
binaries
is
a
lot
more
difficult
than
just
releasing
python
so
that
that's
like
the
only
difference
and
like
I,
said
that
that
work
isn't
too
much
more
difficult.
But
that
is
the
difference
between
like
wanting
to
choose
Go
versus
python,
but
I
think
both
sdks
are
perfectly
fine
to
choose
they're,
both
suitable
CLI
languages.
B
So
it's
more
up
to
the
maintainers.
Do
they
want
to?
You
know
like
essentially
you
know,
bundle
for
Debian
packages
for
Linux
other
Linux
pack.
Now
you
have
to
do
this.
You
know
for,
for
you
know
all
these
different
platforms.
You
know
you
have
to
do
this
with
python
as
well,
but
that
that's
really
easy
all
you
need
to
do
is
like
switch.
B
You
know
the
package,
but
with
like
go,
you
might
have
to
build
this
binary
differently
every
single
time,
which
is
fun
to
be
solved
with
scripts,
but,
like
I
said,
that's,
that's
the
difference
there.
So
you
know
and
I'm
a
I'm
I've
have
a
long
time
experience
with
like
go
so
I
I'm.
Like
all
four
go,
you
know.
I
love
go,
but
you
know
like
I,
said:
choose
what
I
think
is
that
makes
sense
for
the
maintainers
and
that
would
probably
be
the
one
that
I
would
go
down.
H
Yeah
yeah
so
yeah,
basically,
I
can
start
at
an
issue
for
this
in
some
appropriate
repository.
So
we
can
continue
discussion
because
I
agree
with
Ben.
It
should
should
be
a
choice
taken
with
some
some
thought
behind
it.
Basically.
H
A
Sounds
good,
we
could
discuss
new
repositories
and
such
it
would
be
best
I
think,
but
yeah
I
also
agree
that
we
should
at
the
moment
we
should
create
the
CR
where
we
think
we
can
easiest
achieve
it
right
now.
So
we
have
something
that
is
to
to
use
and
it
doesn't
really
matter
if
we
need
to
change
that
position
later
on,
because
of
reasons
whatever
no
exactly.
H
A
I,
wouldn't
be
so
sure
that
all
the
I
mean
the
the
ways
you
hand
the
properties
or
parameters
to
this
year.
I
would
be
exactly
the
same
regardless
unless
we
have
a
specification
of
what
the
CRI
should
look
like,
but
I
don't
think
we
need
to
dictate
that
either
right
now
Louis
as
long
as
it's
possible
to
use
it.
A
So
no
decision
really
need
it,
I
think
now.
Yes,
that's
let's
go
for
what
we
have
and,
of
course,
if
you,
if
you
have
some
rudimentary
CRI
when
you
implemented
python,
SDK
just
provided
us
some
kind
of
data
thing
there
as
well
within
the
SDK.
So
that's
a
little
different
okay,
GitHub
actions.
I
know
that
we
have
and
oh
got
his
name
now.
A
We
haven't
set
the
the
roadmap
or
the
the
content
really
of
the
zeros
one
zero
two
release.
We
have
stated
somewhat
in
the
in
an
old
version
of
the
roadmap
that
we
have
provided
that
we
intend
to
include
certain
features
in
before
end
of
this
year
and
I'm.
Pretty
sure
all
of
those
features
are
not
in
the
0.1
version.
A
So
if
we
should
not
update
that
roadmap
or
config
with
it,
we
need
to
have
something
more
in
place
before
Christmas.
But
again,
of
course,
we
can.
We
can
change
that
logo.
No
one
is
really
dependent
on
it
in
that
way.
So
there's
no
no
urgency
to
really
really
zero
two
before
we
have
something
valuable
to
to
put
in
it.
So
unless
you
have
any
good
ideas,
I
haven't
thought
too
much
about
this.
A
B
Okay,
one
thing
that
might
be
nice
is
these
individual
bullet
points
for
like
fixed,
versioning,
schemas
and
and
the
list
below
it
is
to
put
the
GitHub
issue
next
to
it.
You
know
it'd
be
nice
like
if
I
could
copy
paste
that
and
be
like.
Oh
here's,
the
road
map
and
people
can
just
click.
Those.
A
E
B
A
E
A
Definitely,
if
I
don't
find
it
I
can.
I
can't
react
to
that
if
he
I
was
ready,
yeah
of
course,
then
Justice
is
a
shout
out
so
that
really
received
PM's
problem.
Is
it
Friday
this
week
for
cubiccon
EU?
If
you
are
interested
in
proposing
some
presentation
there,
thanks
for
information,
anything
else
you
would
like
to
bring
up
today,
then
that
we
haven't
put
into
the
agenda.
G
G
Yeah
so
I've
got
a
mechanism
in
that
I
think
I
can
Implement
now,
which
will
allow
us
to
deal
with
that
situation
in
the
future.
A
Yeah,
so
the
idea
is
there
that
there
should
be
a
landing
page
which
is
more
or
less
I
know.
You
think
you
could
correct
me
if
I'm
wrong
there
already,
but
this
landing
page
should
be
quite
generic
at
the
start
of
it.
So
the
information
here
shouldn't
be
too
tight
to
any
specific
spec
version
or
spec
release,
but.
G
Hopefully,
you're
seeing
that
now
yep
yep,
so
what
I'm
doing
basically
is
expanding
this
with
a
narrative
to
to
give
us
that
that
early
introduction.
So
when
you
land
on
this
page,
you'll
you'll
get
you
know
a
quick
pitch
for
why
you
should
read
this
page
and
then
a
narrative
to
introduce
you
into
the
the
specific
challenges
that
we're
addressing
with
with
CD
events.
G
And
then
this
is
giving
you
a
very
high
level
overview
and
then
introducing
you
into
further
links
to
follow.
So
so
this
is
the
for
the
audience
that
really
doesn't
know
what
this
is
about.
This
is
the
the
attempt
to
grab
their
attention
and
draw
them
into
exploring
more
about
the
about
the
content
and
I
need
to
go
through
and
tidy
up
this,
the
the
visual
look
and
feel
of
this
and
make
it
a
little
bit
more
polished
but
yeah.
G
This
is
the
the
overarching
structure
that
that
I'm
looking
to
put
in
place.
A
G
So
that's
just
con.
It's
just
config
in
the
in
in
the
overarching
setup
which
I
I'll
look
at
tomorrow.