►
From YouTube: CDEvents / SIG Events Vocabulary Meeting - Apr 5, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
B
B
I
got
elected
to
the
open
ssf
board.
B
B
So
I
don't
I
I've
got
another
call
like
in
15
minutes,
but
I
did
want
to
let
you
guys
know
so
I
I
was
able
to
get
into
bevy.
B
B
E
D
B
E
B
Ortillius
she
gave
us
a
community
for
ortillius.
It
wasn't
in
cd
events
now,
because
I
asked
her
to
give
me.
B
D
D
E
H
B
B
C
H
F
J
C
C
F
The
agenda
for
today
we
have
the
three
events:
a
city,
con
event
and
there's
the.
C
J
F
F
F
A
K
I
have
not
been
to
this
meeting.
I've
been
to
the
monday
meeting
one
time
a
couple
weeks
ago,
a
quick
introduction.
I
am
a
product
manager
for
gitlab
and
I
see
the
events
I
learned
about
cd
events
towards
the
beginning
of
this
year
and,
frankly,
it's
something
that
we
like
this
concept
of
having
events
for
gitlab
itself.
It's
it's.
I
I
viewed
that
as
a
really
big
me
and
obviously
interoperability
with
other
systems.
It's
also
important.
A
Nice
now
we're
discussing
a
little
bit
on
on
the
the
meetups
that
we're
having
coming
in
about
the
city
corner
and
then,
but
you
know
more,
but
I'm
talking
sandra.
I
took
over
there
from
you.
A
F
It's
great
to
have
you
given
thanks
for
joining
yeah,
so
we
have
a
few
events
coming
up.
So
one
thing
that
I
wanted
to
start
mentioning
is
the
city
events
so
the
event
at
cdcon.
Basically,
we
have
half
a
day
there.
F
It's
going
to
be
june,
the
ninth
in
the
afternoon,
and
there
there
was
a
deadline
on
friday
to
submit
some
some
deepers,
but
hopefully
we
can
still
amend
them
if,
if
needed
so
for
the
event
titles
I
put
like
city
events,
community
summit
and
I
drafted
a
small
event
such
description
there,
but
yeah.
If
you
have
any
input
or
any
suggestion
how
we
could
improve
on
that,
please
let
me
know,
and
then
I
can
send
it
to
cecilia
who
is
the
context
of
this
yeah.
F
So
hopefully
the
conference
is
in
austin
but
yeah.
So
the
idea
is
to
try
and
make
this
and
hybrid
events,
so
as
many
of
us
as
possible
can
can
join
in
and
different
from
city
events
con.
The
idea
for
this
event
would
be
to
to
be
more
of
a
workshop
or
design
type
of
event,
so
hopefully
an
opportunity
for
us
to
to
meet
and
discuss
about
the
spec
and
integration
with
other
projects,
doing
some
work
on
the
sdks
and
so
forth.
F
Yeah,
I
think
I
think
so
I
hope
so
at
least
that's
what
we
discussed
in
the
beginning,
that
this
would
have
to
be
a
hybrid
event,
because
when
we
did
the
google
form
at
the
beginning,
I
think
a
lot
of
people
said
that
they
would
be
able
to
join
remotely
only
so
I
I
think
that
for
this
to
work,
it
would
have
to
be
a
hybrid
event.
E
F
F
Yeah,
so
there's
still
some
time
until
that,
I
think
the
the
main
deadline
for
for
now
was
to
to
say
what
kind
of
to
give
like
title
description
expected
number
of
participants.
I
think
we
can
spend
some
more
time
in
the
next
few
weeks
planning
for
it
in
details.
F
F
F
Anything
else
on
this.
F
Okay,
I'll
move
on
to
cd
events
con,
so
the
registration
for
the
event
is
now
live.
So
if
you're
registering
to
kubecon,
you
can
add
yourself
to
the
event,
which
is
great,
I'm
still
missing
on
the
event
page.
So
if
you
go
to
this
url.
F
F
Also
we
have
a
draft
agenda
is
not
fully
up
to
date
with
the
latest
greatest
news,
but
this
is
what
it
looks
like
and
I
think,
as
soon
as
it's
finalized,
it
will
be
linked
into.
F
The
event
page
and
yeah
so
compared
to
these
the
session
at
1450
is
now
confirmed.
So
mauricio
and
ishan
will
be
discussing
talking
about
k,
native
and
city
events,
and
also
there
will
be
some
content
on
jenkins.
F
That
is
confirmed
so
oleg
they
offer
to
to
present
that,
and
they
also
actually
got
a
few
minutes
ago,
an
email
back
from
shooti
who
was
only
originally
on
the
gsoc
project
with
jenkins
and
events
that
should
be
interested
in
presenting
something
between
the
two
we'll
see.
What
we
can
we
can
have
here
as
a
talk
but
yeah
so
jenkins
will
be
represented
here
in
the
in
the
agenda,
which
is
great
and
yeah.
F
So
the
the
panel
is
still
in
the
works
again,
not
just
they
could
travel
they're
a
bit
of
a
hinder
there,
but
we'll
see
if
we
can
organize
it
either
remotely
or
in
person.
F
And
yeah,
so
we
are
also
discussing
with
the
linux
foundation
team
how
the
setup
for
hybrid
event
will
be
working
exactly
I
mean
most
of
the
talks
will
be
in
person,
but
there
are
some
remote
participants,
and
so
we
need
to
clarify
all
the
details
of
the
streaming
content
in
and
out
and
things
like
if
we,
if
we
need
to
manage
the
virtual
room,
who's
doing
that
and
yeah
that's
kind
of
the
open
questions.
K
F
All
right
thanks,
kevin
yeah,
it's
still
clarifying
how
that's
going
to
work
but
I'll.
Let
you
know,
then,
if
there
is
anything
you
will,
you
will
be
there
in
person
right,
correct.
That's
great!.
F
The
last
thing,
as
soon
as
the
registration
link
is
fixed
there,
I
plan
to
start
promoting
this
on
the
cd
event,
twitter
and
yeah.
I
don't
know
if
there
are
other
channels
that
you
think
we
can
promote
this
through
apart
from
cdf
channels.
A
Yeah-
and
I
don't
know
if
we
want
to
the
readme,
if
you
want
update
that
also.
I
F
So
for
the
sdks
we
have
a
first
few
prs,
a
couple
of
pr's
for
the
java
sdk
just
wanted
to
share
this
yeah.
So
there
is
no
readme
yet,
but
we
do
have
initial
apis
for
the
sdk,
so
which
is
great.
So
this
is
based
out
of
the
version
of
this
of
the
draft
version
of
the
spec
and
as
soon
as
we
finished
the
series
of
pr
and
we
get
to
0.1
version
of
the
spec.
We
can
adapt
this.
F
In
terms
of
work
on
the
spec,
so
my
dspr
was
merged
thanks
for
this,
so
the
introduction
to
city
events,
so
we
have
some
more
context
now
in
the
readme.
A
The
rest
is
in
yeah,
sorry.
F
Yeah
the
rest
is
in
the
in
the
cloud
binding,
which
is
also
published
to
the
website,
so
good
here
in
the
primer.
I
think
you
know
the
primariness
sorry.
F
So
thanks
for
these
matias.
F
Just
as
a
side
note,
the
way
the
documentation
gets
on
the
website
is
is
using
deep
sub
modules
on
the
cd
events,
dev
repo,
so
for
now
I'm
doing
this
manually.
So
whenever
we
have
new
documentation,
I
I
go
there
update
the
sub
module
and
push
a
pr
to
displaypoint.
Then
the
docs
is
updated
automatically,
but
yeah
we
can
set
up
a
nightly
job
or
some
some
of
them
some
more
automation.
There
eventually.
F
Yeah,
absolutely
I
mean
that's,
I
mean
there
is
well
there's
going
to
be
a
web
trigger
at
least.
E
F
F
So
if
we
had
some
cloud
credits
from
some
cloud
provider
we
could
we
could
do
that.
I
mean
if
we,
if
there's
some,
a
concrete
idea
of
what
the
things
we
would
like
to
do.
I
think
we
can
ask
the
cdf
if
you
can
get
the
budget
for
that.
I
D
B
B
Yeah
I
bought
this.
I
bought
this
microphone
and
it
has
it.
You
know
it
has
different
settings
on
it
to
pick
up
only
my
voice,
but
apparently
it's
so
I
have
the
game,
turned
all
the
way
down
and
still
picks
up
steve.
If
he's
talking
too
loud.
F
Okay,
the
other
thing,
the
last
thing
I
add
in
the
agenda
for
today
there's
this
pr
that
I've
been
working
on
and.
F
I
know
there
is
in
some
feedback
materials
I've
not
managed
to
to
answer
to
your
feedback
yet,
but
maybe
I
can
what
I
can
do.
I
can
try
to.
F
A
I
can
try
to
explain
also
if
we
have
time
in
more
details
what
I
was
meaning
with
the
different
comments,
but
please
go
on.
F
F
So
what
I'm
trying
to
do
here
is
basically
the
model
I
was
trying
to
to
set
up
is
there's
a
concept
of
objects
or
we
call
them
subjects
in
the
spec
today.
Maybe
we
could
call
them
object
as
well,
but
basically
having
some
abstractions
like
we
have.
The
task
run
pipeline
runs,
builds
environments
deployments
and
so
forth,
and
then
for
each
of
these
abstractions
I
have
a
set
of
fields
that
are
well
specified
that
are
available
for
them.
We
can.
F
These
are
the
spec.
The
events
the
pipeline
run
is
an
idea.
Source
pipeline
name,
status,
url
and
errors
task
run
similar
type
of
structure-
and
this
is
a
set
of
object-
is
what
basically
makes
our
vocabulary,
and
this
is
where
we
bring
this
kind
of
standardized
or
shared
names
that
we
can
use
then
to
extract
information
from
these
events
across
platforms.
F
But,
of
course
not,
this
entire
object
is
not
applicable
to
all
the
events
and
that's
where
the
mapping
that
I've
done
below
so
for
different
predicates.
So
if
a
pipeline
run
is
queued,
only
certain
fields
in
the
object
will
be
available.
So
in
case
of
queued,
you
will
have
an
id
possibly
a
source
or
a
pipeline
name,
but
you
will
not
have
a
status,
url
or
errors.
F
Well,
if
you
go
down
to
the
finished
ones,
then
the
status
becomes
a
mandatory
field
and
optionally.
You
can
have
url
and
errors
as
well,
and
so
in
my
mind
this
the
kind
of
model
I
was
proposing
to
build
to
have
this
define
this
kind
of
object.
So
this
defined
this
vocabulary.
So
we
have
one
single
place
where
we
define
all
the
terminology
that
we
want
to
use.
F
Along
with
this
model
in
tables,
I
added
some
json
schema
as
well,
and
some
content
into
the
cloud
events
binding.
Basically,
in
the
cloud
events
binding,
I
added
how
these
objects
and
context
that
we
defined
on
cd
events,
maps
into
a
cloud
event
and
for
a
lot
of
fields.
There
is
an
easy
match.
Like
the
cloud
events
id
must
be
set
to
the
city
events
id
so
for
the
source
and
type
for
the
subject.
A
Jump
in
yeah
emma
do
you
want
to
go
first,
or
should
I
go
first.
E
Yeah
yeah,
I
can
converse,
I
haven't,
provided
that
much
comments
or
actually
no
no
comments
at
all.
I
guess
in
the
pr
itself.
I
provided
some
comments
in
the
in
the
slack
channel
there.
I
I
mean.
I
think
this
is
an
interesting
way
to
describe
it
in
one
sense,
I
haven't
really
thought
of
it.
This
way
before
that,
each
of
the
the
activities.
E
What
did
you
call
them
the
these
are
objects
or
subjects
and
we
can
have
fields
or
properties
that
are
mandatory
depending
on
what
predicate
you
put
on
them
or
used
for
them.
In
the
events
to
me,
I've
seen
the
the
event
definitions
themselves
as
the
objects.
E
I
mean
that
maybe
that's
just
my
my
experience,
because
that's
how
it's
done
in
eiffel
right
now
and
then
the
different
properties
are
either
available
or
not
available
at
all.
In
the
various
events.
Event
types
so,
for
example,
for
an
test
run
started
that
that
event
type
would
have
some
of
these
properties
in
it,
and
the
test
run
finished
without
other
properties
in
it
in
the
event
type
itself.
E
But
now,
if
we
like,
if
all
these
event
types
which
have
the
same
core
or
as
you
call
it
and
just
have
different
predicates,
if
they
should
share
the
same
object,
then
I
agree
that
this
is
maybe
a
good
good
way
to
describe
it.
So
I
I
don't
want
to
say
that
this
is
not
the
way
to
go
at
all.
I
think
we
can
continue
evaluating
this
this
way
to
describe
it.
That's
that's,
probably
fine.
E
E
F
Here,
rather
than
having
the
subject
and
the
task
run,
and
then
these
fills
within
here
yeah
to
to
move
all
these
fields
kind
of
top
level.
Here
in
the
json.
E
Yeah,
I
mean
everything:
all
this
event
is
about
the
task
run.
Subject
it
isn't
about
anything
else.
So
why
do
we
need
those
two
extra
levels?
That
was
my
first
just
thought
when
I,
when
I
saw
this
proposal,
but
I
cannot
get
your
idea
with
it,
so
I
I
I'm
not
sure
I
mean
we
will
in
all
of
n
types.
We
will
then
have
this
subject
and
we
will
have
the
what
we
call
it
now.
E
The
taskram
thing,
so
each
event
will
have
such
a
level
additionally
and
then
the
different
properties
for
that
specific
event,
type
family
in
each
of
them.
F
It's
a
cloud
event,
so
it's
going
to
be
an
http
header
and
then
everything
from
subject
under
nif
will
go
into
the
payload.
E
F
No
you're
right,
I
was
just
mixing
things
up:
yeah
yeah,
you're
right.
The
the
cloud
event
context
is
the
top
one,
and
this
will
be
the
payload
yeah.
F
A
But
I
guess
you
could
see
it.
At
least,
when
we
talk
about
it,
we
can.
We
can
combine
everything
into
one
big
json,
so
we
can
see
kind
of
like
the
whole
message
as
it
is.
A
Even
that's
not
might
might
not
be
the
way
it's
sterilized,
but
to
get
the
idea
of
how
a
complete
event,
including
the
cloud
events,
look
like.
If
you
get
my
points.
F
And
yeah,
I
was
not
sure
how
to
to
render
that
in
one
single
one
but
yeah
and
also
realize
that
in
the
cd
event
context
down
below
the
the
subject,
is
there
twice
and
it
shouldn't
be.
So
that's
that's
a
mistake.
So
the
first
one
which
is
just
the
the
id
should
not
be
there.
F
Definitely
we
could.
We
could
have
a
way
to
visualize
this
as
to
as
one
single
json.
I
just
didn't
want
to
give
the
impression
that
everything
would
go
into
the
payload.
So
this
this
separation
into
json
is
allowed
to
show
that
the
first
chunk
is
what
what
is
cloud
events
context,
and
the
second
chunk
is
what
goes
into
the
into
the
payload.
E
Yeah,
but
if
you
would
see
this
coming
on
an
amqp
bus
for
example,
I
guess
you
would
see
the
whole
json
blob
where
they
see
the
events
is
part
of
the
data
value
right.
Is
this
data
value
in
the
major
block,
or
maybe
I
don't
really
make
some?
I
don't
have
much
experience
of
the
cloud
event,
so
maybe
I'm
mistaken.
F
So
if
and
that
allows
for
using
this
data
for
like
routing
of
the
of
the
cloud
events
or
filtering
decision
and
so
forth,
so
that
if
you
have
some
processors
along
in
the
in
the
road
along
the
road
like
you
want,
if
you
send
all
your
messages
to
a
bus-
and
you
want
to
pick
only
certain
messages
based
on
a
subscription
model
or
you
have
some
kind
of
filtering
logic
you
can
do
based
on
on
what?
What's
in
the
cloud
event
context.
F
I
F
In
the
cloud
event
specification,
I
actually
have
this
kind
of
json
to
to
show
the
the
whole
context
and
payload
in
one
one
go
which
we
could
do
as
well
here,
if
you
wanted
to,
but
yeah
at
least
for
the
http
binding.
Everything
which
is
in
the
in
the
context
is
then
transported
as
part
of
the
http
headers.
F
E
E
F
I
think
I
found
this
effective
in
terms
of
showing
what
what
is
the
content
is
going
to
be,
but
I
find
it
confusing
from
let's
say
I
mean
this:
this
pack
is
binding
agnostic,
so
I
think
you
need
you
need
one
way
to
represent
what
is
going
to
be
in
your
message,
regardless
of
the
binding
and
that's
the
content
that
is
going
to
to
be
displayed
as
json
severalizes
json,
but
that's
not
necessarily.
F
A
But
kind
of
like
also
actually
now,
of
course,
I'm
colored,
but
it's
somewhere.
It
would
be
nice
to
have
a
whole
kind
of
like
like
structure
of
it,
because
if
I
remember
right,
for
example,
I
think
that
if
you're,
for
example,
send
over
kafka,
if
you
use
cloud
events
kafka
banning,
you
will
also
get
a
kind
of
like
a
a
message
yeah
and
see
the
whole
entire
structure.
A
I
don't
know
how
we
want
to
do
it,
because
I
guess
I
I
I
understand
your
concern
there
not
to
confuse
people
with
this
is
way.
Look
if
you
used
hp
binding,
but
it's
kind
of
nice
to
see
how
how
things
are
glued
together
in
some
kind
of
way.
E
F
A
F
Right,
okay,
yeah
sure
I
mean
it
would
basically
be
the
the
cloud
event
context.
I
think-
and
I'm
thinking
sorry
just
because
this
is
the
cloud
event
binding.
So.
F
F
So
the
only
thing
extra
that
you
have
in
the
cloud
event
bindings
in
the
top
part,
if
you
will,
that
is
not
in
the
bottom-
is
the
spec
version
which
is
fixed
to
1.0
and
the
data
content
type
which
is
fixed
to
text
json
right.
But
everything
else
is
data
which
is
copied
from
the
cd
event
context
into
cloud
events.
F
If
I
was
going
to
to
render
a
cd
event
on
something
different
than
cloud
events,
I
think
that
the
bottom
json
would
be
the
the
way
to
show
the
entire
content.
Basically,
apart
from
the
double
subject
there,
that
is
a
mistake.
E
Now,
I
guess,
as
you
exemplified
with
the
http
headers
there,
I
think
that
that
makes
sense.
Otherwise,
to
me,
it's
a
bit
strange
that
we'll
duplicate
all
the
cloud
event
fields
into
the
cd
events,
since
they
are
anyway
in
the
same
json
structure
if
it's
like
serialized
or
flattened
to
one
json
structure.
E
But
I
guess
I
get
your
point,
but
then
to
not
confuse
other
readers.
Similarly,
as
I
have
been
confused,
maybe
mattie
as
well,
it
would
be
good
to
have
some
additional.
Maybe
two
examples,
then
on
how
it
would
look
in
an
http
interface
and
a
kafka
interface
respectively.
Something
like
that.
F
A
F
E
That
makes
sense
actually
now
nice,
it
was
a
good.
I.
F
I
think
at
the
at
this
stage
this
in
the
city
events,
I
don't
think
there
is
anything
of
this
fields
that,
apart
from
what
what
I
put
here
as
part
of
the
cloud
event,
context
that
is,
would
be
needed
from
routing
point
of
view,
a
filtering
point
of
view.
F
That
was
my
impression,
at
least
for
the
work
that
we've
done
so
far,
but
it
might
be
that
as
we
go
and
implement
more
pocs
that
we
realize
that
certain
fields
needs
to
be
kind
of
yeah.
It
needs
to
be
part
of
the
context
as
well.
A
I
guess
it
depends
how
much
pain
we
feel
with
the
routing,
if
the.
If
there
is
data
inside
of
it,
that
we
need.
A
So
then
we
can
probably
bring
it
out
for
routing
reasons,
but
we
can
start
off
with
what
we
have
and
then
add
on
as
we
need
instead
of
trying
to
add
too
much
in
the
beginning,.
F
So
if
you
want
to
say,
take
all
the
events
for
a
task
run,
you
have
that
in
there
and
if
you're
interested
in
a
specific
asset,
let's
say
task
run
one
two
three
and
then
you
have
that
in
the
subject
and
at
least
for
the
use
cases
I
could
think
of
that's
or
I'd
say
I
would
be
interested
in
all
events
coming
from
a
certain
source
and
that's
in
there
too,
but
we
may
find
other
different
use
cases.
E
F
E
Because
then
yeah,
if
I've
been
almost
out
of
time,
but
if
you
go
to
the
schema,
then
I
guess
your
idea.
There
is
that
the
top
level
of
the
schema
would
be
more
or
less
the
same
for
any
event
type,
since
they
have
these
standard
fields
and
the
subject
or
if
we
should
call
it
object
or
whatever,
on
the
top.
F
Yes,
indeed,
so,
actually,
this
is
the
schema.
So
that's
the
share
and
you
have
id
type
source
time,
subversion
subject
and
then
the
subject
is
defined
as
any
of
and
then
it
points
to
all
the
other
schemas
for
the
specific
objects
and
yeah
so
in
in
this
model
it
it
makes
it
maybe
a
bit
more
compact
schema.
F
A
Or,
for
example,
if
the
this
subject
would
be
look
have
the
same
fields
in
all
events,
then
we
can
link
to
a
subject
sub
shima,
but
that's
a
little
bit
different
ideas
than
you
have
yeah.
One
thing
we
could
also
think
about
when
it
comes
to
this
is
shima
validators
and
how
easy
time
it
is
for
them
to
use
subsheemus
in
a
full.
A
We,
we
kind
of
like
we
had
the
idea
of
introducing
such
emails,
but
kind
of
like
a
band
that
idea
to
make
it
easier
for
the
shima
validators
and
it
seemed
like
it's
easier
to
have
just
a
flat
stream
without
any
links,
and
but
we
can
take
a
look
at
that
that
so
yeah
it's
something
to
think
about
at
least
there.
F
Yeah
yeah
yeah.
So
to
be
honest,
I
yeah
I
followed
the
what
what's
in
the
json
shima
spec
try,
but
it
may
be
that
different
validators
do
not
support
this.
So
yeah,
that's
a
that's
a
good
point
I
mean
there
are.
There
are
other
ways
we
can
from
what
point
of
view.
There
are
other
ways
we
can
make
sure
we
don't
have
the
replication.
I
mean
we
we
can.
F
We
can
use
some
kind
of
templating
mechanism
to
define
this
these
different
schemas
and
then
render
them
so
that
they
are
complete
as
part
of
this
pack.
If
you
know
what
I
mean
so.
A
That's
how
we're
intending
to
do
is
on
eiffel.
E
E
F
Yeah
we
got
to
drop
for
another
meeting,
but
yeah
thanks.