►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
A
C
Meeting
so
there
was
quite
a
lot
of
aps
that
come
came
after
the
last
meeting.
I
haven't
had
time
to
look
at
any
of
mine
because
I
have
a
report
that
is
due
in
two
days,
but
as
soon
as
that
is
done,
I'm
planning
to
get
back
into
this
again,
so
there's
a
bunch
of
github
discussions
that
need
to
be
had
and
there's
a
bunch
of
other
things
that
need
to
be
looked
into.
C
A
D
A
A
C
Perhaps
a
more
general
question
regarding
that.
I
don't
know
if
it's
been
discussed
before,
but
do
we
see
our
or
I
guess
we
don't
see
our
events
as
sort
of
replacing
the
need
for
those
apis,
but
it
would
perhaps
be
more
that
we
need
to
send
enough
information
in
the
events
so
that
someone
else
can
go
to
those
apis
and
get
the
rest
of
the
information.
Is
that
what
we're
in
for
or
how
do
you.
E
I
think
it
depends
like
for
us
from
like
from
the
captain
perspective
in
an
ideal
world,
we
could
directly
register
a
web
hook
and
whenever
something
happens,
we
get
exactly
this
information
that
that
we
agreed
on
because
right
right
now
we're
doing
a
lot
of
translation
works.
There's
like
a
passive
layer.
That's
just
translating
from
one
proprietary
api
to
a
standardized
format
that
all
services,
then
inside
of
captain,
can
can
use,
and
you
don't
just
know
where
these
events
are
coming
from.
A
A
D
D
We
should
start
there
at
least,
and
then,
of
course
you
could
add,
don't
know
optional
parameters
or
whatever
that
could
contain
more
information
for
convenience
or
whatever.
So
we
don't
need
to
to
dig
up
everything
from
all
sources,
but
we
should,
I
think
we
should
start
small
and
and
expand
from
there
when
needed.
C
I
think
that
makes
sense,
and
I
was
about
to
ask
you
mentioned
like
if
there
is
a
standardized
way
to
fetch
more
information,
my
understanding
or
is
that
maybe
some
of
that
falls
under
the
interoperability
sig
that
they
might
be
thinking
in
the
along
those
lines
to
have
those
kind
of
standardized,
api,
endpoints
and
stuff.
Is
that
correct.
A
Yeah
good
stuff,
so
I
would
say
that
then,
like
the
tasks
kind
of
like
the
pen
and
task
are
going
to
into
the
github
discussions,
making
sure
that
we
add
input
to
the
threads
and
then
start
kind
of
looking
into
the
cloud
events,
mapping
and
the
research
angle
that
I
have
mentioned
right
alice
again.
If
you
can
share
links,
I
will
do
that.
I
will
do
the
same.
I
will
probably
send
a
pull
request
with
the
reference
section
for
each
of
the
each
of
the
projects
that
we
know
that
are
that
are
out
there.
A
E
D
Just
a
heads
up,
I
guess
we
said
in
the
last
russia
meeting
we
didn't
have
any
yesterday,
but
the
one
before
we
said
that
on
the
next
I
think
matthias
accepted
that
he
will
present
the
link
model
rifle
in
the
next
meeting.
So
that
could
be
served
as
as
input
to
this.
You
mentioned
referencing
events
right
mauricio
and
how
we.
A
C
So
I
think
I
mean
what
you
mentioned
before
this,
like
that
the
start
like
to
start
with
the
focus
for
our
events
will
be
to
send
enough
information
so
that
the
recipient
can
understand
that
something
has
happened
and
has
enough
information
to
fetch
more
information.
I
think
that's
a
good
a
good
way
of
doing
it.
D
B
A
I
think
that
I
think
that
topics
that
are
like
big
enough
to
bring
to
the
see
events
meeting.
I
think
that
we
should
definitely
raise
them
there
if
they
are
like
small
topics
or
small
changes.
I
think
that
just
sending
a
pull
request
is
fine,
where
we
can
all
review
and
maybe
discuss
if
we
merge
the
poor
request
during
the
sig
events
meeting,
but
yeah
large
topics
and
discussions
and
outputs
from
discussions,
I
think
that
we
definitely
need
to
touch
on
on
the
on
the
sig
events
meeting
with
the
larger
group.
E
So
what
we
did
on
the
most
like
in
the
when
I
was
working
in
the
w's
receipt,
which
is
obviously
way
more
formalized
process,
we
had
like
a
well-defined
public
event,
comment
period
that
okay,
if
we
want
to
take
a
decision,
we
just
post
it
somewhere,
people
can
comment,
and
then
with
it,
when
every
comment
has
been
addressed
and
has
been
addressed,
doesn't
mean
that
we
necessarily
say
okay.
This
is
like
important
enough,
or
are
we
doing
exactly
what
you're
proposing,
but
you
have
to
be.
E
E
If
you
want
to
add
something
here,
then
please
do
it
right
now,
because
otherwise
it
will
get
merged
that
made
things
merging
pretty
straightforward
and
everybody
knew
when
they
had
to
look
at
it.
So
if
you
looked
at
things
every
two
weeks,
you
were
still
good,
not
saying
we
have
to
formalize
it
that
much,
but
that's
something
that
I've
seen
working
well
in
the
past.
You
just
could
go
through
those
decisions
easily
before
meeting
and
bring
things
up
beforehand.
If
you
wanted
to.
A
E
It
might
also
be
something
to
do
honestly
at
the
later
stage.
I
mean
right
now
you
whistle
like
in
this
draft
stage
with
events
where
nothing
is
like
really
set
into
stone,
but
if
you
want
to
these
are
things
that
you
don't
want
to
do
when
you
move
more
for
a
final
version,
maybe
I
think,
for
the
time
being,
it
would
even
be
fine
to
see
like
if
nobody
comments
on
something
within
or
in
between
two
meetings.
D
Yeah,
I
think
I
agree
with
you
there
at
least
we
can
start
very
easily
now
and
just
put
in
pull
requests
and
drafts
on
on.
It
might
not
be
totally
clear
and
thought
through,
but
let's
put
something
out
there,
so
we
can
start
looking
at
it
and
trying
it
out,
maybe
even
and
then
discuss
it,
of
course,
and
and
when
it's
a
bit
more
formal,
when
we
have
a
real
a
draft,
we
want
to
go
for
a
beta
whatever.
D
C
Thank
you
so
yeah,
so
we
have
two,
I'm
not
sure
how
much
background
you
know
already,
but
we
have
two
two
different
kind
of
meetings.
We
have
the
the
regular
special
interest
groups,
meetings
that
are
typically
on
mondays,
and
then
we
have
this
as
like
a
smaller
work
group
meeting
for
for
trying
to
get
stuff
done
when
it
comes
to
the
event
specification
and
and
the
most
of
the
work
that
we
do
is
either
in
prs
or
in
github
discussions
in
our
sig
events
repo.
C
So
I
think
a
good
way
to
to
participate
there
and
to
follow
along
and
to
contribute
is
to
be
a
part
of
the
reviews
and
discussions
in
github.
I
think
that
would
be
the
main
way
of
doing
it.
We
were
just
saying
before
that.
Unfortunately,
most
of
us
have
been
quite
busy
for
the
last
couple
of
weeks,
but
we're
aiming
to
get
more
or
to
pick
up
the
pace
again
in
the
coming
weekend.
So.
B
D
B
B
D
B
D
Is
some
more
common
discussions
around
interoperability?
At
large,
I
mean
how
good
systems
interpret
with
it
with
each
other,
regardless
of
if
they
produce
events
or
some
other
means.
I
mean
we
base
things.
We
have
discussions
on
metadata
and
policies
and
different
kinds
of
aspects
of
interoperability
between
ci
cd
systems
in
the
that
interoperability
group
or
more,
I
would
say,
more
higher
level,
maybe
or
more
general
level.
D
B
All
right
I'll
spend
some
time
on
the
the
documents
that
you
just
shared
and
I've
been
looking
through
some
other
documents
on
the
events
shared
in
the
calendar.
I
think
these.
This
is
a
lot
more
clear.
What
you
just
shared
so
I'll
go
through
this
and
then
I'll
have
something
too
intelligent.
To
say,
after
that,
I
suppose.
B
D
Much
more
progress
here
and
now
I
was
just
thinking
eric
about
your
suggestion
there
on
how
we
should
file
decisions.
We
could,
we
could
for
sure
for
sure
to
start
up
the
discussion
there
on
how
to
do
it
where
to
file
those
decisions
and
we're
working
around
them.
If
we
shouldn't
evolve
the
sig
in
all
those
decisions
or
not,
such
things
could
be
discussed
there.
I
guess
if
we
just.