►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
So
as
you've
seen
on
the
agenda,
hi
josh
thanks
for
joining
us,
you
both
seen
on
the
agenda
like
your
presentation
and
demo,
is
the
first
topic.
So
I
will
do
some
quick
intro
about
like
hi
how
the
work
we
have
done
in
upd
tag
could
help
with
our
you
know.
Work
in
supply
chain
seek
to
extend,
you
know
the
pipelines
to
production
sizes,
and
then
I
will
give
you
you
know
the
screen
and
then
you
can
do
present
and
demo.
C
A
C
A
A
So
now
I
think
I
can
stop
sharing
and
perhaps
thomas
and
josh.
You
could
take
our
sharing
and
just
to
give
little
bit
of
background
about
why
I
reached
out
to
you,
thomas
and
josh,
to
learn
more
about
what
you
are
doing
in
thai
cafeteria
and
potato
head.
As
I
was
saying
at
the
beginning
of
the
meeting
like
we
want
to
have
a
bit
practical
approach,
software
supply
chain-
not
just
you
know,
documenting
vocabulary
or
you
know-
discussing
the
typical
pipeline
stages.
A
A
Then
how
we
can
you
know,
get
those
things
fixed
and
like
for
left-hand
side
of
the
software.
They
will
do
open
life
cycle
checkers
of
a
factory
and
those
folks
have
done
great
work
back
like
cncf
tech
security
and
when
it
comes
right-
and
I
made
something
there
to
you-
know
bridge
this-
you
know
connect
these
two
things
and
I
was
looking
at
what
we
have
done
with
potato
head.
We
have
this
like
how
different
diploma
studies
could
be
employed
to
put
stuff
on
production
and
so
on,
and
that
was
kind
of
idea.
A
C
Have
a
question
on
that?
What
I
was
hearing
from
you,
I'm
gonna
put
it
slightly
in
my
own
words.
Is
that
a
lot
of
the
effort
around
secure
supply
chain
is
that
build
time
like
make
sure
all
the
right
build
components,
but
there's
nothing.
That's
like
at
run
time.
That's
like!
Are
they
still?
Okay,
yeah.
B
B
Yes,
so
hello,
also
from
my
side.
So
for
those
who
don't
know
me,
my
name
is
thomas,
I'm
actually
the
district
at
the
delivery.
Furthermore,
maintainer
of
the
captain
project-
and
today
I
want
to
bring
you-
I
want
to
tell
you
some
some
some
basics
about
the
gap
delivery
and
my
colleague
josh,
who
is
one
of
the
most
active
contributors
to
the
potato
head
and
also
chia
of
the
cooperative
delivery
working
group
in
the
gap.
Delivery.
B
We'll
show
you
something
about
the
potato,
so
you
will
hear
about
what
the
tech
app
delivery
is.
What
our
role
in
the
whole
ecosystem
is.
What's
our,
what
our
work
is,
which
working
groups
are
involved
in
our
work?
And
yes,
some
some
demo
about
the
potato
here.
So
when
you
think
about
the
cncf
itself,
it
has
some
kind
of
structure.
So
there
is
a
governing
board
with
a
marketing
committee.
B
B
I
will
also
step
into
this
a
bit
later
and
also
to
identify
the
suitable
products
and
gaps
in
the
land
landscape.
So
we
have
some
kind
of
overlap
to
the
cdf.
To
be
honest,
yes,
and
one
of
the
one
of
the
things
which
is
also
one
of
the
one
of
the
things
we
have
we
have
to
do
is
helping
that
you
see
with
assessments
and
also
with
the
due
diligence
of
of
new
projects.
B
Okay,
so
what's
the
scope
of
the
target
delivery?
So
it's
starting
from
with
a
different
application
definition.
So
how
does
an
application
look
like
and
similar
things?
It's
also
about
guidance
and
practices
for
app
design
and
development,
it's
about
application
bundling
and
deployment.
So
so
with
projects
like
helen
like
cnab
and
helm,
and
whatever
it's
also
coming
to
package
management,
it's
going
to
application
delivery,
workflow
and
strategy
and
configurations
of
source
driven
workflow,
just
like
gtops
and
so
on,
and
so
on
the
same
one
for
release
management.
B
Then
we
have
application
operation
rollout,
which
is
also
which
also
consists
of
cdcic.
We
have
the
application,
packaging
and
application
definition,
which
includes
helen
bleedback,
scubila
and
whatever.
So
what
are
we
doing
in
our
daily
work?
We
are
doing
tag
meetings
about
every
two
weeks,
so
each
first
and
third
wednesday
of
the
month,
so
everyone
is
free
to
join
and
join
discussions
and
talk
to
us
there.
We
discuss
app
delivery
trends
and
topics.
B
B
B
Furthermore,
we
will
try
to
publish
more
blog
posts
about
that
delivery
and
related
related
topics.
And
last
but
not
least,
we
are.
We
want
to
create
scenario,
oriented
example
configurations,
and
this
is
the
point
where
the
potato
head
kicks
in.
So
we
wanted
to
give
people
example
configurations
how
they
can
use
particular
delivery
tools.
B
B
B
Their
goal
is
to
define
a
vendor
neutral
principle
at
meaning
of
key
top,
so
they
also
created
the
principles
of
githubs
and
all
of
their
output
is
stored
in
in
the
open
spot
working
tops
project,
which
is
a
sandbox
project.
At
the
moment
I
and
last
but
not
least,
I
think
george
can
tell
us
something
about
the
cooperative
delivery
working
group,
so
you.
C
Okay,
sorry
about
that,
anyway,
the
co-operative
delivery
group
is
just
identifying
patterns,
emerging
patterns,
products
that
facilitate
integration,
delivery
and
integration
of
apps
with
underlying
infrastructure.
So,
like
things
like
the
service,
binding
operators
in
our
radar
cross,
plane
or
things
that
allow
us
to
use
the
same
apis,
you
know
for
apps
and
infrastructure
multi-tenancy.
C
C
Yeah,
I
guess
I
could
keep
going
from
here,
thomas
yeah,
so
let
me
so
I
think,
there's
a
good
summary
at
the
top
line
here.
That
potato
had
to
just
give
a
brief
background
on
the
goals
it
was
created.
I
guess
about
a
year
and
a
half
ago.
I
think
the
project
started,
and
it
was
about
a
showcase
so
that
architects
and
engineers
could
come
in
and
understand
a
bunch
of
different
options
for
doing
app
delivery.
C
So
going
from
the
simple
cube,
cuddle,
helm,
customize,
you
know
rendering
to
flux
and
argos
cd
and
a
few
things
like
cnab
is
in
there
kept
it
and
a
few
other
ones
all
deploying
the
same
app
so
that
and
immediately
usable
go
in,
follow
the
readme
and-
and
you
can
get
up
and
running
and
compare
and
contrast
and
go
from
there
in
the
past.
I
guess
about
a
year
now,
we've
been
adding,
we've
been
adding
more
and
more
documents,
refining
them
and
also
adding
tests.
So
it's
all.
C
Yes,
let's
see
one
other
thing
to
mention
before
I
jump
into
the
actual
demo.
Is
that
that
we
originally
was
for
we
we
focus
on
delivery
scenarios,
but
we've
been
you
know
we
we
it
a
potential
use
for
more
kinds
of
scenarios
and
that's
you
know.
I've
been
watching
things
that
are
happening.
I
actually
opened
an
issue
and
I
can
share
it
with
you.
C
You
know
to
kind
of
you
know
talk
about
how
we
would
run
this,
but
we
see
things
like
observe
k8s,
that's
from
the
observability
tag
in
cncf,
the
open,
git
ops
project,
one
of
their
main
goals
is
to
actually
provide
some
examples
too.
You
guys,
I
saw
the
sig
park
that
you
linked
fati,
which
I
want
to
take
a
look
at
so
it
seems
like
a
lot
of
people,
are
making
these
efforts
yeah.
C
Okay,
I'm
going
to
share
my
screen,
and
I
only
have
one
screen
today,
because
I'm
stuck
in
my
basement
so
bear
with
me.
You
can
see
your
mirrors
over
there,
so
I
wrote
down
some
apps
and
what
I've
got
here
is
sorry.
I
wrote
down
some
notes
here
to
make
sure
we
cover
the
things
I
want
to
talk
about,
but
I've
got
the
repo
up
here
in
vs
code,
it's
connected
back
to
the
ssh
to
a
server
that
actually
has
kubernetes
running
on
it.
C
C
C
Originally
there
was
just
the
single
service
potato
head
server
and
that's
just
one
you
know
builds
one
docker
image.
It
runs
one
service
that
kind
of
includes
everything,
and
then
we
broke
it
up
into
microservices,
where
we
build
actually
six
different
images
and
run
one
entry
point
service
and
then
five
five
services
that
serve
up
the
parts.
C
Then
within
the
delivery
folder.
This
is
all
of
our
delivery
scenarios
and
what
I'm
gonna
show
you
now,
I'm
gonna
use
the
chart,
one
which
is
a
helm
chart
that's
been
that
uses
the
microservices
example
and
it
deploys
it
out
with
that.
The
test
script
deploys
it
all
out
in
you
know
a
kind
of
opinionated
way,
but
it
follows
basically
what
the
readme
walks
you
through
so
they're
meant
to
they're
meant
to
be
in
parallel.
So
what
I'm
going
to
run
here?
Every
every
one
of
the
test
scripts
has
a
flag.
C
C
I
don't
have
a
load
balancer
service,
even
though
this
says
it's
looking
for
a
load
balancer
service.
I
just
have
a
node
port,
so
I'm
going
to
forward
that
port.
Oh,
this
is
a
nice
little
helper,
vs
code
that
I
like
to
use
and
that's
just
the
ssh
tunnel.
I
just
didn't
bother
typing
the
command,
so
you
see
what
happened
here.
We
got
hello
from
potato
head.
This
is
this
service
that's
running
over
there
oops.
C
C
C
C
You
know
at
the
main
point
of
this,
and
certainly
you
have
recommendation
improving
the
core
app.
That's
fine.
The
main
point
was
just
to
have
a
micro
services
app
yeah.
Let's
see
go
back
to
my
notes
here,
so
we
got
that
up
and
running
yeah.
So
that
was
I
wanted
to
illustrate.
If
I,
if
I
take
this
down
now,
I
could
run
the
same
thing:
I'm
not
going
to
actually
take
it
down,
I'm
just
going
to
control
c
out
of
this
little
trick
so
that
I
can
keep
it
up
and
running.
C
C
The
next
thing
I
wanted
to
to
show
you
is
the
an
example
of
where
we're
kind
of
looking
at
other
scenarios
here-
and
this
is
again
it's
just
a
proof
of
concept
of
these
scenarios.
It's
an
initial
basic
one,
but
we've
had
a
couple
issues
where
people
have
opened
where
they
have
wanted
to
try
out
service,
mesh,
stuff
and
and
service
discovery.
So
I
just
to
kind
of
show
how
we
might
do
it.
I
put
in
this
example
of
how
to
change
it
easily.
C
So
you
know
if
I
was
rolling
out
a
new
service,
a
new
hat
service,
where
I
wanted
to
serve
instead
of
this
hat.
You
know
a
pirate
hat
this
walks
through
how
you
would
do
that
use
the
scenario
the
base
chart.
We
will
change
potato
head
man's
hat
by
returning
a
different,
url,
url,
sorry
or
whatever
people
call
it
the
same
way.
C
You
could
follow
the
you
can
follow
the
steps
in
the
readme,
but
also
here,
there's
a
test
script
which
doesn't
do
very
much
it
just
installs
the
home
chart
that's
in
this
folder,
so
I
will
just
do
that.
Let's
see
scenarios
service
discovery
test
and
what
this
is
just
doing
is
adding
another
chart
which
is
adding
another
service.
C
C
I
deployed
another
pod
which
becomes
another
service,
also
potato
head,
ext
half
beta,
and
then
I
can
modify
cube
cuddle
edit
config
map,
something
potato
head
service,
discovery
and
potato
head,
which
one
do
we
change
hat.
This
is
yeah
like
I
said
this.
This
could
be
streamlined,
but
at
least
it's
there.
C
So
I
change
that.
I
also
because
config
maps
changes
don't
automatically
trigger
the
the
restart
of
the
pod.
So
and
I
don't
have
you
know
a
function
for
that.
I
just
have
to
go
ahead
and
kill
that
pod,
but
once
it
comes
back
up,
if
all
goes
well,
I
should
be
able
to
refresh
this
and
get
his
pirate
hat.
C
Sorry,
nobody
cheers
for
you
anymore,
the
yeah,
so
so
that's
an
example.
So
that's
kind
of
you
know
to
kind
of
show
what,
where
you
know,
we
might
add
in
other
scenarios
like
in
that
folder
like
if
we
wanted
a
secure
image,
build
scenario
or
something
so
yeah.
So
I
wanted
to
show
this
specifically
because
we're
talking
to
you
all
and
you're
talking
about
supply
chain
security,
I
wanted
to
kind
of
just
show
you
the
bill.
C
The
way
we
do
image
builds
because
I
feel
like
that
might
be
a
place
where
you
build
on
or
contribute
so
what
we
have
in
there
now
and
it
should
all
run
thomas
says
it
runs
on
his
too.
So
I'm
happy
to
hear
that
if
I
say
potato
head
micro
services
build
images,
actually,
no,
we
even
have
a
make
task
make.
C
Let's
just
do
build
microservices
images,
it
just
runs
through
and
runs
a
bunch
of
typical
tasks
to
build
them,
and
they
all
end
up
calling
back
to
here.
It's
really
pretty
straightforward.
To
be
honest,
it's
just
a
build
image
script,
which
does
the
things
we
want
to
do
at
build
time.
So
docker
build
with
some
tags
and
then
a
couple
things
we
already
did,
but
probably
you
all
know
how
to
do
it
better.
If
we
find
cosine
on
the
path,
then
we
go
ahead
and
do
cosine.
C
If
we
find
trivia
on
the
path,
then
we
do
a
trivi
scan.
These
are
all
build
time
to
what
factory
was
saying.
So
we
don't
have
an
example
of
anything
like
runtime
yeah.
So
that's
that's.
How
we
do
the
builds.
You
can
see
them
all
happening
in
the
back.
One
thing
I
did
want
to
show-
and
I
submitted
a
pr
for
this-
we
for
the
individual
server.
It's
still
using
that
same.
C
Actually,
I
take
it
back.
No,
it's
not
using
that
function,
so
there's
an
update
to
do,
but
anyway,
it's
got
this
build
image
and
we
have
this
test
image.
This
might
help
you
all
for
inner
loop.
So
I
added
this
this
morning.
I
have
to
merge
the
wait
for
delete
thing.
Is
there
too,
but
I'll
just
go
ahead
and
show
that
if
I
do
potato
head
server,
what
was
that
build
test
image
and
I'll?
C
Do
a
wait
for
delete
just
for
that
and
that
should
wake
it
up
or
build
the
image,
and
then
I
should
be
able
to
curl
it
localhost
9000
and
you
could
see
there's
the
html,
that's
actually
behind
mr
potato
head.
So
that's
a
good!
That's
a
way
for
you
all!
If
you,
if
you're,
if
that's
something
you
focus
on,
if
you
focus
on
the
image
build
and
then
I
yeah
I'm
just
guessing,
you
could
use
that
that
stuff
test
image
build
image
from
the
just
from
the
individual
service.
C
Oh
yeah,
okay,
so
that
was
those
are
the
three
things
I
kind
of
want
to
show
the
delivery
scenarios,
the
other
use
cases
and
how
we're
doing
image
builds.
One
thing
that
I
also
wanted
to
show
and
mention
is
that
we're
using
github
actions
to
run
all
of
these
tests,
so
we've
got
three
that
are
oriented
around
microservices.
C
You
know
just
building
and
testing
and
we
have
a
set
here
which
actually
runs.
You
know
test
the
cube,
cuddle
delivery.
It's
just
running
the
shell
script
test,
the
home
delivery
test,
customize
test
catch
test,
flux
operator,
so
you
all
could
could
build
on
that.
You
could
add
to
those
I
wrote
down
here
to
ask
you
if
you're
interested
in
contributing
a
tech
time
example
since
you,
since
you
folks,
are
cdf.
C
You
know
it's
easy
to
use
github
because
we're
already
hosted
there
and
it's
free
to
us
pretty
much
but
yeah.
This
is
my
I
like
to
have
the
github
actions
called
generic
scripts,
rather
than
rely
on
their
built-in
stuff.
But
that's
that's
an
opinion.
I
guess
so.
We
can
talk
about
that
if,
but
that
that
the
reason
I
like
to
do
that
to
be
honest,
is
because
it
does
facilitate
using
gitlab
instead
or
using
tekton
instead.
C
A
There's
a
red
hat.
You
know
it's
like
a
pirate
hat
on
the
potato,
so
I
guess
that
is
yet
another
contribution
to
you
know,
or
maybe
an
issue
on
your
repo
first
talking
about
what
kind
of
scenario
we
could
have
to
demonstrate
those
things
using
potato
hat
and
then
bring
that
scenario
to
life
like
how
you
did
that
for
other
type
of
scenarios.
B
B
C
A
Yeah,
I
was
like
sorry
if
others
have
any
questions.
Please
jump
in
because,
like
like
identifying
problematic
deployment
like
the
potato
head
with
pirates,
hats
and
then
you
know
reacting
or
something
is
wrong
with
thing,
because
we
just
you
know,
got
some
vulnerability
announced,
which
is
that
could
be
red.
You
know
pirate
hat
and
then
you
know
making
another
deployment
with
the
correct
thing
could
be
a
scenario
I
suppose
so.
B
C
Yeah
I'd
be
happy
to
help
dive.
In
I
mean
the
hard
part
is
always
the
implementation
yeah
getting
somebody
to
do
it,
but
yeah
like
I
had
actually,
as
part
of
this,
I
kind
of
tried
to
summarize
the
overall
goal
to
provide
a
collection
of
patterns
in
a
development
frame
like
a
framework
for
how
to
contribute
new
patterns.
So
I
kind
of
talked
about
here's,
how
we
should
do
it.
Here's
the
proposed
process.
C
So
you
know,
if
you
want
to
provide
a
new
pattern,
propose
and
discuss
it
in
a
repo
implement
it.
With
these
steps,
you
know,
try
to
use
shared
foundations,
so
yeah,
if
you
wanna,
you
know
we
can
continue
the
discussion
there
or
you
know.
I
provided
one
example
which
I
still
haven't
done
like
I
said
devil's
in
the
implementation,
but
this
was
where
I
was
like
hey
this.
Might
this,
I
think,
is
a
valuable
scenario
to
to
make
clearer
to
people
with
an
example.
C
B
D
B
So
in
the
in
the
beginning
it
was
intended
to
be
a
simple
application
which
has
no.
So
to
be
honest,
this
has
no
real
use
case,
so
the
application
itself
is
only.
The
only
purpose
is
to
switch
over
components
of
itself
and
the
figure
you
see
there
is
the
potato
head.
So
this
was
the
the
reason
why
it's
called
potato
head,
but
it
might
be
that
that
get
that
we
that
we
have
another
other
name
for
that
in
the
future,
but
I
think
it
won't
get
more
serious
than
now.
C
But
there's
room
for
that,
like
we
have
these
two
you
know
base
apps.
I
think
maybe
we'd
say
that
it's
not
about
the
apps
in
this
case
it's
about
the
stereos
around
them,
but
if
we
want
a
more
relevant
app
like,
let's
add
another
one
there,
that
would
be
totally
fine
and
we
could
even
you
know
if
we
want
to
call
if
we
want
to
make
this
broader.
C
C
D
C
This
might
also
be
something
there's
a
few
of
these
and
I'm
just
kind
of
tracking
them
community
demo
for
open
telemetry.
So-
and
this
is
there's
another
effort
within
cncf
called
observe
k8s,
which
is
also,
I
guess
it's
not
open,
telemetry
specifically,
but
they're
also
kind
of
looking
into
this,
and
then
you
guys
had
that
sig
pac
that
you
mentioned
so
it
seems
like
we're
all.
We
all
have
the
same
idea
so.
A
A
I
believe-
and
we
got
a
presentation
and
demo
from
michael
from
that
group
and
then,
as
we
were
talking
like
that,
focus
on
more
build
time
aspects
and
then
what
about
runtime
aspects
to
have
this
conversation?
Now
you
are
showing
this
telemetry
thingy,
like,
as
you
said
like
we
all
seem
to
be
doing
similar
things
and
how
we
can
you
know,
bring
these
things
here
to
a
more
complete.
A
C
A
And
also
all
these
groups
have,
like
certain
focus
like
you
look
at
app
delivery.
We
look
at
like
ci
cd
aspects,
the
open,
ssf
folks.
They
look
at
more.
You
know,
build
time
and
security
aspects
and
open
tournaments.
They
look
at
what
they
are
good
at
and
it's
like
yeah.
We
all
look
at
certain
things
and
then
yeah,
I
think,
putting
these
things
again.
A
A
So
before
you
leave,
if
there
is
no
other
question,
I
can
perhaps
quickly
talk
about
what
we
have
been
talking
about
to
george
and
thomas,
and
you
can
take
a
look
at
the
document
as
well,
which
we
kind
of
it's
brain
dump.
It's
not
complete
and
it
will
continue
evolving
like,
as
I
noted
like
when
we
first
proposed
this
music
to
cd
foundation.
A
One
of
the
ideas
was
like
take
a
look
at
house.
Sig
events
approached
their.
You
know,
discussions
around
using
events
for
ci
cd
and
they
one
of
the
first
things
they
have
done
in
their
city
is
to
bring
other
talk.
So
people
can
read
their
documents
and
also
play
with
the
talk
to
you
know
understand
what
they
are
trying
to
do
better
and
that's
what
we
also
think
of
doing
and
to
get
that
conversation
start
around
setting
up
a
proof
of
concept.
A
She
put
a
lot
of
time
and
effort
to
document
different
stages
within
a
typical
pipeline
like
field
stage
test
stage,
release
deploy
stage,
and
then
she
didn't
stop
there.
She
also
started
documenting
different
steps
under
different
stages,
which
could
be
used
across
different
stages
or
certain
stages,
and
then
today
I
actually
sent
another
pr
to
actually
add
some
extra
new
stages
to
what
she
put
there
like.
Okay,
the
current
stages
document
on
the
vocabulary
document
looks
at
the
typical
you
know,
builds
deploy
type
of
stages,
but
what
about
supply
chain
specific
stages?
A
And
that
is
where
we
are
at
the
moment,
and
these
things
once
we
have
some
concerns
around
them.
This
thing
could
then
be
used
for
bringing
up
the
pocket
as
well
like
okay,
we
identified
this
open
source
introduction
stage,
which
we
need
to
do
some
kind
of
license
checks
or
community
health
checks,
how
they
can
be
made
part
of
the
secure
software
factor.
A
A
C
A
Welcome
and
the
other
thing
just
to
highlight
again
this-
I
think
there
was
a
webinar
yesterday,
cd
events
webinar
and
I
actually
asked
the
question
like
okay,
now
against
cd
events,
I
see
emails
with
us.
The
current
concern
for
cd
events
is
like
to
you
know,
document
the
typical
ci
cd
relevant
events
and,
like
I
asked
like
what
is
the
possibility
of
having
some
supply
chain
type
of
events
like
a
vulnerability
disclosed
event
type
of
slang,
so
things
could
converge
over
time
putting
these
different
things
together
as
well.
A
B
A
Good
cool
so
just
to
repeat
again
for
aeron
now
going
back
to
our
proof
of
concept
document
here.
This
is
again
a
simple
diagram
talking
about
like
how
we
can
perhaps
bring
up
the
proof
of
concept,
and
it
looks
at
two
main
things
like
development
side
of
things
like
when
a
new
developer
when
a
developer
brings
a
new
open
source
component,
for
example,
and
how
that
component
could
be
introduced
for
product
work
in
a
secure
and
compliant
manner.
A
And
the
second
aspect
is
the
production
runtime
aspects
like
how
you
put
it
josh
and
some
high
level
activities
are
documented.
On
this,
I
can
redocument
like
introducing
a
force
storing
that
force
to
a
known
organizational
trusted
repository
and
I'm
building
our
own
dependencies,
because
sometimes
the
dependencies
when
communities
make
the
artifacts
available,
they
may
not
be
you
know,
signed
or
they
may
not
be
secure,
so
how
organizations
could
actually
build
their
own
dependencies
for
internal
products,
development
and
then
leora
mentioned
like.
A
So
simply,
I
turned
what
is
documented
on
the
icandy
document
into
the
format
and
merry
creates
for
documented
typical
stages.
So
the
three
stages
I,
the
current
on
the
pr,
is
like
source
software
introduction
stage.
It's
like
what
this
stage
does.
What
are
the
aliases?
What
are
the
inputs
like?
What
is
the
upstream
url
of
source?
A
What
repository
of
the
open
software
version
and
policies,
what
kind
of
outputs
generates
and
what
kind
of
side
effects
this
stage
could
have
and
same
for
storage
and
consumption
stages
as
well,
and
currently
this
is
a
four
wheel
and
once
you
know
we
have
some
kind
of
consensus,
then
the
next
step
could
be
creating
steps
that
may
be
specific
to
these
stages
or
some
of
the
extinct.
Steps
could
be
used
under
these
different
stages,
and
with
that
I
stopped
talking
because
I've
been
talking
a
lot
and
just
want
to
hear
your
quick
feedback.
A
A
E
Sorry
buddy
I'm
silent,
but
I'm
trying
to
wrap
my
head
on
what
this
would
mean.
So
that's
why,
but
so
I'm
excited
so
it
seems
to
be
interesting
at
least
sure,
I'm
not
yet
sure
if
it's
worth
to
call
these
different
stages,
but
maybe
or
if
it's
rather
steps
in
some
other
existing
stage.
But
for
sure
I
do
see
the
use
case.
We're
trying
to
show
here.
A
Yeah,
I
think
anne
mary
had
a
similar
comment
there
like,
instead
of
making
one
of
them
as
a
separate
stage.
Why
not
a
step?
So
let
me
open
the
pull
case
to
show
that,
because
yeah,
why
did
you
decide
to
make
these
three
stages
like
again?
This
is
just
a
quick
appear
based
on
what
is
document
on
the
lookout
but,
like
I
call
them
tasks
here,
but
these
different
things
could
be.
Perhaps
we
consider
their
steps?
A
You
know
because,
like
licensed
copyright,
identification
like
it's
just,
it
could
be
considered
as
a
separate
step
under
introduction
stage
that
could
contribute
to
you
know.
Final
evaluation
result
like
if
an
open
source
compound
is
not
using
one
of
the
organizational
approved
licenses,
then
that's
that
could
simplify
that
as
a
policy
violation
contributing
to
final
evaluation
without
saying
that,
okay,
this
open
source
component
is
good,
but
the
license
is
not
in
the
approved
license
list,
so
it
must
not
be
used.
Kind
of
thinking.
A
It's
similar
with
other
stages
like
different,
like
under
storage,
for
example,
dependency.
Analysis.
Using
you
know,
code
analysis
tools
could
be
a
separate
stage,
a
step
identifying
dependencies
for
a
given
open
source
component
and
then
another
step
could
download
those
different
dependencies
and
store
them.
So
again,
that
is
how
I
it
was
difficult
for
me
to
wrap
my
head
around
as
well.
So
I
start
simple
way
to
call
all
of
them:
steps
stages,
sorry
and
then
create
steps
or
reuse,
extinct,
steps
and
mary
created
or
documented.
There.
E
A
They
can't
be
published
for
further
consumption
because
of
again
some
license
issues,
for
example.
So
you
have
the
code
in
your
trust,
repository
the
source
code
of
the
open
source
component,
but
it
shouldn't
be
consumed
or
introduced
to
product
development
organization
as
something
reusable
component
because
it
hasn't
passed
whatever
checks.
The
organization
may
have.
A
E
A
Yeah
again,
introduction
storage
like
introduction,
is
kind
of
first
step
in
approving
the
use
of
a
certain
open
source
component
and
once
that
stage
is
done,
that
open
source
compound
could
be
taken
by
the
storage
stage
doing
additional
stuff.
But
if
it
fails
to
pass
introduction,
there
is
no
point
storing
that,
because
it
is
like
it
failed
to,
you
know,
adhere
to
organizational
policies.
D
D
F
F
A
Yeah
just
to
describe
my
thinking
like
I
have
this
developer
here.
You
can
see
this
diagram
yeah,
it's
very
simple
diagram,
but
when
I
what
I
was
thinking
when
I
was
documenting
this
and
putting
up
the
pr
like,
let's
assume
I
am
a
developer,
I
found
a
cool
technology
and
I
am
working
on
my
ide
and
like
whenever
I
introduce
a
dependency
in
my
code.
Things
start
happening
behind
the
scenes
like
how
I
think
this
scaffold
type
of
tools.
A
You
know
it
does
things
real
time
behind
the
scenes
like
building
image
and
pushing
it
to
kubernetes
cluster
and
then
running
things
and
giving
feedback
on
developers
id
for
example,
or
how
the
escort
does
so
again.
I
was
dreaming
or
imagining
something
like
that.
Okay,
I
introdu
I
introduce
a
dependency
open
source
dependency
and
then
things
happen
behind
these
things
and
if
that
dependency
is
already
vetted
and
made
available
for
organizations
consumption,
I
shouldn't
get
a
warning
on
my
id.
A
I
should
just
live
my
life
happily,
but
if
it
is
the
first
time
that
dependency
is
introduced,
I
should
get
some
kind
of
indication.
Oh
this
tendency
is
not.
You
know
vetted
or
approved
to
use,
but
don't
worry,
we
kicked
the
tires,
things
started
happening
and
then
I
know
how
long
it
takes.
But
then
developer
gets
some
kind
of
you
know,
pop-up
or
whatever.
G
Yeah
and
I
think
in
that
way,
it
doesn't
really
contradict
a
devops
approach.
Really
it's
more
about
the
the
logical
steps
that
need
to
be
taken
to
to
still
even
a
devops
team
needs
some
some
sort
of
structure
in
the
way
they
use
open
source
software,
so
that
assuming
automation
is,
is
a
must
here,
I
think,
and
then
it
wouldn't
contradict.
I
believe
I
like
it
by
the
way
fatty
you
didn't
add
me
to
the
to
the
pr,
but
now
I
received
it's
nice.
A
D
Yeah,
I
think
the
the
thing
that
I'm
a
little
bit
concerned
about-
and
I
had
I
put
some
feedback
on
on
the
original
document-
is
that
I
I
don't
feel
we're
giving
enough
consideration
to
the
versioning
problem
as
as
part
of
our
software
supply
chain
viewpoint,
because
that's
something
that
turns
a
lot
of
these
things
into
being
real-time
issues.
Rather
than
being
things
that
you
can
cash
decisions
long
term.
D
But
because
you're
in
a
constantly
changing
environment,
that
decision
may
not
hold
valid
for
very
long,
and
there
are
lots
of
external
factors
that
can
invalidate
something
that
was
previously
cached
as
good.
So
we
have
to
consider
the
caching
problem
and
cash
invalidation
as
as
as
part
of
this
overarching
supply
chain
problem.
D
D
This
time
cycle
of,
even
if
you
detect
a
problem
and
fix
it
and
release
a
new
version,
you've
got
a
whole
bunch
of
customers
who
potentially
cannot
work
at
the
same
cadence
as
you
and
are
still
relying
on
previous
versions
and
depending
on
your
contract
with
them,
you
may
have
to
maintain
previous
versions
and
a
current
version
for
an
overlapping
period
of
time.
So,
there's
a
lot
of
things
that
mix
into
this
that
make
it
subtle
and
quite
horrible
as
a
as
a
problem
to
to
solve.
D
A
I
see
we
time
is
up,
but
this
this
was
a
great
conversation.
So
then
we'll
obviously
continue
discussing
these
things,
but
terry,
like
I
don't
know,
I
haven't
checked.
If
you
have
put
comment
on
the
pr,
but
can
you
I
took
notes,
I
will
try
to
comment
under
pr
directly
some
of
these
things.
But
can
you
please
add
your
comments
there,
so
we
capture
those
things
like
automation.
Devops
is
one
key
aspect
and
then
this
caching
problem
and
so
on.
A
So
with
that,
I
think
we
are
one
minute
over
time,
so
I
want
to
thank
everyone
again.
I
see
joshua
still
with
us
thanks
for
staying
killed,
and
so
our
next
meeting
will
be
on
12th
of
may,
and
I
don't
remember
if
we
have
presentations
scheduled
for
it
just
quickly,
checking
that
so
yeah
cartographer
was
scheduled,
but
this
morning
I
learned
james
won't
be
available.
Maybe
we
can
continue
with
this
conversation
during
our
next
meeting.
A
Terry,
you
may
need
to
you
know,
remind
us
the
things,
because
some
people
may
hear
those
things
first
time
and
they
join
during
next
meeting
and
then
we
take
it
from
there
and
the
pr
is
there.
So
everyone
is
welcome
to
command
and
as
I
know
that
that
is
just
quick
brain
dump
and
we
can
change
whatever
needs
to
be
changed
there
as
well.