►
From YouTube: CDF TOC Meeting - Aug 30, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
So
anyways
on
on
directive-
I
don't
know
if
anybody
has
seen
it
here.
Let
me
stick
it
in
the
link
in
the
chat,
erective.
C
Here
we
submitted
a
ticket
to
lf
legal
and
we
received
few
questions
from
them,
which
we
sent
them
to
laurie
and
others,
and
I
think
steve
you
are
in
that
thread
as
well,
and
then
we
passed
that
response
back
to
legal
team
and
waiting
for
their
response.
It's
like
back
and
forth
at
the
moment.
C
C
B
Perfect
tracy
did
you
find
that.
A
D
A
And,
of
course,
I'm
interested
in
it
because
it's
so
in
line
with
our
cd
events,
it
is
all
based
on
cloud
events
with
opa
already
built
into
it.
So
it's
a
pretty
progressed
in
terms
of
how
they've
implemented
events
and
they've
built
a
lot
of
vocabulary
too.
So
it
may
help
us
in
three
areas.
B
Do
you
know
if
willem
is
gonna?
Is
he
aware
of
the
process
of
submitting
as
a
project.
A
So
I
was,
I
started
a
stream
with
him
and
it
says
myself
and
jen's
had
a
chat.
We
are
going
to
give
this
a
go
I'll
start
preparing
the
information
you've
sent
through
talk
soon,
and
that
was
on
the
24th
of
august.
So
it's
just
not
even
been
a
week
ago,
I
said
to
my
calendar
and
said:
if
you
want
to
chat
about
how
to
get
that
stuff
going
here's
my
link-
and
I
also
sent
him
the
ortilius
project
proposal
and
the
perseid
project
proposal
as
a
format
to
use.
A
I
think
that
many
of
us
have
seen
it.
I
know,
because
I,
at
least
from
the
event
side,
the
cd
events
team
have
looked
at
it,
but
if,
if
we
want
to
have
willam
present
it,
I
can
schedule
a
time
for
him
to
do
that.
I
know
he's
busy.
It's
a
it's
becoming
a
pretty
popular
product
he
is
in.
A
Where
is
he
at?
I
want
to
say
he's
in
australia,
so
he's
also
at
a
weird
time
zone
for
us,
so
at
10
o'clock.
This
time
might
not
be
a
a
reasonable
time
for
him
to
jump
in
on
a
call,
but
we
might
be
able
to
schedule
something
that's
later
in
the
day
for
him,
I
think
it's
like
maybe
midnight
for
him
right
now,
something
like
that.
A
And
just
in
general,
the
fact
that
we
have
there
are
people
in
new
zealand,
australia
in
that
time
zone
in
general,
that
we
don't
cater
to
very
well
in
terms
of
our
open
source
projects.
A
Ortillius
does
have
a
an
architecture
meeting
that
we
have
embraced
a
lot
of
the
folks
from
that
time
zone
as
part
of
the
reason
why
I
know
willem
because
he's
come
to
some
of
our
open
source
calls,
but
we,
it
might
be
something
we
want
to
have
a
conversation
about
in
the
future,
is
how
to
better
cater
to
australia,
new
zealand.
B
And
I
know
persia
has
one
of
their
members
shuffy,
who
leads
the
their
architecture
meeting
for
folks
in
china,
so
a
couple
of
their
their
members
of
feature
way
in
huawei,
so
he
leads
it's.
It
ends
up
being
like
seven
o'clock.
Pst,
I
think,
is
when
the
architecture
meeting
is
that
he
leads
because
he's
in
the
states
with
the
china
folks.
A
Assistant,
just
a
thought,
yeah,
I
just
thought
I
had.
I
had
two
people
this
past
week
mentioned
that
to
me,
because
all
of
our
working
groups
and
everything
we
do
around
like
events
and
vocabulary-
is
not
at
a
time
and
they're
pretty
active
down
under.
D
Don't
don't
we
have
a
pacific
meeting
time
for
events
to
the
events
either
the
sig
order.
D
There
is
one
yeah
on
wednesdays,
it's
very
early
for
u.s
people,
but
it's
still
quite
late
for
australians,
but
it's
more
friendly
towards
people
from
china
or
india
as
well,
yeah
yeah,
but
it
least
possible
for
australia
to
join.
I
think
at
times.
A
D
B
B
All
right
so
I'll
go
ahead
and
go
into
the
next
on
the
list
is
the
ortilius
project
just
a
kind
of
like
what
we
have
in
the
in
the
pipeline,
so
a
couple
things
that
we
have
speaking
of
brad
and
and
that
group,
so
one
thing
that
we
on
that
side
is
we're
doing
a
a
git
ops
flow
between
ortilius,
kept
in
argo
cd
and
that
and
all
that
type
of
level.
B
So
there's
a
working
group
that
is
mostly
out
of
australia
that
is
driving
the
the
kept
inside
of
the
integration
they
are
actually
going
through
and
writing
in
kept
and
they
call
them
services
some
additional
services
to
expand
out.
Captain
now
captain
is
in
the
cncf
side
because
I
think
they
came
along
before
the
cdf
was
created,
but
the
so
the
integration
is
is
spanning
cross
projects,
which
is
nice,
the
git
flow
process.
B
We
from
the
arturia
side,
we've
had
some
working
group
meetings
and
we
have
between
eight
and
14
members,
come
to
that
working
group
sessions
and
we've
kind
of
broken
out
the
the
tasks
kind
of
assigned
them
into
subgroups
at
that
level.
B
This
initially,
this
is
more
of
like
a
a
documentation
type
of
process
and
then
from
there
we're
going
to
build
out
the
cloud
events
that
are
needed
to
make
all
of
the
the
whole
get
ops
process
flow
between
all
the
products
at
that
level,
and
then
once
we
have
that
that
documented
and
designed
out,
then
we'll
go
into
the
actual
coding
pieces.
Some
of
the
coding
pieces.
B
B
A
So
I
think
that
maybe
we
should
give
up,
I
think,
give
a
foundation.
So
everybody
understands
what
ortillius
is
what
we're
doing
it
with
how
we
interact
with
this
the
pipeline
and
the
supply
chain,
because
and
then
we
can
give
them
an
update
of
what
what
we're
doing
with
the
road
map.
B
Well,
let
me
just
finish:
let
me
see
if
I
can
find
the
the
diaphragm
real,
quick.
A
A
All
right,
so,
just
so,
everybody
knows
steve
and
I
have
a
have
a
company
called
deploy
hub
back
in
2019.
We
contributed
about
80
percent
of
this
catalog
code
to
the
cd
foundation
in
december
of
2019.
A
A
That
process,
I'm
reaching
out
to
I've,
got
meetings
scheduled
and
had
had
demos
with
people
like
from
ibm
their
open
source
community
from
ibm
from
I'm
talking
to
vmware,
and
we
have
a
few
others
that
were
hitting
up,
because
we
really
do
at
this
point
need
a
larger
corporate
contributor.
A
So
we
are
part
we
are
a
governance
catalog
that
sits
underneath
the
cd
pipeline
and
we
suck
up
as
much
devops
intelligence
as
we
can
part
of
the
problem
in
a
cloud
native
environment.
Is
that
we're
not
we're?
No
longer
doing
monolithic
builds?
A
So
you
know,
there's
been
more
and
more
information.
You
know
we
were
a
little
bit
early.
I
think
and
realizing
that
what
a
cd
pipeline
needs
is
a
evidence
store.
Tyler
jewell,
if
you
haven't,
read
his
blogs,
I
highly
recommend
his
blogs
they're
always
great
about.
He
does
a
ton
of
research.
A
This
is
the
uber
kind
of
death
star
and
what
we're
doing
at
artelius
is.
While
this
is
the
look
of
the
of
the
entire
a
single
cluster.
To
be
quite
honest,
this
could
potentially
be
in
a
single
cluster.
A
Anytime,
a
new
package
is
created,
a
new
application
release
is
created
just
in
the
same
way
as
we've
done
with
ci
builds
a
new
library
gets
updated.
You
recompile
your
code,
you
create
a
new
version
of
a
release,
so
we
track
at
the
low
level
we
track
these.
These
low-level
objects.
We
then
track
up
the
chain
to
the
point
that
we
began
tracking
at
the
high
level:
logical
application.
A
A
Most
of
what
we're
doing
it
feels
like
we're
hurting
cats,
because
there's
so
much
of
it
to
be
done,
and
what,
in
the
supply
chain
discussion
and
the
work
that
we're
doing
around
the
open
ssf,
it's
all
about
tracking
s-bombs,
there's
a
discussion
about
all
the
different
levels
of
s-bombs.
We
want
to
track
all
the
different
level
s-bomb
data
in
a
single
evidence
store
so
that
when
change
happens,
everybody
can
see
why
it
occurred.
A
We
know
that
you
know
jim
has
talked
a
lot
about
the
importance
of
s
bombs
and
hardening
cyber
security
and,
as
I
pointed
out,
tyler
jewell
has
had
some
good
conversations
about
what
service
governance
is
and
why
it's
needed
now.
The
way
we
pull
this
together,
we
have
everything,
that's
generated
underneath
the
pipeline
of
a
cd
pipeline.
B
A
Then
we
also
integrate
on
the
kind
of
on
the
right
hand,
side.
This
is
the
component
information
that
we're
pulling
in
as
well.
We
pull
in
key
value
pairs.
We
pull
in
where
they're
they're
installed.
We
would
integrate
with
tools
like
spinnaker
or
harness
or
helm
to
push
that
deployment
data
and
bring
it
back.
So
we
know
where
the
versions
are
that
we're
tracking,
because
we
do
version
the
inventory
and
then
we
track
those
logical
applications.
A
So
our
governance
catalog,
then,
is
able
to
produce
some
interesting
reports.
We
can
re
produce
a
blast
radius
report
so
for
let's
say,
for
example,
our
cart
service
got
updated
and
it
impacted
15
of
our
applications.
We'd
be
able
to
show
exactly
which
applications
and
in
which
cluster
they
are
going
to
be
impacted.
A
A
A
Secondly,
we
have
talked
about
this
and
I'm
hoping
that
we
continue
to
pursue
it,
and
that
is
integration
with
backstage,
so
backstage
is
also
a
catalog,
but
backstage
doesn't
do
the
kind
of
versioning
and
dependency
mapping
that
we
are
doing
or
the
s-bom
creation
or
the
logical
application,
but
they
do
a
good
job
of
saying:
hey
if
you've
got
a
python
module
that
you're
going
to
create
or
a
microservice,
that's
going
to
be
written
in
python
register
it
and
we're
going
to
generate
your
cd
pipeline
for
you
or
your
project
data
that
you
need
to
continue
on
this
project.
A
They've
already
got
a
lot
of
data
about
the
different
microservices.
We
could
potentially
pull
that
in
the
third
area
that
we're
really
looking
at
help
from
and
why
a
larger
a
corporate
level
contributor
would
be
helpful.
Is
data
science,
because
now
we've
now
we're
tracking
the
kind
of
data
that
could
do
predictive
analysis.
A
Let's
say
we
know
that
you
know
as
we
build
the
engine
and
build
the
data.
We
know
that
a
lower
level
open
source
package
has
a
vulnerability.
We
would
have
the
ability
to
produce
and
notify
anybody
who
is
using
the
catalog
that
that
has
occurred
and
what
version
it's
in
and
they
would
be
able
to
tell
where
they
need
to
fix
it.
So
and
again,
we
could
do
risk
values.
A
What's
the
risk
value
of
a
particular
intersource
microservice,
it's
being
deployed
on
a
regular
basis
so
and
it
impacts
20,
different
applications
and
it's
running
in
40
of
our
clusters.
It's
probably
kind
of
a
high
risk
service
compared
to
maybe
a
change
to
a
jar
file.
That's
going
to
impact
one
team.
A
So
in
my
world,
when
we
think
about
cd
events
in
a
micro
service
world,
I
don't
believe
that
every
microservice
is
the
same
and
in
a
cd
event
world
we
could
begin
pushing
that
risk
analysis
up
to
the
cd
event
and
the
cd
event.
Then
using
policies
could
determine
what
requirements
that
particular
microservice
needs
to
go
through
in
the
pipeline
in
order
for
it
to
be
pushed
out
to
an
end
user
securely
and
safely
and
as
fast
as
possible,
which
is
ultimately
the
goal
of
the
cd
foundation.
A
So
any
any
questions
on.
Basically,
what
ortillius
is
in
general.
A
Think
of
us
as
the
cloud
bees
to
to
jenkins
one
of
the
areas
that
we
did
hold
back
were
the
group
users
we
have
in
in
the
open
source,
there's
two
types
of
users:
there's
an
administrator
and
a
user,
and
the
pro
version
we
held
back
the
ability
to
restrict
access
to
certain
what
we
call
domains
and
and
and
objects
within
the
tool
in
the
same
way
as
cloudbees
did,
with
adding
user
controls
and
groups
to
jenkins
and
there's
a
few
other
things
that
relate
specifically
to.
A
A
E
A
B
And
this
is
where
the
the
blockchain
technology
comes
into
play
because
as
people
make
changes
to
new,
you
know,
if
you
check
in
your
code,
you
generate
a
new
service,
a
new
version
of
the
service.
We
want
to
make
sure
that
the
history
is
preserved
of
the
of
the
older
version,
so
you
can
actually
show
progress
that
developers
are
fixing
things.
B
You
know
you
can,
so
you
can
show
that
at
at
this
date
we
had
a
log
for
shell
issue
and
then
you
know
three
days
later
they
fixed
it
and
that's
where
the
immutable
ledger
comes
into
play
as
part
of
that
and
where
we
most
of
our
information
is
actually
at
the
the
ci
level
of
the
pipeline.
A
So,
where
we
are
triggered
we're
triggered
in
two
places
on
the
pipeline,
so
micro
service
developer
would
create
a
new
build
image
for
their
container
or
a
monolith
for
that
matter.
But
let's
just
think
about
it.
In
cloud
native,
we
enter
interface
with
the
you
know:
get
artifact
repos
any
of
the
s-bomb
and
cve
scanning.
We
pull
that
into
the
catalog.
A
We
also
interface.
At
that
point,
we
can
be
triggered
at
the
point
in
time
that
the
deployment
occurs
and,
at
that
point
in
time
we
can
grab
information
about
where
it
was
sent.
So
we're
triggered
at
the
mainly
at
the
image,
build
here.
That's
where
we
determine
if
there's
a
as
there's
been
a
s-bomb
scanned.
A
We
also
at
that
point
in
time
when
we
are
triggered
at
that
image
build.
We
know
a
new.
A
new
image
is
out
there.
That
is
when
we
go
and
we
grab
the
shaw
and
we
grab
the
the
the
commit
and
any
of
the
information
that
we
need
to
create
the
new
version
of
the
of
the
component,
and
then
we
look
to
see
every
applicate,
logical
application,
that's
consuming
that
particular
component
and
we
create
new
versions
of
that
component.
A
The
kinds
of
components
we
can
manage
are
files,
containers
and
databases
and
believe
it
or
not.
Those
three
types
covers
everything
that
we're
creating
at
this
point
in
time
there
may
be
a
fourth
one
in
the
future,
but
there
hasn't
been
one
yet,
and
the
reason
why
we
have
to
have
different
component
types
is
because
there's
there's
different
attributes
for
each
of
those
components.
A
B
Yeah,
so
in
this
diagram,
when
you
know
the
changes
are
made
by
the
developer
to
the
get
repo,
whether
they're
doing
a
source
code
change,
that's
gonna
trigger
a
new
build
or
they're
going
to
do
a
new
deployment
through
a
get
ops
model.
B
So
that's
where
the
hooks
are
initially
in
the
get
ops
model
is,
is
in
that
event
based
process.
Now
one
of
the
things
that
once
we
get
our
event
process
flushed
out,
we
will
be
contributing
those
events
that
we
have
specifically
around
ortelius
back
to
the
events
vocabulary.
D
We
had
yesterday
on
our
sig
events,
meeting
a
presentation
from
mike
libre
what
is
it
lieberman
on
fresca,
the
architecture
or
the
fresca
framework?
It
sounds
some.
I
mean
it's
not
the
same
thing,
of
course,
but
it
seems
that
ortiz
could
maybe
fit
into
there
as
well.
Have
you
thought
of
that?
In
any
sense
first
case,
the
implementation
of
the
cncf
reference
architecture
for
secure
software
supply
chain.
B
I
I
have
not.
We
have
not
looked
at
that,
yet
it
would
be
nice
if
you
could
drop
us.
The
information
we'll
take
a
look
at
that
yeah.
B
So
in
in
in
general,
when
we
talk
about
artelias,
you
know
we,
we
are
hoarding
all
this
data
and
making
these
relationships
kind
of
linking
together
the
puzzle
pieces
as
application
developers
are
making
their
changes,
and
what
we
see
is
that
is
a
as
information
starts,
becoming
available
to
us
from
the
supply
chain
side
of
things.
So
we
know
that
a
package
was
built
and
signed
with
sigstor
that
sig
store
information
is
important
to
us
to
associate
to
the
package
which
then
associates
to
the
container
and
so
on.
B
So
we
will
be
consuming
those
inner
additional
information
as
they
become
available
and
same
thing
like
with
persia
when
perseus
build
consensus,
network
becomes
available
and
they
have
a
blockchain
backing
their
city
of
their
piece
of
things.
We'll
be
sucking
in
that
information
as
well.
A
A
We
do
have
access
to
some
of
the
xrp
folks,
but
we're
hoping
to
get
somebody
that
is
not
an
xrp
person
to
take
a
look
at
the
architecture
and
let
us
know
if
there's
a
better
direction
or
make
recommendations
and
it
would
be
a
paid
engagement.
So
if
anybody
has
somebody
they
know
who
would
be
a
good
candidate
for
taking
a
look
at
the
architecture,
please
let
me
know.
B
So
that's
what
we
have
going
on
with
with
ortelius.
You
know
we
like
tracy,
said
just
to
recap:
we
have
the
three
main
focuses.
You
know
the
the
get
ops
backstage
and
then
the
immutable
blockchain
ledger
is
where
we're
focused
coming
this
this
next
year
and
the
blockchain
work
is
actually
going
to
start
in
september.
B
So
all
that
will
be
transparent
and
available
to
everybody
to
see
how
we're
moving
along.
A
A
And
brad
mccoy
is
being
quiet
today,
but
he
has
been
a
great
contributor
to
the
project
and
brad.
We
thank
you
for
all
your
hard
work.
E
So
yeah
thanks
a
lot
for
this
presentation,
looking
forward
to
see
how
arterius
evolves
thanks
a
lot
for
bringing
so
many
standards
together.
So
hopefully
it
will
be
beneficial
for
the
foundation
for
the
for
its
ecosystem.
D
On
the
subject
of
get
ops
so
a
little
bit
tangential,
I
would
like
to
say
something
about
the
get
ups
certified
developer
exam
that
we're
developing,
but
this
can
come
later
in
schedule.
E
Okay,
so
yeah
we
can
try
two
months
through
the
agenda.
There
are
a
few
topics
so
but
yeah
sorry
for
being
played
first,
if
somebody
is
already
tracking
they
just
just
take
it
over
and.
A
Website
is
down,
I
yeah
right.
I
see
that
they're
moving
it
around,
but
we
have
had.
I
don't
know
if
all
the
open
source
projects
have
to
do
this,
but
every
three
months
we
have
to.
We
have
to
ping
the
the
linux
foundation
to
update
our
our
signature,
steve.
We
can't
hear
you.
B
Yeah,
it's
because
of
less
encrypt
and
that's
where
we're
actually
brad
is
work.
I'm
working
with
brad
to
get
the
azure
front
door
sorted
out
with
a
new
certificate
that
will
be
automatically
renewed,
so
we're
trying
to
get
rid
of
that.
E
B
Yeah,
so
we're
moving
to
that
split
type
of
solution
where
the
linux
foundation
owns
the
domain
and
that
we
manage
the
dns
servers
on
our
side.
It
just
gives
us
some
more
flexibility.
B
Yes,
so
we
had
the
linux
foundation,
stand
up
and
azure
subscription
for
ortelius
and
that's
where
it's
currently
moving
over
to
as
we
speak.
B
And
so
in
in
our
azure
kubernetes
cluster,
we
have
like
argo
captain
or
or
the
ortilius
website,
the
ortiz
documentation
and
the
ortelius
like
sandbox
for
folks
to
play
on
will
all
be
in
the
azure
cluster.
B
E
So
yeah
should
we
move
on
then
so
yeah,
thanks
again
for
the
presentation
yeah.
So
one
topic,
which
was
waiting
for
quite
a
while,
is
about
criteria.
So
andrei
submitted
an
issue
with
overview
of
tickton
state
and
compliance
with
different
requirements,
and
I
guess
we,
as
the
tvc
need
to
sign
off.
The
criteria
is
correct.
D
F
Alec
yeah,
so
I
created
the
issue
exactly
to
just
confirm
the
criteria
because
it
says
in
our
documentation
that
the
project,
specifically
some
criteria,
needs
to
be
agreed
upon
with
the
dlc,
and
I
had
also
a
couple
of
questions
here
and
there.
So
I
I
can
go
through
this
now,
if
you
think
you
have
time
or
anyway,
but
yeah.
So
basically,
I
listed
here
the
standard
acceptance
criteria
like
having
a
governing
body
having
documented
governance,
documentation
having
a
healthy
number
of
committers.
F
Process
and
so
forth,
yeah
so.
E
F
F
I
guess
one
question
was
on
the
ossf
patch,
because
if,
if
you
scroll
to
the
top
of
the
issue,
I
put
a
list
of
the
tecton
projects,
we
have
a
lot
of
repos
and
I
think
we
it
shouldn't,
be
required
for
all
of
these
requests
to
to
achieve
the
batch,
because
some
of
these
ripples
are
related
to
like
tecton
infrastructure
so
like
for
how
we
run
the
test,
how
we
deploy
tecton
upstream
for
testing
and
the
community
repo
things
like
that.
F
D
E
E
F
So
it's
still
not
up
to
date
with
everything
that
I
think
shouldn't
be
blocking
the
overall
project,
because
it's
something
we
just
started
christmas
and
same
for
for
results.
It's
a
relatively
new
project.
So
I
don't
think
that
the
openness
is
that
bad
for
things
like
results
or
resolutionship
like
the
overall
project.
F
Then
it
says
other
metrics,
as
defined
by
the
applying
project
during
the
application
process,
in
cooperation
with
the
toc,
and
there
are
some
examples
and
I
think
the
examples
in
there
they're
quite
fitting
for
tecton.
F
The
first
one
is
about
documented
release,
cycles
and
plans
for
lts,
and
I
think
this
this
is
fitting,
so
we
can
have
the
proper
documentation
for
release
cycles.
We
do
have
something
we
can
improve
upon
it,
but
we
do
have
clear
greasy
release
cycles.
So
that's
that
should
be
fine
in
terms
of
lts.
I
looked.
F
We
looked
at
what
kubernetes
does
because
we
depend
on
kubernetes
and
there
was
kubernetes
working
group
about
lts
for
a
while
and
what
they
created.
Is
this
page,
where
basically
they
say
for
each
release,
it
was
released
initially,
what
was
the
latest
release
of
patch
release?
F
What
is
the
end
of
life
for
that
release,
and
so
the
result
of
the
ltf
discussion
was
to
extend
the
end
of
life
of
each
release
a
bit.
So
we,
my
proposal,
is
that
protection
would
define
something
like
this.
D
F
Okay,
other
requirements,
project
that
have
themselves
become
platforms
for
other
projects
and
the
thing
that's
fitting
for
text
on
as
both
jenkins
and
openshift
pipelines
are
two
open
source
projects
that
rely
on.
D
F
A
Did
we
do
anything
more
when
jenkins
graduated
was
there
a
process,
then
I
wasn't
on
the
toc.
I
just
know
that
we
put
it
through.
E
The
same
process
give
or
take
one
thing
that
we
were
discussing
for
jenkins
and
we
agreed
not
to
do
is
security
audit
because
normally,
for
example,
cncf
projects
expected
to
have
a
security
audit
before
president
deportation
and
the
question
whether
we
want
to
do
it
for
digital
for
jenkins.
We
didn't
do
that.
E
D
F
The
security
audit
for
protecton
was
completed,
so
we
did
it
on
march
and
we
just
published.
We
just
published
the
report
on
the
on
the
blog
on
the
ecd
foundation,
blog.
F
Yeah
I
mean,
I
guess
the
question
would
be
is:
is
it
fine
to
have
security
hold
it
done
at
some
point
in
the
store
history
of
the
project,
I
mean,
and
I
mean
three
projects-
the
free
core
project,
where
analyzed
so
the
the
pipeline
to
yours
and
the
dashboard.
B
The
only
question
I
have
is
as
far
as
like
the
the
long-term
support
and
stuff
like
that,
are
you
going
to
produce
like
a
matrix
or
something
that
says
you
know
this?
Is
this
release
is
currently
the
the
stable
release
and
then
it's
going
to
be
predicted
to
be
retired.
You
know
two
years
from
now
or
something
like
that.
F
Yeah,
I
think
that
that
would
be
the
plan.
So
basically
it's
similar
to
what
kubernetes
says
when
it
is
they
have
this
release
releases
page.
Let
me
put
the
link
in
the
chat.
F
For
each
for
each
release,
when
it
was
last
released
and
what
is
the
end
of
life
got,
it.
A
So
am
I
understanding
we
need
as
a
toc,
we
need
to
create
cdf
kind
of
graduation
guidelines.
We
do.
We
do.
E
Not
we
already
have
them
these
guidelines,
where
we've
published
the
first
time.
One
jenkins
was
going
through
graduation.
We
updated
these
guidelines
and
afterwards
we
did
a
few
beats,
but
basically
we
agreed.
Then
the
guidelines
were
good
enough,
so
we
passed
through
the
incubation
through
the
criteria
and
basically,
what
andrea
presents
the
is
more
so
the
same
as
jenkins
did
for
jenkins.
E
E
A
A
E
But
yeah
we
had
a
discussion
with
the
spinning
curtain.
I
did
a
presentation
to
ops
max
you
had
a
conversation
with
armory
a
while
ago,
but
carl
also
restored
communications
with
spinnaker
vendors
in
spring
vertical
karakia,
but
basically
it's
up
to
the
community.
If
they
want
to
drive
and
to
pass
through
this
process,
then
they
can
and
yeah.
The
spinnaker
would
need
some
changes
to
pass
through
the
production
criteria.
B
So,
what's
the
next
step
that
we
need
to
do,
do
we
need
to
comment
on
the
pr
or
do
we
need
to
do
plus
ones
or
what's
kind
of
like
then?
The
next
step
here.
E
E
So
if
we
as
toc
agree
that
all
the
content
is
in
place
that
all
the
check
boxes
are
matched
like,
I
believe
so,
then
we
can
schedule
it.
F
E
So
one
thing
so
yeah
when
you
work
on
that
it
would
be
definitely
useful
to
have
links
to
open
ssf
for
the
projects.
Are
you
going
to
just
have
one
options
of
entry,
or
do
you
want
to
have
entry
page
company.
B
Yeah,
I
I
personally
think
the
what
is
laid
out
in
the
in
the
pr
and
the
approach
on
how
you're
gonna
take
the
subset
of
the
of
the
repos
and
submit
those
over
to
open
ssf
makes
sense,
like
you
said
some
things
like
experimental,
just
don't
make
sense
to
deal
with
on
that
front.
So
I
think
the
approach
is
perfect.
E
So
actually,
one
of
the
first
empty,
interesting,
open
search
list
allows
you
to
specify
what
is
actually
in
the
scope
for
the
review-
and
this
say
basically
all
deliverables
shipped
by
the
project,
et
cetera,
et
cetera,
and
I
believe
what
is
listed,
the
only
github
issues
totally
accomplished
with
this
criteria.
Everyone
has
experimental
projects,
it's
okay,.
F
F
D
D
Cdf
well
we're
going
to
start
the
process
in
2023
or
something.
How
does
that
work.
E
So
how
it
generally
works,
but
it's
definitely
not
quite
fine
on
this
ddf
side,
because
ctf
slide
side,
especially
cdf2ec,
is
relatively
lightweight
so
yeah
you
might
provide
consulting
et
cetera,
but
ultimately,
the
most
of
the
leg
work
is
done
by
the
projects
like
going
through
these
checklists,
going
through
the
openness
server
pages,
obviously
and
yeah.
E
So
if
you
have
a
timeline
and
actually,
as
you
may
see
in
a
project
area,
your
earlier
review,
you
say
that
ask
one
question
which
is
actually:
what
is
your
timeline
expectation
for
the
next
steps
in
the
cdf
and
yeah?
Where
is
it.
E
Now
change,
I
will
migrate
it
to
the
new
github
projects
later,
but
here
here,
for
example,
there
is
roadbump-
and
here,
for
example,
you
can
easily
say
that
computation
is
near
term.
We
can
link
it
whenever
but
yeah.
If.
F
E
Have
some
items
like
jenkins,
sex,
graduation
on
your
mind,
you
can
easily
put
it
here.
You
can
invest
a
snow
that
you
plan
it
in
your
project.
You
can
put
it
on
your
project
throughout
the
month
and
then
we
are
informed
that
something
is
coming
up.
Why
it's
important,
because
even
if
it's
quite
easy
on
the
toc
side,
so
we
do
the
reviews.
We
do
the
commands.
We
do
the
voting.
We
hosted
the
presentation.
E
There
is
still
a
marketing
car
split
thanks
to
steve
and
yeah
for
marketing,
etc.
It
would
be
great
for
cdf
to
be
informed.
What's
coming.
E
Yeah
so
since
we
ran
out
of
time
actually
what
we
agreed
last
meeting,
if
we
cannot
go
through
all
topics
on
the
agenda,
we
can
host
another
meeting
out
of
order.
So
my
question:
would
you
like
to
be
the
next
week
same
time
so
that
we
go
through
the
remainder
of
the
agenda,
or
do
we
just
postpone
all
the
topics
until
well?