►
From YouTube: CDEvents / SIG Events Vocabulary - Oct. 4, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
C
C
C
C
Okay,
yeah
feel
free
to
sign
yourself
in
in
a
participant
list.
Shall
we
get
started?
What
do
you
think
it's
really
free
passed.
C
All
right,
yeah,
that's
a
welcome
everyone
to
the
City
events.
Work
group,
I
I
did
a
couple
of
things
on
the
agenda
for
today.
C
I
guess
the
first
thing
that
I
had
in
the
agenda
as
a
review
of
the
0.1.0
project
as
I
think
we
are
getting
quite
close
to
the
continuous
delivery.
Summit
and
I
mean
we
had
a
goal:
aim
to
to
do
a
release
0.1
in
time.
For
that,
so,
basically,
in
terms
of
planning
I
mean
the
decision
deadline
would
be
October
the
17th,
but
as
soon
as
possible
would
be
best.
C
So
that
means
that
any
the
cut-off
date
for
technical
work
would
be
the
17th
as
well,
and
then
we
would
have
some
days
for
any
release,
preparation,
meaning
completing
the
the
versions
from
0.1
draft
to
zero,
to
one
preparing,
release,
announcements
and
updating
the
sdks
accordingly
and
those
kind
of
things
the
summit
happens
on
the
25th
and
yeah
I
think
it
would
be
until
the
21st
more
or
less
for
release
preparation,
because
then
this
weekend,
the
middle
and
some
travel
time
to
Detroit,
at
least
for
me,
but
yeah,
so
I.
C
Basically,
I
wanted
to
have
a
look
at
the
project,
see
where
we
are.
If
there
are
things
that
we
can
this
scope
from
from
these
or
not,
and
so
if
we
think
we
can
do
the
do.
C
C
C
No,
but
maybe
we
need
to
discuss
the
the
plan
for
the
proper
City
events,
governance,
it's
something
that
we
would
need
to
do.
You
guys
have
some
governance.nd
in
place.
Yeah.
B
I
intend
to
do
more
or
less
copy
what
we
have
in
the
stick.
Events
report
today,
I
believe
it's
there
right
now
right
something
but
then
of
course,
updated
to
some
extent,
but
we
will
not
have
a
a
proper
governance
in
place
for
the
project
for
zeros,
one
I
mean
setting
up
a
technical
committee
and
having
everything
in
place
when
it
comes
to
maintenance
strategies
or
something
like
that
for
the
projects
and
everything
it's
not
really
in
scope
for
this
time
frame,
but
at
least
we
should
have
a
start
for
it.
C
B
C
C
For
the
short
intro,
video
and
I
I,
don't
think
this
is
something
that
we
can
do
in
time
or
and
for
the
summit.
Okay,
I,
don't
think
I
would
have
time
for
putting.
B
Some
more
videos,
it
would
have
been
beneficial
to
have
it
when
we
release
it
more
officially,
of
course,
but
I
totally
see
that
that's
actually
not
really
possible
with
the
resources
we
have.
B
B
B
C
All
right,
this
is
highlight
supported,
use
cases
on
City,
events.dev
I
think
this
is
we
discussed
that
we
want
to
have
and
I
will
work
in
it.
I
think
this
is
still
doable
foreign.
C
Documentation
document
subscriber
model
for
events,
so
this
is
about
taking
the
functional
diagram
that
you
already
have
and
kind
of
adapt
it
a
bit
and
put
it
in
the
docs.
C
B
I
will
also
I
was
thinking
Eric.
Is
it
so
that
you
have
some
time
to
spare
on
this,
and
you
would
feel
comfortable
working
on,
for
example,
this
one
given
that
I
also
have
the
python
SDK
in
my
life.
I
need
to
be
a
little
bit
careful,
but
probably
I
can
find
time,
but
yeah
I
will
need
to
focus
on
the
pythonastic
here.
I
think
yeah.
Okay,.
B
C
Okay,
sorry
Trace
I
think
there
is
some
so
hello.
First
I
think
there
is
some
background:
noise,
okay,.
A
C
Okay,
so
in
terms
of
course
back
we
have
expand
the
buckets
back
documentation
which
is
at
the
end,
these
other
four
issues
so
extended
change.
Data
model
extend
the
artifact
data
model,
extend
the
service
and
environment
data
models
and
the
incident.
So
this
four
so
I
added
this
for
the
the
first
three
in
the
agenda
for
today.
Hopefully
we
can
get
to
it
or
we
can
discuss
them
offline.
C
It's
basically
what
we
implemented
kind
of
out
of
the
spec
for
the
demo
that
we
have
done
with
Eric
in
the
open
source
Summit.
C
C
B
C
Okay,
yeah
I
will
remove
this
from
the
the
myosin.
C
And
yeah,
so
the
other
three
we
can
hopefully
make
those
three
in
time
and
in
terms
of
backward
compatibility
strategies,
I
think
custom
data
is
implemented,
so
the
only
thing
left
would
be
to
expand
a
bit
about
this,
so
describe
a
bit
more
about
what
custom
data
is
and
what
it
is
for
in
in
our
primary
document.
C
Hi
Ben
yeah,
so
we
discussed
previously
about
different
approaches
that
we
can
have
to
allow
services
to
to
carry
data
that
they
already
have
through
CD
events.
We
are
tempted
to
see
if
it
was
possible
to
use
HTTP
adders,
but
this
approach
did
not
really
work
because
of
how
Cloud
events
are
defined.
So
it
does
not
really
it's
not
really
possible
to
to
have
the
entire
the
entire
body
original
body
directly
in
in
into
a
city
event,
and
also
there
is
a
problem
of
the
message
type.
C
So
basically,
what
we've
discussed
in
the
creating
previous
meeting
is
that,
if
a
producer,
so
if
there
is
a
case
where
there
there
is
existing,
there
are
existing
events
and
there
are
consumers
that
are
not
ready
to
process
the
events,
so
the
producer
will
have
to
send
existing
events
and
the
City
Event
until
all
the
consumers
are
able
to
process
the
CD
event,
but
and
also
we
defined
customer
data
so
that
we
allow
like
setting
any
data.
That
is
not
part
of
the
City
events.
A
B
Yeah,
so
this
abbreviations,
it's
I
mean
it's
a
quite
low
prioritized
requirement,
but
it
would
be
good
to
have
these
abbreviations
in
our
documentation
to
to
easily
refer
to
different
event.
Types
I
will
try
to
do
that,
but
it
won't
be
on
top
of
my
to-do
list,
the
other
one.
On
the
other
hand,
there
I
think
we
should
at
least
have
a
relation
or
relate
to
that
work
that
was
done
in
this
sig
interoperability.
B
So
we
should
have
some
kind
of
statement
on
in
what
way
we
are
aligned
with
this
on
or
not
than
if
or
yeah.
If
we
have
any
plans
or
whatever
too
be
more
aligned,
so
I
intend
to
write
some
statements
about
that.
There.
C
C
Yeah
I
agree:
I
think
we
should
have
that
in
terms
of
artifact
ID.
We
discussed
this
a
little
in
Dublin
and
I
think
the
idea
was.
We
could
include
a
package
URL
as
a
recommended
option
for
describing
artifact,
IDs
and
so
I
plan
to
to
make
a
PR
for
that.
I
think
this
is
still
doable
within
the
time
frame
of
the
next
couple
of
well.
A
Yeah
yeah.
Oh
sorry,
oh
a
heavy
like
plus
one
for
this
Pearl
spec.
We
actually
talked
about
this
internally
Apple
like
when
we
were
talking
about
CD
events
like
Pearl
spec
did
come
up,
so
I
am
heavily
in
favor
of
this
and
then
out
of
curiosity
like
how
do
we
envision
so
do
we
think
so
like
I
guess
so,
let's
say
we
have
someone
sending
events.
Are
we
expecting
implementers
to
just
unmarshall
the
scheme?
A
You
know
parse
it
and
if
it
fails,
it's
not
the
Pearl
spec
or
what's
the
kind
of
idea
to
are
we
making
this
like
the
required
format,
because
it
sounds
like
it's
not
so
I'm,
just
kind
of
wondering
like
how
people
can
go
about.
You
know
reason
what
format
this
artifact
ID
is.
C
Yeah,
that's
a
very
good
question:
Ben
I
guess
we.
C
We
were
not
sure
when
we
discussed
this.
Whether
this
would
be
like
the
best
way
forward.
I
mean
it
looked
like
a
good
option.
So
that's
why
we
thought
maybe
we'd
make
it
as
a
recommended
format,
but
not
enforce
it
in
the
beginning,
but
we
could
also
consider
enforcing
it
and
that
that
will
allow
consumers
to.
B
B
B
You
prove
a
concept
for
this
series,
one
version
and
see
if
if
people
seems
to
be
satisfied
with
with
having
this
format
and
then
we
could
maybe
set
it
as
the
required
format
when
it
becomes
to
the
sharp
1.0
version
or
whatever
later
on,
if
there
seems
to
be
an
a
consensus
on
that,
this
is
a
good
format
to
use
for
any
type
of
object.
B
A
Yeah,
okay,
yeah,
I,
think
I
think
that's
definitely
good.
You
know
definitely
seeing
the
the
feedback
there
or
you
know
like
what
the
community
wants.
A
My
in
my
like
thinking
here
is
that
I
think
it
would
be
good
to
enforce
this,
mostly
because
you
know
like
having
users
being
able
to
like
you
know
already
do
something
or
like
implementers
already
expecting
something
versus
like
implementing
it
later
is
generally
harder.
You
know
saying:
oh,
we
now
have
this
format,
but
you
know
like
I
said:
that's
not
you
know
it's
it's
you
know
it's
fine
to
you
know,
introduce
it
later,
but
I
just
want
I
want
to
make
sure
that
you
know.
A
We
also
have
you
know
like
I.
Don't
know
if
there's
a
GitHub
issue
around
the
Pearl
spec
because
like
if
we
can
get
some
like
you
know,
maybe
some
Community.
You
know
discussion
around
that
because,
like
I'll
definitely
comment
on
it
because
I'm
really
in
favor
of
this
format-
oh
perfect,
yeah,
I'll,
just
add
it
to
this
one.
B
I
think
we
should
maybe
have
some
some
actually
communication
with
the
actual
package,
URL
people
and
see
what
their
take
on
this
is.
If
they
see
that
this
format
is
is
being
used
widely,
and
they
also
think
that
it's
something
that
we
should
base
our
common
event
format
on.
That's
one
thing,
I
think
we
should
do
before
saying
that
this
will
actually
be
the
required
version
for
things.
B
One
option
could,
of
course
be
that
we
also
include
like
a
artifact
ID
type
field
or
something
to
the
spec
saying
that
yeah,
this
artifact
ID
is
some
type
Earl
or
other
to
make
it
easier
for
the
consumers,
because
I
totally
agree,
then
that
if
you
are
a
consumer
and
you
it
would
be
easier
if
you
could
expect
a
certain
format
on
the
artifact
ID.
B
A
Yeah
yeah,
I
think
I.
Think
that's
fine,
I,
don't
know
about
introducing
another
field.
I
feel
like
you
know,
just
either
enforcing
one
or
just
let
it
be
anything
is
completely
fine,
but
we
just
need
to
I
think
when
we're
making
the
you
know
when
we're
deciding
on
the
spec.
We
just
need
to
be
clear
on
what
we
expect
that
field
to
be
whether
we
expect
it
to
be
anything
or
this
Pearl
spec.
A
You
know
because
my
issue
is
like,
if
you
allow
it
to
be,
you
know
like
if
you
have
this
format
type
field,
you
know
like
some
people
will
have
you
know
this
other
field
format,
other
people's
will
have
this
other,
you
know
format
and
then
that
makes
interoperability
that
much
harder,
because
now
everyone
has
to
implement
this.
You
know
the
spec,
if
you
will,
rather
than
just
implementing
this
one
way
that
could
actually
be
built
into
the
sdks.
So
it's
kind
of
that's
kind
of
my
my
opinion
on
that
yeah.
B
Actually
kind
of
agree,
so
maybe
we
should
actually
set
it
as
a
request,
wired
format
for
series
1
and
if
it
is
revealed
that
people
that
try
to
use
the
0.1
spec
cannot,
for
some
reason,
use
this
format
or
don't
want
to
use
it.
They
can
instead
provide
their
IDs
through
some
custom
data
field
if
they
don't
feel
comfortable
using
the
current
format
and
then
they
can
like
write
a
full
bar
specification
in
the
artifact
ID
field,
Maybe,
so
yeah
I'm,
actually
fine
with
with
requiring
this
format
for
0.1.
If
everyone
else
is
as
well.
B
A
You
yeah
I'm,
okay
with
it
like
I,
said:
I
love
this
I
love,
the
spec
I.
Think
it's
a
really
well
thought
out:
Pearl
spec!
You
know
artifact
ID
or
just
IDs
in
general,
so.
C
Yeah,
it
works
for
me
as
well.
I
I
agree
that
not
having
enforced
format
are
arms
interpretability,
so
yeah
yeah,
we'll
need,
but
like
I
said,
but
I
mean
we'll
need
to
to
implement
it
in
the
in
the
SDK.
By
worst
case,
we
can
have
it
in
the
spec
for
0.1,
ensure
it
left
at
0.1.
We
can
update
the
SDK
accordingly,
if
we
don't
make
it
in
time
for
the
SDK.
B
Yeah,
so
this
is
another
such
should
I
say
low
priority
thing,
but
we
have
the
vocabulary
document
in
the
segment
probability
right
repository
again,
where
we
have
mentioned
a
lot
of
different
CSD
tools
and
we
should
add
the
CD
events
terminology
to
that
table
as
well.
So
we
can
see
how
it
maps
to
other
existing
toolsom
thanks.
C
Okay,
yeah
makes
sense
to
me:
I
think
it
should
be
doable.
C
All
right
so
in
terms
of
SDK
I
mean
we
do
have
the
go
SDK
I.
Think
one
missing
item
is
to
align
with
the
versions,
not
the
versions
Prius
it's
merged,
so
we
need
to
to
align
that
Indigo
SDK.
C
C
For
the
python,
SDK
I
think
the
first
version
is
merged
now
on
Main
and
we
created
a
number
of
issues.
So
thanks
Eric
that
that
we
need
to
address
at
some
point
yeah.
B
C
C
So
that's
where
I
see
maybe
some
some
risk,
but
other
than
that
I
would
say.
Everything
else
is
something
that
is
doable
in
terms
with
0.1,
so
I'm
inclined
towards
saying
that
it
can
do
to
release
0.1
in
time
and
announce
it
at
the
summit.
B
I'm
thinking
about
this
last
week
before
releasing
it
as
I
mentioned
there,
the
administrative
stuff
should
be
done
there,
but
some
documents
appear
or
the
your
document
and
such
things
written.
That
seems
a
bit
short
if
we
don't
prepare
it
already
now
in
some
way,
I
think
at
least
to
me
I,
don't
really
have
a
clear
picture
on
exactly
what
needs
to
be
done
during
that
week
that
you
mentioned
in
the
the
agenda
there.
C
C
We
need
to
update
wherever
it
says,
0.1.0.
draft
to
0.1.0.
C
C
I
think
that's
all
from
this
pack
point
of
view
from
the
sdks.
Also
we
need
to
do
the
same
update
from
draft.
C
In
terms
of
other
work,
I
think
we
probably
would
be
good
to
us.
Some
kind
of
blog
or
article
so
I
know
fatty
is
in
contact
with
Jesse
from
the
CDF
and
he's
kind
of
holding
off
to
prepare
some
media
coverage
for
this
and
I
guess,
we
would
have
to
work
with
Jesse
to
prepare
some
some
content,
so
I
would
imagine
some
kind
of
blog
post
or
article.
C
We
announced
every
the
release
yeah,
but
I
don't
have
full
details
about
this
last
bit.
B
B
C
When
we,
when,
when
we
announced
the
the
project,
the
CD
event,
project
I,
think
in
that
case,
what
what
happened
is
that
Jesse
kind
of
arranged
a
couple
of
interviews
with
different
technical
writers?
C
So
we
basically
I
presented
see
the
event.
What
city
event
is
and
the
chat
with
this
folks
and
basically
they
wrote
a
couple
of
Articles
out
of
these.
C
So
there's
I,
don't
know
if
that's
the
plan
for
for
for
this
announcement
as
well.
So
I
can
ask
if
I
can
ask
fatty
whether
that
would
be
the
plan
or
if
it
would
be
enough
to
to
have
a
blog
post,
that
we
published
on
the
CDF
blog.
C
Yes,
so
I
mean
if
we,
if
we
are
in
general
agreements,
that
this
is
doable
so
kind
of
the
technical
side
of
of
it
is
doable.
B
Yeah
at
least
I
think
we
should
initiate
it
with.
We
thought
it
or
maybe
or
others.
So
we
see
that
it's
on
track.
C
C
Another
thing
that
I
think
fatty
mentioned
is
whether
we
need
to
update
the
the
white
paper.
B
Hey
gentlemen:
I
have
to
jump
to
another
meeting,
but
once
you
are
once
you
get
this
kind
of
stuff
in
order,
it'd
be
great
for
us
to
do
a
presentation
to
the
TOC.
B
So
keep
that
in
mind
once
you
have
once
you
have
this
ready
I
think
we
could
I
think
it's
something
that
they
should
see.
Okay,.
C
B
What
about
Post
Release
activities
I
mean,
should
we
do
some
kind
of
no
way
it
will
be
announced
during
the
The
Summit,
but
should
we
also
try
to
plan
for
like
presentations
to
other
communities
or
among
other
foundations?
Even
now,
when
we
have
a
series
one
version
out,
or
should
we
wait
with
that,
it
is
probably
not
a
rush
to
do
it
directly
the
week
after,
but
maybe
we
should
start
thinking
about
it.
How
we
should
announce
this
this
broader
than
just
putting
it
on
the
blog
on
the
CDF
website.
C
Yeah,
that's
a
very
good
point:
I've
not
told
too
much
about
it
yet,
mostly
because
the
remaining
things
I
guess
they
take
most
of
my
time
but
yeah,
that's
a
very
valid
point
and
I
I
can
also
check
if
fatty
about
this.
If
there
is
any
expectation
or
or
any
recommendation,
what
is
the
best
way
to
kind
of
benefit
from
the
announcements
at
the
community.
Sorry,
at
the
CD
Summit
cubecon.
B
C
C
Yeah
a
little
good
question:
I
guess
we
could
start
with
those
I
mean
we
have
some
good
connections
already
with
tecton
Captain,
Jenkins
and
Spinnaker.
Folks
so
probably
makes
sense.
B
C
C
All
right
so
the
next
items
and
on
the
agenda
or
sorry
actually
before
before
we
move
on
from
this.
Do
you
think
that
we
can
decide
now
that
we
can,
we
will
make
a
0.1
release,
or
would
you
prefer
to
to
wait
another
few
days
and
see
how
it
goes
on
some
of
these
tasks.
B
No
I
think
we
should
say
that
it's
it's
fine,
I
mean
it's
mostly
you
and
I
I'm
Andrea
or
our
tickets
here
and
I
I
need
the
pressure
to
get
my
things
going.
So
I
would
say
yes
yeah
it's
the
same.
For
me,
pressure
is
Good
from
time
to
time.
C
Okay,
yeah,
that's
great
yeah.
No,
it's
really
exciting
pressure
helps
me
as
well.
So
it's
it's
good.
We
have
a
decision
and
yeah
we'll
do
what
we
have
to
to
make
it
happen.
C
So
the
the
other
things
we
still
have
20
minutes,
I,
don't
know
what
we
want
to
discuss
first,
so
there
discussions
about
specific
Fields
I
guess
it
can
take
some
time
to
discuss
them
now.
The
third
item
that
we
add
in
the
agenda
is
roadmap
ideas,
so
at
a
CD,
Summit
I
will
do
lightning
talk,
which
is
a
five
minute
presentation
and
the
topic
is
City.
C
C
So
do
you
want
to
discuss
the
the
roadmap
ideas
or
the
the
other
items?
First.
B
How
are
the
other
items
related
to
0.1?
Are
they
mandatory
zeroth
one
or
is
it.
C
B
C
C
Yeah,
yes,
maybe
we
can
start
with
the
issues.
Then.
C
C
Yeah
get
an
idea
what
this
is
about,
I
think
Eric
is
pretty
familiar,
but
so
this
is
the
first
one
is
for
the
change
event.
So
the
change,
dependent
change
created,
merge
to
reviewed
and
updated.
C
C
And
the
idea
is
basically
to
be
able
to
associate
a
change
with
the
Repository,
so
repository
can
be
like
older
slash,
so
there
is
already
this
basically
can
be.
The
organizations
like
the
repository
name
and
the
source
can
be
the
git
hosting
system
where
the
repository
is
hosted.
C
But
yeah,
so
the
main
idea
is
that
today
the
change.
C
The
change
of
answer,
basically
very
they
are
basically
empty.
There's
not
much.
There's
no
data
model
in
there.
C
A
C
C
Actually,
when,
for
instance,
a
GitHub
repository
is
created
to
create
a
new
repository
in
git
and
GitHub,
or
in
gitlab
or
and
change,
is
about
as
a
name
that
we
have
picked
for
generic
change,
that
would
be
what's
called
pull
request
in
GitHub
or
merge
request
in
gitlab
or
change.
I
can
get
it
and
so
forth.
C
So
the
change
propose
here
is
to
add
the
repositories
part
of
the
data
model
in
in
all
those
events.
In
all
these
events,
in
all
the
change
events,
change,
Creator,
reviewed,
marriage,
abandon
and
updated.
B
I'm
a
little
bit
reluctant
to
to
say
that
this
is
a
very
good
suggestion
right.
It
again
comes
back
to
things
that
you've
talked
about
before
on
this.
If
we
should
reference
previously,
some
events
or
not,
but
I,
think
we
have
for
for
those
cases
where
we
actually
repeat
the
same
information
in
consecutive
events.
B
We
we
try
to
just
repeat
the
the
information
that
is
uniquely
needed
for
for
such
subjects.
I,
guess
so,
isn't
it
so
that
the
source
range
events
here
then
should
they
could
include
a
reference
to
the
repository,
but
with
a
as
small
as
possible,
still
uniquely
identifiable
group
of
properties,
not
having
all
properties
repeated
from
the
repository
created
and
changed
and
whatever
updated
events.
C
Yeah,
indeed,
that's
what
the
the
reference
is
for
it's.
Basically,
a
combination
of
the
schema
combination
of
an
ID
and
the
source
and
the
source.
The
only
purpose
of
the
source
is
to
say
I
mean
this
ID
is
unique
within
the
source.
So
it's
the
kind
of
minimal
set
of
information
right,
yeah,.
C
Okay,
cool,
so
the
the
next
one
is
for
the
artifact
packaged.
C
C
So
this
makes
sense
only
if
there
is
a
kind
of
one-to-one
association
between
a
specific
repository
where
change
is
made
and
an
artifact.
So
this
works
under
the
assumption
that
there
is
a
one-to-one
relationship
which
is
a
limitation
in
the
data
model,
and
my
proposal
here
will
be
to
start
with
this
and
then
in
0.2.
Then
we
can
have
a
proper
discussion
about
like
what
is
it
the
name
compositions
so
and
how
we
want
to
see
artifact
produced
by
a
combination
of
other
artifacts,
multiple
repository
and
so
forth.
B
C
Or
yes,
I
guess
it's
I
mean
yeah.
How.
B
Would
you
envision
Authority?
Do
you
think
that
if
there
is
a
group
of
commits
that
has
come
in
since
last
time,
the
art
fact
was
another
artifact
was
created
for
this
repository,
then
the
last
one.
C
C
So
the
idea
of
the
last
change
was
to
to
say,
okay,
the
end
of
the
the
head
in
the
geek
Repository,
so
that,
if
you,
basically,
if
you,
if
you
have
this
information
from
the
artifact,
you
can
find
out
through
these
and
then
talking
with
a
git
provider
as
well,
and
whether
a
specific
change
was
included
in
an
artifact
or
not.
C
So
you
cannot
only
find
out
you
can.
You
cannot
find
iPhone
events
alone
and
that's
something
that
we
discuss.
Also,
do
you
need
to
talk?
You
need
to
have
an
interface
into
the
software
configuration
management
system
that
allows
you
to
say.
Okay.
This
is
the
latest
change
ID
that
I
have.
C
Is
this
other
change,
ID
included,
so
does
it
come
before,
for
this
concept
of
Precedence
is
not
something
we
we
have
encoded
in
City
events
at
least
not
now,
so
the
idea
was
to
include
this
and
I,
don't
like
the
name
last
change
either.
So
if
there
is
a
proposal
for
different
name,
I'm,
probably
I'm,
happy
with
it,
but.
A
Yeah
I
think
lost
change
is
a
little
misleading,
I.
Think
that's
what
you're
getting
towards
and
personally
I
would
like,
I
think
a
good
name.
I
would
rather
just
call
it
like
change
reference
or
just
change.
Ref
or
Source
change,
like
you
know,
was
saying.
Last
change
is
yeah.
It's
it's
a
little.
It's
a
little
ambiguous.
B
C
It's
no
I,
don't
think
it's
the
biggest
I
just
I
just
wanted
to
clarify
that
it's
not
a
single,
a
single
change,
or
that
is
included
in
this
because
we
don't
have
it's
just
the
kind
of
the
yeah
the
reference
to
the
top
change
in
the
in
the
repository
when
the
build
was
made,
but
yeah
I,
don't
like
the
name
last
change
either
so
I'm
happy
to
replace
it
with
Source
change
or
change.
Ref.
B
B
Yes,
we
we
decided
to
call
it
the
change
and
not
the
source,
change
that
event,
the
the
change
created
and
change
updated
in
those
yeah
instead
of
having
Source
change,
creating
silver
change
updated.
So
maybe
we
should
just
call
it
change,
so
the
change
that
was
involved
when
there
it
was
decided
to
build
this
artifacts
somehow,
and
then
it
would
be
obvious,
probably
for
the
people
seeing
that
reference
that
well.
Of
course,
there
might
be
other
previous
changes,
also
included
since
the
last
artifact
was
built.
C
So
the
other
change
that
we
did,
there
was
one
two
three
foreign
events
like
service
deployed
service,
rollback
and
service
upgraded,
and
the
change
here
is
to
include
the
artifact
ID.
C
Of
the
chain
of
the
artifact
that
is
used
for
the
service
again,
there
is
an
assumption
here
that
there
is
one
artifact
ID
Associated
to
this
new
service,
but
I
think
this
is
maybe
an
assumption
that
we
we
could
keep
in
future,
as
if
you
have
an
aggregation,
some
kind
of
common
concept
of
composition.
You
could
always
say
that
a
number
of
artifacts
are
composed
into
one
final
service
artifact.
That
is
then
deployed
or
I.
Don't
know
why.
A
Not
just
make
it
a
list
like,
instead
of
just
a
single
string
like
that
it
seems
like
you
know,
if
it's
a
list
of
one
item,
that
that's
completely
fine,
but
if
we
introduce
many
or
someone
has
many
artifacts
for
a
service,
you
know
they
can
add
it
or
you
know,
that'd
be
representable.
C
Yes,
we
could
use
a
list.
I
was
just
wondering
whether
yeah
I
just
wanted
to
keep
it
simple
for
initial
version
and
not
get
into
the
weeds
of
discussing
what
is
the
best
format,
because
it
could
be
a
list
or
we
could
become
a
map
or
something
else.
But
if
you
think
it's
it's
valuable
to
have
it
as
a
list
right
away,
we
could
we
could
do
that
as
well.
A
Yeah
no
I
think
yeah
I
was
just
suggesting
it
just
because,
like
I
can
definitely
see
services
having
more
than
one
artifact,
but
I'm
I'm
not
opposed
to
keep
yeah
well
like.
Let's
just
keep
it
simple
like
yeah,
as
you
were
saying,
and
just
keep
it
as
a
string
for
now.
B
B
So,
regardless
of
what
we
stayed
here
now,
we
might
need
to
introduce
the
non-back
coach
compatible
change
to
it.
So
I
think
we
can
keep
it
simple
for
for
now.
That's
that's
fine!
For
me.
C
C
All
right
so
I
will
then
make
three
PRS
for
these
three
changes,
so
that
would
be
the
the
scope
of
what's
basically
changed
for
the
demo,
and
that
would
be
the
scope
like
we
would
introduce
them
with
addressing
this.
These
three
issues
here
so
I'll
make
this
for
aprs,
then,
and
plus
the
extra
documentation
PRS
that
are
required.
C
Thanks
for
the
feedback
on
those,
there
are
only
three
minutes
left
but
yeah.
So
if
what
I
can
do,
I
can
add
a
issue
for
the
roadmap.
Let's
see
at
least
one
was
added
already,
so
maybe
we
can
comment
on
the
issue
and
then,
until
the
next
meeting
we
can
have
a
better
idea
of
what
we
want
to
have
in
the
roadmap
and
discuss
it
and
next
time.
B
B
I
I
think
so
that's
why
I
added
it
here
I
actually
got
a
contribution
to
the
python
SDK,
which
was
nice
wow.
Someone
who
knows
more
about
GitHub
actions
than
I
do
created
a
pipeline
for
running
the
stuff
that
I
put
in
the
issue.
Unfortunately,
the
tests
don't
pass,
but
I've
been
fixing
that
during
the
afternoon,
so
if
I
can
get
them
to
replace
the
issue,
that
will
be
fine,
but
I
found
out
that
you
cannot
or
like
the
people
in
October
was.
B
C
B
C
Oh,
this
is
a
PR
right
sorry,
so
there
is
the
issue.
That
is
the
problem,
so
that
would
be
a
last.
C
So
I
think
usually,
if
someone
comments
on
an
issue,
then
it's
possible
later
to
to
assign
them
to
that
issue,
but
only
after
they
come.
They
commented
on
the
issue.
Okay,.