►
From YouTube: CDF TOC Meeting - March 14, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
C
E
C
E
A
E
C
F
A
C
I
would
say:
let's
get
started,
we
had
a
few
things
on
the
agenda,
so
welcome
everyone
to
the
TOC
meeting.
Oops.
Sorry
today
is
March
the
20th,
sorry
March,
the
14th
and
I'm
a
day
of.
E
C
So,
just
to
start
wanted
to
quickly
review
action
items
for
the
last
meeting
and
then
in
fact
he
will
talk
about
the
demo
theater
and
then
we
have
the
the
first
project
update
presentation
of
the
year
with
tecton.
So
thank
you
Christy
and
David
for
standing
up
for
this
presentation
and
then
we
have
fewer
more
item
on
the
gender.
C
So,
let's
get
started
action
item
I,
add
mark
from
last
meeting
shipwright
project
representative
that
was
missing
so
Enrique
offered
to
to
be
representative
for
the
project,
so
he's
added
to
the
list
there
and
also
I
added
the
list
of
project
representative
for
each
project
here
to
the
TOC
contributors
so
that
we
have
them
tracked
on
the
TOC
webs
GitHub
repository.
C
Okay,
the
other
thing
that
we
discussed
about
that
I
wanted
to
follow
up
we
discussed
about
two
weeks
ago
is
the
LFX
tools
working
group.
So
thanks
everyone
who
worked
on
setting
this
up.
So
there
is
a
GitHub
repository
now
with
the
readme
and
Conference
and
all
the
information
in
there,
and
also
there
is
a
slack
Channel
and
mailing
list
available
for
the
working
group.
C
Okay,
so
next
the
demo
theater
a
city
called
github's
count
fatty.
You
wanted
to
say
something
about
this.
G
G
G
So
we
are
looking
for
volunteers
to
you,
know,
serve
on
the
boat
and
you
know
talk
about
CDF
and
their
projects
or
if
you
are
interested
in
you
know
helping
our
community
and
our
projects,
please
sign
up
to
the
spreadsheet,
and
then
you
can
work
within
the
boot
during
the
breaks
and
talk
about
your
project
or
the
community.
And
the
third
thing
which
we
are
still
working
on
is
Project
Summit
and
if
you
can
click
that
fit
thanks
Andrea.
G
So
we
are
also
looking
at
the
possibility
of
giving
rooms
to
our
projects,
so
they
can
meet
with
the
community
members
contributors
and
interested
individuals
during
the
event
and
discuss
their
project,
their
roadmap
or
other
issues
or
topics
they
might
have,
and
you
can
just
sign
up
on
this
part
and
then
you
can
get
the
room
one
of
those
rooms
for
your
project
during
those
time
slots.
As
you
can
see,
we
have
morning
slots
before
the
session
starts
lunchtime
slots
or
you
can
grab
something
to
eat
and
meet
with
your
fellow
community
members.
G
Also
for
Tuesday.
We
plan
to
have
a
slot
after
the
sessions
are
done.
So
if
you
are
planning
to
host
a
project
meeting
discussion,
you
can
sign
up
for
this
loss
and
similar
to
demoted
Rambo
schedule.
This
is
also
first
capture
served
and,
finally,
the
demonstrator
schedule
and
projects
on
the
schedule
will
be
displayed
on
the
official
event
schedule.
So
you
can
see
and
point
your
colleagues
and
Friends
to
the
schedule
if
they
want
to
meet
with
community
and
so
on
any
questions
this
is
just
this
has
just
became
available.
G
C
C
Okay,
yeah
next
on
the
agenda,
I
have
the
the
project,
update
presentation.
If
that's
a
good
time
for
you,
Christy
and
David
to
to
do
the
presentation
or.
E
I
think
so
David
has
the
first
slide.
So
I'll
talk
to
you,
David
yeah.
H
A
E
C
So
there
is
a
checkbox
when
you
start
sharing,
so
if
you
stop
sharing
and
start
sharing
again
just
before
you
say:
okay,
there
is
a
checkbox
that
says
something
about
sharing
the
audio
screen.
H
C
C
H
I,
don't
know
what
was
different,
I
changed,
slides
and
suddenly
you
could
see
so
sorry
for
the
technical
glitches.
Let
me
start
there
a
quick
introduction.
My
name
is
David
bendori
I
am
the
engineering
manager
for
the
tecton
open
source
team
here
at
Google
I'll,
let
Christie
introduce
herself
when,
when
we
get
there,
I've
got
the
first
couple
of
slides
I'm
going
to
be
talking
about
the
tecton
community
roadmap.
H
This.
This
was
an
effort
that
I
undertook
in
Q4
to
basically
be
forward-looking
through
2023
as
to
what
the
different
companies
and
contributors
to
techton
had
in
mind.
The
full
roadmap
is
available
on
GitHub
I'm,
certainly
not
going
through
the
whole
thing.
These
slides
we'll
put
a
link
in
the
doc.
If
Christy
didn't
do
that
yet
and
you
can
pick
up
the
link
from
there.
So
at
the
top
here,
we've
got
the
high
level
Community
goals
that
we
identified.
H
Basically,
one
is
community
based
since
that's
what
all
of
OSS
leans
on.
We
want
to
encourage
further
Techs
on
adoption,
add
features,
Advanced
maturity
and
then
improve
our
our
own
developer
infrastructure
and
the
developer
experience
in
tecton
down
the
bottom.
There
I've
got
a
list
of
people
who
effectively
contributed
to
the
content
I'm
going
to
share.
These
are
all
the
people
I
met
with
when
we
were
putting
the
roadmap
together,
and
you
can
see
a
variety
of
companies
and
contributors
there,
foreign.
H
So
with
regard
to
healthy
Community,
it's
really
about
how
we
govern
ourselves
and
what
our
community
standards
are.
H
We
had
an
issue
or
two
in
2022,
where
we
were
a
little
bit
inconsistent
around
this
sort
of
thing
and
it
it
created
some
friction
that
we'd
like
to
avoid
so
we're
trying
to
be
a
little
bit
better
about
that
in
terms
of
how
we
self-govern
and
then
broad
Global
representation,
variety
of
companies,
variety
of
Industries,
a
variety
of
backgrounds,
Etc.
H
In
terms
of
encouraging
adoptions,
really,
there
are,
there
are
line
items
under
each
of
these
themes,
so
I'm
just
going
to
bring
the
themes
here.
Integrations
are
things
like
well,
I've
got
my
source
in
in
git
lab
and
how
do
I,
integrate,
git,
lab
and
and
with
with
tecton,
or
how
do
I
use,
artifactory
or
any
other
third-party
tool
you
might
want
to
use.
H
As
part
of
your
s,
we'd
like
to
collect
some
metrics
around
actual
usage,
we
have
a
bit
of
a
blind
spot
here
and
we'd
like
to
have
some
metrics
around
tecton
installations
and
what
people
are
doing
with
tecton
and
that
sort
of
thing
that
that
kind
of
user
metrics
would
help
guide
our
future
development.
H
One
issue
that
came
up
last
year
we've
got
a
lot
of
practitioners
who
are
using
tectonic
scale
and
very
little
data
around
and
benchmarking
around
that.
So
we
we
want
to
get
get
some
information
around
that,
so
we
can
give
some
guidance
and
then
finally,
documentation
is
always
critical
and
in
particular
we
want
to
focus
our
our
documentation
on
kind
of
end-to-end
user
Journeys
in
terms
of
new
features
and
advancing
maturity.
I'm
just
going
to
highlight
the
last
bullet
point
there,
because
Christy
is
going
to
talk
about
that
in
depth.
H
Really
security
is
the
ongoing
story
on
everybody's
mind
in
cicd.
We
talk
about
it
all
the
time
and
as
you'll
see
we're.
We
have
done
a
lot
and
are
going
to
continue
to
do
a
lot
in
that
particular
space
and
then
finally
improving
our
own
infrastructure.
Basically
tecton
on
tecton
is
the
theme
where
we
want
to
spend
more
time
dog
food
in
our
own
product,
understanding
it
not
only
from
a
developer
perspective
but
from
a
user
perspective.
H
Christy.
If
you
want
to
take
over
you
can
do
this
screen
share
I'm,
happy
to
stop
or
I'm
happy
to
page
slides
for
you
as
you
go
just
to
me
sure.
H
Christy
I
have
a
feeling
you
made
the
same
mistake
I
made
when
you
choose,
which
tab
to
share.
There's
a
little
check
box
down
the
bottom
that
you
need
to
uncheck.
It
says
I
think
share,
share
audio
from
presentation
or
something
like
that.
You
need
to
uncheck
that
before
you
share
your
screen.
E
A
E
C
Like
a
pretty
that
default
value
for
that
check,
anyways
wait.
E
You
can
see
my
slides
slide
great,
so
I'm
Christy
Warwick
I
used
to
be
Christy
Wilson.
You
might
know
me,
as
Christy
Wilson
I've
been
working
on
Tech
time
since
the
beginning.
I
am
an
engineer
at
Google,
currently
still
leading
techton
efforts
at
Google,
but
also
focusing
a
lot
more
on
secure
Supply
chains
in
general.
E
So
I
wanted
to
talk
to
everyone
here
today,
A
little
bit
about
some
of
the
things
that
we're
working
on
in
techton,
around
secure
Supply
chains
and
especially
a
call
out
to
anyone
working
on
other
projects
that
are
also
working
on
particularly
complying
with
salsa
or
maybe
interested
in
consuming
the
provenance
that
we're
going
to
be
generating
with
tecton,
because
I
think
it's
important
to
make
sure
that
all
these
tools
work
together.
So
there's
some
interesting
I
think
opportunities
for
collaboration.
There
I'll.
D
E
Into
a
bit
more
detail
about
what
I
mean
so
I'm
going
to
be
talking
mostly
about
salsa,
we
are
working
on
supply
chain
Security
in
general,
but
there's
a
lot
of
different
aspects
in
the
way
that
we're
tackling
it
right
now
has
been
through
the
lens
of
salsa.
The
high
level
themes
of
salsa
are
around
generating
provenance,
the
isolation
of
the
build
system
and
the
Integrity
of
source
I'm
going
to
get
into
more
detail
about
all
those.
So
first,
what
am
I
talking
about
when
I'm
talking
about
provenance?
E
You
may
have
heard
this
term
before
also
everyone
on
the
call
might
be
completely
familiar
with
this
it'll
only
be
a
brief
overview,
just
in
case
I
also
find
myself
getting
confused,
because
the
terms
attestation
and
provenance
seem
to
be
used.
Interchangeably
I've
found
it
helpful
to
try
to
think
about
this
in
the
context
of
things
outside
of
software,
like
what
does,
because
Providence
and
Anastasia
are
both
terms,
that
that
mean
something
in
other
domains.
So
one,
for
example,
is
in
the
domain
of
art.
E
You're
talking
about
a
painting,
the
provenance
of
that
painting
is
the
is
the
traceable
evidence
of
where
the
painting
came
from
and
how
it
exchanged
hands
along
the
way
and
how
it
came
to
be
where
it
is
and
that's
similar
to
the
provenance
that
we
generate
about
software,
which
is
how
did
we
get
this
piece
of
software,
this
binary?
How
is
it
built?
Where
did
it
come
from
and
then
similarly
there's
attestations,
which
you
can
have
all
kinds
of
attestations
about
anything
really
I
can
attest?
E
I
can
attest
that
I'm
standing
in
my
office
in
my
house
right
now.
You
can
have
an
expert
who
attests
to
a
painting
and
says
I've
examined
this
I
see
based
on
the
paint
that
was
used
in
the
in
the
analysis
of
the
paint
that
this
was
painted
at
this
time
and
painted
by
this
person
and
that's
an
attestation.
So
you
can
have
all
kinds
of
attestations.
E
So
usually,
when
we
talk
about
provenance,
it's
a
kind
of
attestation
that
we
make
about
software,
for
example
an
image
we
can
make
provenance
we
can
attach
to
the
provenance
of
that
image
and
how
it
was
built.
So
a
big
piece
of
complying
with
salsa
for
tecton
is
being
able
to
generate
this
kind
of
provenance
for
artifacts.
That
tecton
builds
looking
more
at
Salsa,
specifically,
the
another
big
piece
of
salsa
is
around
requirements
on
the
build
system.
E
So
if
there's
provenance
generation
as
I
was
just
talking
about
there's
different
levels
for
that
the
first
level,
the
bare
minimum
is
that
you
make
the
provenance.
The
next
level
is
that
the
Providence
is
authentic,
so
you've
actually
I
believe
it
comes
down
to
signing
it
and
being
able
to
verify
those
signatures.
So
you
know
it
actually
came
from
where
you
thought
it
came
from,
and
then
the
strongest
level
is
that
it
couldn't
be
foraged.
So
you
know
that
the
values
that
are
inside
of
that
provenance
actually
are
what
they
say.
E
The
other
big
piece
is
around
isolation,
so
making
sure
that
different
workloads
that
execute
on
the
build
system
can't
interfere
with
each
other
if
you're
familiar
with
salsa
at
all,
you
might
notice
that
this
is
a
slightly
shorter
list
than
some
of
the
ones
that
you've
seen
previously
and
that's
because
salsa
is
coming
out
with
a
new
version
1.0
which
actually
Scopes
it
down
a
fair
amount.
I'm.
B
E
To
touch
on
some
of
the
other
features
that
they've
removed,
at
least
for
now
later,
but
initially,
let's
talk
about
how
tecton
is
trying
to
meet
salsa
1.0,
so
in
in
the
domain
of
isolated
execution,
we're
doing
pretty
well
with
techtime.
We,
our
unit
of
execution,
is
containers,
so
that
is
already
ephemeral.
We
can
improve
this
and
we've
seen
some
of
our
users,
such
as
IBM,
doing
this
by
adding
additional
sandboxing
like
they're
using
cat
ibms
using
cat
containers
for
execution
for
examples
makes
it
makes
each
container
more
like
a
lightweight
VM.
E
As
far
as
isolation
is
concerned,
like
can
different
workloads
interfere
with
each
other.
There
are
a
few
features
of
tecton
that
make
it
so
that
you
can
violate
that
isolation.
It
kind
of
depends
on
how
you
use
tecton.
Basically,
one
feature
of
tecton
tasks
and
pipelines
is
that
they
can
share
data
via
something
called
a
workspace.
E
Also,
if
you
allow,
if
you
let
people
execute
privileged
workloads,
which
means
that
they
would
have
access
to
the
underlying
node,
then
that's
another
way
of
violating
isolation.
So
we
can
meet
these
these
requirements
today,
but
it
depends
a
bit
on
how
people
use
tecton.
Basically
they
have
to
set
it
up
and
configure
it
correctly.
E
On
the
on
the
theme
of
provenance,
as
I
was
discussing
before
today,
we
out
of
the
box
using
an
optional
techton
service,
called
tecton
chains.
You
can
meet
the
first
two
levels
of
salsa
you
can
generate
provenance
and
it'll
be
signed,
so
it'll
be
authentic
to
meet
the
further
non-forgeable
requirement.
E
So
here's
kind
of
an
a
brief
overview
of
how
provenance
generation
Works
in
tecton
in
the
kind
of
upper
right
side
of
the
screen
there's
a
depiction
of
a
pipeline.
So
a
typical
this
could
be
a
typical
pipeline
of
tasks.
Pipelines
and
tasks
are
both
techton
terms
by
the
way
tasks
are
they're.
Both
reusable
units
tasks
can
be
combined
in
pipelines.
Here's
a
here's,
a
typical
pipeline,
where
somebody
might
be
fetching
source
code,
running
tests
on
that
source
code
and
then
building
an
image
from
that.
E
If
we
wanted
to
generate
Providence
for
this
part
of,
what's
going
to
happen,
is
that
there
is
the
fetch
source
code
task
will
run
it
uses
parameters
and
workspaces
and
inputs,
and
it
creates
something
called
a
result
which
is
basically
just
string
values
that
it
outputs
and
then
this
optional
component
tecton
chains
observes
that
execution
and
generates
provenance
from
that.
So
that's
sort
of
at
a
high
level
how
this
works.
E
There
used
to
be
a
salsa
level,
four,
for
example,
and
that's
not
in
the
in
the
requirements
right
now,
but
my
understanding
is
that
they're
playing
planning
to
re-add
it
they're,
also
planning
to
add
a
track
to
salsa.
That's
focused
primarily
on
Source,
because
there
are
a
number
of
requirements
like
every.
E
Every
change
to
source
code
needs
to
be
reviewed
by
two
people
that
were
very
difficult
to
enforce
in
the
previous
model
like,
for
example,
Tech
time
would
have
no
idea
if
the
source
code
had
been
reviewed
by
two
people,
so
I
think
that
they're
trying
to
figure
out
a
way
to
focus
on
source
and
bring
that
back
in,
but
we'll
see
what
the
implications
are
for
tecton
and
other
build
systems,
but
there's
a
few
things
that
we
think
are
likely
to
come
back
that
we
are
already
working
on
specifically
build
this
code,
hermetic
execution
and
trusted
Source
fetching,
which
I
will
get
into
a
bit
more
detail
about
so
first
for
Builders
code.
E
So
this
is
the
idea
this
is
coming
from.
Infrastructure
is
code
from
all
the
other
as
code
initiatives.
The
idea
being
that
the
configuration
you
use
to
define
your
build
processes
is
actually
stored
in
Version,
Control
somewhere
and
when
you're
building
an
artifact
you're,
actually
fetching
that
configuration
from
Version
Control.
E
E
Another
feature:
that's
exciting,
that
a
lot
of
build
systems
don't
seem
to
provide
yet
which
I
think
is
part
of
why
salsa
descoped
it
because
they
seem
to
have
trouble
finding
examples
of
this
actually
being
used
is
hermetic
execution.
So
in
tecton
we
actually
have
an
experimental
feature
for
hermetic
execution
which
drops
network
access
to
a
pod.
So
you
can
run
a
task
and
you
can
say
it
should
be
hermetic
and
then
it
will
run
with
no
network
access.
E
So
that's
something
that
exists
as
an
experimental
feature
and
hopefully
we
can
promote
it
to
Alpha
and
beta
and
so
on
and
Tech
time
and
I.
Think
that
we'll
see
some
movement
on
this
and
then
also
hopefully
see
the
requirement
come
back
into
salsa.
But
it's
still
very
useful.
Whether
it's
in
salsa
or
not.
E
The
last
thing
I
wanted
to
touch
on
is
weight
is
a
little
bit.
Oh,
let
me
see
sorry
I,
don't
actually
haven't
been
paying
attention
to
chat.
Let's
see
her
medic
means
no
access
to
the
network.
Yes,
that
is
accurate,
I
think
if
you
look
at
I
was
going
to
say
if
you
look
at
the
salsa
requirements,
but
it's
not
in
there
anymore,
at
least
in
the
previous
salsa
requirements.
They
had
a
very
specific
definition
of
hermetic
and
I.
E
Believe
I
believe
it
means
that
no
it's
I
think
that
part
of
what
they
ran
into
as
well
is
they
had
another
requirement
reproducible
so
there's
reproducible
and
there's
hermetic,
and
it
was
sort
of
hard
to
draw
the
line
between
the
two,
because
one
way
of
defining
her
medic
was
that
if
you
ran
exactly
the
same
thing
again,
there's
no
outside
influence
on
it.
So
you'd
end
up
with
the
same
thing,
but
then
that
sounds
like
reproducible,
so
network
access
isn't
all
that
there
is
to
a
hermetic
execution.
E
I
think
the
idea
was
that
nothing
externally
could
could,
but
then
I'm
already
talking
myself
into
a
box,
because
time
time
is
something
that
changes
and
I
believe
that
was
explicitly
outside
of
the
scope
of
hermetic
execution.
The
idea
that
if
you
built
an
artifact
at
one
time
and
at
another
time,
you'll
actually
end
up
with
two
different
artifacts,
potentially
the
could
still
be
hermetic,
but
they're,
not
reproducible.
E
So
it
seems
like
network
access
is
the
main
thing
that
it
boils
that
hermetic
execution
boils
down
to,
but
there
might
be
a
bit
more
to
it
than
that
I'm,
not
sure,
quite
where
the
line
is
between
that
and
reproducible,
though,
but
happy
to
go
into
that
into
more
detail
about
that
as
well
or
I
could
look
up
the
salsa
requirement.
E
I
think
the
last
thing
I
wanted
to
talk
about
is
it's.
It's
primarily
about
trusted.
Source
fetching,
which
was
the
salsa
requirement.
So
salsa
had
a
requirement
that,
when
you're
fetching
source
code
to
build
an
artifact,
basically
that's
kind
of
a
special
operation
and
the
control
plane,
that's
doing
it
needs
to
be
able
to
say.
E
So
the
idea
is
that
these
reusable
tasks
and
pipelines,
instead
of
just
saying
oh
a
user-
can
use
any
task
or
pipeline.
They
want.
We
added
the
ability
to
have
a
policy
that
says
at
the
I
think
that
this
can
evolve
over
time
at
the
moment.
All
that
it
says,
is
if
you
get
a
task
or
a
pipeline
from
this
particular
place.
So
from
this
git
repo,
for
example,
I
expect
it
to
be
signed
with
this
key.
So
this
is
a
way
of
at
least
we
can
say
when
I'm
running
a
source.
E
Fetching
task
that
comes
from
this
particular
location.
I
know
that
it
was
built
by
these
people
and
it
hasn't
been
tampered
with.
And
on
top
of
that,
if
you
combine
that
with
the
idea
of
a
catalog,
for
example,
the
tecton
open
source
catalog,
then
you
could
see
that
you'd
see
a
path
where
we,
where
people
can
publish
catalogs
of
verified
tasks
and
pipelines.
E
That
kind
of
have
more
trust
than
just
the
user,
specifying
a
task
or
pipeline
that
they've
written
themselves
so
between
the
catalog
and
then
this
this,
the
introduction
of
the
idea
of
trusted
tasks
and
pipelines
we're
hoping
to
kind
of
move
some
of
the
tasks
into
the
trusted
control
plane.
So
the
same
pipeline
that
we're
looking
at
before,
where
source
code
is
fetched.
E
If
we're
using
trusted
tasks
and
we're
using
a
catalog,
then
what
that
can
look
like
is
that
this
task
is
stored
in
version
with
task
that
fetches
source
code
is
stored
in
Version
Control.
There's
people
who
are
in
charge
of
maintaining
it
whenever
they
make
a
change
to
it.
They
test
it
and
then
they
sign
it,
and
so,
when
the
actual
Pipeline
executes
and
fetches
this
task,
it
can
verify
that
the
task
is
assigned,
and
then
we
have
at
least
at
least
somewhat
more
trust
than
just
a
random
task
that
does
Source
fetching.
E
The
very
last
thing
I
wanted
to
touch
on
is
a
feature.
That's
in
progress
called
techton
artifacts,
it's
very
early,
and
we
don't
even
really
know
what
it's
going
to
look
like
yet,
but
we
basically
need
to
solve
the
problem
of
how
our
provenance
generator
knows
what's
occurring.
At
the
moment,
tecton
chains
which
makes
provenance,
looks
at
the
execution
of
pipelines
and
tasks,
and
it
looks
for
it.
It
basically
looks
for
special
string
values
and
that's
how
it
knows.
Oh,
these
are
the
inputs,
and
these
are
the
outputs
So
based
on
this
special
string
value.
E
I
know
that
an
image
was
built
so
I'm
going
to
make
provenance
for
that
image
and
based
on
this
other
special
string
value,
I
know
what
source
was
used
to
build
that
image.
So
we're
kind
of
storing
it
we're
encoding
information
about
the
artifacts
that
are
being
built
into
these
strings.
So,
instead
of
that,
there
is
an
effort
to
add
first-class
support
for
artifacts,
so
that
you
can
declare
them
a
bit
more
explicitly.
E
It'll
be
the
same
information,
but
in
a
more
useful
form
and
then
potentially,
we
can
have
kind
of
a
plug-in
plugging
plug-in
mechanism
around
tests.
That
makes
them
a
bit
more,
but
it's
a
bit
more
control
into
the
hands
of
Administrators.
So
back
to
the
trusted
task
for
Source
fetching.
Maybe
we
can
even
have
policies
that
say
whenever
we're
dealing
with
Source
artifacts,
you
should
use
this
particular
trusted
task
to
fetch
them,
and
then
we
could
add
more
things
on
top
of
artifacts
like
caching
and
immutability.
E
So
the
last,
the
last
evolution
of
that
pipeline,
that
I
was
showing
you
before
would
be
that
we
have
a
way
of
declaring
source
code
as
an
artifact
in
the
pipeline.
We
have
a
trusted
task
for
fetching
that
source
code
that's
verified
when
it
executes,
we
could
have
policies
around
what
tasks
can
fetch
source
code.
So
that
way,
we
can
have
this
piece
of
The
Trusted
control,
plane
that
does
Source
fetching
or
some
other
job,
but
then
also
have
the
flexibility
and
flexibility
that
tecton
provides.
E
So
that
was
a
whirlwind
overview
of
some
of
the
security
related
features
in
progress
in
Tech
time,
specifically
around
salsa
I
included
a
link
there's
a
link
to
these
slides
in
the
in
the
notes
for
this
meeting.
That's
currently
shared
with
tech
time
Dev,
though,
because
it's
kind
of
hard
to
open
these
up
to
just
anyone
we
might
want
to
just
David.
We
might
want
to
just
move
this
to
one
of
our
personal
accounts
and
we
could
open
the
slides
up
to
everybody.
H
I
actually
moved
I
moved
the
slides
to
the
tecton
folder.
Oh.
E
H
Will
it
just
be
yeah
I'm,
not
sure
if
you
can
make
it
public,
which
is
kind
of
what
we
want,
but
I
did
link
it
in
the
dock,
which
told
me
who,
in
this
that
who
has
access
to
the
agenda
for
this
meeting
that
couldn't
access
it
and
I
shared
with
all
of
them?
So
everybody
here
should
be
able
to
see
it
we'd
like
to
make
it
wider,
but
there
are
restrictions
on
us
googlers.
So.
E
Sounds
good
that
was
all
I
had
for
slides?
Does
anybody
have
any
questions.
C
All
right
thanks
thanks
a
lot
Christie
and
David
see
Tracy!
You
have
your
address.
You
have
a
question
yeah.
B
Hey
Christy,
thank
you
for
that.
That
was
an
awesome
overview.
Super
excited
about
what
you
guys
are
doing
around
salsa
in
particular.
I
just
have
a
couple
of
questions
or
things
for
you
to
think
about.
Have
you
looked
at
in
terms
of
the
on
the
build
side?
Have
you
looked
at
what
Percy
is
doing
around
the
decentralized
package?
Network,
no.
B
I,
don't
think
that's
on
our
radar.
You
might
you
might
you
know
these
are
other
CDF
projects
and
I
love
that
you're
looking
at
Salsa
as
a
kind
of
a
standard
for
what
you're
doing
but
it'd
be
great
to
also
kind
of
think
about.
B
Some
of
the
other
CDF
projects
and
Percy
is
interesting
because
it's
you
know,
you
think
about
restricting
network
access
for
a
bill
to
make
it
hermetic
and
repeatable
Perseus
sort
of
addressing
that
in
a
very
interesting
way,
where
it's
both
hermetic
and
repeatable,
because
you're
doing
it
across
multiple
nodes
and
not
just
trying
to
do
it
on
a
single
node,
and
that
means
that
all
nodes
have
to
agree
that
that
build
was
correct
before
it
is
blessed
so
to
speak,
and
then
I'd
love
to
chat
with
you
more
about
some
of
that
Providence
information
that
you
are
are
starting
to
grab
because
ortilius
collects
that
data
and
snaps
shots
that
data
over
time
with
every
release
of
a
component
and
logical
application.
B
So
that
would
be
information
that
we
might
be
pulling
up
and
then
finally,
it
would
be
great
if
some
of
this
stuff
was
built
around
CD
events.
The
event,
the
City
events
is
really
trying
to
build
out
some
some
standards
and
vocabulary
around
that.
So
if
you
could
keep
CD
events
in
mind,
so
those
would
be
the
three
Pro
other
CDF
projects
that
I
think
might
want
to
have
their
head
into
what
you're
doing.
E
Thank
you,
yeah.
That
makes
that
makes
no
sense.
I
think
the
I
think
maybe
something
that
could
be
useful,
protect
time
to
do
at
the
very
least,
would
be
to
publish
we
could
publish
or
write
something
that
shows
sort
of
what
information
we're
emitting
so
you're
mentioning
like.
Is
it
way
to
wanting
to
kind
of
consume
this
data
and
maybe
make
some
use
of
it?
We
could.
We
could
I
think
document.
E
Exactly
what
we're,
publishing
and
emitting
and
I
think
Andrea
I,
don't
want
to
put
you
on
the
spot,
but
I
know
that
you've
been
looking
into
events
with
tecton
I.
Think
we're
I
think
we
want
to
have
cd
events
more
integrated
in
Tech
time
as
a
whole.
I
think,
there's
I
think
we're
making
some
progress
towards
it.
C
Yes,
we
have
an
experimental
controller
that
produces
City
events
and
yeah
So.
The
plan
is
to
definitely
have
all
that
into
a
core
component
and
I
think
going
back
to
what
Christie
was
saying:
I
mean
to
detect
them
as
pretty
non-opinionated.
So
right
now
we
know
about
tasks
and
pipelines,
but
the
more
we
create
structure
around
like
RT
parts
or
more
structured
information
about
provenance.
C
C
D
F
Not
just
a
technical
role
with
this
group
liked
prefer
to
hear
a
strong
focus
on
technical,
or
do
you
want
to
hear
the
the
the
good
and
the
bad
of
the
governance
side
and
the
flaws
and
weaknesses
or
the
the
strengths
and
weaknesses
of
the
Jenkins
project
is,
should
should
the
next
month's
presentation
that
I
do
be
biased
strongly
towards
technical?
The
way
Christian
David
did
excellent
technical
material,
or
do
you
want,
in
addition
to
technical,
some
governance
material,
some
hey
how's,
the
project
going
how's
its
Health,
whether
it's
the
threats
to
it,
Etc
I.
A
B
Yeah,
so
sorry,
Andrea,
I
I
think
that
some
of
the
stats
around
the
community,
the
involvement
in
the
community,
any
threats
that
you
see
I
think
would
be
very,
very
helpful
to
understand
you
know:
do
we
have
a
community
building
issue
on
some
of
these
projects?
Are
there
just
a
couple
of
companies
that
are
involved
and
not
a
lot
of
just
general
Community
contributors
from
the
global
Community?
Those
kinds
of
things
would
be
great.
F
F
Well,
I'm
going
to
prepare
that
material,
whether
or
not
I
present
it
here,
because
I've
realized
I
need
that
material.
So.
A
F
Was
more
interested
in
if
the
rest
of
you
want
to
hear
my
my
overview
of
oh,
my
sakes,
I'm
frightened
by
this
or
oh
I'm,
really
kind
of
proud
of
this?
Those
sorts
of
things?
If
that
helps
you
I'm
happy
to
share
it,
and
if
the
the
techniques
we're
using
to
collect
the
the
information
about
the
project,
help
you
great
I
I,
that's
that
was
sort
of
my
question.
Robert
was,
if
it's
useful
to
you,
I
want
to
present
it.
J
Would
absolutely
be
useful,
Mark
and
I
think
what
Robert's
getting
at
is
we're
here
to
help
you.
So
if
you
tell
us
something
that
we
can
latch
on
to
and
get
you
some
help
with,
you
know
like,
for
example,
Community
Building,
like
what
Tracy
mentioned,
we
have
resources
that
we
can
put
into
play
to
help
the
project.
Oh.
F
Good,
thank
you,
okay
yeah,
so
so
the
last
month's
country
conversation
about
the
LFX
working
group
was
a
crucial
one
right
because
I'm
critically
dependent
on
that
data.
I
really
need
the
data
that
that
the
current
current
Dev
stats
site
is
doing
so
I.
Don't
want
to
sacrifice
that
and
I'll
happily
talk
to
more
topics.
Next
month
when
we're
When,
We
Gather.
C
And
thanks
Andrea
for
Christy
and
David
or
anyone
else
who
wasn't
in
two
weeks
ago
in
last
meeting
conversation
about
the
LFX
working
group.
So
the
idea
is
that
we're
starting
a
working
group
to
discuss
features
that
are
interesting
for
projects
or
for
the
CDs
Community
to
have
in
the
LFX
tools.
C
E
C
And
I
wanted
to
link
to
something
that
you
said
David
about
learning
more
about
what
tecton
users
or
about
who's
using
tecton
and
downloads
and
usage,
and
this
kind
of
information
and
I
think
in
last
meeting
we
had
some
discussion
about
exactly
this
topic
because,
as
a
DLC
I
think
it
we
would
be
interested
in
learning
from
all
the
projects
yeah,
but
the
health
of
the
community
is
and
what
the
kind
of
usage
is
out
there.
C
So
so
let
me
let
me
share,
maybe
the
notes
from
last
week
so
right
we
discussed
assessing
CDF
project
elf
in
terms
of
project
Community
metrics
and
that
links
back
to
devstat
and
the
LFX
working
group
and
the
other
aspect
was
really
usage
metrics
and
there
is
a
policy
from
the
Linux
Foundation
about
data
collection,
so
that
there
is
linked
here.
If
you
want
to
look
at
the
policy.
The
other
thing
that
Mark
mentioned
is
that
Jenkins
has
been
collecting
this
data
anonymized
for
quite
a
few
years
now
today.
C
So
I
wonder
whether
there
is
some
some
learning
here
that
may
be
some
experience
that
we
could
share
and
reuse
across
projects.
I
think
it
would
be
really
good
if
we
could
yeah
enabled
old
projects
that
are
interested
in
collecting
this
information
in
an
effective
way
and
compliant
with
the
policy
as
well.
H
Thanks
for
that
guidance,
we
were
actually
aware
of
both
the
usage
policy
and
that
Jenkins
has
been
collected.
We
actually
looked
at
summer
Jenkins
as
as
guidance
exactly
as
you're,
describing.
G
Just
want
to
add
to
this:
if
I
may,
this
topic
came
up
during
board
meeting
as
well,
so
Mark
thanks
a
lot
for
sharing
the
Jenkins
information
and
on
board
level.
There
is
a
document
we
are
working
on
to
gather
this
type
of
information,
so
I
think
our
next
step
there
would
be
to
combine
what
Jenkins
is
doing
and
what
our
quantities
I
want
to
have.
G
Then
we
can
bring
that
document
to
Toc
once
it
is
finalized
and
once
the
community
a
start
of
LFX,
the
Consular
group
or
until
C
this
discussion.
Once
you
finalize
that
document,
we
can
go
back
to
legal
with
a
more
complete
information,
both
from
Jenkins
site
plus.
There
may
be
things
Jenkins
is
not
looking,
but
our
community.
Our
projects
want
to
collect
and
I
mean
get
feedback
from
the
legal
ones
that
have
that
work
is
completed.
C
Think
yeah
I'm
unit.
Sorry
thanks!
Buddy
now
I
was
just
reading.
Cameras
comment
from
the
chat
that's
been
like
that
connects
Cemetery
data
Telemetry.
A
C
C
Great
any
last
question
or
comment
on
the
background
presentation.
C
Well,
thanks
again,
David
and
Christine
much
appreciated
you've
doing
your
presentation
here.
I
think
it
was
brilliant,
very
useful.
This
meeting
is
recorded
So,
the
presentation
will
be
well.
The
video
will
be
available
soon.
So
I'll
share
the
link
with
you
once
it's
available.
C
Okay,
all
right
so
moving
on
on
the
on
the
agenda
next
item,
I
just
wanted
to
briefly
bring
a
status
update
on
the
technical
oversight
committee.
It
was
okr,
so
what
we
presented
last
meeting
I
created
a
GitHub
project
and
we're
basically
the
five
objectives
are
here
and
then
you
can
expand
and
for
each
objective.
C
There
are
like
key
results
and
then
for
this,
then
we
can
have
a
series
and
assignees
and
we
can
have
linked
pull
requests
or
linked
items,
and
so
the
plan
that
I
have
is
to
well
sync
this
with
the
roadmap
that
we
have
today,
so
to
make
sure
that
all
the
work
that
we
are
doing
and
that
is
in
the
roadmap-
is
a
associated
with
some
of
these
key
results.
C
And
the
other
thing
that
is
ongoing
is
to
map
this
to
CDF
white,
okay,
errors
to
make
sure
that
we
have
a
link
between
what
we're
doing
as
a
DLC
and
the
general
direction.
A
strategy
of
the
CDF.
C
Yeah,
that's
all
I
had
on
these.
There
is
a
question
comments.
C
All
right,
so
this
is
the
next
topic
is
seek
updates
and
this
is
I
brought
it
back
from
last
meeting
I
think
we
didn't
have
time
to
discuss
it.
C
So
the
first
point
is
about
TOC
sponsors.
So
the
way
special
interest
group
are
set
up
is
that
they're
supposed
to
have
a
Toc
sponsor
someone
on
the
TOC.
That
is
sponsoring
this
as
seek
and
right
now,
I
think
most
of
our
sake.
They
don't
have
a
sponsor,
because
the
original
sponsor
is
not
part
of
the
TLC
anymore
or
well,
mainly
that
so
it
would
be
good
to
to
have
a
sponsor
assigned
to
each
of
these,
like
interoperability,
events,
envelopes
and
best
practices.
C
I
I
think
we
should
take
it
offline
and
and
go
and
hunt
down
sponsors
offline
on
that
I
think
it'll
just
be
quicker
and
easier
to
get
feedback
from
the
individual
sigs.
C
Thanks
Steve,
the
other
point
I
wanted
to
to
bring
to
to
the
group
is
that
the
way
cxr
defined
in
the
charter,
their
six
are
expected
to
to
like
a
regular
communication
through
this
group
to
the
DLC
and
brings
back
bring
back
like
quarterly
updates.
I
have
a
roadmap
design
for
for
the
interest
group,
and
maybe
that's
something
that
I
I
was
suggesting.
We
could
have
something
like,
in
the
end
of
year
report
to
bring
together
all
the
quarterly
updates
and
have
a
nice
February
the
end
of
the
year.
C
What
the
what
happened,
what
was
discussed
and
achieved
by
the
special
interest
group
so
Yeah.
E
C
Basically,
I
would
propose
to
to
kind
of
bring
this
back
and
maybe
join
some
of
the
the
various
sects
to
present
these
and
ask
to
to
us
some
presentation
similar
to
what
we
started
with
project
presentation
to
some
presentation
from
the
special
interest
group
to
this
Toc
meeting.
I
Would
it
make
sense
for
the
quarterly
updates
if
we
could
do
like
a
Google
form
or
something
like
that
that
they
could?
Just
we
can
ask
them?
You
know
five
questions
that
we
want
to
find
out
from
them
just
to
make
the
the
burden
on
them
pretty
light,
but
we
still
get
the
same.
Information
that
were
were
to
make
decisions
and
stuff
just
an
idea.
E
C
Yeah,
yes,
it
makes
sense.
Yeah
just
want
to
make
sure
that
we
we
are
kind
of
aware
of
what
what
is
going
on
with
the
different
seeks,
and
you
know
we
can
discuss
it
as
a
group.
So
but.
E
C
Think,
like
answers
from
this
form
would
be
sufficient
just
to
put
you
on
the
stop
on
the
spot
Steve
since
you
you
proposed
this
I
was
wondering
if
you
would
be
interested
in
drafting
yeah.
I
A
C
C
There
are
some
other
dimensions
that
that
we
get
to
to
consider
like
user
feedback
and
surveys,
maybe
so
information
from
from
users
directly,
not
in
the
form
of
like
anonymous
Telemetry,
but
like
yeah,
so
sending
around
surveys
or
generics
feedback
that
we
get
from
users
and
another
aspect
that
we
we
could
consider
is
to
include
in
the
project
acceptance
and
graduation
criteria,
some
more
requirements.
Then
we
have
today
something
some.
C
Maybe
areas
that
could
be
interesting
are
like
what
the
installation
process
for
the
tool
looks
like
what
is
the
quality
of
the
documentation
yeah
and
it's
open
for
more
ideas,
and
one
of
the
key
results
that
is
in
the
okr
is
to.
Is
this
one
to
basically
establish
a
clear
roadmap
for
graduation
of
two
CDF
projects?
B
I
definitely
think
we
should
get
a
clarifier.
You
know
what
the
road
to
graduation
looks
like
and
a
pro
there's,
probably
a
couple
of
those
items
on
there.
Like
you
know,
governance,
do
they
have
a
governing
board?
Do
they
have
a
maybe
a
security
officer
or
those
types
of
things
to
determine
the
maturity
of
the
group
and
the
involvement?
I
B
I
Because
those
those
definitions
of
what
what's
needed
for
incubating
versus
graduating
is
to
find
somewhere.
C
Yeah,
it
is
definitely
defined,
but
I
was
wondering
whether
we
could
announce
some
of
that
based
on
some
of
this
area,
because
I
think
we
have
the
requirement
about
governance.
We
have
requirements
about
yeah
like
having
securely.
We
have
the
open,
SSS
badge,
I,
don't
think
we
have
specific
requirements
about
kind
of
user
experience.
I
I
It
would
be,
it
could
be
too
much
work,
but
it'd
be
kind
of
nice
to
know
that
a
project
is
like
50
of
the
way
they're.
You
know
and
has
has
achieved
these
items
on
the
checklist,
and
you
know
from
a
Toc
point
of
view,
that
will
kind
of
help
us
figure
out
how
we
can
help
them
get
them
over
to
the
the
line
to
the
next
level.
B
Yeah
that
I
think
it's
there's
quite
a
bit
on
already
written
about
it.
Maybe
we
just
spend
some
time
and
review
this
and
just
go
through
it
and
see.
If
there's
anything
we
want
to
add
to
it,
I
see
that
the
openssf
best
practice
badge
has
been
added
to
it.
For
example,
I.
Don't
think
that
was
there
initially.
C
B
So,
for
example,
I'm
looking
at
it
and
I
could
almost
say
that
based
on
the
graduated
status,
ortilius
could
graduate,
but
we
don't
I,
don't
think
we
would
be
ready,
considering
we
just
pretty
much
got
our
MVP
ready
and
is
out
there
and
we're
just
starting
the
adoption
process.
So
I
feel
like
that.
Probably
should
be
a
little
bit
more
and
the
acceptance
criteria,
as
you
indicated
you
know,
is,
is
there
good
documentation?
B
B
C
B
You
know
surveys
don't
get
art,
well,
people
get
pretty
burnt
out
on
surveys,
but
maybe
you
know
a
number
of
case
studies
or
written
case
studies,
which
also
can
be
challenging,
because
not
a
lot
of
companies
will
will
want
to
expose
the
tools
that
they're,
using
at
least
that's
been
our
experience.
Many
of
them
will
be
happy
to,
but
maybe
we
do.
User
feedback
in
the
form
of
you
know
case
studies
that
we
can
publish,
I,
think
that
surveys
and
get
yeah
a
little
old.
G
Actually
about
the
case
studies,
we
launched
the
user
stories
program
and
I
think
we
had
the
first
case
study
for
affidative
published
beginning
of
February,
and
we
have
three
or
two
of
them
are
in
draft
and
third
one
is
being
written.
So
if
any
of
you
know
a
non-user
company
using
one
of
our
projects
or
more
of
our
projects
just
reach
out
to
us-
and
we
do
our
best
to
help
done,
got
their
case.
Studies
published.
C
B
I
just
want
to
point
out
that
we
have
our
first
LFX
tools,
meeting
on
Monday
I'm,
not
sure
if
the
all
of
the
projects
got
notified,
that
we
were
doing
that
Fati
or
who
did
we
I
know?
Mark
has
been
added
and
I'm
hoping
that
at
least
the
project
Representatives
have
been
added,
and
this
is
a
working
group.
So
it
means
it's
not
permanent.
We're
just
trying
to
get
some
initial
recommendations
and
requirements
for
the
LFX
team
that
we
can
push
over.
G
B
Be
great
to
have
one
person
from
each
project
on
that
working
group.
B
And
that
will
be
a
monthly
meeting,
so
we're
not
being
super
aggressive
about
this.
But
and
hopefully
we
will
gather
most
of
them
on
discussions
on
in
the
GitHub
repo.
G
A
C
A
A
C
C
Okay,
so.
A
D
C
J
C
G
C
G
Think,
historically,
we
kept
the
meeting
time
same.
We
didn't
follow
UTC.
We
followed
the
local
time
zones,
so
this
meeting
is
now
happening
or
next
week.
It
will
happen
one
hour
later
for
Pacific
and
other
time
zones
as
well,
so
pulling
it
back
to
5
PM
CET
to
bring
it
back
to
same
time
in
Pacific
and
others
as
well.