►
From YouTube: CDEvents Working Group (EMEA/APAC) - Jan 16, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
D
Oh
yeah.
We
have
to
meet
this
week
as
well.
C
Yes,
that
would
be
great.
Are
you
in
back
in
Australia
now.
D
Yeah
yeah
I
just
got
here
last
week
late
last
week,
so
I'm
all
settled
back
into
normal
time,
which
is
good.
B
C
Hello,
nice
to
meet
you
and
nice.
E
And
nice
to
meet
all
of
you,
Brad
I've
met,
let's
see
I
think
maybe
Bruno
is
joining
too.
Let's
see.
E
E
E
D
D
D
How
are
you
yep,
yep.
D
This
one,
this
one's
because
we're
doing
we're
looking
for
early
bird
submissions
and
the
deadline
was
like
they're
like
okay.
We
need
some
early
bird
submissions.
You
have
a
week.
So
it's
not
it's
not
a
lot
of
time
to
tell
people
so
I'm,
trying
to
tell
as
much
people
as
I
can.
D
I
think
so,
yeah
we're
actually
I
just
asked
that
question.
If
there
was
a
couple
of
questions,
if
one
person
can
be
virtual,
another
one
presenting
I'll
get
back
to
it.
It's
a
good
question.
D
C
Where
are
you
I
I'm
in
the
UK,
okay
and
Wales
action
right.
C
Not
from
the
UK
originally
Italian
board.
C
All
right,
yeah
thanks
everyone
for
joining
just
kick
off
the
meeting,
so
we
can
get
started
so
welcome
to
the
City
events.
Working
group
today
is
January
the
7th
the
16th
yeah.
We
have
a
participant
list,
feel
free
to
add
yourself
to
the
participant
list.
If
you'd
like
to
just
put
the
link
to
the
to
the
notes
in
the
chat,
everyone
is
it.
C
So
we
have
a
few
things
on
the
agenda
today.
Just
pushed
up
the
test
events
proposal,
since
you
Bruno
and
Ola-
are
here
today.
So
thanks
for
joining.
Thank
you
just
wanted
to
quickly
review
the
reaction
items
for
last
week.
First,
so
the
first
one
is
a
SDK
Java
pull
request
that
was
marked
as
need
review.
So
there's
some
review
comments
from
jalander
and
myself,
so
I
think
it's
back
to
the
to
Adam
the
author
to
continue
review.
C
And
the
second
point
from
last
week
was
the
Spinnaker
RFC
and
whether
we
should
have
an
adult
meeting
so
I
left
a
comment
about
that
on
the
ERC
itself,
yeah
I
haven't
heard
anything
from
Ben
whether
he
is
organizing
a
meeting
yet
but
yeah.
But
that's
all
the
updates
I
have
from
that
today.
B
C
Okay,
thanks
for
that
quick
question:
do
we
want
to
update
the
meeting
notes
on
a
yearly
basis,
so
I
can
create
an
archive
file
for
2022
and
update
this
link
to
be
the
the
running
one
or
we
can
keep
it
a
large
front.
B
C
C
C
All
right
yeah,
that's
all
for
the
kind
of
initial
logistic,
so
Ola
or
Bruno.
Would
you
like
to
miss
Casio
proposal.
E
Sure
so
yeah,
just
for
the
record,
I
am
I'm.
Only
Bruno
is
with
the
test.
Cube
project
and
I've
been
in
touch
with
facility
and
Brad
times,
and
we
just
discussed
the
the
or
the
possibility
to
Define
top
level
testing
events
I'm
going
to
share
some
screen.
Is
it
if
you
could
you
allow
that.
C
Yeah
I
think
as
long
as
I
stop
sharing
you
should
be
able
to.
But
let
me
know
if
not.
E
Challenge
of
having
here
we
go
so
so
the
it's
a
work
in
progress.
Obviously,
so
what
is
it
so?
An
addition
of
top
level
testing
related
events
to
the
city
event,
spec,
and
why?
E
Because
from
our
experience,
testing
is
often
performed
kind
of
out
of
bounds
or
independently
from
cicd
workflows.
So
I
know
there's
already
today
in
this
continuous
integration
events.
There
are
some
test
related
subjects
and
predicates,
but
we've
seen
it's
pretty
common.
That
tests
are
not
around
kind
of
independently.
So
if
you're
like
a
loader
performance
engineer,
you
run
these
tests
separately
or
you
might
run
security
tests
or
compliance
tests
that
you
run
independently
of
UCI.
E
Also
the
possibility
that
you
know
people
run
tests
manually
or
like
in
an
ad
hoc
way
or
if
they
are
kind
of
reacting
to
other
events,
not
specifically
CI
related
workflows,
you
might
be
triggering
tests
from
I,
don't
know
something
happening
in
your
cluster
or
from
slack
or
I,
don't
know
from
some
schedule
or
just
some
tester
goes
in
and
runs
a
test
that
they
want
to
rerun
and
also
something
we
see
quite
often
is
with
test
Cube
and
also
I.
E
Just
used
to
work
at
smart
bear,
which
is
a
testing
company,
is
you
know,
you
run
the
same
test
multiple
times
simultaneously
for
you
know,
either
by
by
a
purpose
or
not,
but
we
might
want
to
kind
of
provide
some
way
to
handle
that
or
understand
what's
going
on,
and
obviously
this
is
inspired
by
the
test,
related
subjects
and
predicates
that
you
already
have
Under
The,
Continuous
integration,
test
events
topic
so
and
obviously,
of
course,
we
want
to
start
very
small,
so
I've
started
I'll
I'll
open
this
in
just
a
sec
like
a
proposal
I've
just
you
know
kind
of
worked
off
the
format
that
you
guys
already
have
on
GitHub,
working
with
test
case,
test
Suites
and
adding
a
test
artifact
subject,
which
could
be
like
a
video
or
a
report,
or
you
know
a
log
or
something
that's
kind
of
produced
by
a
test.
E
It
really
depends
on
the
type
of
test
that
you're
running
and
where
you
know
the
the
fields
in
the
corresponding
predicate
would
provide.
You
know
a
URL
or
a
way
to
access
that
that
artifact
I
think
there's
I
mean
there's.
You
know,
I'm
sure.
E
As
you
know,
there's
a
lot
of
things
that
come
to
mind
when
you
and
we
will
try
to
keep
it
reasonably
simple
at
this
initial
point,
maybe
as
I'm
one
thing
that
I
we
were
thinking
about
and
I,
don't
know
if
you
have
any
strong
opinions
here
is
if
test
execution
should
be
a
subject
in
itself,
because
the
model
is
usually
that
you
have
a
test
case
or
a
test
Suite
when
you
run
that
which
creates
an
execution
which
is
a
short-lived
object
or
well
could
be
a
pretty
long-lived
depending
on
the
type
of
test,
and
then
that
results
in
one
or
more
test
artifacts,
and
once
again
this
is
to
kind
of
separate
between
multiple
executions
of
the
same
test,
or
you
know
as
a
test
changes
over
time.
E
You
might
you
know,
usually
tests
evolve
and
you
have
versions
of
tests
Etc.
You
might
want
to
kind
of
associate
an
artifact
with
a
specific
execution,
so
we
kind
of
we
didn't
know
how
to
get
deep
to
go
so
I
I
kept
it
pretty
shallow
or
at
least
from
our
point
of
view,
and
then
there's
a
document,
a
test
events
document
which
is
find
it
here.
No,
that's
not
it!
Sorry!
Here
we
go.
E
This
is
a
fork
of
the
repo,
so
where
I've,
basically,
these
three
subjects
for
test
case
we've
added
a
Fields,
an
optional
type
of
test
severity,
critical,
aluminum,
High,
an
optional
review
URL
to
access
the
actual
test.
This
is,
of
course,
too
independent.
E
Test
Suite,
as
before
is
more
a
grouping
of
tests,
so
we
kind
of
piggyback
to
what
you've
already
done
there
and
then
test
artifacts,
which
is
a
describes,
an
artifact,
so
there's
a
type
of
artifact.
It
could
be
like
a
report,
video
image
style.
This
was
an
enumeration
I,
don't
know,
I'm
happy
to
obviously
add
things
or
remove
a
format
which
would
be
the
content
type,
which
should
make
it
easier
for
a
Target
system
to
know
what
to
do
with
that
actual
artifact
and
then
URI
references
to
those
objects
or
artifacts.
E
So
and
then
there
are
some
events:
I,
don't
know
how
deep
you
want
to
go
on
this
call
and
I.
Don't
know
what
the
process
is
here.
So
I,
just
I
guess
wanted
to
throw
this
out
there
and
see
see
what
your
reaction
is
and
if
you,
if
we
should
open
a
PR
or
if
we
should
have
a
separate
call
or
if
I
should
write
some
more,
you
know
background
or
I,
don't
know.
What's
what
what
are
you
guys
thoughts
around
the
process
of
moving
this
forward.
C
Yeah
thanks
for
that,
I
I,
don't
think
we
have
any
like
very
strongly
defined
process
because
we
are
a
small
group,
so
we
should
kind
of
discuss
about
things
in
in
meetings
and
and
or
issues
and
make.
C
A
C
Yourself
and
Bruno
that
are
working
in
the
test
area
and
they're
proposing
about
the
things
about
the
test.
That's
very
useful.
C
E
C
E
Would
keep
the
these
events
here
that
you
have
these
are
to
this
I
guess
it's
a
good
question.
It's
a
good
question
in
the
sense.
Is
there
a
risk
for
we
should
maybe
keep
these
two
subjects
aligned
so
they're
not
diverging
from
each
other,
but
it's
I
still
think
it
makes
sense
to
have
because
it's.
D
E
F
Yeah
and
like
a
bit
also
a
big
difference
if
I
might
just
like
other
people,
so,
for
example,
that
artifact
is
more
around
tested
right
continuously,
integration,
where
you
see
RT
packed
there
means
like
a
deal,
was
safely
done
where
here,
the
SRT
packs
is
more
like
the
artifacts
of
a
test
itself.
So
there's
like
a
different
meanings
on
this
events,
for
example
in
in
the
other
side,
is
more
about
the
deployment
itself,
whereas
here
is
more
Auto
integrate
your
test
events
with
other
tools.
F
The
motivation
for
this
was
actually
how
to
communicate
in
a
synchronous
manner,
with
other
components
that
want
to
either
deploy
or
promote
applications
to
environments
based
on
on
things
that
happens
with
tests.
So
and
that's
why
we
are
addressing
these
events
are
really
more
specific
towards
testing
scenarios
where
the
other
ones
are
more
like
focused
on
on
the
continuous
deployment.
E
B
Yeah
I
have
so
few
thoughts.
Yes,
I
know
that
we
have
the
build
events
today,
which
are
like
the
only
events
apart
from
pipelines,
Pipeline
and
the
step
events
which
are
kind
of
life
cycle
events,
if
you
will
that
tell
something
about
something
being
scheduled
and
started
and
finished,
and
so
on,
and
for
sure
one
good
thing
that
any
thing
that
happens
in
a
pipeline
are
steps
in
some
way
and
then
everything
could
just
be
noted
as
pipeline
steps,
but
at
the
same
time
I
know
we
have
the
build
events
there.
B
So
why
not
have
test
events
at
this
as
the
same
same
level,
then
where
to
draw
the
line?
Of
course
it's
it's
hard
eventually.
So
that's
maybe
one
one
reason
for
me
being
a
bit.
What
should
I
say,
not
skeptic,
but
a
bit
I'm,
not
sure
how
long
we
should
take
how
far
we
should
go
with
defining
specific
types
of
actions
that
are
taken
in
a
pipeline.
I'm
sure
test
is
a
general
term,
but
then
we
have
delivery.
We
have
a
deployment.
B
We
have
production
with
other
things,
that's
one
aspect
of
it
and,
of
course,
we
should
relate
them
to
each
other.
At
least
I
mean
there
is
a
pipeline
somewhere
that
has
actually
been
executed,
and
if
we
execute
tests
it
should
relate
then
to
the
pipeline
execution
connect
to
it
in
some
way
and
then
to
the
point
of
where
to
place
this.
The
these
events
we
see
now
are
in
the
completely
integration
bucket
and
for
sure
tests
are
performed
within
the
continuous
integration
base
of
your
pipeline
as
well.
B
If
you
will,
but
for
sure
tests
can
be
done
wherever
also
in
the
delivery
or
deployment
pipeline,
they
could
be
tests
as
well.
So
I
understand
that
there
is
a
bit
it's
a
bit
hard
to
categorize
this
kind
of
events
into
one
of
these
continuous
blah
blah
blah
events
so
yeah,
we
don't
have
a
crisp
definition
of
what
these
buckets
are
supposed
to,
how
they
should
divide
the
the
group
of
events.
Let's
say
yes,.
D
B
D
I
was
going
to
say
I
think
for
scalability,
for,
in
my
opinion,
it
makes
sense
to
be
outside
the
CI,
because,
later
on,
when
we
add
more
that
you
know
you
could,
you
could
probably
technically
have
a
smoke
test
that
runs
in
the
CD
space.
That
would
just
make
sure
that
the
environment's
ready
or
working
as
it
should
so
possibly
for
scalability.
It
might
be
better
to
have
it
in
its
own
bucket.
E
E
A
C
Yeah
I'm
a
bit
wary
that
I
have
a
multiple
test
case.
Type
of
events
might
generate
confusion
about
which
one
to
adopt
as
I
say
if
you're
sending
events
do
I
should
go,
send
the
ones
from
the
CI
bucket
or
the
one
from
the
test
bucket.
I
think
this.
This
buckets
were
originally
designed
to
where
we're
thinking
about
I
guess
compliance,
because
it's
it's
a
large
scope
for
City
events.
So
if
you
wanted
to
say
well
as
an
application,
I'm
implement
City
events
I,
don't
necessarily
need
to
implement.
C
You
know
all
the
events
in
in
City
events,
because
that's
not
likely
going
to
be
the
case
for
any
system,
so
we
could
say
well
if
I
implement
the
events
in
the
testing
buckets
or
in
the
CI
bucket
or
in,
and
that
was
the
I
guess.
One
of
the
reason
for
for
this,
this
buckets,
but
we
have
not
actually
defined
yet
any
compliance
policies
or
anything.
So
at
this
stage,
they're
just
kind
of
a
little
logic.
Regrouping
but
I
think
example
said
it's:
it's
kind
of
hard
to
cut
things.
C
You
know
to
separate
them
exactly
I
mean
there
is
always
going
to
be
an
overlap.
Personally,
my
preference
I
I,
don't
mind
having
a
testing
group,
but
I
would
then
prefer
to
drop
or
move
the
existing
test
cases.
C
It
can
be
in
the
format
that
you
propose
into
the
testing
events
bucket
and
maybe
having
some
filled
like
you,
you
already
have
some
some
Fields
for
it
to
type
I
believe
or
we
could
have
an
extra
attribute
to
define
whether
there
is
a
a
reference
pipeline,
CI
pipeline
or
so
that's
something
we
can
also
add.
Incrementally
we
don't
have
to
do
it
in
the
initial
model.
E
And
this
is
where
the
execution
test
execution
thing
comes
on,
because
you
might
run
the
execution
could
be
in
the
scope
of
a
pipeline
right,
but
it
could
also,
sometimes
you
might
run
the
test
as
part
of
your
pipeline.
But
then
sometimes
you
might
run
it
as
not
as
part
of
the
pipeline
or
so
the
pipeline
would
is
more
related
to
the
actual
execution
and
not
the
test
itself.
E
C
My
question
there
would
do
you
have
any
use
case
or
Automation
in
mind
for
events
Associated
to
the
test
case
definition
or
test
definition.
So
would
you
have
events
like
okay?
A
new
test
case
has
been
defined.
A
new
test
suit
has
been
defined
or
has
been
modified
because.
A
E
Yeah
I
didn't
add
those
deliberately
because
it
felt
like
those
were
outside
the
scope
of
continuous
delivery
or
is
continuous
deployment.
I
didn't
I
couldn't
come
up
with
this
scenario,
where
those
would
be
relevant,
I
mean
we
can
add.
You
know
a
bunch
of
to
your
point,
like
predicates,
created,
modified
deleted
kind
of
four
test
cases
and
test
Suites,
but
I
couldn't
like
in
the
context
of
CD.
E
When
would
that
be
interesting?
If
there
was
if
this
was
like
a
test
management
thing,
then
definitely
right,
because
then
it
would
be
interesting,
but
if
I
mean
that's
not
saying
it's
just
saying
that
I
didn't
come
up
with
him.
That
doesn't
mean
that,
obviously
they
don't
exist.
So
if
you
can
come
up
if
we
can
come
up
with
some
areas
where
it
would
be
relevant
in
this
context
of
CD
to
know
when
a
new
test
has
been
created
or
a
test
has
been.
F
F
What
much
like
it's
running
I
mean
that
event
happened,
so
that's
it
and
then
that's
the
event
and,
for
example,
if
a
test
is
created
and
somebody
wants
to
have
a
component
just
execute
any
test
that
is,
for
example,
on
a
certain
environment,
if
that's
a
use
case,
I'm,
not
sure
if
it's
just
like
a
very
common
one,
but
I
mean
we
can
write
this
back
for
it.
B
I
also
have
a
small
comment
there
on
the
not
executing
it
in
a
pipeline,
as
we
talked
about
there,
so
I'm
just
wondering
or
thinking
about
the
scope
of
seed
events
itself.
The
whole
protocol,
which
is
intended
to
be
a
protocol
for
continuous
integration,
continuous
delivery
deployment
and
those
continuous
practices.
B
B
So
we
have
a
conscious
decision
there
that
we,
we
must
allow
for
events,
see
the
events
to
descent,
also,
on
a
as
I
said,
the
notification
from
slack
or
schedule,
or
something
else,
I
see
it's
of
course
relevant
to
use
the
same
way
of
notifying
these
kinds
of
executions,
regardless
of
if
it's
from
a
cicd
system
or
if
it's
from
a
manually,
triggered
execution
or
something
else,
but
yeah
just
to
be
aware
of
that.
B
B
Yeah,
because
if
we
would
go
there,
that
way,
we
could
say,
of
course
that's
what
anything
you
deploy
manually
in
a
system
could
also
then
send
these
CD
events
for
deployed
serial
deployed
over,
and
it's
called
outtrack
deployment
and
similar
things.
So
where,
where
to
draw
the
line,
then
on
when
to
send
City
events
or
not.
C
A
C
Point
of
view,
I
think,
even
if
the
pipeline
is
not
automated
from
it's,
not
automated
through,
like
a
pipeline
orchestration
engine
like
if
Jenkins
detect
on
or
whatever
tool,
it's
still
in
a
way
a
pipeline
I
mean
if
you're
going
for
a
soft
and
delete
software
implementation
and
delivery,
you
will
have
like
some
kind
of
tests
that
you
execute
in
different
stages
and
even
that,
even
if
that
pipeline
is
not
an
automated
pipeline,
it's
a
kind
of
a
process
pipeline.
C
These
events,
this
Manual
triggering
of
events
as
well
as
Manual
triggering
of
deployments
and
so
forth.
They
they
belong
to
to
City
events
but
yeah.
So.
B
C
Yeah
I
guess
I
mean
continues
in
continuous
delivery
is
not
necessarily
automated
delivery,
though
I
would
argue,
I
mean
you
could
have
continuous
manual
delivering
well
yeah,
but
I
I
know
that,
like
effective,
continuous
delivery,
best
practices,
you
know
they.
A
C
They
go
towards
automating
as
much
as
possible
because
that's
how
you
can
achieve
like
high
frequency
of
deployments-
and
you
know
good
good,
Dora,
metrics
and
so
forth.
But
if
you're
doing
things
manually,
you
may
still
be
doing
continuous
deliveries.
But
you
won't
have
like
height
throughput
of
things.
D
E
But
that
maybe
an
extension
here
or
a
consequence
could
be
of
this
discussion-
is
to
say
that
there's
testing
is
it
if
we
say
testing
or
or
if
we're,
okay
with
those
being
top
level
events,
we
might
also
Advance
some
point
think
that
we
might
have
build
related
top
level
events
and
artifact
related
top-level
events,
and
then
the
this
becomes
more
a
bucket
of
different
sequencing
of
steps,
like
you
said,
email,
whereas
each
step
could
refer
to
something
in
another
top
level
around
the
bucket
right,
so
it
could
be.
E
E
So
we
don't
end
up,
duplicating
or
having
like
misaligned
yeah,
so
duplicates
in
multiple
buckets.
Does
that
make
sense.
B
And
one
one
other
thing:
I
was
just
thinking
about.
Maybe
it's
a
detailed
thing,
but
you
you
mentioned
test
artifact
there
in
your
proposal
right
yeah,
so
we
have
artifacts
already
when
we
perform
a
build.
We
it
results
in
an
artifact,
yes,
I'm,
not
sure
Andrea
I
do
remember
what
we
have
said
about
like
log
files
from
a
build
and
such
things
or
all
those
okay
to
announce
this
artifact
as
well,
or
does
an
artifact
yeah
for
the
output,
so
it
could
be
include
a
long
quiet,
Maybe.
B
E
E
C
Yeah
I
can
see
we're
not
explicitly
limited
artifacts
to
being
certain
things.
C
What
we
discussed,
though,
is
that
we
wanted
to
use
the
the
Pearl
format,
so
the
package
URL
format
we're
describing
artifacts
produced
by
a
build.
C
Okay.
Is
that
potential
sorry
a
link
to
the
chat?
So
maybe
you
could
have
a
look
and
verify
whether
that's
something
that
you
think
could
work
for
test.
Artifacts,
I,
think
Pearl
is
actually
specific
to
packages
so,
whether
it's
a
distribution
package
or
whether
it's
a
container
image
or
some
kind
of
npm.
A
C
And
Reservoir
so
I
think
that's
not
meant
to
be
used
to
describe
things
like
log
files
or
links
to
a
video
and
so
forth.
But
that's
that
said.
C
We
would
probably
then
need
some
kind
of,
or
we
could
have
some
kind
of
more
generic
artifact
concept
also
for
a
build,
because
we
we
could.
We
might
want
eventually
to
to
include
the
link
to
to
the
build
logs.
C
So,
let's
yeah
I
think
it.
It
makes
sense
to
to
have
some
artifact
concept,
which
is
bound
to
back
to
software
artifacts,
because
it's
it's
more.
It
has
a
more
specific
set
of
attributes
that
might
not
be
relevant
or
for
other
things
like.
We
were
planning
of
introducing
things
like
maybe
s-bomb
signatures
and
and
this
kind
of
things-
and
you
won't
have
an
esplan
for
a
log
file,
for
instance.
C
C
Yes,
that
that
said,
I
mean
for
from
a
build
point
of
view.
The
logs
are
probably
might
be
just
the
link
to
the
logs
might
be
just
a
field.
A
C
The
build
log
you,
you
will
do
much
automation,
but
for
the
test.
If
you
start
your
test
results,
and
so
you
might
want
to
have
it
as
a
as
an
artifact
and.
E
But
please
you're,
suggesting
that
we,
we
add,
like
a
package
or
some
kind
of
new
subject
with
you
can
refer
to
with
pearl
or
and
then
or
build
artifacts.
So
I
don't
know
what
you
want
to
call
it,
which
is
kind
of
separate
from
this
generic
artifact.
Or
should
we
just
add
a
discriminator
to
this
generic
of
kind
of
where
we
have
a
type.
C
Now
I
think
the
artifact,
as
as
we
have
today,
it's
it's
more
specific
to
software
artifacts,
really,
okay,
so
I
I
think
it
makes
sense
to
keep
it
independent
because
we
were
planning
of
expanding
it
to
at
things
like
s-bomb
sort
of
to
build
up
material
and
signatures,
and
things
like
that
and
those
are
really
specific
to
software
artifacts.
B
E
B
Yeah
I
don't
know
we
could
maybe
discuss
some
time
if
we
should
have
similar
data
formats
of
all
log
fields
in
our
different
events,
for
example.
So
if
you
would
have
a
deployment
log
and
a
some
kind
of
release,
logo,
or
something
like
that,
so
that
those
all
logs
be
formatted
or
the
date
information
about
them
in
our
events,
should
they
be
formed
the
same
way,
even
though
we
might
not
have
them
as
subjects,
then
we
still
would
like,
probably
to
reference
them
using
the
same
properties
and
so
on.
C
A
E
C
C
Trying
I'm
trying
to
to
figure
out
what
what
the
use
case
is
for
like
a
generic
artifact
and
subject
as
opposed
of
having
just
a
link
or
an
attribute
into
the
interior
subjects
if
it
makes
sense.
So,
if
you're,
if
you're
signing,
if
you
say
like
this
test
completion,
this
test
suit
was
executed
and
in
the
completed
event,
you
could
have
an
attribute
that
includes
a
link
to
the
logs
or
other.
C
B
E
Word
screenshot
or
multiple
screenshots,
depending
on
what
you're,
using
as
a
testing
tool,
so
I
I,
guess
you
could
have
an
array
of
artifacts
but
then
you'd
miss
out
I,
don't
know
if
you
want
to
have
different
content
types,
fridge
artifacts.
So
if
it's
video
or
whatever
so
from
I,
guess
you
could
embed
all
that
in
in
the
the
finished
event,
also,
sometimes
just
from
a
synchronicity
aspect
or
asynchronous
increase.
It
might
take
some
time
to
create
those
videos
or
to
make
them
available.
So
you
might
want
to
say
the
case
is
finished.
E
It
failed
and
then
you
know
a
minute
later.
You'll
get
the
event
and
here's
a
video
of
it
of
the
failure.
So
you
don't
have
to
wait
for
that
to
happen
just
depending
on
kind
of
the
once
again,
so
many
different
tools
work
different
ways.
So
that's
kind
of
one
of
the
reasons
I
think
we
put
it
out
into
a
separate
or
a
couple
of
reasons
why
it's
a
separate
object,
a
subject.
C
C
Yeah
then
my
proposal
would
be
I
mean
we
could
start
with
like
test
artifact
as
you
proposed,
and
maybe
we
could
consider
renaming
the
other
one
to
like
a
package
artifact
or
some
build
artifact.
E
C
Yeah,
but
I
would
keep
the
change
to
to
the
back
to
the
the
existing
guard
effect
may
be
separated
if
that's
okay
with
you,
okay,
but
yeah,
so
I
think.
C
So
that's
I,
guess
the
main.
The
main
feedback
I
would
have
on
on
this
and
then
yeah,
so
maybe
move
for
existing
and
adapt
it
and
should.
B
C
Don't
know
yeah
I
guess
the
other
thing
is
the
the
the
type
does
not
includes
should
not
include
the
sorry.
C
E
C
E
C
Think
that
was
on
purpose
because
yeah,
so
this
is
one
representation.
The
the
bucket
is
one
representation
of
the
events
is
but
yeah.
It's
not.
C
We
didn't
want
to
embed
that
representation
in
the
event
types,
yeah,
I'm
thinking
the
things
more
flexible,
yeah.
So
the
other
thing
in
in
the
spec
repo.
We
have
Json
schemas
okay.
A
C
Schema
for
each
event,
so
when
you,
when
you
go
and
update
the
schema
of
the
other
events,
types
if
you,
if
you
could
update
your
schemas
here
as
well
and.
C
Test
types
you
could,
you
could
make
an
Anu
here
in
the
schema,
if
you
wanted
to,
if
you
have
like
specific
strings,
that
you
think
it
would
make
sense
to
have
as
part
of
the
test
type.
For
instance,
you
could
have
Adam
editing
here
so
that
you
actually
formalize
on
these
are
the
strings
that
needs
to
be
used
to
identify
a
unit
test
or
endulin
test
and
so
forth
and
I.
Think
that
would
be
will
go
a
long
way.
Types
of
interoperability.
E
Yeah
I
agree:
it's
just
I
I
made
this
a
lot.
The
type
specifically
I
just
remember,
working
with
load
testing,
there's
like
stress,
testing,
performance
testing,
load
testing.
You
know,
there's
like
seven,
eight
facets
of
load
testing
and
there's.
This
can
be
like
a
heated
discussion
at
a
load,
testing
conference
and
I
and
I
I
didn't
I
didn't
want
to,
like
you
know,
to
make
a
put
a
stick
in
the
ground.
I'm
happy
to
do
an
enum
I'm,
just
I,
don't
know,
but
I
can
do
that.
D
D
Did
you
say
the
low
testing
conference
so
I
only
goes
to
the
performance,
testing
conferences?
Well,.
D
D
E
Load,
testing,
testing
and
Baseline
testing-
and
you
know
this
and
that
testing
and
then
they
get
quite
crazy
and
then
the
same
with
functional
testing
and
so
I
I
don't
want
to
get
into
the
I.
Just
I
was
being
like.
You
know:
swedishly
swedishly,
careful
here,
but
I'm
happy
to
put
a
stake
in
the
ground
and
say
these
are
the
and
if
people
we
can
extend
that
enum
over
time.
So
but
so
I'll
do
that
and.
C
As
you
wish,
I
mean
it
doesn't.
It
can
also
be
an
additional
PR
and
we
can
also
do
some
like
background
research.
If
you
want
to
provide
names
used
in
the
wild
but
different
tools,
and
then
we
can
come
to
an
agreement
on
specific
names,
it
doesn't
have
to
be
in
the
original
PR.
So
I
understand
your
concern.
E
C
Okay,
okay,
great!
Thank
you
all
right,
I
hope
we
we
have
enough
to
send
for
a
Next
Step.
B
We
have
in
in
a
relating
interoperability.
There
is
a
vocabulary,
work
on
going
since
years,
back,
which
is
quite
far
from
being
done,
but
there
are
discussions
there
on
names
for
different
things.
Okay,
so
there
is
a
pipeline's
terminology
document
in
there,
for
example,
and
there
is
also
a
what
is
it
called
now
tools
terminology
document,
but
for
this
discussion
is
mostly
for
the
pipeline
technology,
and
there
are
discussions
there,
for
example,
on
what
maybe
not
exactly
what
is
along.
B
But
it's
mentioned
there
is
generated
software
and
generated
binaries,
which
we
I
think
we
should
be
aligned
with
whatever
that
vocabulary,
work
ends
up
with
So.
Eventually,
we
might
need
to
change
data
these
terms,
but
as
as
they
are
not
defined,
yet
they
are
not
really
set
in
stone
what
they
should
be,
but
it
could
at
least
serve
as
an
input
for
for
this
work
as
well.
B
D
C
Okay
yeah,
so
thanks
again
for
for
your.
C
Leadership
on
this
guys,
so
it's
much
appreciated
and
it's
great
to
see
you
joining
our
meeting
and
yeah.
So
look
forward
to
to
the
next
step
on
this.
E
So,
to
be
specific,
there
then
we'll
try
to
incorporate
all
your
feedback
and
should
be
open
like
a
draft
PR
and
and
share
it
or
what
would
you
suggest
or
should
we
wait
for
the
next
meeting.
C
Yeah
I
would
say,
then
we
can
iterate
on
more
details
on
the
pr
if
needed,.
C
We'll
do
all
right,
we
have
only
eight
minutes.
Left
I
wanted
to
say,
welcome
your
sorry
trouble
during
the
meeting.
We
have
a
couple
of
things
more
in
the
with
agenda,
but
if
there
is
anything
that
you
want
to
do
to
bring
up
to
this
meeting
today
feel
free
to
jump
in.
C
Okay,
maybe
just
a
couple
of
comments
on
the
incident:
I,
don't
know
we
can
have
a
long
discussion
because
we
only
have
a
few
minutes.
C
We
had
some
comments
by
Emil
and
by
Andrea
Meyer
on
the
incident
issue.
So
thanks
for
that-
and
it
was
good
to
see
also
contributions
Bye
by
Andrew
and
always
good
to
get
new
contributors
commenting
on
things
so
I
guess
the
the
current
proposal
would
be
to
to
start
with
a
minimal
data
model
based
on
the
on
the
comments
there,
and
and
also
to
to
have
a
formal
definition
about
the
incident
means
in
fact
Simon
for
bringing
that
up.
C
B
So,
just
shortly,
what
we
then
mean
with
incidents
based
on
the
discussion
we
got
on
the
ticket
Andreas
is
that
it's
some
kind
of
degradation
degradation
of
a
service?
So
it's
actually
intended
to
be
the
base
for
a
Dora
metric
where
it's
either.
Using
this
event,
you
could
calculate
the
time
to
restore
service
or
time
between
failures,
I
think
it's
called
right
or
nothing
about.
C
B
C
That
would
be
my
definition,
so
some
some
degradation
of
a
production
environment,
as
opposed
to
of
like
a
softer
package
specifically
so
I,
would
see
it
as
something
like
performance
degradation
response
time.
Some
some
kind
of
metric
that
you
can
Define
for
your
production
environment,
which
is
degraded
that
triggers
an
incident.
And
then
the
incidence
can
be
root,
cause
and
could
be
Associated
to
I.
C
C
All
right,
yeah,
finally,
I
think
Brad
already
mentioned
this
in
the
beginning,
but
the
cfp
for
silicone
is
open.
It's
going
to
happen
in
May
next
year
in
Vancouver.
Yes,
thanks
Brad,
and
there
is
an
early
bird
that
ends
on
January
the
7th
which
is
tomorrow,
and
there
is
a
later
date
for
the
cfp.
I,
don't
know
if
right,
you
know
by
hard
when
that
is
otherwise.
C
Yeah
well,
if
anyone
has
any
more
conference
there
should
be
under
a
radar.
Please
bring
them
up
or
add
them
to
the
notes.
So
we
are
aware.
C
Okay,
right
I,
don't
think
we
have
any
other
updates
on
python
SDK.
Every
commissioner
could
not
be
here.
Maybe
Brett
briefly.
Do
you
know
if
there's
anything
new
on
the
Jenkins
site
have.
D
C
Okay,
any
final
remark
from
anyone.
E
B
The
intention
there
is
to
to
not
discuss
in
depth
details
of
the
citizens
protocol
itself,
but
rather
events
in
general
in
general.
It
could
be
outside
events,
the
protocol
as
well,
so
it's
more
presentations
on
how
events
are
used
in
other
kinds
of
systems
or
other
City
systems
which
we
might
eventually
relate
to
so
such
more
General
event.
Discussions
are
held
there
and
also
some
formatted
this
as
well.