►
From YouTube: CDF SIG Interoperability Meeting 2020-04-16
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
D
A
A
We
didn't
discuss
how
long
like
I
was
thinking
like
normally
again
based
on
what
other
communities
to
like
someone
takes
the
chair
or
chaired
the
meeting
or
first
late
meeting
for
few
meetings.
Oh
and
then
it
that
person
passes
the
role
to
other
person,
so
we
have
always
like
continuity
and
rotation
other
binary.
Every
meeting,
changing
people
and
that's
I-
don't
want
to
ping
you
about
agenda
either
because
I
was
thinking.
You
would
sent
the
agenda
for
this
week.
Well.
Clearly,.
A
Okay,
so
welcome
everyone
and
I
see
people
are
putting
their
names
and
if
you
haven't
done
it,
please
do
that.
So
we
know
who
joined
and
this
week,
as
you
see
the
agenda,
we
don't
have
a
presentation
this
week.
I
think
it
was
Roman.
It
was
your
SLO
district
if
I
am
not
mistaken,
but
you
already
warned
us
that
you
won't
be
able
to
make
it.
So
that's
fine
and
the.
A
So
thanks
coming
on
the
agenda
is
like
two
usual
action
item.
You
review,
I,
don't
know
if
we
have
any
action
items
from
us
which
I
don't
see
any
like
I
should
share
my
screen,
and
the
second
topic
is
the
idea.
Tracy
I
think
you
proposed
to
use
hack
MD
like
during
the
very
first
meeting,
which
we
haven't
had
time
and
opportunity
do
that.
But
since
Eric
joint
I
said
like
Eric,
maybe
we
can
try
this
and
then
we
did
a
quick
try
on
hack
and
the
end.
A
It
looks
like
it
just
it
just
works,
so
that
is
the
next
topic.
So
the
problem
we
currently
have
is
I
it's
not
a
problem,
but
the
challenges
we
have
two
places
to
keep
meeting
knows
we
keep
notes
on
Google
Docs
because
we
can
edit
the
document
collaboratively.
So
if
someone
is
talking,
the
other
person
can
take
notes
and
vice
versa,
and
that
means
to
migrate.
The
meeting
minutes
to
get
has
because
certain
countries
don't
have
access
to
Google
services.
A
So,
in
order
to
be
more
inclusive,
we
put
the
notes
to
github
in
meetings
that
MD
file,
but
that
is
like
it
is,
even
though
it
takes
ten
minutes
every
week.
It's
useless
time
spent
on
syncing
to
nose
between
each
other,
and
it
is
not
that
simple
to
do
that,
copying
from
Google
Docs
to
github,
markdown
and
so
on,
and
then
we
gave
a
try
on
hi
candy.
A
This
is
what
we
have
now:
the
basic
sync
from
github
repo
into
the
project
we
created
in
hack
MD,
and
then,
when
you
update
this
file,
it's
obvious
goes
and
pushes
the
change
to
github
and
under
hi
and
the
user,
which
is
also
good
because,
like
putting
meeting,
means
yeah
it's
the
contribution,
but
it's
better.
It's
pushed
by
a
functional
user.
So
everyone
knows
this
was
a
meeting
made
update.
It's
not
some
other
type
of
contribution
in
case.
A
B
Now
happy
to
I
think
anything
that
makes
life
easier
for
the
chairs.
Is
it's
a
good
thing
and
if
it
removes
this
one
extra
level
of
kind
of
boring
work,
I'm
all
for
it,
I've
used
it
in
a
couple
of
other
communities
and
yeah.
If
you
have
a
github
account,
it
seems
to
be
straightforward
for
people
to
just
update
minute
sign
themselves
in
in
the
same
way,
so
yeah
I'd
be
fully
supportive
of
moving
on
to
it
as
the
the
default
way
to
capture
the
notes.
B
D
A
And
now
the
next
question
is,
since
again
we
can
help
each
other
during
the
meetings
and
so
on.
Currently
the
team
we
have
on
hack,
em
D
is
called
C
interoperability
and
we
I
think
Eric
Tracy.
You
are
both
admins
in
this
team
and
we
can
add
anyone
who
wants
to
get
admin
to
this
team,
so
you
can
go
and
take
notes
and
do
whatever
hi
kandi
needs
admins
to
do
I
dunno
how
to
configure
this
yeah
team
settings
members.
A
So
you
just
reach
out
to
Eric
or
me
or
Tracy,
and
ask
to
be
added
as
admin
or
what
else
do
we
have
writer?
So
you
can
take
notes
or
reader?
Actually,
you
don't
need
to
be
a
member
of
the
team
to
read
the
notes,
because
it's
the
notes
is
publicly
available.
You
don't
need
to
login.
You
can
see
the
notes
both
on
hi
candy
or
in
github.
A
B
B
A
So
then
I
put
agree
here
from
next
meeting
and
onwards.
We
switch
to
hack,
MD
and
then
I'll
put
this
document
to
read
only
mode
and
only
suggestions,
comments
with
a
lot
ofin
in
case.
If
someone
finds
this
leak
and
unable
to
figure
out
where
the
meeting
notes
are
kept
from
mexicanos,
you
can
atleast
respond
to
that
person's
question.
So
this.
E
A
E
A
Always
like
similar
thing
happens
with
the
meeting
tools
as
well
like
hangouts,
you
can't
use
hangouts
with
China
Chinese
contributors,
so
you
zoom
some
time
ago.
Zoom
was
kind
of
going
into
some
kind
of
issue
with
China
and
and
this
was
brought
up
to
see,
bf
talk
discussion
as
well
like
few
months
ago,
so
sometimes
these
things
change
and
I
mean
to
adapt
to
a
low
contribution.
B
B
Project
and
Eric
Sorensen
is
going
to
write
something
about
Tecton
and
the
view
of
how
Tecton
is
going
to
drive.
Standardization
and
I
have
Cara
Telemark
from
Jenkins
ex.
Who
will
talk
about
Jenkins
X
as
a
platform
that
kind
of
pulls
together
best-of-breed
tools
and
what
the
benefits
are
for
that
and
I.
A
B
B
B
A
B
And
I
think
Jackie's
still
working
on
this,
but
watch
this
space.
If
she
she
might
be
looking
to
set
up
some
follow-up
like
a
panel
or
like
a
virtual
panel
and
in
which
case
you'll
invite
sort
of
the
authors
of
the
articles
to
come
along,
or
maybe
the
interoperability
sig
as
a
whole
to
to
do
as
I
sort
of
ask
me
anything
type
session
or
I'm,
not
sure
what
state
that's
in.
But
if
that's
the
case,
I've
told
her
to
reach
out
to
this
group.
If
she's
she's
got
a
date
and
a
format.
A
B
B
Okay,
so
can
you
see
my
screen
with
the
document
yeah
right?
Okay,
so
this
doc,
it
outlines
the
Charter
now
and
we've
got
kind
of
these
outcomes
which
we
want
to
use
to
work
towards,
and
thanks
andreas
for
adding
in
those
additional
comments
which
I'll
go
through
and
sort
of
work
out
how
to
elaborate
them
in
the
document.
So
I
think
this
comment
was
capturing.
The
different
types
of
end
users.
C
B
Yeah
I
think
that's
pretty
key
and
actually
there's
an
assumption
in
the
in
the
way
I'd
used
end
user,
which
is
probably
a
bad
habit.
Some
of
us
haven't
CDF
that
in
that
case,
end
user
refers
to
end
user
company.
Not
even
those
girls
I
think
it's
well
worth
clarifying
again
yet
sort
of
the,
as
you
said
that
developers,
the
managers
and
the
different
focus
and
priorities
of
them.
B
C
First
point:
we
would
like
to
define
well-defined
interfaces
and
reusable
libraries
and
in
order
to
identify
their
interfaces,
I
guess
it
would
be
helpful
to
understand
common
tasks
which
are
executed
in
a
CD
bug
flow,
so,
for
example,
the
deployment
testing
verification
and
to
release
and
so
on.
And
if
we
have
these
tasks,
probably
they
can
help
us
to
identify
the
interfaces
and
needed.
B
Yeah
no
I
I
think
that's
great
and
I,
like
the
the
list.
You've
proposed
and
like
I,
think
some
of
these
kind
of
more
well
defined
than
others.
So
it's
almost
nice
to
start
with
some
of
them,
like
you
know,
just
configuration
changes.
This
is
once
you
start
getting
into
more
complex
things
like
you
know.
What
is
a
cloud
native
application?
It
becomes
a
bit
muddier,
so
yeah,
well,
I
didn't
this
section
will
be
good
to
have
everybody's
feedback
on
the
different
types
of
categories.
Andres
has
proposed.
B
B
B
And
then
we've
got
the
end-user
case.
Studies
like
the
Brahmins
one
with
eBay,
which
I'm
sure
we're
all
looking
forward
to
so
I
think
that
ties
well
kind
of
into
the
shared
terminology.
Publishing
and
we've
got,
for
instance,
the
page
on
the
vocabulary.
So
one
discussion
I
wanted
to
have
is
what
would
we
see
as
some
next
steps?
B
So,
let's
say,
for
instance,
we
wanted
to
propose
some
terms
which
we
standardize
on
and
we
want
those
to
be
kind
of
pushed
out
to
to
the
entire
industry
and
if
I
take
a
really
sort
of
trivial
example,
even
the
term
see
ICD.
You
know
the
D
tends
to
be
very
context,
specific
or
ambiguous
and
actually
can
be
pretty
confusing
for
people
if
they
don't
have
the
same
shared
reference.
So
let's
say
something:
some
body
like
ZDF
or
the
interoperability
group
want
to
come
forward
and
propose:
let's
standardize
that
D,
so
it
always
means
delivery.
B
B
A
A
We
can
add
that,
like
CI
CD,
when
we
talk
about
CI
CD,
this
is
what
we
mean
is
an
additional
section
in
that
document
and
then,
as
you
suggest,
that
we
can
maybe
go
to
talk
and
ask
their
input
and
say
this
is
not
about
interpret
to
be
honest
because
it
happens
to
be
us
working
with
McAlary,
and
this
is
what
we
came
up
with.
Does
it
make
sense
to
see
the
F
talk?
B
D
If
we
agree
on
which
one
is
the
not
necessarily
the
right
one,
but
one
is
the
you
know
the
one
that
we're
gonna
go
with
so,
for
example,
that
the
the
one
that's
like
again
to
start
with
a
concrete
by
trivial
example
that
if
for
all
the
people
that
are
writing
these
pipeline
style
tools,
that
if
we
agree
that
smallest
unit
of
work
is
called
a
step,
for
example,
then
the
people
that
don't
that
who
are
the
maintainer
zuv
tools?
You
need
to
change
something.
D
You
know
the
terminology
all
across
their
their
entire
ecosystem
of
the
of
that
tool,
and
that's
gonna
be
a
lot
of
friction
for
people
unless
and
so
just
thinking
that,
through
the
reason
why,
if
I
was
the
maintainer
of
one
of
those
tools,
the
reason
why
I
would
want
to
do
that
would
be
if
there
was
some
well.
Ideally,
if
somebody
else
did
the
work
for
I
mean.
D
That
would
be
great
if
I
got
a
pull
request
from
someone
that
said:
hey
I
went
through
and
I
I
the
least
identified
all
of
the
places
in
your
documentation
where,
if
you
change,
if
you
change
these
terminologies,
it
will
be
more
standard
and
you'll
be
able
to
get
access
to
folks
that
are
not
familiar
with
your
tool,
because
they'll
have
a
lower
learning
curve.
They
won't
have
to
learn
as
much.
They
don't
have
to
relearn
things,
to
use
your
tool
and
by
the
way
we
made
a
pull
request.
That's
like
the
ideal
situation.
D
Stepping
down
from
that.
If
I
can
see
the
benefit
to
it,
and
but
I
have
to
do
the
work
myself,
then
I
could
probably
go
back
and
in
you
know,
get
on
board
with
it,
particularly
if
it's
a
tool,
that's
a
you,
know
a
foundation
and
kind
of
member
or
the
organization
as
part
of
it,
and
they
just
sort
of
agree
as
a
term
of
their
participation
that
they
want
to
redo
it.
D
But
if
it's
not,
if
it's
neither
of
those
things
I,
neither
a
organization
that
I
bought
into
and
something
that
I
had
input
in,
nor
nor
am
I
getting
any
help
with
the
actual
work
to
do
it.
The
odds
of
me
deciding
to
go
through
with
it
are
slim
to
none
just
frankly,
I
think
that
would
be
really
that
would
be.
You
know
it
would
feel
like
to
me.
I
I
had
I
didn't,
have
any
input
into
this.
D
B
Yeah
no
I,
like
your
points,
about
demonstrating
clearly
the
benefits
and
ways
to
mitigate
the
friction,
because
yeah
I'm
under
I've
kind
of
been
involved
with
lots
of
projects
where
you
know
just
changing
terminology,
is
a
huge
huge
burden.
Not
to
mention
kind
of
sometimes
involves
migration
for
end-users,
which
is
just
far
from
ideal.
Yep.
D
So
I
think
so
and
then
coming
at
it
from
our
perspective,
I
think
it
would
be
important
to
prioritize
things
that
actually
matter
like.
Maybe
is
it
sufficient
to
just
have
a
blessed
like
this
rosetta
stone
idea
and
really
make
that
part
of
the?
Like
we
say:
look,
you
know
the
world.
The
world
is
complicated
out
there
there's
a
lot
of
different
tools.
D
There's
a
lot
of
different
terminologies
people
use
different
words
for
the
same
things,
the
one
that
we
care
about
is
you
know
that
that
people
can
transfer
the
technology
across
tools
easily
and
maybe
they
have
to
relearn
things
or
translate
things
in
their
head,
but
it
at
least
they
know
what
how
to
move
around
across
the
ecosystem.
But
the
thing
that
we
actually
care
about
is
the
interoperability
of
the
technology
and
not
so
much
the
terminology,
and
so
we'll
just
publish
this.
D
And
maybe
that's
like
you
know,
it's
not
like
gonna,
be
a
stamp
that
we
can
impress
every
single
tool
into
the
same
mold.
But
at
least
we
you
know,
we've
contributed
value
there
and
we've
made
it
easier
for
people
to
understand
how
to
get
started
in
the
space,
and
maybe
that's
a
sufficient
goal.
That
has
that
that
we
could
just
you
know,
kind
of
leave.
It
leave
it
at
that
and
and
continue
on
with
the
other,
the
other
F
or
efforts
around
standardization
that
are
are
of
more
immediate
benefit
to
people.
I.
A
Like
do
you
use
Eric,
like
recommendation,
I,
think
that
is
friendly
word.
You
know,
instead
of
calling
this
okay
standardized
term
knowledge
or
whatever
or
some
people
are
not
very
you
know
into
standards,
and
so
on
open-source.
You
know
they
do
whatever
they
want
and
enjoy
to
do,
but
if
we
can
go
of
it
like
recommended
by
CDF
or
recommendation,
then
that
may
make
people
bit
more
open
to
at
least
look
at
these
things.
E
Yeah,
having
been
in
this
space
for
a
long
time
now
at
multiple
companies
and
I
keep
building
the
same
darn
tool
over
no
freaking.
We've
done.
We've
done
this
over
at
eBay
ever
since
2015
when
I
joined
and
we
have
an
internal
tool
called
be
loosely
called
eBay
Enterprise
continuous
delivery
is
eating,
and
that
has
its
own.
E
It
is
very
unlikely,
I,
don't
I,
don't
know,
I,
don't
see
it
happening
where
all
of
a
sudden,
Jenkins
X
will
turn
to
its
users
and
say:
hey
I
know
we.
We
called
this
thing
as
stage
and
with
steps
inside
of
it.
But
now
we
have
we're.
Gonna
switch
this
to
be
called
tasks,
and
you
know
which
is
of
a
Tecton.
You
know:
Tecton
went
with
priests,
three
levels
actually
tasks,
so
we
have
a
pipeline
which
has
tasks
which
then
each
task
has
a
step.
E
The
tools
themselves
like
Jenkins
X
and
that's
a
good
example,
but
it's
actually
you
know
it's
translating
between
its
own
a
pipeline,
DSL
and
and
Tecton,
because
it
now
had
each
to
not
produce
an
actual
checked
on
pipeline
DSL
from
what
the
users
its
users
has
created.
It's
very
unlikely:
they're,
gonna,
they're,
gonna
switch
through
terminology,
so
I'm
not
sure
how
worthwhile
it
is
to
have
an
effort
where
we
set
a
particular
term
to
mean
a
particular
thing.
E
We
can
do
it
and
we
can
put
a
lot
of
time
into
this
I'm
just
wondering
how
much
how
worthwhile
it
is
for
things
like
continuous
delivery
versus
continuous
deployment,
which
is
what
Traci
you
brought
up.
These
are
I'd,
say,
we'd,
be
recreating
the
wheel.
These
have
been
de
facto
industry
defined
for
a
while
now,
in
fact,
I
just
posted
a
link
on
to
our
chat
window
here,
meaning
the
folks
at
circle,
see
I,
have
a
pretty
decent
page
on
that
particular
topic
introduced
to
the
reverses
the
GS
deployment.
E
A
Well,
because
we
all
use
different
tools,
you
have
your
own
internal
to
reuse,
Jenkins
or
whether
others
use
spinnaker,
and
if
you
can't
even
communicate
between
humans,
then
it
is
very
difficult
to
tackle
with
the
standardization
of
whatever
interface
across
the
tools,
and
this
is
more
again
repeating
myself,
but
more
targeted
for
humans
and
distress.
Rosetta
stone
is
for
humans
and
yeah.
A
If
the
tools
add
up
the
terms,
that
is
something
we
haven't
imagined
in
the
beginning,
but
that
is
even
but
I
think
again,
expectations
yeah,
it's
great
everything
is
cold
same,
but
that's
not
the
way,
but
at
least
we
can
share
the
experiences
we
had
with
the
difficulty
of
communicating
with
each
other
and
put
this
thing
out
there
saying
that
look
guys.
This
is
what
we
did
for
to
make
our
lives
easier
when
we
talk
to
each
other-
and
this
doesn't
have
to
become
anything-
to
be
honest,
so
just
to
clarify
that.
E
E
We
come
up
with
a
standard
terminology,
yet
says
that
in
fact,
let's
just
say
we
adopt
what
I'll
use
the
the
Tecton
terms
we
adopt.
What
Tecton
has
done
for
its
pipeline
naming
conventions
and
and
terminology
a
pipeline
has
tasks
which
then
has
steps
and
a
story.
Let's
say
we
do
that.
What
practical
effect
will
that
have
on
the
tool
writers
of
the
future?
I
can
see
it
myself.
E
Let's
say
I
go
to
adopt
act
on
for
something
that
I'm
gonna
build
on
which,
by
the
way
that,
as
you
heard
last
time
when
when
Christie
was
talking
about
acceptance,
Evie
is
something
that
it's
kind
of
a
you
know
plummeted.
They
want
they
what
they
intended
that
tool
to
be
the
plumbing
of
other
things,
which
totally
makes
sense,
which
exactly
that's,
what
exactly
Jenkins
X
is
gonna
use
it
as
its
it's
kind
of
using
it
as
the
as
the
pipeline.
Plumbing,
what
practical
effect
will
that
have
on
people
who
are
creating
things
and
what?
E
What
will
it
have
on
people
who
already
created
stuff
I
was
just
bringing
up
the
point
that,
even
if
we
achieve
what
we're
planning
on
achieving
I'm,
not
sure
how
much
value
you
will
have
from
from
the
amount
of
time
we
would
have
put
into
that
again.
Just
playing
devil's
advocate
here:
I'm,
not
suggesting
one
way
or
another.
That's
all
and.
B
I
think
to
that
point,
I
think
this.
This
is
just
this
idea
of
confusion
like
I.
Think
people
don't
even
know
that
the
terms
are
different
across
tools.
So
if
you
stay
in
a
world
with
just
one
tool,
I
think
you're.
Fine,
it's
just
irrelevant
to
you,
but
the
minute
you
start
saying:
okay
I
might
need
to
potentially
move
my
tools
around
I
want
to
move
workloads
around.
It
gets
very
confusing
very
quickly,
and
even
if
we
don't
have
everyone
using
the
same
thing,
maybe
just
having
the
reference.
B
You
know
some
something
like
CDR
saying:
okay,
references,
we're
going
to
treat
Tecton
terms
as
the
reference
one.
So
we
can
talk
about
other
tools.
So
when
you
say
okay,
I'm
doing
something
you
get
hub
actions
the
this
bit
in
github.
Action
is
equivalent
to
the
tech
tones
other
bit
and
it
becomes
maybe
a
just
a
way
for
people
to
communicate
better
and
not
be
talking
at
odds
when
this
each
saying
something
like
pipeline.
B
G
G
We
say
that
this
is
the
benefit,
and
you
get
all
of
this
I'm,
not
sure
it
still
would
help
much
if
we
expect
them
to
change
that
is
I'm,
more
leaning
towards
with
what
I
mentioned
I
had
to
have
this
human
language,
at
least
as
a
cheat
sheet.
If
you
will
to
have
this
ground
sing
at
it,
then
it
would
still
be
good,
I
think,
to
bring
it
up
to
the
talk
since
still
I
feel
it
covers
more
than
just
the
interoperability.
C
Also
agree
that
this
is
a
nice
mapping
for
human
language
between
the
different
terms,
but
I'm
wondering
whether
it's
really
and
the
most
difficult
tasks
for
engineers
the
tool
to
understand
those
terms.
I
think
people
have
much
heavier
problems
in
in
implementing
than
the
actual
stuff
the
actual
deployment
ends
on,
and
they
do
not
struggle
that
much
with
the
different
terminology,
because
they
choose
one
tool
and
then
they
start
implementing
their
pipelines
or
continuous
delivery
flow.
C
C
A
Again,
if
I
go
back
to
communities,
I
was
contributing
to
an
MC
contributing
to
I.
Think
one
thing
that
is
clear
is
like
all
these
cloud
native
virtualization
containers,
micro
services,
all
this
transformation,
I
think
the
things
are
not
that
as
simple
as
before
previously
I'd,
like
mono
reach,
we
had
like
one
two
with
pipeline.
You
build
everything
in-house
you
run
through
that
pipeline
on
Jenkins,
possibly,
and
we
have
a
release
in
that.
A
Esther,
and
what
is
what
in
CN
CF
doesn't
matter
what
is
called
in
OpenStack
or
open
daylight
or
open
Fe,
and
it
gets
explosive
like
I
am
NOT
warper
I
am
NOT
a
contributor
to
Tecton
or
Jenkins.
I
am
a
user,
and
if
I
look
at
from
users
perspective,
it
is
very
difficult
to
wrap
my
head
around
like
okay.
A
How
can
I
integrate
these
cool
technologies
in
my
company,
so
I
can
build
a
product
on
top
of
it
and
I
can't
even
bring
those
things
together
because,
like
there
is
no
way
to
map
wanting
to
other,
even
in
my
head
before
getting
our
hands
dirty
by
building
a
pipeline
internally,
so
that
is
giving
true
there
and
again
the
CFC
I
cross
Claudia.
If
you
are
aware
of
CNC
of
cross
Claudia
initiative,
they
are
hooking
into
on
up
community.
They
are
who
coming
into
open
efi.
They
are
hooking
to
CNCs.
A
A
I
am
NOT
trying
to
define
the
vocabulary,
but
just
trying
to
highlight
the
challenges
we
face
it
every
day,
like
Tesco,
think
you
know
any
little
help
or
whatever
I
see
this
as
a
little
help
to
those
people
who
are
struggling
to
map
things
with
each
other
when
they
talk.
So
that
is
again
trying
to
look
at
things
from
user
perspective.
B
Think
part
of
the
effort
should
be
kind
of
getting
ahead
of
those
tools.
So
when
we're
talking
about
newer
concepts
like
perhaps
something
like
deployments,
you
know,
are
we
gonna
use
Bluegreen
deployments
in
spinnaker?
What
does
that
mean?
What
is
the
definition
of
a
canary
deployment,
maybe
going
into
feature
flags
or
things
around
any
kind
of
new
kind
of
you
know,
area.
That's
emerging!
You
have
things
like
progressive
delivery.
B
You
know
how
do
we
make
sure
that
we
can
help
people
understand
what
the
different
terms
are
or
what,
as
each
tool
kind
of
comes
along
how
these
things
map
to
each
other
and
for
the
new
ones?
I
can
see
more
value
in
kind
of
trying
to
get
ahead
of
it
and
just
sort
of
say:
okay,
actually
we're
going
to
go
with
these
terms,
and
everything
can
derive
from
that.
B
B
And
no
one's
interrupting
just
on
the
CI
CD
point
I.
Think
for
that.
It's
not
specifically
looking
to
redefine
the
terms
at
all,
but
more
specifically,
just
establishing
the
very
simple
idea
of
the
the
de
facto
definition
or
the
de
facto
assumption
that
CI
CD
will
mean
delivery
unless
specifically
stated
and
I
think
it.
It
might
be
a
small
distinction,
but
I
certainly
know
for
myself
coming
into
kind
of
this
new
area
and
for
other
people
and
just
talking
at
odds
with
people
who
had
different
definitions
or
different
understanding.
B
E
I
totally
agree
Tracy
if
we're,
if
we're
limiting
this
particular
endeavor
to
listing
out,
but
has
already
been
industry,
accepted
terms
that
have
already
been
industry
accepted.
You
say
one
thing:
everyone
across
the
board,
who's
ever
even
been
in
that
space
agrees
that
that
is
that's
what
that
term
means,
putting
those
down
wolf,
worthwhile
effort
and,
as
as
a
CDF,
a
continuous
of
every
foundation,
it's
great
for
us
to
explore.
Put
it
down,
expose
it
and
say
this:
this
is
what
we
mean
when
we
say
this
so
I.
B
E
Know
can
you
imagine
that
that
conversation
we
we
want
to
want
to
standardize
on
I'm,
jumping
ahead
to
the
engineer,
I
go
directly
to
the
implementation.
Can
you
imagine
that
conversation
hey
red
eyes
on
the
word
stage?
Really
we
already
we
already
called
it
sets
a
task.
Well,
what
can
it
be
a
stage
because
a
task
you
just
go
down
right?
You
know
your
rat
hole
into
the
Hat
naming.
B
Biggest
problem,
yeah
no
I,
agree,
I
think
we
want
to
avoid
them
yeah.
Having
said
that,
I
will
give
an
example
of
where
the
Jenkins
community
did
kind
of
dump
the
term
workflow
and
migrate
to
using
pipeline.
So
I
know
it
can
be
done
in
the
right
circumstances,
but
yeah
I'm,
not
sure
like
in
that
example,
and
all
of
them
are
worthwhile
and
probably
more
trouble
than
it's
worth.
E
Right
and
so
I
I'm,
cautioning,
I'm,
cautioning,
us
against
or
I
should
say
I
should
lead.
One
I
want
us
to
lean
towards
those
things
that
we
already
absolutely
know
are
de
facto
terms
and
putting
those
down,
and
so
that
no
one
ever
if
any
one
like
right
now,
if
you
want
to,
if
you
want
to
ask
the
question
what
what
you
know,
what
is
the
difference
between
continuous
delivery
and
deployment?
E
B
A
A
Discussion
because,
like
previous
weeks,
we
had
like
presentations,
we
didn't
have
time
to
you,
know
deep
dive
into
these
things,
so
I
enjoyed
conversation.
I
was
like
thanks
for
contributions
from
everyone.
So
I
think
that
was
the
last
agenda
item.
So
anyone
has
anything
has
to
bring
up.
We
have
seven
minutes.
A
Okay,
then,
the
next
meeting
will
be
on
April
30th
and
we
will
have
presentation
from
Stefan
from
we've
works
on
flagger,
so
I
don't
know
what
flagger
is,
but
it
took
school
when
I
google
it.
So
please
join
to
the
next
meeting
and
then
see
what
is
a
button
and
we
continue
with
roadmap
and
we
hopefully
see
the
newsletter
around
that
time.
End
of
April
or
not
we'll
see
and
thanks
out
for
joining
today
and
keep
safe
and
be
healthy
and
talk
to
you
in
two
weeks
and
thirty.