►
From YouTube: CDF - SIG Events Meeting - 2021.07.19
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
B
A
A
A
It's
not
so
terrible.
It's
31.
A
Yes,
leaving
the
northern
part
of
europe
for
many
years,
I
now
31
feels
to
me,
like
it's
terribly
hot.
D
We
only
have
like
22
23
here,
so
it's
it's
pretty
nice.
I
can't.
A
I
think
welcome
surety.
Yes,
I
hope
I
pronounce
it
correctly.
E
E
No
you're
fine,
so
yes,
I'm
shooting
and
I'm
working
alongside
kara
and
also
on
the
members
of
the
city
of
jenkins
community
to
design
the
cloth
lens
plug-in
for
jenkins.
And,
as
you
said,
this
is
my
first
time
attending
the
cloud
event
sig
meeting
or
the
the
event
meeting,
and
I'm
really
excited
to
look
at
all
of
the
work.
And
I
also
do
have
some
questions
if,
if
you
do
have
time
to
take
them
on
on
design
patterns
and
just
cloud
events
and
working
with
them
in
general,.
A
Okay,
then
welcome
again
and
let's
get
started.
I
think
first
thing
in
the
agenda
is
to
review
the
action
items
from
last
week
we
had
a
couple
of
those
first
one
eric
to
make
a
pr
about
what
is
a
change.
C
A
A
Great
thanks,
that's
led
it
to
the
pr
discussion
at
the
end,
and
the
second
action
item
was
for
me
to
make
a
pr
about
lightweight
versus
heavyweight.
A
A
I
don't
know
it
has
been
merged
already.
Okay,
great,
so
no
discussion
on
that
in
terms
of
sig
events
update,
which
is
the
next
item
on
the
agenda.
A
A
A
Okay
and
then
so
for
the
work
stream
updates,
we
had
a
workstream
meeting
last
tuesday,
I
believe,
and
we
had
updates
on
the
status
of
the
poc.
A
A
Update,
yes,
okay,
so
this
is
the
the
current
setup
of
the
demo,
the
plc
how
it
works
today,.
C
A
C
A
Once
the
approval
is
done
again
sends
cloud
events
which
are
picked
up
by
tekton
tekken
runs
the
deployment
and
once
the
deployment
is
done,
it
goes
back
again
to
captain
and
captain
marks
the
sequences
complete
successfully
and
then
in
the
cloud
event
player.
You
can
see
the
events
that
were
exchanged
and
in
the
kind
of
orange
boxes
in
here,
you
can
see
the
custom
components
that
we
developed
for
this
poc.
A
So
on
tecton's
side
we
have
a
techno
cloud
events,
controller
which
sends
cloud
events
in
the
format
specified
by
us
and
then
for
captain.
We
have
an
inbound
translation
layer
and
an
outbound
translation
layer,
so
that
dave
all
the
events
that
go
for
the
broker
are
events
in
the
cd
event
format.
A
Okay,
any
question
on
the
plc.
E
E
So
when
I'm
looking
at
k
native
and
again,
a
very
interesting
architecture
for
the
cloud
events
broker,
so
is
the
cloud
events,
the
broker
architecture.
So
is
the
cloud
events
broker
just
listening
to
all
of
the
cloud
events
which
are
coming
in
from
tecton
and
captain,
or
is
it
only
listening
to
a
certain
kinds
of
events
which
a
user
might
be
able
to
filter
out
in
a
way.
A
I
see
the
cloud
event
broker
itself,
it's
it's
a
sync.
It
exposes
an
url
where
you
can
send
events
too.
So
it's
up
to
the
client
what
to
send
in
this
demo.
The
client
sends
everything
and
then
the
trigger
is
where
the
filtering
happens.
So
the
trigger
is
kind
of
a
subscriptions.
It's
a
it's
a
crd,
so
you
can
create
a
resource
and
in
the
resource
you
can
define
what
kind
of
events
you
want
to
filter.
A
So
what
kind
of
events
you
want
to
receive
and
yeah
so
basically
for
techno
triggers,
I
can
say
I
want
to
receive
this
kind
of
events
and
same
for
the
captain
inbound
and
in
case
of
the
cloud
events
player.
We
have
a
trigger.
That
is
basically
a
catch-all
so
that
you
get
all
the
events
visualized
in
here.
D
I
guess
you
can
generally
say
that
it's
up
to
the
listener
to
filter,
so
the
cloud
broker,
the
vans
broker,
will
send
all
events
and
then
the
you
as
a
client
have
to
have
to
listen
in
and
filter
the
events
you're
interested
in.
That's
like
a
general
idea.
A
E
And
I'm,
I
was
also
thinking
about
a
way
that
you
said
this
is
between
tecton
and
captain,
but
but
but
a
way
where
all
of
the
services
which
are
so
specifically
for
jenkins
is
to
sing
all
of
the
services,
above,
as
the
publisher
has
a
black
box,
so
anything
can
be
anything
or
any
service
really
attacked
on
or
captain
k
native
or
any.
E
You
know
service,
which
is
emitting
cloud
events
and
and
jenkins
consuming
it
so
a
way
to
listen
for
events
coming
in
from
different,
obviously
sources,
and
also
that
there
was
a
conversation
similar
to
this
on
the
sac
channel
for
event,
sake
about
the
payload,
looking
very
different
for
each
cloud.
Events
which
is
emitted.
So
that
is
one
thing
that
we've
been
thinking
about
of.
Implementing
is
the
the
event
we
do
want
to
have,
give
or
give
users
the
way
to
filter
events
based
on
the
event
metadata.
E
E
So
just
how
how
how
has
been
implementing
or
parsing
through
different
data
for
all
different
kinds
of
sources,
because
you
know
tecton-
has
a
very
different
weight,
attack,
dynamic
demands
and
then
also
one
is
using
binary
format.
The
other
is
using
a
structured
format.
So
if,
if
an
event
value,
if
like
a
metadata
or
just
data,
that
we
need
from
the
event
body
is
present
inside
of
an
object
just
parsing
through
it
in
in
again
like
an
agnostic
manner.
So
we
don't
really
know
about
the
source,
just
curious.
A
So
if
you
see
that,
for
instance,
when
you
are
going
to
build
an
artifact,
you
have
a
name
and
a
version
which
are
common
fields,
so
we
define
those
as
part
of
the
like
shared
vocabulary
and
then
it's
responsibility
of
the
platform
that
generates
those
events
to
fill
valid
values
in,
and
we
don't
have
yet
like
an
extensibility
mechanism.
But
it's
something
that
we'll
need.
A
A
There
are
some
bits
of
information
the
captain
needs
and
those
are
into
the
payload
of
the
event
generated
by
captain
or
well.
They
are
originally
into
some
headers
and
then
they
are
picked
up
and
put
into
the
payload
and
then
tecton
puts
them
back
into
the
payload
and
they're
picked
up
again,
but
that's
kind
of
custom
logic
and
the
idea
is
to
reduce
that
to
a
minimum
yeah.
But
I
think
we
still
have
a
lot
of
work
doing
that
that
direction.
E
Yes,
yes,
and
that
does
make
a
lot
of
sense
and
the
trigger
for
this
particular
poc,
I
would
say,
is
filtering
events
based
on
the
event
metadata
right.
So
if
we
have
cloud
events
usually
like
see
type
source,
we're
over
the
over
also
just
filtering
out
based
on
the
event
body.
A
So
the
filtering
okay,
let
me
go
back
so
the
filtering
that
is
done
by
k
native,
it
happens
only
for
headers
and
what
canadia
supports
is
just
full
match.
A
A
E
This
sounds
really
great,
and
this
is
does
this
also
support
both
the
versions
of
cloud
events,
because,
like
techton
and
captain
uses
different,
if,
if
I'm
right-
and
if
I
remember
correctly,
contact
and
captain
are
both
using
different
formats
for
cloud
events,
I'm
also
guessing
that
setting
up
triggers
also
supports
just
setting
up
triggers
for
those
different
sort
of
elements
like
a
binary
format
and
structured
format.
C
A
Format
of
cloud
events
and
that's
what
this
inbound
and
outbound
components
are
responsible
for
for
doing
translation
between
like
the
cd
events
into
the
caption
format,
when
bringing
and
from
captain
events
to
cde
events
when
going
out,
it
makes
sense.
D
D
With
multiple
different
event,
types
by
creating
a
like
a
uniform
protocol
that
you
will
use
to
communicate
between,
so
if
you'll
be
reading
or
parsing
that
event,
you
know
how
the
vamp
looks
likes
and
how
you're
gonna
do
it.
So
you
don't
have
to
take
care
of
several
different
version
of
events.
E
Yeah-
and
I
think
that's
one
of
the
challenge
for
this
plugin
because
we
are
trying
to
achieve
interoperability
in
an
indirect
manner
where
we
really
especially
for
jenkins,
is
the
thing
where
we
really
don't
want
to
define
that
it's
only
a
certain
kind
of
source
which
is
emitting.
So
that's
a
bit
of
a
challenge,
thinking
about
the
event
metadata
or
the
event
data,
and
also
the
types
of
the
or
the
formats
of
the
events
coming
in
from
so
many
different,
varied
and
vivid
systems.
E
A
Something
that
I
wanted
to
mention
that
might
be
relevant
for
jenkins
as
well,
because
I
think
it's
similar
to
dakton
in
a
way
is
that,
while
some
systems
have
concept
of
a
deployment
or
a
build
or
remediation-
or
you
know
like
this
kind
of
abstractions,
tecton
only
knows
about
tasks
and
pipelines,
and
you
can
see
in
the
sequence
diagram
when
the
pipeline
is
started.
A
A
So
if,
if
these
results
are
available
and
the
annotation
is
there,
then
tactile
will
also
send
this
extra
artifact
and
there's
it's
a
way
for
the
pipeline
author
to
say
pipeline
also
is
a
regular
pipeline,
but
it's
also
responsible
for
creating
this
artifact,
and
this
extra
metadata
allows
tekton
to
send
the
cd
events
for
that
kind
of
city
events
as
well
and
similar
in
the
deployment.
A
Were
those
yes
here:
environment,
id
service,
name,
service
version
which
are
required
by
our
product
by
our
protocol,
and
these
two
captain
context
and
captain
trigger
vehicles
are
exposed
because
they
are
needed
by
by
captain,
and
this
is
something
that
we
had
to
do
for
the
poc,
but
I
think
we,
it
would
be
nice
to
find
a
general
way
to
carry
this
kind
of
context.
Information
without
having
to
do
you
know,
one-to-one
specific
integration,
but
this
is
a
problem
we
have
not
solved.
A
I
think
actually
putting
the
poc
together,
maybe
raise
more
questions,
but
I
think
it's
it's
good.
If
it
raises
the
right
question,
then
we
can
try
to
find
solutions
that
are.
E
E
Pipelines
so
all
of
the
information
that,
for
example,
you
have
all
of
this
information
inside
results,
and
so
it's
essentially
a
way
of
saying
that
all
of
this
should
be
there
is
it?
Is
it
like
an
and
sort
of
a
way
of
saying
that
each
of
them
needs
to
be
there?
Is
it
more
like?
Even
if,
let's
say,
service
name
is
absent?
E
We
we
will
send
this.
Even
if
some
information
is
null
or
just
not
present,
we
will
send
this
or
every
time
we
are
sending
this
kind
of
event.
All
this
information
needs
to
be
there
and
that's
a
way
of
standardizing
whenever
a
sink
is
receiving,
and
then
at
this
kind
of
event
from
it
exactly
knows
what
it's
getting.
A
I
think
we
could
support
both
cases
and
right
now
I
think
we,
I
thought
the
plc
probably
are
mandatory,
but
I
think
we
are
some
cases
already
in
the
vocabulary
where
some
of
the
fields
are
marked
as
optional,
and
so
it
should
be
possible
to
have
both
both
cases.
I
think.
D
A
A
A
So
something
we
discussed
during
the
meeting
on
tuesday
last
week,
I
think
is
it
would
be
good
to
to
have
these
as
kind
of
a
framework
and
enable
you
know
switching
components.
So
you
could
keep
kind
of
the
cloud
events
broker
part
and
the
view
monitor
measure
block
underneath
and
then
we
could
use
this
framework
to
show
different
integrations.
A
So
we
could
have
a
poc
where
we
have
an
attackton
captain
and
jenkins,
or
maybe
tactum
and
jenkins
or
jenkins,
and
captain
and
other
projects
as
they
they
want
to
get
on
board
to
make.
You
have
to
show
more
use
cases
and
make
this
more
compelling.
A
So
if
you
have
any
specific
use
case
in
mind
that
you
think
you
would
like
to
to
build
a
plc
on
between
jenkins
and
some
other
components
or
a
collection
of
other
components,
that's
definitely
something
that
we
can
look
into
and
collaborate
on.
I
think.
E
Yeah,
I
think
that
sounds
really
interesting,
because
for
now
we
like
have
not
explored
the
idea
of
having
k
native
as
a
way
of
like
serving
serving
as
a
middle
teen.
Sending
and
receiving
events.
And
I'd
really
like
to
see
how,
like
jenkins,
can
work
alongside
here
and
also
other
tools
to
to.
You
know
essentially
have
that
pipeline
running.
A
Monitor
measure
block
underneath,
so
you
can
have
someone
who
listens
to
all
the
events,
which
means
it
will
receive
events
from
any
platform
on
top
that
talks
to
the
broker,
and
that
speaks
cd
events
and
by
the
hope
is
that
by
building
this
kind
of
share
semantics
across
different
platforms,
then
you
can
build
something,
maybe
a
bit
more
sophisticated
than
the
cloud
events
player
with.
A
Instead
of
just
showing
a
list
of
events,
you
could
show
maybe
a
timeline
with
a
what
happened
into
your
workflow.
Maybe
container
image
was
built
or
deployed
and
rolled
back
and
then
also
you
could
have
a
storage
where
you
put
all
your
events,
data
and
you
can
use
that,
then
to
measure
your
devops
performance.
So
you
could,
you
know,
know
how
many
deployment
you've
done
per
day
of
the
month.
You
could
know
how
many
rollback,
how
many
remediation
you
had
to
enact
and
and
so.
E
Forth
the
vocabulary
or
just
standardizing
a
way
for
events
to
to
basically
like
mean
one
thing
I
was,
I
was
just
curious
in
understanding
how
that
vocabulary
can
function
so
again
going
back,
for
maybe
you
know
jenkins
is
saying
that
that's
like
the
case
in
my
mind,
so
right
now
you
know
there
are
a
couple
of
different
events,
there's
so
so
much
you
can
do
inside
of
jenkins.
So
when
we
have
that
vocabulary,
I
was
wondering
what
it
can
look
like
you
know.
E
A
Yeah,
I
think
you
make
a
definitely
valid
point
and
it's
something
that
we
discussed
before.
So
it's
not
the
expectation
that
all
the
platform
will
have
to
produce
all
possible
events,
and
rather
we
want
to
have
a
common
format
for
platforms
who
are
able
to
deal
with
certain
abstraction
or
concept
to
to
have
a
standard
way
of
expressing
that,
like
yeah,
I
was
saying
for
captain
freeze,
sorry
for
techton
section
really
only
has
concept
of
task
run
tasks
and
pipelines.
A
So
if
you
look
into
the
protocol
specification,
sorry
we
have
in
here.
A
Right
so
we
have
different
buckets
of
events
and
core
things
like
pipeline,
run,
queues
started,
finish,
taskcone,
started,
finished
and,
and
that
might
be
what
as
much
as
platforms
like
tekton
and
perhaps
jenkins
as
well,
can
can
produce.
A
And
so,
if
a
platform
deals
with
a
continuous
deployment,
then
it
will
be
able
to
produce
continuous
deployment
type
of
events
and
for
the
plc
in
case
of
protecton.
I
use
this
trick
with
an
annotation
to
express
extra
metadata
and
allow
basically
yeah
pipeline
authors
to
to
send
deployment
type
of
events
even
through
tekken,
and
that's
something
that
might
be
a
valid
approach
for
for
jenkins
as
well.
I'm
not
sure.
E
Yeah,
thank
you
so
much
for
showing
it
around
and
we
were
talking
about
it
earlier
and
definitely
something
that's
worth
exploring
and
testing
and
I'm
sorry,
my
questions
are
all
around,
but
I
just
had
one
question
about
the
the
event
or
the
k
native
event
broker.
E
So
I
I
wondering
how
is
it
handling
events,
and
so
it
it's
like
asynchronously
and
also
is
there
a
way
to
basically
like
send
events
back
if
a
network
failure
occurred
or
just
network
failures
or
no
failures
in
general?
So
how
is
it
handling
those
sort
of
failures.
A
A
Of
persistency
for
the
events,
you
can
have
multiple
implementation
underneath,
so
you
can,
I
think
the
default
one
is
an
in-memory
queue
that
has
that
you,
this
has
set
up,
but
you
can
have
it
running
on
top
of
other
implementation
like
kafka,
for
instance,
and
but
yes,
so
I
think,
because
the
events
are
stored
in
into
whatever
underneath
implementation
you
have,
it
should
be
possible
to
have
retry
mechanism
in
the
triggers,
but
I'm
I'm
not
entirely
sure.
I
need
to
check
on
that.
E
So,
just
to
follow
up
that,
and
it's
totally
okay,
if
there
isn't
a
very
concrete
answer
to
it,
but
anything
that
we
are
adding
in
the
mechanism
to
ensure
event,
delivery.
Also
and
persistence
is
not
going
to
be
a
part
of
the
events
or
the
cloud
events
broker,
but
more
so
of
the
whole
k
native
serving
in
general
and
adding
adding
on
bits
to
it.
For
example,
there
can
be,
as
you
said,
like
a
kafka
which
is
routing
and
also
like
persisting
or
just
other
mechanisms.
A
Right
something
that
we
discussed-
and
I
think
we
would
probably
end
up
adding
to
the
protocol-
is
the
ability
to
kind
of
link
sequence
events
between
each
other.
So
we
have
not
discussed
yet
whether
this
is
going
to
be
mandatory
part
of
the
protocol
or
not.
But
I
think
it
would
make
very
much
sense,
also
taking
inspiration
from
what
the
eifel
protocol
does
to
have
a
way
for
a
receiver
to
know
whether
a
certain
event
is
is
part
of
a
sequence
of
events.
A
You
know
it's
the
first
event,
the
last
event
and
and
so
forth.
Because
then,
even
if
you
get
an
event
multiple
times
or
if
you're
missing
some
events,
you
have
enough
information
to
to
understand.
What's
going
on
and
that's
interesting,
both,
I
think
for
the
platform
that
is
receiving
event.
If
it's
something
like
captain
or
tactum,
but
as
well
for
those
kind
of
bottom
components.
E
Yes,
that's
that
sounds
very
interesting.
E
Yes,
and
that
was
another
thing.
That
is
something
that
we
are
thinking
like
talking
about
is
just
what
happens
when
events
are
emitted
in
a
sequence
or
you
know
there
so
something
that
happened
in
tecton
and
then
we
want
to
do
something
in
captain
and
then
send
that
back
and
then
there's
multiple
like
sequences,
so
just
making
sure
that
you
know
the
triggers
are
set
on
it
correctly
and
the
the
the
filtering
and
everything
so
yes,
thank
you
again
for
for
the
explanation.
If
that
makes.
A
Sense
all
right,
you
know,
thanks
for,
for
all
the
questions
and.
A
A
Is
there
any
regular
meeting
you
have
to
do
to
discuss
this,
this
work
in
cloud
events
or
anywhere?
It
would
make
sense
to
to
follow
the
conversation.
E
Yes,
we
do
have
a
meeting,
so
it's
this
time
so
the
meeting
this
time-
you
just
do
it
an
hour
earlier,
so
this
meeting
was
at
3
pm
utc
and
we
do
it
every
monday
at
2pm
utc
and
we
also
do
have
so.
This
is
the
top
projects.
We
also
created
a
channel
for
g-stock
advance.
I
can
I
I'll
copy
the
name
of
the
channel
sure
how
we
can.
E
Yes,
cara
posted
it
in
the
chat.
Thank
you,
carl.
The
channel
name
for
cd
of
stock
jenkins
called
events
plugin.
E
We
we
also
have
demos
for
like
the
first
space
demo,
so
the
first
phase
was
developing
jenkins
as
a
source
and
now
we're
moving
on
to
jenkins
as
a
sing.
So
we
do
have
a
bit
of
demo
for
jenkins
as
the
source
itself
tomorrow
at.
I
think
it's
1
pm
1.
Yes,
it's
at
1
pm
utc
again,
if
that's
something
that
the
community
is
interested
in,
wants
to
join
and
also
send
a
link
to
that.
A
Perfect-
and
I
mean
if
you
at
some
point
have
a
demo
that
you
a
presentation
that
you
think
you
would
like
to
share
into
this
working
group.
Just
let
us
know
when
you're
welcome,
also
to
come
to
this
working
group
and
make
a
demo
here.
If
you
would
like
to.
E
Yes,
that
sounds
amazing.
I
will
be
running
short
of
time,
but
but
we
can
do
it.
The
the
next
meeting
that
we
have
in
august
that'll
be
really.
A
Okay,
great
so
I
I
won't
be
into
this
meeting,
but
email
will
so
if
you
would
like
to
do
a
presentation
in.
E
A
Okay,
that's
great
yeah!
So
thanks
for
that
I'll,
I
put
some
notes
here
in
the
list
of
presentation
for
august
16th
and
yeah.
So
once
we
prepare
the
agenda
for
the
next
meeting
I'll
I'll
edit
the
list
of
the
presentations
and
feel
free
to
add
more
information
or
reschedule
if
the
date
doesn't
work
anymore,.
A
All
right
anything
else
on
the
work
stream
updates.
I
think
yeah
there's
something
I
wanted
to
mention.
We
had
a
discussion.
We
started
a
discussion
during
the
last
vocabulary
meeting
last
tuesday
about
where
is
the
right
home
for
the
our
vocabulary
specification
and
any
software
artifact
that
comes
along
with
it,
like
sdks
and
so
forth,
whether
we
should
have
an
open
source
project
independent
from
cdf,
with
its
own
governance
and
yeah.
So
alois
raised
this
this
point
and
yeah.
So
that's.
A
I
think
something
that,
from
my
point
of
view,
would
be
interesting
to
have
on
the
I
don't
know,
I
would
say
medium
term
or
long
term
or
even
short
term,
but
I
think
we
discussed
that
the
focus
for
now
would
be
on
the
pse
and
you
know
getting
really
started
with
a
protocol
that
or
a
specification
that
is
useful
to
to
solve
some
real
use
cases,
and
I
think
once
we
have
a
name,
so
we
we
have
a.
A
We
set
ourselves
a
deadline
for,
or
at
least
a
tentative
date
for
october,
for
deciding
on
a
name,
and
I
think
once
we
have
a
name
for
our
specification,
we
will
be
able
to
start
doing
things
like
creating
a
github
organization.
If
you
want
to
or
by
buying
a
domain
name
and
and
then
eventually,
we
could
start
to
move
some
of
the
software
artifacts
into
that
space.
D
So
we,
when
you're
writing
great.
We
talked
about,
for
example,
looking
at
the
the
cloud
events
how
they
do
they
have
a
repo
for,
or
I
think
it
knows,
organization
for
cloud
events,
and
then
they
have.
The
specification
is
one
repo
and
then
all
the
different
test
case
is
another
repo
and
I
guess
that's
good,
because
then,
if
you're,
if
you're
doing
a
pull
request
on
on
the
sdk,
it's
not
in
the
same
repo
as
a
specification.
A
C
A
Right
so
mauricio
and
myself,
we
are
working
on
a
presentation.
A
It's
almost
it's
almost
finished
so
for
devops
word,
because
where
the
recording
is
scheduled
on
wednesday-
and
I
think
the
essence
of
the
presentation
is
to
yeah
kind
of
demonstrate,
a
real
life
kind
of
problem
that
we
want
to
to
solve
by
combining
different
platforms
like
tekton
and
captain
and
then
introducing
the
seek
events.
A
B
A
All
right,
we
don't
have
anything
here
for
blog
post
to
share.
C
Yes,
so
basically
me
well,
this
is
basic.
Actually
to
start
with,
it
was
based
on
a
comment
you
did
andrea,
but
then
it
was
a
discussion
between
me
and
I
completely
asked
your
name
mathias
and
yeah,
so
so
there's
a
a
a
pull
request
up
to
the
renaming
and
yeah.
Basically
we're
renaming
change
to
change
proposal,
because
that's
in
some
sense
what
it
is-
and
my
question
is
so
right
now
in
the
terminology.
C
So
there's
like
a
change
proposal
created
change
proposal,
reviewed
blah,
blah
blah.
But
then,
when
it
comes
to
the
merge,
I
had
an
internal
discussion
with
myself
earlier
and
I
my
current
proposal
is
to
actually
start
referring
to
it
as
a
change
when
it
gets
merged,
because
that's
when
the
code
actually
changes,
but
it
might
be
that,
for
consistency's
sake,
we
should
just
refer
to
it
as
a
change
proposal,
because
it
is
in
some
sense
also
the
change
proposal
that
gets
merged,
and
I
was
just
wondering
if
anyone
has
any
input
on
that.
D
Proposal
created
change,
proposal,
change,
change,
bubbles
and
abundant
and
in
your
sites
the
change
proposal
merged
or
else
you
would
actually
have
changed
merged
events.
So
you
don't
have
proposal
in
the
last
step.
Basically,.
D
I
I
would
say
I
keep
consistency.
I
do
understand
your
idea,
but
maybe
people
if
they're
looking
for
proposal
and
they
don't
have
the
last
one
they
will
miss
it
out.
But
that's
my
in
my
head.
C
D
C
C
C
F
C
F
So
we
use
multiple.
I
don't
know
if,
if
that
is
the
case,
so
maybe
I'm,
as
I
said,
maybe
I'm
trying
to
open
the
closed
door
or
vice
versa.
If
we
are
trying
to
find
the
proper
naming
for
for
pr
but
more
generic
one,
we
at
reddit
use
it
call
it.
We
name
it
code
contribution
because
we
are
working
with
github
and
gitlab
and
gareth
and
other
git
services.
Does
that
make
sense.
C
I
mean
that's
also
an
alternative
name.
I
think
matthias
was
the
one
who
who
proposed
the
term
proposal-
and
I
sort
of
like
to
have
that
word,
because
it
means
that
it
doesn't
actually
become
anything
until
it's
approved.
A
code
contribution
is
a
contribution
whether
or
not
it's
approved
or
not.
So
to
say
I
mean
I
can
presumably
contribute
code
directly
to
the
main
branch
if
I
wanted
to,
but
a
proposal
implies
in
some
sense
that
that
it
needs
to
be
looked
at
and
it
needs
to
be
approved
by
someone.
F
C
Yeah,
that's
also
a
good
point,
so
we
initially
had
change,
but
that's
like
stolen
directly
from
garrett
and
not
everyone
uses
garrett
all
right
so,
but
I
think
you
are
you,
you
bring
up
an
a
good
point
and
we
need
to
keep
that
in
mind
for
a
lot
of
things
like
what
is
the
the
least
strange
name
we
can
choose,
because
we're
not
gonna
find
a
name
that
everyone
agrees.
Is
the
perfect
name
for
it,
but
finding
some,
how
the
principle
of
least
surprise
or
something
like
that
would
be
nice.
A
Yeah,
I
agree,
but
yeah.
C
A
Think
it's
going
to
be
difficult
to
not
surprise
someone
and
you
can
think
about
ways
yeah,
you
can
you
can
view
it
in
different
ways
and
I
guess
it
gets
into
the
philosophical
territory.
D
D
I'm
not
100
staples
you're
searching,
but
I
think
the
resetta
stone
has
has
that
type
of
comparison.
What
the
difference
called.
A
I
wanted
to
check
if
we,
if
he
had
this
terminology
about
contribution
tracking
there,
because
it
would
be
good.
D
C
Spontaneous
thought
to
me
the
word
proposal
and
the
word
request
are
greatly
interchangeable.
Maybe
it
would
be
better
to
call
it
a
change
request
know
that
that
collides
with
other
terminology,
I
know
eric's
on
in
ericsson.
You
have
a
different
meaning
for
a
change
request.
I
think
that's
basically
a
feature
across
right.
C
D
A
A
Was
it
sorry
leora?
Yes,
I'm
not
sure
if
I'm
pronouncing
the.
A
A
C
A
If
you
would
like
to
you,
don't
have
to
do
it,
but
we're
trying
to
capture
there
as
many
as
possible.
I
think
so
I
thought
it
might
be.
It
might
be
good.
A
Yeah
absolutely
I'll
upload
the
meeting
as
recording
as
soon
as
it's
available,
and
it
will
be
then
in
the
playlist
on
the
cd
foundation
site
youtube.
Somebody.
A
All
right,
well
thanks
everyone
for
joining
today
and
have
a
great
rest
of
your
day
until
next
time.