►
From YouTube: CDEvents Working Group (EMEA/AMERICAS) - Jan 24, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
B
Yeah
or
we
can
mention
it
on
the
Sig
meeting,
maybe
on
Monday
yeah,
we
don't
ruin
the
time
for
this
meeting
here.
Foreign.
C
Did
you
get
my
meeting,
invite
Andre
I
I
sent
you
and
jillander
the
meeting,
but
it's
for
next
week
Tuesday,
it's
one
o'clock,
Pacific
time
so
I
think
it's
like
five
or
six.
Your
time,
I'm,
not
too
sure.
C
C
That
was
the
only
time
that
was
available
for
basically
like
every
because
like
I,
so
there's
a
couple
guy
or
a
guy
coming
from
a
maintainer
from
the
Salesforce
side,
and
then
a
few
people
coming
from
the
Armory
Spinnaker
side,
so
so
yeah.
That
was
that
was
obviously
the
best
time
so
I
knew
it
was
going
to
be
a
little
bit
late
for
you
guys,
but
I
was
like.
Maybe
you
know
we
can
figure
something
out,
but
hopefully
hopefully
that
works
for
you
guys.
A
C
A
I
should
be
able
to
make
it.
It
might
be,
though
it
do.
You
know
where
jalander
is
located.
Emil
is
in
Sweden.
A
Yeah,
let's
see
I,
don't
know
if
it's
going
to
join
today,
but.
A
All
right:
well,
it's
very
bust
I
think
we
should
probably
get
started.
A
All
right
so
hopefully
Mo
will
join
as
we
go
so
I
welcome
everyone
to
the
city
lands.
A
My
name
is
Andrea
Frito
I
work
for
IBM
I'm
in
UTC.
We
have,
after
this
list
in
our
meeting
notes,
so
feel
free
to
sign
in
if
you'd
like
to
just
put
the
link
in
the
chat.
A
Right
so
we
have
a
few
items
on
the
agenda
for
today.
First
review
of
action
items,
you
had
a
question
about
Java
SDK
immigration
for
last
time.
So,
as
you
may
know,
we
working
on
getting
the
Java
SDK,
along
with
the
latest
version
of
the
specification.
Adam
is
working
on
it
and
my
question
was:
how
are
we
going
to
Endo
like
if
you're
partial
upgrades,
but
basically
Adam
confirmed
that
it's
working
in
a
single
PR
that
will
move
the
entire
SDK
to
the
new
version?
A
So
that's
kind
of
answer
the
question
there
for
this
pina
car
racing
just
mentioned
Ben
there
is
a
meeting
set
up
for
the
31st,
so
thanks
for
that
I'm
looking
forward
to
it
and
the
last
many
things
I
wanted
to
mention
is
that
I
have
archived
the
notes
for
2022
for
these
working
group,
as
well
as
for
the
Sig
events,
and
specifically
for
this
working
group.
A
Sorry
I
moved
the
notes
to
the
City
events
community
meeting
because
it
seemed
to
be
more
relevant
and
I
put
a
link
here
the
previous
year.
So
if
you
open
this,
take
you
to
the
notes
for
2022.
B
A
Community
yeah
and
for
the
Sikh,
let's
see.
A
Oh
seek
events,
that's
where
it
used
to
be
so
vocabulary,
Works
same
no.
D
A
Oh
yeah
I
think
I.
Did
it
wrong
so
I
need
to
Archive
this
sorry
about
that.
A
Yeah
yeah
I
know
exactly
luckily
they're
in
kids,
so
things
can
be
rolled
back
in.
A
Case
but
so
let
me
see.
A
All
right
next,
we
discussed
in
the
past
meeting
about
test
events
with
a
whole
Ben
Bruno
from
gift
shop,
desk
queue
project,
so
all
of
the
pr
based
on
what
they
propose
in
their
discussion
I
had
some
initial
feedback
on
it.
So
if
you're
interested
in
this,
please
also
review
it
and
add
comments
and
then
waiting
for
Ola
to
also
come
back
with
this
replies.
A
A
A
A
A
The
first
one
that
seemed
to
be
relevance,
the
others
are
mono
variations
or
less
specific
I
think
this
is
a
good
definition
that
covers
both
actual
actually
and
potentially
jeopardize
a
different
aspect,
so
confidentiality
integrity
and
availability.
So
we
choose
good
because
then
like.
If
there
is
like
a
case
where
it
is
reported,
the
new
CV
has
been
discovered
and
that
affects
one
of
the
versions
deployed
already
in
production.
C
Real
quick
I
just
want
to
make
a
comment
on
something
because
I
was
unsure
about
the
event
type
format,
because
I'm
looking
at
this
testing
events-
and
it
looks
like
the
version-
is
a
part
of
the
event
type
is
that
is
that
part
of
the
spec.
A
C
Yeah,
like
you
guys,
would
have
to
parse
that
on
the
SDK
side,
right
and
then
figure
out
whether
or
not
and
then
you
need
on
Marshall
into
that
type
right.
This
Dev
Suite
started
I
I,
guess
that's
if
you're
mixing
versions,
but
that
could
happen
right.
I'm.
Just
curious,
like
what
happens
like
when,
when
versions
are
out
of
sync,
are
you?
C
Are
you
imagining
that
the
whole
system
would
be
a
system
as
in
you
know,
multiple
systems
that
are
talking
to
one
another
to
being
on
all
all
the
same
versions
here,
like
I'm,
just
trying
to
figure
out
if
like
how,
how
version
bumping,
Works
and
gets
propagated?
And
then,
if
it,
if
a
version
is
not
or
if
a
version
is
different
than
the
current
version
of
another
system
like
how
does
that
get
unmarshalled?
And
how
does
that
get
handled
by
the
sdks.
A
Yeah,
that's
a
very
good
question,
so
we
try
to
map
the
the
variations
to
the
fact
that
changes
are
Backward,
Compatible
or
incompatible
so
depending
on
how
strict
the
the
SDK
parsing
is
I
think
a
general
generally.
It
should
be
the
case
that
if
you
have
a
bump
in
a
minor
patch
version,
the
SDK,
if
you
allow
for
extra
attributes
so
to
say,
you
should
still
be
able
to
parse
to
parse
even
your
messages,
but
you
will
need
a
new
version,
definitely
of
the
SDK.
A
C
Yeah
yeah,
it's
just
I
I,
didn't
know
that
the
version
was
actually
part
of
that.
I
must
have
missed
that
that
discussion,
when
that
happened
was
part
of
the
event
type.
But
it's
it's
not
I
just
thought.
It
was
a
little
interesting
because
I
thought
it
was
going
to
be
a
separate
field
from
when
we
first
talked,
but
it
looks
like
it's
actually
a
part
of
the
event
type
which
which
isn't
a
big
deal,
but
it's
just
kind
of
interesting.
B
Mean
what
I
mean
we
discussed
that
a
bit?
We
ended
up
at
that
time,
at
least
on
the
conclusion
that
it
it
suits.
It
fits
better
in
in
the
extra
type
field,
but
we
also
discussed
the
option
of
hanging
in
a
separate
version
field
and
I'm
to
me.
It
doesn't
make
too
much
difference,
I
think,
but
I
I,
remember
I,
think
Andrea
that
you
had
some
some
good
argumentation,
why
it
should
be
in
the
type
for
Simplicity
reasons
of
the.
A
Yes,
so
it
I
mean
I,
guess
there
are
advantages
in
both
cases,
but
at
least
if
you,
if
you
have
the
version
in
there
just
by
reading
the
type,
so
just
by
reading
a
single
thing,
a
single
field,
you
can
know
from
an
SDK
whether
you're
able
to
actually
parse
that
type
or
not,
as
opposed
to
reading
the
two
types,
and
also,
if
you're
filtering
on
certain
versions,
you
can
use
a
single
field
for
doing
that.
A
That
said,
there
are
advantages,
I
think
in
both
directions.
I,
don't
know,
I,
think
that's
that's
the
way
we
we
set
it
up.
We
designed
it
now
and
I
imagine
this
is
the
way
we
would
go
at
least
for
the
next
three
days.
My
feeling
or
my
proposal
would
be
I
mean.
Let's
try
to
we
we're
going
to
start
building
this
now
into
into
tools,
and
if
we
see
that
we
hit
any
major
issue
a
roadblock
with
this
approach,
we
can
still
revert
a
different
approach.
C
Yeah
yeah
definitely
I,
do
I.
Think
there's
going
to
be
a
couple
things
that
are
going
to
be
interesting.
This
is
more
from
the
SDK
side,
less
from
the
spec
side,
but
more
from
the
SDK
side.
I
think
there's
going
to
be
a
little
bit
of,
because
now
one
you
have
to
assume
that
people
that,
when
they're
writing
these
event,
types
are
going
to
follow
this
format.
So
if
someone
adds
their
own
custom
type
for
example,
and
wants
that
to
be
like
propagated
through
the
system,
you
know
they
they
have
to
follow
this.
C
C
Actually
they
would
have
to
because
if
the
SDK
is
actually
parsing
it
and
that
you
know
you
might
get
a
null
or
you
know
you
would
have
to
do
those
checks
and
whatnot
as
opposed
to
having
a
field
having
that
empty
is
easier
to
check
than
parsing
it
and
figuring
out
me
when
I,
whenever
I
hear
that
you
have
to
parse
a
string
to
get
some
sort
of
value,
I
always
find
that
to
be
a
little
bit
more
there's
a
lot
more
there's
a
lot
more
you're
more
prone
to
errors
than
the
sdks.
C
That's
that's
more
of
the
concern,
and
so
the
second
part
of
this
is
when
you
have
it
in
a
separate
field.
What's
great
about
that,
is
you
know
you
can
have
the
the
version,
and
you
can
just
you
know,
check.
Oh
you
know
it's.
This
type
then
check
the
second
field.
It's
this!
You
can
just
check.
You
know
like
the
first
major
version,
major
and
minor
version
and
be
like.
Oh,
you
know
this
doesn't
have
any
breaking
changes
and
then
you
know
just
on
Marshall
right
and
you're
done.
C
But
again
in
this
case,
in
your
case
yeah,
you
can
look
it
up
with
one
field
and
the
things
that
are
the
same
version.
It's
easy!
It's
just
a
simple
string
check,
but
once
they're
not
the
same
version,
it
becomes
far
more
complicated
and
I
think
so.
The
thing
is
is
that
when
you're
trying
to
solve
for
these
problems,
you
have
to
think
whether
or
not
that
version
mismatches
are
going
to
be
more
occurring
or
less
occurring
and
when
they
do
occur
right.
C
C
No,
you
can
have
a
single,
a
single,
a
single
version
feels
even
fine,
and
you
could
do
you
know
the
parts,
because
you
know
version,
that's
pretty
standard
right.
You
could
just
have
version
like
you
could
just
say
it's
semantic,
versioning
right
and
horsing.
A
version
string
is
a
lot
simpler
than
parsing
an
event
type
string.
Where
there's
multiple
dots
there
could
be
drafts,
you
know
and
and
whatever
other
you
know,
different
characters
in
there.
C
So
and
and
that's
kind
of
like
you
know
why
I'm
saying
like
parsing
a
version
string
versus
parsing,
a
a
vet
type
string
is
far
more
complicated
and
then,
when
version
mismatches
do
happen,
you
know
what
extra
steps
are
needed
to
take,
as
opposed
to
you
know,
just
checking
the
version
string.
You
know
just
simply
the
major
and
minor
version.
Just
you
know
you
can
just
check
that
easily,
just
with
a
string,
split
right
and
then
just
check
the
major
and
minor
version,
and
then
okay,
these
two.
C
B
B
The
the
top
level
structure
of
the
cloud
event,
whereas
the
the
version
field
is,
is
not
so
I
guess
that
that's
one
reason
for
having
it
also
in
in
the
in
the
cloud
event
type
field,
and
as
part
of
that,
because
then
it
makes
it
even
possible
to
just
just
on
the
cloud
events
level.
You
don't
even
need
to
go
down
to
the
CD
events,
data
level
of
the
event
to
to
see
what
version
of
event
is
this
yeah.
A
C
Okay,
so
this
is
yeah
like
a
little
off
topic.
You
know,
like
I,
just
brought
it
up,
because
I
was
a
little
a
little
interesting
and
I.
Don't
want
to
say
Hey,
you
know
we
need
a
rewrite,
but,
like
I,
just
want
to
break
up
the
concerns
a
little
bit
like
with
the
version,
mismatching
I
think
it's
going
to
make
things
a
lot
more
complex.
C
If
you
go
this
route,
however,
if
we
start
introducing
this
into
tools
like
going
off
what
you
said
Andrea-
and
this
turns
out
to
not
be
the
major
case
of
you-
know-
version
Mitch
massing,
then
that
might
be
fine.
However,
I
have
a
feeling.
That's
not
going
to
be
the
case
because,
like
especially
like,
when
you
get
into
you
know
like,
for
instance,
Apple
like
people
are
very
siled.
C
People
are
going
to
have
their
own
versions,
you
know
and
they're
just
going
to
be
sending
you
know
whatever,
but
we're
just
gonna
expect
them
to
be
compatible
to
some
degree.
Not
we
can't.
You
know
we
can't
be
complete,
dictate
haters
Accord
across,
like
you
know
like
we're
talking,
you
know
potential
like
you
know
dozens
of
dozens
of
teams
and
that's
going
to
be
true
from
another
Corporation.
You
know
like,
like
apple
Amazon
and
Google,
for
example,
so
so
that's
kind
of
like
what
I'm
getting
at.
C
B
But
regarding
custom
event,
types
I
mean
an
event
type
that
starts
with
dev.ca
event.
Something
is
assumed
to
be
part
of
the
protocol
and
adhere
to
the
the
specification
that
we
have
there.
So
if
someone
sends
an
event
and
puts
the
event
type
Devil
city
events.something
else,
then
all
consumers
will
be
confused,
so
so
I
mean.
Then
they
shouldn't
expect
any
City
Event
consumer
to
understand
that
that
information
and
then
the
students
consumer
would
probably
crash
or
I
mean
bailouts
are
some
have
somehow
right.
C
Right,
yeah
and
I
agree,
you
know,
that's,
you
know,
that's
if
the
customer
is
passing
custom
customer
event
types
right,
but
what
I'm
talking
about
is
just
a
different
version.
Even
so,
there's
actually
two
problems
here.
It's
custom
event
types
knowing
the
proper
structure
and
then
the
second
problem
is
when
version
mismatching
happens.
Person
becomes
a
little
bit
more
difficult
if
the
versions
in
the
string,
because
if
you
look
at
it
right
like
you,
have
zeroed.1.0
right,
but
then
you
have
draft.
C
On
top
of
that,
you
know
so
you
got
to
figure
out.
You
got
to
know
all
these
different
nuances
between
draft
now
this
Dash
draft
Dash
Alpha.
You
know
0.1.0
0.1.1,
you
know
so
it's
far
more
complicated
of
parsing
when
you
start
adding
more
information
to
the
versions
right
as
opposing
just
to
having
a
standard,
dispersion
string
right.
A
Why
it's
being
specified
until
we
make
a
release
and
then
we
cut
all
the
drafts
out,
so
the
SDK
will
only
ever
handle
the
semantic
version.
Numbers
right,
right,
yeah,
I
think
to
go
back
also
to
what
evil
mentioned
about
the
cloud
events
binding.
So
if
you,
if
you
have
different
tools
that
are
sending
different
versions
of
events,
so
as
long
as
they're
within
the
same
major
version,
there
would
be
backward
compatibles.
A
So
if
you
have
like
zero
dot
star
and
if
you
have
a
router
of
events
like
a
broker,
you
could
you
could
use
filters,
say
everything
which
is
a
event
type
that
start
with
City
Dev
City
events,
environment,
deleted,
I'm
interested
in
those
events,
but
you
can
then
exclude
things
that
are
on
a
different
major.
So.
C
B
C
Yeah
yeah.
Definitely
that's
if
you
go
with
like
two
separate
things,
but
what
I'm
saying,
though,
for
the
single
one
right
like
you
would
have
to
do
a
regex
right
this?
This
would
have
to
be
Dev.
You
know,
CD
events,
environment
deleted
and
then
you
know
the
version
and
then
you
would
have
to
compare.
But
this
was
just
CD
event.
Environment
deleted.
You
know.
All
you
have
to
do
is
look
that
up
in
the
map
and
then
look
up
the
version
in
the
map
and
you're
done
right.
C
You
don't
have
to
do
any
any
regexes
there
right
so
yeah
I,
don't
know.
B
C
B
D
C
B
C
Yeah,
you
could
still
do
that,
though,
without
regex
yeah,
you
could
do
all
all
the
the
only
issue
like
the
only
time
it
just
depends
on
how
you
want
to
parse
it
like
originally
I,
wasn't
considering
regex,
because
it's
quite
it's
a
lot
more
expensive
than
just
doing
a
string
split.
C
But
if
you're
doing
regexes
you
know
that's
completely
valid,
but
what
I
was
saying
is
I,
wouldn't,
like
my
solution,
is
that
I
wouldn't
be
doing
rejects,
is
I
would
just
be
using
the
version
having
those
map
to
the
proper
routing
points,
and
then
I
would
do
a
string,
split
and
just
say
major
versions.
If
it's
two
just
go
here,
if
it's
major
version
three
just
go
here,
for
example,.
B
Yeah
I'm
not
sure
how
Cloud
events
broke.
Good,
propagation
or
Federation
works,
really
there's
any
common
rules
for
that,
but
I
don't
know
when
it
comes
to
messaging,
with
the
amqp
on
revitemke,
for
example,
you
could
State
the
the
routing
keys
that
you
would
like
to
to
match
when
you
are
federating
a
message
from
one
end
to
another,
but
another
end,
and
then
it's
only
one
field
that
you're
able
to
begin
to
it
can't
really
introspect
into
the
actual
event
itself.
You
could
only
see
the
the
part
that
is
called
in
the
name
Cube.
C
Right
right
so.
B
If
the
event
type
and
the
version
was
already
there,
then
you
could
match
on
the
the
routing
level
directly
for
any
event
tax
that
you
say
that
you
are
able
to
to
understand.
You
would
like
to
Route
forward
or
fed
it
right
in
separate
field,
and
you
will
need
to
actually
look
into
each
event
and
parse
them
and
that's
totally
more
expensive
operation
to
do
in
the
routing.
C
I
mean
you
don't
have
to
I
mean
you
can.
Even
you
know
in
terms
of
routing,
can't
even
combine
them
right
like
that's,
not
difficult
to
do
either
right
just
to
do
the
same
thing
just
build
this.
You
know
single
single
event
type
with
the
version
on
it.
If
you
want
to
do
routing
that
way,
I'm
talking
about
it
from
more
of
a
deserialization
serialization
standpoint,
you
know
right,
like
I
said
we
can
go,
you
know
through
routing,
you
know,
regex,
you
know
or
parsing.
C
You
know,
but
yeah
you're
right
regex
is
the
way
to
do
routing
that
that's
correct.
You
know,
that's
how
you
do
processing
that
that
makes
perfect
sense,
but
you
know,
like
I
said
when
it
comes
to
serialization
and
deserialization
is
more,
is
more
of
where
my
concern
lies.
Yeah.
B
C
No,
no,
no
yeah.
Definitely
absolutely
right!
You
know
it's.
It
is
an
extra
step,
but
the
thing
is:
when
you
do
the
string
split,
you
now
need
to
know
the
where,
where
the
version
I
guess
it
would
be.
The
last
three
assuming
assuming
draft
was
in
a
part
of
the
part
of
the
the
actual
version
spec,
so
so
yeah
that
that's
that's
completely
fair.
C
You
know
you
can
totally
do
a
string
split
assuming
that
the
that's
the
version
version
is
there
you
know
and
and
like
I
said
you
know
it
just
it
just
depends
on
whether
or
not
you
know
like
how
you
want
to
do
how
you
want
to
represent
the
event
type
because,
like
when
I
do
unmarshalling
right,
like
I,
just
want
to
look
at
the
event
type
you
know
get
the
version
because,
like
in
my
serializer
right,
like
I,
might
have
a
custom
serial,
because
this
is
more
of
java.
C
That
takes
the
version
and
then
just
does
the
deserialization
from
there
right.
You
know,
as
opposed
to
now.
You
know,
I
need
to
now
parse
this
event
type
string.
C
You
know
parse
that
and
then
and
then
do
extra
work
there.
Well,
it's
actually
not
me
it's
the
sdks
again.
This
is
just
more
from
the
SDK
side
of
things.
I
feel
like
it
just
makes
the
serialization
and
deserialization
more
complicated,
but
that's.
C
That
the
complication
is
is
much
right,
I'm,
just
saying
that
you
know
when
I'm
looking
at
that,
it's
a
little
I'm
just
a
little
bit
worried
because
that
it
makes
deserialization
serialization
more
complicated.
What
else
could
it
potentially
make
more
complicated?
It's
kind
of
like
where
my
mind's
going
so
like
this
is
the
first
time
I
saw
that
see.
I've
seen
this
so
I
haven't
thought
about
it
too
much,
but,
like
I
said
you
know,
I'm
I'm
I
think
we
should
go
with.
C
You
know,
like
I
said,
with
the
original
suggestion
that
Andrea
had
said
you
know
just
roll
it
out
get
into
tools,
see
what
the
use
case
is
for
each
of
these
tools.
And
then
you
know
if
things
come
out,
you
know
we
can
make
the
changes,
but,
like
I
said
you
know,
it
was
just
it
just
looked
a
little
concerning
to
me.
I
just
wanted
to
bring
it
up
just
in
case.
Like
you
know,
you
guys
were
on
the
fence
about
it
and
then
you're
like
oh,
you
know.
You
know
that
makes
sense.
C
You
know,
but
you
know,
like
I
said
you
know
it's
it's
I.
Don't
think
it's
it's!
It's
a
it's
a
breaking!
You
know
it's
gonna
break
this,
the
spec.
If
you
will.
B
But
I
think
you're
hard
at
a
very
important
point
that
we
haven't
really
put
our
time.
To
do
great
I
mean
we
would
need
to
probably
draw
write
a
decision
log
where
we
State
we
choose
to
have
the
version
here
because
of
this,
and
that
and
and
then
that
discussion
decision
could
be
questioned
by
someone
and
we
could
revisit
it.
B
But
now
it's
I
mean
we
can't
really
even
say
how
we
why
we
took
the
decision
we
did
really,
since
we
need
to
look
for
all
issues
and
pull
requests
and
other
things
to
see
those
comments.
So
I
think
that
we
should.
Actually.
This
is
one
of
those
things
we
should
document
out
how
we
came
to
this
conclusion
that
we
have
the
version
as
part
of
the
type
yeah
yeah.
That.
A
I,
don't
know
no
sorry,
I
was
muted,
absolutely
man
I
think
this
is
really
useful
feedback
and
input.
So,
as
email
was
said,
I
mean
we
got
an
action
item
for
sure
to
document
better
to
document
why
we
have
a
certain
decision
made
made
in
the
past
I,
don't
know
if
you
wanted
to
create
an
issue
to
track
your
concerns,
specifically
about
the
current
approach
that
we
could
keep
in
the
backlog,
also
to
track
that
that'd
be
great,
but
I.
C
Think
it's
a
little
bit
early,
okay,
I!
Think
it's
gonna
really
just
depend
on
how
people
ingest
this
and
how
CD
events
grow.
I
think
that's,
what's
going
to
kind
of
determine
and
dictate
things
so
I
think.
Naturally,
if
this
you
know,
I
think
this
is
natural.
If
this
is
an
issue,
this
is
just
gonna.
Naturally
come
up
come
up
again,
so
I
I,
don't
think
we
need
to
create
a
backlog
item
you
know
and
then
once
it
does
naturally
present
itself.
A
D
A
Probably
PR
as
well
all
right,
foreign.
A
So
for
now
the
we
would
have
one
subject
incident
and
two
predicates
reported,
and
the
name
here
is
yeah,
maybe
reported
is
not
the
best
I
mean
we
I,
think
I
know.
You
suggests
that.
C
Yeah,
thank
you,
opt
for
one
more
product
kit
would
be
reported,
maybe
pending
and
resolved
just
or
like
work
in
progress.
Just
to
show
that,
because
you
know
like
in
in
tooling
like
Jenkins
and
whatnot
there's,
you
know
a
new
issue,
that's
open,
then
someone
will
say
then
they'll
switch
it
to
like.
You
know,
working
on
it,
work
in
progress
and
then
lastly
resolved
so
I
think
they're,
just
one
more
that
that
would
be
really
nice
to
have.
B
Yeah,
but
that
is
really
also
corresponding
to
a
comment
that
I
had
and
that
this
is
this
term
doesn't
really
match
issues.
It's
rather
that
this
is
an
incident
that
has
happened
in
a
system
which
could
be
declared
by
an
issue.
C
D
B
One
could
relate
to
a
in
an
issue
maybe
explicitly
through
a
link
to
an
issue
tracker
or
the
issue
itself
could
be
a
top
level
item
as
well
in
the
spec.
C
Okay,
awesome
and
then
is
there
like
a
priority
of
the
type
of
incident
like
like,
for
instance,
incident
is
like
level
five
super
crazy
incident
that
destroyed,
like
you
know,
took
down
the
internet,
because
that
might
be
useful
like
having
a
like
a
piety
or
like
a
level
to
the
incident.
A
Yes,
so
we
we
had
a
few
meetings
ago,
some
discussion
on
on
these,
and
we
had
a
lot
of
ideas
of
actually
multiple
predicates
that
we
could
have
and
multiple
fields.
A
So
I
guess
here
what
I
was
trying
to
do
is
to
capture
kind
of
the
very
minimum
set
that
we
could
start
with
to
to
make
this
useful.
But
yeah
I
mean
priority,
sounds
like
something
that
don't
mind
we
needed
even
for
for
the
very
basic
like
for
predicates.
We
also
had
like
things
like
updates.
It's
ignoring.
A
C
B
C
A
C
A
The
incident
like
occurrence,
I,
guess
and.
C
C
What
the
other
predicate
was
or
resolved
right
yeah
and
then
you
would
have
the
priority
of
it
and
then
you
would
have
a
ticket
that's
associated
with
that,
and
then
that
might
be
a
really
good
way
of
doing
that
or
an
interesting
or
you
know
a
good
way
of
kind
of
a
describing
that
because
yeah
I
think
actually
yeah
particularly
I,
think
is
absolutely
needed
or
yeah
some
sort
of
ticketing
or
triaging
type
of
spec
proposal
is
needed,
especially
if
we're
going
to
start
introducing
incidents.
C
B
I'm
thinking
how
much
we
should
mimic
the
the
issue
system
itself,
I
mean
in
the
spec
here
or
if
we
should
just
refer
to
a
ticketing
system.
I
mean
oh.
B
B
You
often
would
send
an
incident
event
saying
that
something
has
happened,
and
then
there
may
be
some
automation
that
creates
a
ticket
for
you
automatically
or
is
the
human
that
does
it
afterwards
and
then
you
need
to
relate
those
together
afterwards
and
then
you
would
need
some
kind
of
event
or
some
some
way
to
reference
those,
the
the
issue
that
was
created
after
the
incident
to
the
incident,
and
that
would
make
sense
that
if
there
are
separate
issue
events
but
I
yeah
I'm,
not
exactly
sure
it
could
be.
B
Could
there
be
some
other
predicate
on
the
incident
event
and
saying
that
well,
it
was
detected
first
and
then
the
incident
was
reported
later
in
a
later
event,
and
that
reported
event
could
then
contain
a
reference
to
the
actual
issue
tracking
system.
Yeah.
That's
a
good
idea.
C
Yeah
actually
I
really
like
that
and
then
kind
of
give
a
little
background
of
like
why
this
ticketing
system
kind
of
came
about
like
when
you
were
talking
about
the
incidents
is
so
my
experience
with
AWS.
They
have
their
own
internal.
You
know
incident
reporting,
but
incident
reporting
is
done
through
the
ticketing
system.
So
it
might
be
nice.
You
know
to
kind
of
figure
out.
You
know
how
we
can
comb.
You
know.
Well,
you
know
that's
just
one
way
of
AWS.
So
there's
two
ways.
C
B
Yeah
I'm
also
a
bit
conscious
that
we
shouldn't
mimic
the
full
life
cycle
of
an
of
a
ticket.
B
Mean
there
are
numerals
of
different
transitions
that
a
ticket
could
take
and
we
don't
want
to
have
predicates
follow
those
to
handle
those
details
as
as
properties
of
the
ins
issue.
Events,
if
those
would
exist,
yeah.
C
Yeah
and
that's
why
I
was
thinking
like
keeping
it
simple,
is
just
like
open
work
in
progress
resolved
like
just
like,
keep
it
as
broad
where
it
covers
you
know
as
as
or
as
vague
as
possible,
where
it
covers
as
much
as
possible
is
kind
of
like
what
I'm
thinking
you
know
and
I
think
you
know
once
we
start
coming
up
with
the
proposal,
we
can
start.
We
can
start
thinking
about
all
these
things
or
we
can
even
deal
with
two.
C
D
B
A
B
A
Yeah,
just
thinking
yeah,
let's
try
it
I'm,
just
thinking
the
the
detected
the
incident
be
could
be
generated
by
something
like
I,
don't
know,
Prometheus,
or
something
that
not
something
not
Prometheus
directly,
maybe
but
there's
something
that
is
listening
to
Prometheus
looking
at
Prometheus
metrics
and
comparing
them
with
thresholds
and
saying
well.
This
is
off
the
threshold
now
and
so
sending
an
incident
and
then
generate
some
ID
for
that.
A
B
Yeah
I
guess
they
could
be
an
event
listener.
A
consumer
of
the
incident
detected
events
that
would
automatically
create
an
issue
for
it
and
then
send
the
incident
reported
event
as
as
a
result
of
that,
or
it
could
be
a
system
that
just
visualizes
all
detected
incidents
and
then
a
person
goes
there
and
and
creates
an
incident
or
an
issue.
Sorry
manually,
and
then
some
system
of
course
would
need
to
monitor
that
the
the
issue
is
created
which
concerns
this
incident.
D
B
So
yeah,
okay.
D
A
A
Yeah,
that
means
that
things
like
priority
is
something
that
we
could
include,
but
then
only
in
the
reported
predicate.
What
do
you
think?
Oh.
B
C
Yeah
yeah
yeah
definitely
yeah
because
like
for
instance,
if
you
know
S3
goes
out
and
the
internet
goes
out,
you
know
that
severity
is
pretty
pretty
huge
right
and
you
definitely
would
want
to
have
a
listener
like
if
we
have
an
event
listener.
That's
looking
for
severities,
like
that
makes
things
really
really
easy.
It's
just
like.
Oh
these
severities
do
this.
You
know
you
know,
send
out
an
alarm
or
or
do
whatever.
So
that
makes
that
really
easy.
Rather
than
needing
to
go
to
a
ticket.
C
To
then
look
I
mean
you
want.
You
would
want
to
do
this
anyways,
but
you
could
go.
You
know
you
would
have
to
look
through
the
tickets
to
see
what
the
high
priorities
are
and
then
decide
whether
or
not
you
want
to
send
a
page,
for
example.
But
if
the
severity
is
just
set
to
like
you
know,
like
internet
is
blown
up,
then
you
know
you
can
just
immediately
send
a
page
right,
so
I,
I,
I,
think
severity
makes
a
lot
of
sense,
but.
C
Yeah,
so
luckily
I
have
found
that
most
people,
not
everyone,
but
most
people
are
pretty
good
at
setting
severities.
C
However,
that's
not
to
say
that
everyone
follows
you
know
some
people,
just
you
know
like
to
set
it
to
high
whatever
reason,
but
you
know,
like
I,
said
that
that
is
just
up
to
the
people
in
that's
in
this
whole
system
and
I.
Think
that's
fine.
We
can.
We
can
just
assume
that
people
are
going
to
know
what's
best
for
that
incident
and
kind
of
go
from
there.
I
don't
think
we
should.
You
know,
try.
B
To
what,
if
what,
if
some
person
would
like
to
race
or
decrease
the
severity
of
an
incident
should
City
events
have
support
for
then
somehow
changing
and
modifying
the
severity
as
well?
Or
is
that
just
an
initial
severity
some
from
from
the
producer
and
then
it
will
probably
be
reflected
in
the
ticket
created
or
maybe
then
the
ticket
could
have
could
be,
have
severities
changed
in
it?
But
not.
The
original
incident
will
never
change
or.
C
A
Yeah
I
think
for
for
the
incident
events
when
we
discussed
about
them
with
Eric
in
the
in
a
presentation
with
them
of
Laura
metrics.
We
always
said
that
we
should
expect
for
incident
events
to
have
to
support
having
multiple
instances
of
the
same
event,
because
it
could
be
the
same
event
reported
by
different
sources.
So
we
could
have
a
updates
or
incremental
updates
on
the
same
incident
from
the
same
source.
A
So
we
should
be
possible
to
set
the
same
event
with
the
same
incident
ID
and
everything
but
a
new
severity,
and
that
would
mean
that
the
new
severity
is
what
is
meant
so.
C
C
Don't
even
know
how
you
do
that
somehow
group
them
like
you
would
need
to
have
some
sort
of
knowledge,
but,
like
Emil
was
saying,
if
you,
if
you
send
an
event
with
a
severity,
that's
high
it
it
would
duplicates
it
would
page
keep
paging.
C
D
A
Okay,
yeah
in
general,
I,
I,
wanted
to
say
and
I
would
tend
to
to
avoid
like
updated
predicate,
because
that
means
you
must
know
that
you
already
sent
a
previous
one.
That
is
the
initial
one
yeah
the
the
detector
implies
that
I
mean
I.
I
got
some
information
about
it,
but
I'm
not
saying
I'm
the
first
one
or
the
only
one
who
detected
this
information.
That's
what
I
was
trying
to
to
convey
about
that.
A
So
if
we
say
started,
then
it
would
I
wanted
to
avoid
the
starting
because
I
think
I'm
I
I,
don't
want
to
imply
that
if
I
sent
this
event,
I
have
an
overarching
knowledge
that
I'm
the
first
one
to
you
know
saying
that
something
is
going
on,
because
that
could
be
very
difficult.
We
could
have
different
parties
looking
at
the
system
and
you
it
would
be
really
hard
for
some
party
to
to
know
that
this
is
the
very
first
information.
C
We
talked
about
this
yeah
to
expand
all
that
I
think
what
might
be
good
for
the
spec
then
for
CD
events
in
general
is
any
event
type
needs
to
be
stateless.
Once
you
introduce
States
what
I
mean
by
States
is
like
you
know,
events,
you
know
you
have
something
that
is
now
severity
or
started
right.
That
introduces
a
state
in
the
CE
of
events
ecosystem.
C
Where
now
things
can
you
know
that
need
to
update
it
or
see?
The
events
need
to
do
something
to
you
know,
trigger
a
series
of
other
events
and
then
propagate
makes
this
system
really
complicated
by
having
things
stateless,
where
it's
just
saying
it
did
this.
If
you
know
a
system
finished
this
rather
than
started,
this
makes
things
a
lot
more
simple,
but
started
or
started
is
still
really
nice
to
have,
though,
and
I.
D
B
C
B
D
C
Yeah
I
mean
you
could
make
the
argument
that
instances
do
you
have
a
starter
finish
though,
but
but
yeah
I
but
I
agree
with
what
you
were
saying.
Andrea
of
you
know
wanting
to
avoid.
C
You
know
having
you
know
having
some
knowing
no
knowing
what
the
system
is
doing
or
you
know,
because
then
it
requires
you
to
have
Insider
knowledge
on.
You
know
what
that
system
is
doing.
You
know
what
how
it
reacts
and
and
all
that
and
I'm,
a
big
fan
of
you
know,
like
you
said
in
in
the
document
there
keep
things
simple
and
I
think
you
know
keeping
severity
just
out
of
it
makes
makes
perfect
sense
and
I
I
think
you
know
we
should
strive.
C
What
you
were
saying
you
know
try
to
keep.
You
know,
try
to
keep
things.
I
I
want
to
use
the
word
stateless,
but
I,
don't
know
if
that's
a
good
word
to
describe
what
we're
talking
about,
but
but
I
get
what
you're
saying
Andrea
foreign.
A
Yeah
thanks
I
will
update
accordingly,
then
just
I
mean
we
have
a
few
all.
Only
a
few
minutes
left
I
just
wanted
to
to
show
in
general.
What
are
the
General
fields
that
I
was
envisioning
for
this
apart
from
did
source
I
thought
it
would
make
sense
to
have
a
description
at
least
a
freestyle
description,
so
that
we
could
use
for
now
to
I
guess
some
context
about
the
incident
and
then
reference
to
the
environment,
where
the
incident
happened.
A
C
A
Yeah
so,
but
this
is
in
the
SDK,
then
becomes
a
reference.
So
it's
since
every
object
is
identified
univocally
by
a
combination
of
ID
and
Source.
A
It
means
that
here
we'll
need
to
have
either
the
ID
only
if
the
source
is
the
same
or
if
the
source
is,
if
the
ID
is
unique
enough
or
ID
and
Source
like
in
this
case-
and
this
is
just
a
link
to
the
environment
which
is
broken.
Why
is
it
broken?
Well
I
need
to
check
that,
but
we
basically
have
in
the
continuous
deployment
we
talk
continuous
deployment.
Where
is
it
okay,
yeah?
It
doesn't
show
it
to
me
here,
but
we
have
a
definition
of
environments.
A
C
Those
links
are
the
schema
like
I
I,
didn't
understand
if
it
were
was
or
wasn't
and
like
I
said,
I
I
couldn't
yeah,
you
know,
click
the
link
four
to
four
right.
So
was
it
or
was
it
not
the
schema
of
what
that
represents
with
that
object?.
A
Yeah
yeah
it
does
okay,
cool
cool
yeah
and
then,
if
you
look
at
the
reported
it
will
be
related
to
detected
only
the
environment
would
be
mandatory.
C
A
B
A
Yeah,
that's
an
object
that
that's
a
very
good
question:
I
mean
the
reason
why
I
only
have
artifact
I
put
only
artifact
ID
there,
because
we
use
artifact
daily
in
other
events,
and
it's
because
we
we
chose
this
plural
format
that
is
meant
to
be
globally
unique,
regardless
of
the
source
because
it
can
can
include
the
source
as
well.
D
A
A
We
should
just
use
IDs
the
problem
with
with
IDs
yeah
I,
don't
know
if
it's
globally
valid
or
not
because
in
the
in
the
spec
like
when
we
have
environment
events,
we
say:
okay,
we
have
ID
and
you
have
the
source
of
the
event,
and
so
the
ID
must
be
unique
within
the
source
and
like
in
this
case,
for
instance,
the
source
could
be
your
infrastructure
is
a
service
in
written
one,
but
on
the
flip
side,
maybe
you
have
like
Global
unique
names
for
your
environment,
so
you
don't
need
to
specify
a
source.
A
A
All
right,
well,
I,
guess
we
are
almost
a
time
now,
but
I
think
I
got
already
quite
some
good
input
and
what
I'll
do
maybe
I'll
try
to
inject
where
possible.
Some,
like
reasoning
behind
decision
for
names
and
things
that
we
discussed
during
the
meeting
I
think
that
it's
probably
something
we
should
try
and
do
also
in
the
future,
so
that
we
try
keep
track
of
our
decisions.
B
D
A
All
right
connecting
events,
there
was
no
progress
since
last
time
we.
A
C
I
said,
I
was
going
to
work
on
it.
I
have
been
just
dreadfully
busy
at
working
at
Apple
and
so
I
will.
I
will
allocate
some
time,
though,
in
these
next
two
weeks
to
look
over
your
proposal,
see
if
I
can
make
any
suggestions
and
see
where
we
can
expand
on,
because
I
thought
it
was
pretty
Bare
Bones
when
I
first,
when
I
first
saw
it.
So
we
can,
we
can
definitely
or
I,
can
definitely
try
to
make
some
suggestions
and
we
can
go
from
there.
Sound
good.