►
From YouTube: SLSA Specifications Meeting (October 3, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
Like
the
the
new
orange
look.
A
A
No
we've
got
a
fairly
light
agenda
today,
but
if
anyone
has
anything
they'd
like
to
add,
please
do
so
and
we'll
see
what
yeah
see
what
we
can
get
through.
Maybe
we
can
do
some
triage
of
some
of
the
undecided
issues
for
1.0
milestone.
A
Give
it
a
couple
more
minutes
for
folks
to
make
their
way
in
before
we
get
started.
A
A
A
A
Filed
a
pull
request
against
the
proposals
Repository
just
to
convert
the
the
agreed
to
items
in
the
Google
Doc
for
philosophy,
one
into
a
markdown
document
to
capture
it
for
kind
of.
Oh
look:
there's
mark
cut.
A
Problems
yeah
so
I
was
just
talking
about.
A
You
know,
PR
against
proposals
repository
it
just
converts
the
agree
to
items
from
the
Google
Doc
into
markdown
for
a
kind
of
broader
visibility,
so
I've
dropped
a
couple
of
links
in
please
folks
on
this
call
just
take
a
few
moments
to
Mark
your
agreement
with
the
proposals,
assuming
that
you
do
still
agree
and
I've
provided
a
GitHub
PR
link
and
also
a
link
to
the
rendered
version
in
Mark
Fork
just
so
that
the
all
of
the
links
in
the
document
work
for
markdown
rendering
is
a
little
bit
different
and
the
diff
view
versus
the
original
kind
of
raw
file.
A
Cool
awesome,
the
other
thing
or
the
next
thing
was,
and
instead
of
a
just
spending
some
time
to
think
talk,
a
bit
about
getting
some
more
reviewers
for
the
1.0
change
and
what
process
we
can
follow
for
1.0
we've.
A
A
So
there's
a
bunch
of
changes
that
aren't
related
to
the
things
we
discuss
here,
but
even
when
the
changes
are
related,
there's
a
styling
and
things
in
the
way
that
can
make
reviewing
those
changes
difficult,
so
I'm
curious
to
spend
a
bit
of
time
talking
about
how
we
can
make
the
review
easier
and
what
we
can
do
to
streamline
the
1.0
process.
A
One
kind
of
proposal
just
to
get
a
discussion
going
is
that
for
1.0
PRS
targeting
the
kind
of
hidden
version
of
the
1.0
spec,
we
could
drop
from
requiring
two
approvals
to
one
approval
and
then
go
through
a
like
a
more
intense
review
process
of
the
complete
set
of
changes
before
1.0
is
marked
as
final
exactly
how
to
do
that,
and
not
entirely
certain
so
yeah.
D
From
my
point
of
view,
I
think
it's
a
lot
of
changes
all
at
once.
Right,
the
in
the
pr
and
so
I
would
like
a
huge
chunk
of
time
to
just
review
it
and
I
think
that's
where
I
get
stuck,
because
it's
hard
to
find
that
huge
chunk
of
time
and
I
think
it's
overwhelming
and
so
I
don't
want
to
like
just
chunk
it
up
into
different.
E
D
D
The
one
in
the
first,
the
first
blank
gets
pr7
and
then
even
the
one
that
you
had
mentioned
in
the
last
salsa
meeting
mark
I
was
trying
to
go
through
all
the
different
changes
and
I
was
like
okay.
This
is
a
lot
I.
Can't
just
do
this
in
like
10
minutes,
so
PR
was
it.
It
says
PR
number,
seven
for
the
salsa
proposal
right.
D
It's
478
lines
right
so
just
reading
through
all
of
that
right,
making
sure
that
I
remember
where
we
discussed
it,
and
you
know
it's
what
we
discussed
Etc,
but
again
that
this
is
my
issue,
but
that's
just
a
point
of
view
and
then
the
other
one
that
you
mentioned
on
Salsa's
meeting
I,
think
it
had
like
many
file
changes.
I
think
it
was
at
least
four,
but
it
was
just
a
lot
of
changes
for
me
to
review
in
a
matter
of
like
10
minutes.
D
Yeah
I
think
I
yeah
486.
Yes,
this
one
yeah
files
change
20
right
so
that
that
definitely
requires
a
little
bit
more
inspection
right
to
go
going
through
all
the
changes
that
were
made
so.
B
Yeah
and
And
to
clarify
so
that
486,
the
one
that
created
the
new
directory,
some
of
the
I,
said
in
the
pull
request
thing.
The
entire
V
1.0
tree
is
just
copied
verbatim.
Github
does
not
the
diff
doesn't
tell
you
this.
It
looks
like
a
new
file
got
it
but
like
if
you
compare
the
hashes
of
the
files
they're
the
same
okay
and
I
have
like
a
little
command
in
the
pull
request
that
you
could
verify
that
it
is
the
same.
B
That
is,
the
ls
tree,
tells
you
the
hash
of
a
directory,
and
so,
if
you
give
it
I
guess,
maybe
there's
too
much
magic
here
in
the
command.
But
if
you
compare
the
0.1
to
the
1.0
tree.
D
B
They
should
be
the
same
if
they're,
not
that
was
not
intentional
and
we
should
fix
that.
Okay,
so
yeah
that
one
has
I
I.
Don't
have
a
good
way
to
do
this
and
that's
why
also
I
wanted
to
switch
to
like
a
branch
based
thing,
because
that
would
make
the
version
history
easier,
but
that's
going
to
require
some
like
technical
work
to
change
so
for
now
we're
just
doing
file
copies
in
the
but
yeah,
so
that
one
is
a
big
one,
the
other
one,
the
proposal,
doc
I.
B
The
intention
was
to
just
copy
the
text
from
the
Google
Doc
without
changes
but
yeah.
If
you
want
to
re-review
the
whole
thing
just
to
make
sure
like
you
know,
because,
like
you
know,
you
probably
reviewed
in
chunks
at
the
time
but
didn't
repeat
the
whole
thing:
yeah,
that's
yeah,
that's
totally
understandable.
B
Would
it
help
I,
guess
I!
Guess:
we've
had
it
this
long,
I
don't
know
we
could
either
never
mind.
That's
fine,
see
I
I,
don't
think
it's
particularly
urgent
to
get
it
into
markdown,
so
I
think
having
the
like
that
pull
request
be
open
for
a
little
while,
while
people
have
time
to
review,
it
is
fine
for
the
proposal.
A
Yeah
I'm
I'm
extremely
sympathetic
to
the
this
stuff
takes
time
admission
like
that.
Certainly
it
certainly
does
and
I
think
the
the
challenge
is
to
find
something
that
works
without
slowing
down
because
or
slowing
things
down
too
much
right.
We
want.
We
wanted
to
get
salsa
1.0
out
sometime
this
calendar
year,
and
that
seems
very
unlikely
given
that,
like
there's
national
holidays
in
North,
America
and
okay,
then
like
winter,
is
a
big
shutdown
for
a
lot
of
companies.
So
this
really
is
just
like.
A
Let's,
let's
throw
some
ideas
around
so
one
idea,
I've
seen
other
communities
use
is
there'll,
be
a
time
window
for
a
review
and
if
there
aren't
reviews
in
that
time
window,
it's
assumes
that
people
don't
object
enough
to
like
kind
of
comment,
and
that
kind
of
that
can
help
motivate
things.
A
But
it
also
can
just
mean
that
something's,
just
like
get
through
without
any
actual
review,
which
is
why
I
kind
of
liked
the
the
account
proposal
in
the
document,
which
is
just
like
reducing
the
restrictions
or
reducing
the
requirement
to
one
approver.
While
we
have
a
flurry
of
changes,
but
it
really
won't
help
the
final
one
does
error
review.
If,
if
time
is
the
gating
factor
for
a
few
people
which
it
sounds
like
it
is
like
in
the
chat
and
I'll
just
comment,
then
yeah
go
ahead.
Mark
yeah.
B
I'm
in
favor
of
having
the
draft
be
lowering
the
barrier
and
we
mark
it
clearly
on
whatever
site
I
do
think
it's
helpful
to
have
One
reviewer,
because
I
feel
like
that
single
reviewer
catches
a
whole
lot
of
stuff,
and
in
fact
the
couple
pulls
over
said
so
far
had
useful
review
comments
and
changes
were
made
because
of
that.
B
So
if,
if
we
still
have,
if
we
could
have
enough
time
to
have
a
single
reviewer
and
if
we
set
the
bar
to
it,
doesn't
have
to
be
perfect,
but
it
just
has
to
like
Advance
it,
and
then
we
book
effectively
several
weeks
in
November
for
like
the
community,
this
group
in
particular,
but
also
anyone
else
who
wants
to
review,
to
review
it
as
a
whole
I.
Imagine
it's
probably
more
efficient
and
easier
to
read
the
whole
thing
in
one.
A
So
I
guess
the
obvious
kind
of
following
up
to
that
is:
would
folks
anticipate
being
able
to
spend
extra
time
doing
review
of
the
of
like
a
closer
to
final
form
document,
because
I
think
time
is
still
a
barrier.
But
if
we
have
a
a
window,
we're
aiming
for
a
review
period
for
many
of
us.
So
it's
kind
of
easier
to
block
our
time.
B
Yeah,
another
alternative
is
actually
just
have
zero
reviews
for
the
draft.
We
could
publish
it
to
a
branch
instead
of
to
the
main
branch
you
know
to
some
draft
Branch
and
then
we
we
basically
defer
all
of
the
reviews
to
the
final
form.
You
know
you
could
always
send
a
pull
request
asking
for
an
individual
review
if
you
want
particular
feedback
which,
if
we're
having
problems
getting
enough
reviewer
time
like
both
now
and
the
final
form,
we
could
just
push
it
all
to
the
end.
That
would
be
I.
A
Do
like
personally
I'm
I'm,
really
in
favor
of
having
some
review
happen
like
the
it
just
turns
it
into
more
of
a
collaboration
and
catches.
A
A
D
A
D
A
B
I,
don't
think
anything
well,
there's
nothing
pending
right
now
and
so
I
think
that
I
I
just
listed
that
one
as
an
example
like
it
has
been
reviewed,
so
I
I,
don't
think
it's
I
mean
if
you're
interested
you,
you
could
take
a
look
I.
Think
probably
the
most
important
right
now
is
the
proposal
one
just
to
make
sure
that
it
really
does
capture
the
the
intent
of
this
group
like
if
you
disagree
with
something
in
there.
B
We
should,
you
know,
reflect
that
or
reflect
the
you
know:
alternate
dependence,
Etc,
it's
not
urgent,
but
I
think
it's
important.
There
I'll
probably
have
another
pull
request
later
this
week
on
defining
the
levels
page.
It
would
probably
be
good
to
have
someone
from
this
group
review.
B
We
could
also
have
a
con
a
convention
around
who's,
doing
the
review
because,
like
there's
no
way
to
say,
I
am
doing
the
review
and
there's
actually
no
way
in
GitHub
to
assign
it
to
people
unless
they're
part
of
the
org,
and
it
also
Auto
assigns
anyone
who
is
in
the
code
owners
and
there's
no
way
to.
B
C
F
I
think
it
just
I
think
it's
still
set
up
what
just
for
two
reviewers,
so
whoever
is
like
listed
as
a
oh
yeah
yeah
so
like
on
that
end,
it's
like
whoever
is
in
whatever
group
it
is
in
GitHub.
There
needs
to
be
at
least
two
of
those
folks
need
to
give
a
thumbs
up
in
order
for
it
to
get
merged.
A
I,
don't
know
if
we
have
any
controls
in
place
to
require
steering
committee
folks,
two
two
or
more
I
think
it
was
two
or
more
stereo
committee
members
reviewed
I
think
we
already
controls
around
code
owners
but
yeah
just
Sebastian's
coming
in
the
in
the
chat
like.
If
someone
does
comment
in
an
pull
request
or
issue,
you
can
then
assign
them
to
it
once
they've
commented
and
kind
of
opted
into
the
discussion
thread,
so
people
can
certainly
comment
and
say,
hey,
I'm,
interested
in
reviewing
this.
A
B
Yeah
yeah
I
think
like,
if
maybe
we
could
use
a
convention
that
if
you
were
reviewing
a
pull
request
and
it's
going
to
take
more
than
you
know
like
in
an
hour
or
two
from
when
you
start
that
you
you
let
people
know.
So
you
know,
if
there's
other
viewers,
that
we
don't
if
other
people
are
short
on
time.
B
We're
like
I
wanted
to
say
this
thing,
but
now
it's
merged
and
like
do
I,
really
want
to
comment
after
the
fact,
I
think
it's
nice
to
let
people
know
that
that
you've
started
it
and
then
they
could
hold
the
the
submission
before
until
your
thing
is
ready.
Yeah.
B
Good
idea,
I
think
the
clearest
thing
is
maybe
if
we
start
each
one,
starting
with
like
the
one
point,
zero
colon,
because
that's
right
in
the
title,
like
labels
and
other
stuff,
are
kind
of
hard
to
see
and
also
I
think
there's
permissions
things.
If
anyone
like
not
everyone
can
add
those
labels.
But
anyone
could
just
add
that
prefix
to
the
title.
A
Yeah
the
pl
subject:
prefix
works
for
me,
a
low
barrier
but
like
high
signal.
A
Okay
so
I
think
we
have
some
consensus
around
trying
to
better
signal
which
things
need
or
need
review.
With
the
with
the
pr
subject,
prefix
we've
agreed.
We
want
to
keep
some
review
on
one
of
their
PR's
I.
Don't
didn't
hear
any
objections
to
reducing
the
number
of
required
reviewers,
but
I
didn't
hear
a
lot
of
agreement
either.
A
F
C
Yes
and
Melba's
point
I
think
every
well
at
least
I'm
interpreting
this
as
dropping
it
from
two
to
one
rather
than
two
to
zero.
A
A
Yes,
Sebastian
further
clarified.
I
won't
begged
the
the
document
to
say
that
this
is
reducing
required
reviews
from
two
to
one
for
v1.0
changes
while
v1.0
and
make
sure.
A
A
F
Yeah,
that
was
that
was
me
so
once
again,
if,
if
there's
time,
I
think
the
thing
that
Mark
and
I
had
a
little
bit
of
a
conversation
on
it,
it
might
not
be
something
that
that
once
again,
we
want
to
take
on
for
1.0,
but
just
something
that
was
brought
up
by
a
couple
of
different
folks
is
sort
of
a
lot
of
the
metadata
from
a
salsa
attestation
is
sort
of
encoded
in
the
invocation
piece,
and
you
know
it's
based
on
what
is
coming
out
of
the
Builder,
and
so
there
was
some
cons.
F
There
were
some
originally
it
kind
of
stemmed
out
of
the
like
dependencies
versus
Source
sort
of
conversation.
It
sounds
like
at
least
from
at
some
level
from
the
the
salsa
perspective.
We
should
just
view
both
of
those
as
being
the
same
thing,
a
dependency
in
a
source,
because
we
just
can't
really
make
the
distinction,
but
individual
Builders
might
make
that
distinction,
and
one
of
the
things
that
was
kind
of
brought
up,
also
from
some
of
the
folks
who
were
doing
the
salsa
GitHub
building.
F
They
plan
on
making
the
salsa,
GitHub,
Builder
sort
of
plugable
and
all
this
stuff,
and
one
of
the
things
that
was
kind
of
like
they
wanted
to
kind
of
think
through
was
like.
Does
it
make
sense
to
have
some
way
of
allowing
the
builders
with
the
URI
to
be
able
to
say
here
is
my
spec
for
the
URI,
so
this
is
some
additional
content,
so
if
so,
if
you're
ingesting
salsa,
you
can
look
at
Salsa
and
then
you
go,
and
you
say
oh,
this
is
a
builder
I
understand
like
the
salsa
GitHub
Builder
cool.
F
That
means
I
should
be
also
expecting
this
information
in
the
invocation
in
the
you
know,
things
and
so
I
can
also
derive
additional
sort
of
context
from
it
and
and
an
additional
sort
of
interesting
metadata
they
might
want
to
use
from
it,
and
so
one
of
the
things
was
just
like,
even
just
like
a
hey,
that's
something
to
consider
might
be
just
at
some
point
like
I.
Don't
I
don't
want
to
also
hold
up
anything
for
1.0.
For
that,
though,.
A
So
is
the
the
topic
here
then,
is
effectively
I
I
heard
two
things
from
there.
I
think
one
might
be
extracting
more
common
fields
and
adding
them
to
the
standards
which
may
be
all
right.
Sorry,
I'm,
not
gonna,
interpret
that
I'm
just
going
to
say
what
I
think
I
heard
and
then
the
other
thing
I
think
I
heard
was
how
to
effectively
communicate
when
a
builder
is
including
richer
metadata
in
these,
like
non-standardized
Fields,
where
the
standard
basically
says
this
is
a
an
object
you
can
supplement
How.
A
Do
they
communicate
that
additional
information
before
I
verify
to
leverage
are
those
reasonable
interpretations.
A
Effectively
that
there
are
like
three
or
four
places
in
the
sales
of
Providence
spec,
that
say
this
is
optional
Builder
defined
and
we
might
want
to
add
some
of
the
common
fields
that
crop
up
as
people
start
to
implement
back
into
the
spec
break.
But.
F
Potentially
or
we
might
just
want
to
make
the
claim
that
hey
look,
those
fields
are
going
to
be
very
much
Builder
dependent
fields,
and
so,
even
if
there
is
you
know,
so
we
might
want
to
provide
I,
think
hints
or
something
like
that.
But,
like
you
know,
for
example,
if
everybody
uses
the
term
inputs
right
as
to
or
use
the
word
dependencies
or
uses
the
term
sources,
whatever
I
think
there's
there's
things
there,
but
I
think
there's,
there's.
Definitely
something
where
we
do
want
to
like
I
think
the
bigger
piece
is
allowing
individual.
F
Or
making
it
clear
how
folks
might
use
a
salsa
Builder
specification
to
hit
some
of
those
extra
things
because
people
are
starting
to
ask
the
question
of
you
know:
hey
I'm
running
a
go,
build
and
I
want
to
invoke
policy
against
that
go.
Build.
Could
I
use
the
invocation
to
sort
of
address
that
policy,
but
if
I
don't
know
it
was
a
go
build
because
salsa
doesn't
have
any
of
that
metadata.
F
F
Yeah,
sorry,
yes,
the
built,
that's
what
I
meant
the
build
type
URI,
that's
used
by
the
Builder.
To
do
this!
Sorry,
yes,
I
my
mistake:
yes,
the
the
build
type
and
and
because
right
now
the
build
type
I.
Don't
think
anybody
has
a
specification
for
their
build
type
or
what
folks
should
be
actually
looking
at
from
the
salsa
perspective
of
like
oh
hey,
now,
look
at
the
build
type.
The
build
type
now
should
give
you
the
specification
for
how
those
things
are
and
then
to
your
point.
F
Those
things
are
potentially
from
the
salsa
and
once
again
like
we
might
want
to
provide
a
thing
of
like
hey
generally.
People
say
use
this,
as
you
know
the
term
for
dependencies
or
whatever
it
might
be.
A
Yeah,
my
Italians
and
I
guess
I'm
just
talking
first,
because
I'm
unmuted,
so
apologies
my
entirely
unsaturated
responses
that
this
feels
like
we
almost
have
to
wait
and
see.
It
feels
too
early
to
try
and
codify
anything
but
yeah.
Maybe
maybe
things
are
further
along
I-
haven't
attended
the
tooling
meeting
for
a
while.
Maybe
things
are
further
along
and
I
realized
I'm
gonna
mute
and
see
if
anyone
else
has
thought
so
much.
F
So
I
don't
want
to
put
Sean
on
the
hook,
but
I
know
Sean
had
a
couple
of
ideas
here
as
well.
C
Yeah
I
think
yeah
that
that
this
is
very
Implement
a
specific
and
there's
no
real
consensus
around
it
right
now,
I
think
having
the
the
GitHub
action
out
there
as
an
example
of
what
to
do
is
a
good
start,
but
the
other
thing
is,
you
know,
with
these
Builder
type
specs.
Is
there
anything
on
the
end
of
the
Uris
that
these
point
to
at
the
moment
and
I
guess
for
the
GitHub
one
probably,
but
for
everyone
else,
maybe
and
then
also
what
does
that
look
like?
What's
the
definition
there
I
mean?
C
A
That's
a
good
point,
I
think
I
forget
which
we're
in
the
suite
of
specifications.
We
recommend
it
sits,
but
I'm
fairly,
certain.
We
do
recommend
that
if
you
have
a
type
URI,
it's
resolvable
so
that
people
can
read
yeah
like
effectively
the
spec
for
the
type
URI
and
the
convention
I've
suggested
is
that
they
use
the
same
kind
of
formatting
conventions
as
the
salsa
Providence
back.
But
that
may
not
be
machine
readable,
as
requested
so
yeah.
F
Yeah,
yeah
and
I
think
what
you
know
I
think
base
like
so
so
to
give
a
couple
of
the
use
cases
that
people
have
brought
up
was
okay,
cool,
I
I
now
have
this
salsa
GitHub
build
and
I
want
to
validate
some
of
the
stuff.
That's
coming
out
of
the
invocation
like
some
of
the
inputs
that
are
coming
out
of
the
invocation
about
like
what
build
number
and
you
know
whatever
else.
F
What
information
should
I
expect
to
be
in
there
right
right,
because
if
one
of
the
things
that
could
happen
right
is
somebody
could
claim
to
be
a
particular
Builder
and
not
actually
be
that
Builder
or
somehow
not
be
compliant
with
that
Builder.
You
do
a
machine,
readable
thing
you
go
and
just
expect
a
thing
to
exist.
It
doesn't
exist,
whereas
you,
you
know,
if
there's
a
spec,
okay,
cool
I
can
check
the
inputs
against
the
spec.
If
the
inputs
don't
match
the
spec,
this
is
not
valid.
F
You
know,
and
and
like
some
of
this
is,
is
coming
to
a
head
with,
like
you
know
the
salsa
GitHub
generator
and
then
the
fact
that
there's
going
to
be
plug-ins
for
the
salsa
GitHub
generator
right,
there's
going
to
be
like
a
go
plug-in
and
a
python
plug-in,
and
this
that
and
the
other
thing,
and
so
there
might
be
also
once
again
like
you
know,
the
salsa
GitHub
generator
might
have
a
spec
and
then
a
parameter
to
that.
F
Spec
is
like
the
python
one
which
changes
the
spec
in
this
way
and
just
being
able
to
kind
of
say,
okay,
cool
I
can
pull
down
a
Json
with
that
spec
a
lot
of
automated
stuff.
You
know
whether
you
know
whatever
the
specification
might
be
like
a
Json
schema
or
protobuf
or
whatever
it
doesn't
matter.
But
if
there's
some
way
to
sort
of
figure
that
out
great
there's,
a
new
Builder
I
can
pull
out
semantic
information
from
the
Builder,
because,
once
again,
if
salsa
says
generally,
input
should
be
used
in
this
way.
F
If
generally,
certain
things
should
be
used
in
this
way,
like
a
lot
of
automated
tools
could
potentially
just
start
to
ingest
a
lot
of
that
information
be
able
to
pull
in
interesting
stuff
and
then
a
much
later
on
sort
of
idea
that
was
kind
of
being
thrown
around
as
well.
A
use
case
was
like
from
a
Rebuilder
use
case
right.
Could
somebody
take
enough
information
out
of
a
salsa,
build
to
run
a
build?
You
know
to
to
sort
of
say:
could
I
now
take
all
of
those
inputs
run
them
in
a
different
environment?
A
Yeah
I
get
the
desire
completely
I.
Think
there's
like
like
what
we.
What
we
kind
of
should
do
in
the
spec
today
is
relatively
limited.
While
we
see
some
more
kind
of
real
world
implementations,
I
really
I,
think
Sean's
comment
on
should
should
that
URI
even
resolve
is
a
really
important.
One
like
I
feel
like
that's
recommended
somewhere,
but
maybe
we're
not
doing
a
good
enough
job
of
communicating
that
and
and
even
what
to
put
there
when
it
is
resolvable
yeah.
F
Yeah
I
I've,
seen
in
similar
sorts
of
things
that
resolves
to
something
like
the
Json
schema
of
a
of
a
pro
you
know
of
a
project.
F
The
thing
that
is
also
I,
like
the
thing
that
I
think
we
might
just
want
to
do
from
our
perspective,
is
to
say
like
this
is
you
know
either
something
we
want
to
eventually
take
care
of
or
not
take
care
of
or
whatever,
and
just
make
it
clear
to
end
users
like
hey
look,
yes,
you
should.
If
you
are
generating
a
salsa,
you
know
a
Json
like
a
builder,
you
should
have
that
specification
defined
somewhere
right.
You
should
be
able
to
do
this
this
and
this.
F
The
intention
of
having
this
is
to
eventually
have
machine,
readable.
You
know
systems
to
be
able
to
pull
that
information
out
and
process
it
analyze.
It
potentially
rebuild
some
of
those
use
cases.
We
don't
have
a
lot
of
you
know
like
we.
We
can
make
it
clear
that
we
don't
have
a
lot
of,
at
least
for
1.0
and
yeah
yeah.
We
don't
have
any
guidelines
on
how
you
should
do
any
of
that
stuff,
but
just
be
aware,
that's
the
intention,
and
so
maybe
for
salsa
2.0.
F
You
can
imagine
that's
kind
of
very
clearly
defined
and
then
people
can
go
great.
I
can
just
pull
in
various
different
Builders
and
yayada
and
be
able
to
map
that
against
my
policy-
and
you
know
this
salsa,
you
know
this
salsa
GitHub
Builder
that
was
built
in
this
way.
I
I
get
you
know,
I
trust,
both
the
identity
that
built
the
thing
and
then
I
also
trust
the
Imp.
You
know,
based
on
the
inputs,
those
inputs
match
my
policy
or
whatever
great
I'm
gonna.
Let
that
into
my
environment.
F
But
yeah
so
I
I
don't
want
to
take
up
any
more.
You
know
time
on
on
this,
because
I
think
it's
gonna,
be
you
know,
based
on
the
initial
consensus.
It
just
sounds
like
yeah.
That
sounds
like
a
great
idea.
That's
going
to
be
significantly
more
in
the
future,
but
you
know,
if
need
be.
F
Does
it
make
sense
to
write
up
a
quick
proposal
to
just
sort
of
add
something
in
there
just
to
clarify
build
type,
a
little
bit
more
to
say
that
build
type
should
be
like
you
know,
there
should
be
some
sort
of
specification
right
to
make
sure
that
folks,
who
who
understand
the
build
type
could
process
it
and
then
say
you
know,
you
know
in
future
iterations
of
salsa.
We
might
have
additional
guidelines.
A
Yeah
we've
got
an
explicit
goal
of
making
the
1.0
spec
like
communicate.
Some
of
the
the
future
intentions
so
I
think
there's
value
in
driving
consensus
around
like
whether
we
want
to
claim
this
as
a
future
intention
effectively
and
also
the
idea
of
of
filing
creating
something
to
emphasize
that
the
type
you're
always
should
should
be
what
must
be,
but
should
be
resolvable
and
provide
some
some
kind
of
sophistication
at
the
end
of
it.
That
folks
can
use
to
augment
how
they
interpret
their
problems.
A
Okay
sounds
like
we've
come
to
yeah
a
stopping
point
on
that
topic
and
Sean
has
a
good
one
on
the
list
for
ephemeral,
isolated
and
hermetic
distinctions.
C
Yeah
so
I
think
there's
a
there's
at
least
two
discussions,
if
not
more
on
that
kind
of
touch
on
this
about,
you
know
where
the
boundaries
around
build
should
be,
and
at
what
level
we
should
do
that
and
I
think
we
potentially
you
know,
there's
a
there's,
a
lot
of
potential
overlap
in
how
people
understand
these
things,
so
I
think
it's
it's
worth
kind
of
coming
down
on,
because
you
know
we've
got
one
which
is
isolated
and
ephemeral
at
Salsa
level,
three
and
then
hermetic.
C
C
I
also
think
that
the
intent
of
the
mechanic
that
you
use
for
this
is
important
over
just
necessarily
the
implementation,
because
you
know
we
know
that
it's
possible
to
break
out
of
true
Tales.
It's
possible
to
break
out
of
containers.
It's
possible
to
break
out
of
VMS
are
those
the
intent
of
those
systems.
C
Is
it
a
a
requirement
of
those
systems
that
you'd
be
able
to
break
out,
or
is
it
just
a
flaw
in
the
underlying
system
that
allows
you
to
do
so
and
I
think
we
should
be
taking
the
intent
of
the
underlying
mechanism
as
enough
to
include
it
as
part
of
the
spec
rather
than
well?
You
know
containerdy's
great
and
all,
but
if
you
do
this
hack,
you
can
break
out
of
it
or
if
it's
configured
this
way
you
can
break
out
of
it.
C
I
I,
don't
think
that's
necessarily
relevant
to
this
spec
I
think
that's
just
a
vulnerability
in
the
underlying
system
that
needs
to
be
addressed.
So
I
just
wondered
what
what
other
people's
take
on
those
terms
and
what
they
mean
for
the
specification
were.
C
I
mean
ephemeral
is
another
bit
of
a
weird
one
as
well.
In
the
you
know,
isolated
and
hermetic,
don't
say
anything
about
the
about
whether
or
not
the
Builder
can
contempt
a
contemporary,
but
ephemeral
does
in
that
it
speaks
to
the
lifetime
of
the
of
the
build
environment
yeah
and
again.
Does
that,
how
far
do
you
draw
that
down
is
ephemeral,
the
lifetime
of
the
container?
Is
it
the
lifetime
of
the
host
machine
that
opens
the
container?
Is
it
you
know
if
that's
a
VM?
C
A
Yep
yeah
I
definitely
agree.
This
is
there's
like
three
or
four
issues
at
least
I,
think
that
are
touching
on
around
these
these
terms
and
how
to
interpret
them
and
that
somewhere,
when
I
was
doing
some
triage
earlier,
I
was
a
proposal
to
make
isolated
and
ephemeral.
A
Was
it
isolation?
There
was
a
proposal
to
merge
two
of
them
because
it
was
like
they're,
basically,
two
mechanisms
that
are
building
towards
the
same
control,
not
the
right
term
but
providing
the
same
functionality
feature
of
the
system,
and
if
you
isolate
them,
it's
really
difficult
to
describe
them
individually
in
a
way
that
you
know
would
lead
to
the
results
where
we're
recommending
here
so.
C
Yeah
I
think
there
was
some
suggestion
about
dependency
is
complete
and
hermetic
I
think
one's
potentially
an
implication
of
the
other,
but
it's
not
I,
don't
think
they're
the
same
thing,
but
again
that's
I've
been
level
four
anyway.
F
Yeah
so
I
think
one
of
the
things
that
we
did
that
worked
pretty
well
in
the
cncf
best
practices
guide
was
we
sort
of
like
we
viewed
some
of
these
almost
like
a
hierarchy
where
it's
like
you
know.
F
Yes,
hermetic
means
all
of
these
things
right
and
that's
maybe,
like
you
know,
the
top
level
like
hermetic
and
reproducible
are
sort
of
the
top
level
things,
but
there's
lots
of
other
things.
Like
you
know,
repeatable
is
maybe
not
you
know.
A
all.
Reproducible
builds
are
repeatable,
but
not
all
repeatable
bills
are
reproducible
and
it's
the
same
thing
like
all
hermetic
builds
are
isolated,
but
maybe
you
know,
but
not
all
isolated
builds
are
truly
hermetic
or
whatever
based
on
a
particular
distinction.
F
So
we
might
just
want
to
have
like
almost
I,
don't
want
to
say
like
levels,
because
that's
overloaded
in
everything
we've
been
doing
but
I
think
it
might
make
sense
just
to
kind
of
say,
like
you
know
the
you
know,
the
Venn
diagram
is
more
of
like
you
know,
hermetic
means
all
of
this.
Isolated
means
this
this
you
know
and
and
be
able
to
kind
of
make
it
clear
because
yeah
I,
I,
agree.
C
Yeah
I
think,
even
if
it's
not
hard
and
fast
part
of
the
spec
I
mean
we
shouldn't
be
calling
out
particular
implementations
and
Technologies
in
the
spec
necessarily,
but
certainly
in
the
in
the
accompanying
guidance.
We
should
be
saying
things
like
containerdy
is
good
enough
for
isolated,
and
you
know
the
fact
that
you've
got
in
short-lived
containers
that
do
just
the
build
is
enough
for
ephemeral.
C
E
E
I
think
there
is
also
the
strength
of
isolation,
the
you
have
security
boundaries
and
like
container
VM,
complete
harder
box
and,
depending
on
the
level
that
you
or
for
Assurance,
that
you
want
container
may
be
sufficient
for
this.
But
for
other
things
you
may
want
to
use
a
long
time
machine.
It's
very
unlikely
scenario,
but
yeah.
C
A
A
Not
my
yeah
I,
unfortunately
ill-equipped
to
do
that
so
yeah
I
think
there's
like
an
ongoing
recognition
that
we
he
needs
to
be
a
bit
more
careful
about
what
terms
we
use
like
one
of
the
first
issues
that
was
ever
filed
against
the
salsa
repository
shortly
after
it
being
open
source
with
someone
saying
what
the
heck
does
hermetic
even
mean
like
I'm
used
to
it
in
a
medical
context,
but
I
don't
know
what
it
means
in
a
build
system,
context
and
yeah.
A
There's
I
I,
don't
have
a
good
solution
for
how
to
succinctly
describe
some
of
these
things
without
using
words
that
are
prone
to
misinterpretation
effectively.
A
A
This
kind
of
community,
but
definitely
yeah,
sorry
I'm,
just
mumbling
now
in
agreement.
I
think
that
we
need
to
do
something
here,
but
with
her
concrete
ideas
of
what
to
do.
C
Well,
I
think
the
the
discussion
on
those
tickets
is
still
open
and
then
maybe
it's
it.
Let's
further
that
discussion
a
little
further
and
see
whether
any
consensus
arrives
and
if
it
does
or
doesn't
even
maybe
somebody
should
just
put
together
a
pull
request
to
kind
of
put
in
some
clarification
on
that
because
at
least
then
there's
a
straw
man
that
people
can
pick
out
as
well.
Yeah.
A
Yeah,
so
let's
try
and
get
a
few
more
ideas
on
those
issues
over
the
next
week
or
two
and
then
see
see
if
we
stimulate
any
discussion
and
if
not,
we
can
I
say
move
ahead
with
a
PR
and
try
and
start
clarifying
sounds
good.
Thank
you.
Sean
yeah
I
would
encourage
everyone
to
dive
into
the
linked
issues,
but
more
than
welcome
for
more
comments
here.
If
anyone
has
anything
they'd
like
to
add.
A
Okay,
great,
we
have
10
minutes
left
I'm,
not
sure
how
effective
trying
to
triage
some
issues
will
be.
Does
anyone
have
anything
else
they
wanted
to
throw
onto
the
end
of
the
discussion.
F
I
think
the
only
thing
that
I
think
might
be
worthwhile
in
either
an
upcoming
meeting
or
something
maybe
as
in
just
an
issue,
is
as
I
know,
some
of
the
initial
timelines
we
had
for
1.0
might
be
a
little
off
and
just
it
might
be
worthwhile
just
to
kind
of
say
generally
like
what.
When
do
we,
you
know
what
quarter
do
we
anticipate
1.0,
something
like
that.
A
Yeah,
it
would
be
good
to
especially
given
the
discussion
earlier
about.
You
know
needing
needing
some
good
time
to
be
able
to
focus
on
reviewing
things.
It
would
be
good
to
put
a
a
Target
date,
a
Target
window
together.
C
I
feel
like
we
probably
need
another
week
or
two's
worth
of
kind
of
measurement
on
effort
before
we
can
on
you
know
on
how.
Well
we
do
against
these
things,
because
at
the
moment,
I
don't
think.
There's
apart
from
Mark's
PR,
which
splits
the
directory
I,
don't
think,
there's
anything
that
we've
got
that
addresses
anything
that
we've
identified
for
1.0
right
now
in
terms
of
pull
request
as
just
the
issues
so.
A
We've
got
the
PRN
for
like
setting
up
the
scaffolding.
I,
don't
know
if
anyone's
had
a
look,
but
you
can
now
go
to
the
salsa
website
and
see
like
if
you
navigate
to
the
right
URL
there's
a
1.0
draft
and
it
warns
you
that
it's
a
draft
and
at
the
minute
it's
just
the
same
as
0.2,
but
there's
a
place.
We
can
start
doing
some
of
this
work
and
if
we've
got
consensus
on
the
proposal,
PR
then
definitely
if
there's
something
you'd
like
to
start
working
on.
A
Please
do
and
just
I
think
they're
I
think
just
communicating
that
you're
working
on
it
to
avoid
someone
the
unlikely
event
that
there's
a
someone
beating
you
to
it,
but
yeah
still
Western
I,
think
if
there
is
something
you
would
like
to
work
on.
Please
do
and
just
shout
on
the
issue
that
you're
going
to
do
so,
but
I
also
yeah
I
agree
with
you
show
them
that
we
need.
We
need
a
bit
more
time
to
figure
out
just
what
the
scope
is
before
we
can
start
twister.
Please.
A
A
Okie
dokie
well
I'm
gonna,
say:
let's
wrap
up
six
minutes
early
rather
than
trying
to
control
the
time
superficially.
So
another
good
discussion.
Thank
you.
Everyone
for
your
participation
and
I
look
forward
to
the
next
one
and
yeah
see
you
on
the
PRS
and
issues
in
the
meantime.
Hopefully
have
a
good
week,
foreign.