►
From YouTube: CDF - SIG Events Meeting - 2021.10.19
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
B
I
saw
that
shiroti
was
writing
something
in
slack,
but
I
didn't
see
that
she
finished
it.
So
I'm
not
sure
if
she
wanted
to
add
something
about
her
attendance
or
not.
I
haven't
heard
that
anyone
else
is
planning
to
join.
On
the
other
hand,
I
haven't
heard
that
anyone
else
is
not
planning
to
join
either.
C
D
A
Yeah
we
can
take
a
look
at
discussions
and
also
maybe
if
there
are
peers
that
have
some
comments.
I
know
you
eric
and
made
some
comment
on
one
of
my
pr's.
A
Regarding
I'm
trying
to
remember
now
last
words.
A
No,
it
was
the
not
the
human
testing,
but
the
markdown
files
edited
and
added
some
examples
based
on
what
we
currently
have,
but
you
wanted
to
improve
and
or
have
continuous
discussions
on
if
we
really
should
have
it
in
the
outside
layer,
I
should
move
it
in
right.
Yes,.
C
I
think
maybe
a
general
comment
on
this
meeting.
I
think
we
briefly
talked
about
it.
Last
monday
meeting
I
mean
we
need
to
maybe
make
a
bit
clearer
focus
on.
I
mean
division
on
what
we
should
talk
about
in
in
this
meeting
compared
to
the
sig
meeting,
because
now
I
haven't
been
there
for
several
times
in
this
meeting,
but
I
see
now
that
there's
been
a
lot
of
discussions
on
the
name
and
the
repositories
and
those
things,
and
I
would
suggest
that
we
keep
those
discussions
in
the
sig.
C
B
A
C
A
A
So
if
you
want
to
to
kind
of
change
this,
so
we
have
a
discussion
before
I
can.
I
can
close
the
pull
request
and
open
a
new
one
with
the.
B
B
As
always,
basically
we
we
had
issues
drawing
the
line
between
attributes
that
we
need
for
routing,
which
should
be
on
top
level
and
attributes
that
we
don't
need
for
routing,
which
should
be
inside
the
data
thing
and
it's
I
think
you
commented
andrea
or
someone
else
that
basically
any
attribute
we
look
at.
We,
we
probably
could
come
up
with
a
scenario
where
we
you
would
use
that
for
routing,
but
that
doesn't
mean
that
everything
everything
should
be
on
top
level.
C
B
That,
to
me,
would
be
something
that
maybe
should
go
on
top
level
if
we
want
to
follow
the
cloud
events
idea
of
having
rooting
and
filtering
things
on
top
level,
I'm
not
sure
if
that
is
adding
to
the
discussion
or
not,
but
but
something
like
that
might
have
a
to
to
be
on
the
top
level
inside
of
inside
the
date
object.
But
we
could
also
say
yes
exactly,
as
you
said,
anything
that
we
standardize
on.
We
should
just
go
into
the
data
object
and
we
don't
touch
the
top
level.
C
Maybe
that's
not
possible,
I
mean
we
might
need
to
have
some
more
fields
on
top
level
than
what
cloud
events
provides,
but
yeah,
I'm
not
exactly
sure.
I
think
someone
said
sometime
also
that
it
extensions
of
the
protocol
are
often
done
on
the
top
level
which
surprised
me
at
that
time
a
bit,
but
maybe
that
is
I'm
not
sure
what
cloud
events
says
about
the
differentiation
between
data
object
and
the
top
level
parameters
for
properties.
D
I
think
extensions
with
extensions
are
meant
extensions
of
the
top
level.
So
if
you
define
schema
for
the
the
body,
I
don't
think
the
ssl
is
considered
an
extension
of
cloud
events,
because
cloud
events
does
not
mandate
anything
about
what
you
put
in
the
body.
So
it's
not
it's.
It's
a
black
box.
I
think
from
design's.
D
A
A
A
Different
add
add-ons
to
it,
so
it's
not
it's
not
like
it's
forwarded
fields
or
something
so,
but
that
way
I
don't
know
if
they
actually
need
a
schema,
but.
D
D
I
think
our
vocabulary
or
schema
that
we
define,
if
the
type
of
data
that
we
want
to
transport
in
our
events,.
D
It
does
not
necessarily
have
to
be
so
it's
not
going
to
be
in
its
basic
definition,
I
think,
associated
with
cloud
events,
and
then
we
can
have
a
cloud
advanced
binding
and
this
card
event
binding.
We
can
identify
whether
some
of
the
fields
needs
to
be
specified
as
an
extension
of
cloud
events
or
not.
C
Yeah,
I'm
trying
to
sort
out
in
my
mind
on
what
we
would
what
we
should
suggest
for
ourselves,
at
least
if
we
should
suggest
our
protocol
to
be
an
official
extension
known
to
cloudvents
or
if
we
should
be
morris.
Andreas
said
something
that
is
currently
based
on
cloud
events,
but
should
it
be
really
tightly
connected
to
cloud
events
and
could
just
use
some
other
layer
in
between
tomorrow?
Maybe
whatever
comes
up
to
me,
it
feels
more
natural
to
go
that
way
to
to
specify
our
specification
on
like
the
body
level
or
data
level.
C
I
mean
then
we
will
have
like
a
dependency
currently
to
cloud
events.
I
mean
somehow
down
in
the
protocol
hierarchy
or
the
osi
model,
but
we
shouldn't
have
any
reference
back
from
cloud
events
to
us
really.
That
sounds
a
bit
weird
to
have
that
reference.
Actually,
in
my
mind,
if
we
would
consider
the
cloud
events
as
a
transport
protocol
in
between
ourselves
and
whatever
message,
bus
or
broker
is
used.
D
Yeah,
I
agree,
and
I
think
we
could
follow
similar
modes
with
the
cloud
events
do
themselves.
They
have
like
the
core
specification
and
then
they
have
the
different
bindings
for
amtb,
http,
kafka
and
so,
depending
on
the
transport
player,
underneath
how
the
the
different
cloud
defense
fields
are
mapped
to
it
and
yeah
I
mean
the
one
that
we
used
in
the
in
the
plc.
Of
course
it
could
be
protocol
binding.
D
C
D
D
So
in
those
scenarios
cloud
events
might
not
be
the
best
protocol
for
communication.
C
I
was
thinking
of
there
for
this
event,
format
specifications
that
exist
there
are
row
and
json
and
protobuf
for
example.
How
what
do
they
really
dictate?
Is
that
the
the
format
of
the
the
top
level
or
the
data
level
or
all
of
it
or
I
mean
we
said
now-
we
should
at
least
start
with
having
our
definition
in
json,
but
are
we
somehow
bound
to
using
one
of
these
event
formats
or
I'm
not
sure
what
that
means?
C
I
mean
it's
not
really
a
protocol
binding
in
in
the
stack
going
downwards
in
the
osi
model.
Rather,
event,
format
rather
dictates
our
syntax.
It
seems,
or
am
I
misunderstanding,
this.
B
B
D
D
D
C
B
C
Make
capture
proposal,
at
least
of
course,
we
need
to
make
sure
that
everyone
is
aligned
with
it.
I'm
pretty
sure
that
that's
not
how
captain
does
it
today,
at
least,
but
maybe
they
are
okay
with
doing
it
that
way
anyway,
but
of
course
we
need
to
sync
with
them
to
see
if
they
have
any
any
objections
to
it
or
any
other
comments
on
it.
E
Parts
yeah
I'm
not
very
familiar
with
the
implementation
right
now,
but
yeah.
What
I
can
say
that
this
plugin
is
rather
a
prototype
at
the
moment.
So
once
the
specification
gets
closer
to
the
final
version,
we
will
be
aligning
it
anyway
for
me.
Currently
it's
not
a
concern
and
yeah.
I
need
to
look
into
the
code
to
see
how
the
events
are
handled
and
produced
there.
D
I
would
have
one
one
document,
which
is
valid
across
all
the
various
event
types
which
defines
how
this
is
mapped,
for
instance,
into
a
json
body
that
can
be
included
then
into
into
cloud
events.
D
C
B
C
Writing
it
in
the
notes.
Yes,
okay,
sounds
good.
I
was
just
reflecting
on
the
comments
you
had
in
there
in
the
beginning
on
the
what
how
a
field
does
it,
for
example,
with
this
domain
parameter,
I
would
maybe
suggest
that
we
start
with
not.
I
mean
trying
out
this
trying
this
out
this
statement
and
see
if
it
holds
also
for
any
data
that
is
currently
held
in
in
eiffel
events.
C
So
it's
compatible
with
that,
for
example,
the
domain
id
would
be
part
of
the
the
routing
key
as
well
and
could
in
in
this
spec.
I
would
say
it
could
maybe
be
part
of
the
the
event
type
itself
where
we
actually
intend
to
have
inverse
dns
lookup,
but
maybe
the
domain
and
could
actually
be
part
of
that.
Somehow.
C
Yeah
that
actually
sounds
like
a
very
good
idea
and
that's
another
view
on
extensions.
I
think
that
is
quite
good
to
have,
maybe
that
the
extensions
could
actually
be
seen
as
cloud
events
but
an
amendment
to
cloud
events,
but
we
do
something
on
top
of
it
at
least
or
yeah
yeah.
That's
a
good
point.
Okay,.
D
Right,
so
what
we're
saying
is
also
that
if
we
identify
that
there
is
a
need
for
an
extension
and
none
of
the
existing
extension
fits
the
job,
we
might
go
ahead
and
actually
try
and
contribute
an
extension
to
cloud.
Events
like
a
general
purpose
cloud
events
and
then
make
use
of
it.
A
Sounds
good,
it
should
be
pinned
that
down
also,
and
that
svg
is
what
you
said,
because
it
was
a
good
statement.
I
think
so.
We
have
that
if
we
want
to
because
for
me
my
mind,
it
means
that
if
we
want
to
do
something
on
top
level,
we
should
contribute
with
an
extension.
D
All
right,
it's
great
sounds
like
we
are
quite
aligned
or
agreeing
on
on
this.
D
D
D
D
A
And
now,
when
in
a
full,
we
generate
code
based
on
on
jsonshima's.
Unfortunately
I
don't
have
that
in
my
head
top
of
my
head
right
now
what
we
use
there
but
yeah
you
can
generate
code
based
on
shrima's
signal.
D
D
D
It
does
not
take
us
much
forward
in
terms
of
content,
and
necessarily
I
mean
if
we
come
up
with
a
way
to
generate
the
code.
I
guess
it
would
allow
us
then
to.
D
To
make
an
sdnk,
which
is
more
complete
in
terms
of
the
events
that
we've
defined
now,
but
I
think
there
is
a
lot
of
there
are
other
areas
of
the
protocols
that
needs
to
be
further
investigated.
I
mean
we
had
some
previous
discussions
about
links
between
events
and
how
to
manage
extensions,
for
instance
and
context,
and
well
one
of
the
questions.
I
I
I
added
the
kubecon
when
I
presented
this.
D
D
And
my
answer
was
that
we
we're
trying
to
come
up
with
a
list
of
fills
that
can
be
matched
to
as
many
implementations
as
possible,
but
that
will
provide
an
extension
mechanism
so
that
a
specific
club
platform
can
transport
extra
data
if
they
want
to-
and
I
think
this
is
something
that
will
be
needed
and
we
need
to
to
specify
how
we
handle
that
in
the
protocol.
C
Yeah,
that
sounds
like
a
very
good
thing
to
look
into
as
well,
and
therefore
the
naming
of
the
I
mean
the
vocabulary
used.
I
mean
we
had
this
rosetta
stone
document
in
the
interoperability
sig.
I
think
we
should
revisit
that
and
use
that
as
a
base
when
we
decide
on
on
some
generic
names
for
these
things,
for
example
the
scm
parameters
or
attributes,
but
also
we
should
look
into
what
spdx
uses
for
similar
things,
and
maybe
others
as
well.
C
I
was
thinking
it
sounds
like
we
are
approaching
some
kind
of
decisions
now
which
we
haven't
really
done
before.
I
believe
so
I
was
thinking
where,
should
we
note
such
decisions?
We
had
a
proposal
now
on
on
using
the
data
object
in
a
certain
way,
and
I
guess
we
should
note
that
as
a
decision
when
we
have
taken
it
of
course
somewhere.
So
maybe
that's
input
to
the
sig
meeting
to
decide
on
or
describe
where
to
note
such
decisions
that
we
take.
B
We
did
discuss
a
while
ago
during
the
summer.
I
think
how
the
work
group
takes
decisions
and
I
think
it
might
have
been
like
one
of
the
primary
outcome.
Outcomes
of
this
working
group
is
the
package
decisions
for
a
quick
like
check
in
in
the
sig,
but
maybe
that's
that's
going
too
far.
I'm
not
sure
I
mean.
Obviously
when
it
comes
to
smaller
stuff,
we
have
to
be
able
to
take
our
own
decisions,
but.
C
Oh
yeah
for
sure
for
sure,
but
maybe
these
more
groundbreaking
ideas
or
rules
we
might
need
to
sink
them
on
the
sig
as
well,
because
there
are
some
other
people
in
the
scene.
Maybe
that
are
normally
on
this
meeting.
So
we
make
a
broader
consensus
on
those
decisions.
I
think
it's
I'm
not
sure
at
least
so
far.
I
think
it's
good
that
we
take
those
decisions
in
the
sig,
but
it's
very
good
that
they
can
be
prepared
from
here.
C
A
But
then
to
answer
your
question
about
where
we
document
our
decisions,
isn't
that
going
to
be
part
of
the
protocol
itself?
I
mean
if
we
decide
that
we
should
use
a
specification,
as
in
the
proposal
here.
Doesn't
that
go
into
the
specification
as
a.
D
Yes,
absolutely,
I
totally
agree
on
this
and
I
think
yeah
every
time
we
take
this.
This
kind
of
decision
we
can
incrementally
add
them
to
sentences
of
paragraphs
were
relevant
in
the
spec,
so
we
keep
track
of
them
and
we
can
always
modify
them
over
time,
but.
D
Many
terms
of
governance,
we
can
start
lightweight
for
the
project,
I
think,
but
even
if
we
take
a
decision
in
the
in
the
working
group,
I
would
say
that
we
can
still.
D
D
So
and
when
we
the
project,
will
we
can
decide
at
some
point
rules
that
we
want
to
to
have
for
making
changes
to
the
specification.
If
you
want
to
have
a
certain
amount
of
reviewers
diversity
across
companies
or
this
kind
of
rules,
we
can
set
up
over
time.
A
That
might
be
a
bit
cumbersome
is
to
actually
create
a
pr
with
this
proposal
and
then
refer
to
the
pr
everywhere.
A
C
D
Andrea,
you
were
saying
something
I
was
going
to
say.
I
think
that
I
mean
this.
This
group
should
be
able
to
take
decisions
about
the
about
the
protocol
and
the
vocabulary,
and
I
mean
right
pr's
and
I
I
fear
that
if
we
make
proposed
decisions
related
to
the
protocol
here
and
need
to
validate
them
back
in
the
main
meeting
and
then
come
back
here
and
then
come
back
to
the
main
meeting,
it
will
make
things
more
complicated,
slower,
slows
down
and
I'm
not
sure.
D
It
would
provide
much
value,
I
mean
if
folks
are
interested
in
discussing
the
specific
of
the
protocol,
and
then
we
should
make
it
clear,
as
emily
was
suggesting
in
the
beginning.
What
is
the
scope
of
each
meeting?
And
so,
if
you
say
okay,
this
is
where
we
discuss
the
vocabulary
and
the
protocol
format
and
the
technical
aspect
of
that.
I
think
that's
where
we
should
take
the
decisions
as
well.
E
E
Introducing
some
kind
of
review
cycle
would
be
nice,
but
you
know
one
of
the
ways
would
you
actually
review
particular
pull
requests
that
might
delay
the
process
a
lot
or
just
a
new
version
of
the
specification.
E
Yeah,
so
what
we
experienced
in
jenkins,
we
have
jenkins
enhancement
proposals
and
I
would
say
that,
even
if
everyone
wants
to
help
the
feedback
cycle
is
extremely
slow.
So
if
you
rely
on
reviewing
every
particular
pull
request,
it
will
take
ages
to
get
any
specification
approved.
E
So
basically
we
ended
up
that
there
is
a
champion
that
needs
a
development
of
particular
job.
Then,
at
some
point,
when
this
champion
believes
that
jack
is
ready
for
review
and
approval,
then
it
gets
raised
to
wider
community
that
makes
the
disapproval
only
once,
but
in
middle
cycles
it's
basically
just
the
open
document
for
collaboration.
D
I
guess
it's
similar
in
a
way
yeah,
so
we,
we
do
add
a
feature
specific
feature
to
the
protocol.
So
let's
say
we,
we
have
the
initial
protocol
and
we
add
support
for
links.
D
D
E
Right
so
basically,
the
idea
is
to
not
slow
down
small
changes,
because
if
you
expect
all
stakeholders
to
sign
off
every
request,
then
it
will
become
a
nightmare
yeah,
just
maybe
separate
into
some
specification
parts
and
separate
proposals
and
go
on
through
all
the
standard
proposal
there.
E
D
D
E
So
does
this
make
sense,
it
makes
sense,
so
maybe
it
makes
sense
to
explicitly
but
yeah.
There
is
a
kind
of
approval
process
for
the
larger
group,
so,
for
example,
in
jenkins,
what
we
do
we
put
it
on
the
developer
mailing
list
at
least
one
week
ahead
of
a
governance
meeting
and
then
in
the
governance
meeting.
If
there
is
a
consensus
in
the
mailing
list,
we
basically
rubber
stamp
it.
If
not,
we
discuss
and
agree
on
the
next
decisions.
D
D
Yeah,
this
is
partly
what
we
started
discussing,
also
in
the
last
meeting
about
what
to
put
in
the
spec
repo
in
the
new
project.
If
you
wanted
to
have
there
like
a
community.md
or
governance.md,
where
we
specify
this,
this
kind
of
processes
as
well
yeah.
E
And
so
governance
md
is
expected
in
the
cd
application
checklist.
E
D
Yeah,
I
I
mean
we
can
create
the
structure
and
I
think
in
the
beginning
it
might
be,
the
content
might
be
simple
and
then
we
can
add
over
time.
I
don't
want
to
do
too
much
content
ahead
of
time
without
the
right
context
to
you
know,
protect
them.
D
All
right,
okay,
I
guess
we're
getting
closer
to
the
to
the
hour.
One
thing
that
I
wanted
to
to
ask
us.
D
Whether
well
first
is
whether
it's
it's
okay.
Should
we
go
ahead
and
start
creating
this
repos
in
the
news
in
the
new
gita.org,
you
know,
setting
up
the
apache
license,
creating
the
readme.md
and
importing
some
of
the
content
already.
D
And
this
is
one
thing
I
mean
I
could
I'd
be
happy
to
do
some
of
the
work
there
setting
up
kind
of
the
basic
structure
for
the
spec
repo.
C
Yeah
we
actually
at
least
defined
or
settled
on
the
name
for
the
repository
itself
on
the
last
sig
meeting
or
the
proposal
there.
I
haven't
created
it
yet
I
intended
to
do,
but
I
haven't
yet
done
it.
So
the
proposal
was
to
create
it
and
call
it
spec,
just
as
it
and
then
the
sdks
should
be
called
decay.
Repos
should
be
called
sdk
dash,
something
where
something
is
the
language
or
whatever.
The
sdk
is
for.
A
I
think
both
the
is
this
background
is
the
case
we're
following
the
cloud
events
way
of
naming
it.
C
D
Okay,
so
you
you
want
to
to
do
that
work,
a
mill
start,
creating
the
repo
setting
up
the
scaffolding
for
for
the
repo
or
shall.
C
Maybe
you
have
more
time
than
I
have
so
then
you're
free
to
do
it.
No,
no
problem
at
all.
I'm
sure
if
I
need
to
give
you
some
authority
to
be
able
to
do
it,
but
for
sure
you
can
do
it
for
me,
that's
no
problem
at
all.
D
D
Investigate
about
json
schema,
and
I
mean
it's
something
that
we
can
do
collaboratively
of
course,
but
yeah.
I
just
wanted
to
ask
if
anyone's
felt
like
you
want
to
drive
that
that
part
of
the
work
come
up
with
some
proposals
we
can
discuss
together,
because
I
feel
like
we've
been
discussing,
we
discussed
a
bit
in
two
or
three
meetings
about
that
topic,
but
I
think
we
need
to
to
get
more
more
information.
So
someone
of
us-
or
maybe
all
of
us,
could.