►
From YouTube: Working Group: 2021-07-15
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).
A
B
B
C
B
A
A
B
Platform-
all
right,
sorry
about
that,
let's
see
so
pack
went
into
rc
or
we
released
an
rc
yesterday.
The
anticipation
is
to
get
that
rolling
out
for
about
a
week.
So
that's
next
wednesday
we'll
try
to
publish
it.
There
might
be
because
I
will
be
out
of
you
know
out
of
the
office
during
that
time.
I
might
not
be
able
to
get
to
it
until
the
following
monday,
but
somewhere
around
that
time
frame
is
when
you
should
expect
a
pack
release.
B
We
are
still
working
on
the
life
cycle.
Hopefully
the
spec
should
be
finalized
soon
and
we'll
be
in
a
place
to
release
a
release.
Candidate.
B
C
We
also
got
a
release
for
lip
cnb,
which
added,
like
the
gate,
service
findings
for
runtime,
instead
of
using
the
buildbacks
form
and
some
minor
patches
and
dependency
updates.
A
D
B
A
All
right,
so
first
thing
is
skip
over
the.
B
A
That
aren't
rfcs,
those
are
just
pr's.
I
think
first
thing
is
officially
supported:
utility
build
packs.
Any
updates
on
this
joe
just
need
anything
yeah.
I
added.
B
I
added
some
criteria
for
what
criteria
for
accepting
utility
build
packs
to
the
project.
So
take
a
look
at
that.
If
you
get
a
chance,
it's
a
little,
it
requires
that
the
behavior
be
specced,
which
is
something
I
think
sam
brought
up
so
happy
to
go
back
and
forth
on
that.
But
that
was
just
starting
point.
A
Dynamic
runtime
base
image
selection,
it's
mine,
I'm.
I
responded
to
a
couple
of
comments
here,
I'm
not
focusing
on
this
one
until
the
other
two
get
through.
I
think
there's
a
lot
more
interest
in
removing
stacks
and
this
kind
of
what
we're
going
to
do
about
stack
packs
compared
to
this
one,
so
I'll
kind
of
skip
over
this
will
be
maybe
a
little
more
consensus
on
these
two.
Unless
anybody
feels
like
they'd
like
to
talk
about
that
one
more
just
kind
of
wanted
to
see.
A
B
A
Of
the
red
hat
folks,
you
know
we'll
kind
of
talk
about
this
when
we
get
to
it,
remove
stacks
and
nixon's.
I
also
responded
to
a
bunch
of
feedback
in
there
last
night.
A
I
think
this
is
could
be
ready
to
go
if
everybody
magically
agrees,
but
I
you
know
please,
please
take
a
look
if
there's
anything
there
that
would
worried
you
or
that
you
want
me
to
update
or
that
you
disagree
with.
A
B
Just
real
quick
on
the
one
that
you
skipped
over,
it's
not
an
rfc,
but
I
would
like
some,
you
know
eyes
on
it,
so
that
we
can
merge
that
in.
B
D
Logic,
I
think
this
is,
I
think
I've
addressed
most
of
the
issues
here.
It
seems
like
the
outstanding
sticking
point.
Is
the
default
build
packs?
The
last
thing
that
I'd
like
feedback
on
from
people
is
there's
a
big
discussion
about
signal
handling
at
the
bottom,
and
I've
described
why
I
think
this
actually
doesn't
affect
signal
handling,
but
some
folks
wanted
this
be
added
to
the
rfc.
So
just
let
me
know
if
you
agree
with
my
explanation
or
want
changes
there.
B
A
Next
thing
is
make
the
layers
read
only
for
subsequent
build
packs.
Is
this
still
active,
or
was
there
something
around
caching
needed
to
happen
for
this
too?
C
I
have
not
seen
emily's
last
comments.
I
think,
apart
from
that.
C
C
So
there
was
a
comment
around
backwards
compatibility.
I
added
an
example
on
how
we
can
preserve
backwards
compatibility
for
with
cyclone
dx
json
format,
so.
C
We
can
talk
about
it
later
if
you
want,
but
since
icon
dx
does
lose,
json
schema,
validation
and
metadata
is
not
an
existing
key
in
the
components
object.
We
can
preserve
the
metadata
table
as
it
is,
and
all
of
the
information
is
preserved.
I
only
recommended
moving
name
and
version
to
the
appropriate
cyclone
dx
mappings.
C
A
Do
you
want
to
put
this
in
the
agenda?
You
said
there's
more
stuff
to
talk
about.
Oh
sure,
I
mean
no
pressure,
just
move
on
to
the
get
to
the
rest
of
them.
We
talked
about
read
layers,
so
there's
just
more
feedback.
There
combine
and
organize
metadata
file.
A
Locations,
I
think
this
was
jesse.
B
Is
that
right,
yeah,
I
think
jess
is
taking
this
over
he's
on
pto
for
the
next
few
weeks.
So.
B
D
I
left
some
comments
because
I
feel
like
we're
implicitly
changing
the
build
pack
contract
as
well
in
terms
of
how
we
supply
values
to
a
build
bank,
and
I
feel
like
we
should
call
that
out
explicitly.
But
overall,
I
feel
like
this
is
in
pretty
good
shape,
but
we
just
need
to
explicitly
add
the
build
back
contract
changes.
B
As
is
someone,
does
someone
want
to
take
that
over?
Are
we
just
going
to
wait
for
jess
to
get
back,
I
think
was
kind
of
stephen's?
What
stephen
was
hinting
at
right.
A
Yeah
either
way,
I'm
just
wondering
if
this
is
high
priority
for
anybody
or
if
it's
you
know,
some
of
the
changes
are
blocking
other
things,
because
it's
like.
B
A
A
So
thing
on
the
list
I
put
just
as
a
note
there's
a
cncf,
secure
supply
chain
working
group
meeting
this
morning
at
I
forget
what
time
sam
you
know,
I'll
write
after
this
right
after
this
at
11
eastern,
so
sam
and
I
and
matt
mcnew-
are
going
to
be
presenting
there
just
around
how
build
techs
contribute
to
secure
supply
chain.
Please
show
up
if
you
are
interested
in
seeing
that
learning
more,
I
think
it'll
be
recorded
too.
A
That's
a
good
question.
I
think
it's
on
the
cncf
secure
supply
chain
working
group.
B
A
C
B
A
quick,
sorry
steven
could
I
just
make
a
quick
comment
before
we
dive
into
topics
since
we
just
completed
the
rfc
roundup
and
we're
talking
about
moving
it
moving
that
part
of
the
meeting
to
wednesdays
to
the
wednesday
core
team
sink.
If
we
could
just
there
the
the
talk
about
having
a
structured
agenda
for
this
meeting,
as
you
were
speaking
and
people
were
saying.
Oh
you
know.
B
B
A
That
all
makes
sense,
so
that
means
after
the
court
core
team
sub
team
sync
where
people
should
take
information
about
the
rfcs
they
you
know
we
kind
of,
did
a
check
in
over
and
then
make
sure
it
gets
on
this
agenda
for
people
to
talk
about
awesome.
I
did
notice
it
was
empty
today,
so
it
would
definitely
be
good
to
start
with
it.
Let's
start
with
an
agenda
there.
A
A
So
some
feedback
I
received,
I
think
a
big
part
of
the
feedback
here-
was
that
just
app
specified
docker
files,
even
though
it
solves
a
problem
for
like
ruby
and
node
apps,
that
you
know
require
native
extensions
where
buildpack,
wouldn't
you
know
like
the
the
package
requirements,
are
really
coming
from
the
app
the
build
pack
wouldn't
be
able
to
tell
you
know.
A
Oh
this,
you
know
ruby
app
needs
this
image,
magic
c
library,
you
know-
maybe
a
buildpad
could
do
that,
for
you
know
some
small
number
of
native
extensions,
but
you
know
not
all
of
every
node
module
in
the
world
or
every
ruby
event
world,
so
it
well
it
kind
of
solves
a
problem
for
those
cases.
A
There's
still
use
cases
that
people
care
a
lot
about
that
involve
packages
getting
installed
based
on
the
app
source
during
the
build
process,
and
so
the
updates
I
made
were
an
attempt
to
provide
that
functionality
without
adding
any
complexity
to
the
build
pack
api
at
all.
So
let
build
packs
do
what
build
packs
do
best,
have
them
function
at
the
application
layer
and
then
provide
you
know
kind
of
a
separate
piece
that
you
know
is
responsible
for
stack
customization.
A
The
way
this
works
is
so
I
actually
I've
removed
the
apps.
Let
me
go
to
the
readable
version
easier.
I
removed
that
app
specified
docker
files
feature
entirely,
but
the
builder
specified
docker
files
implement
the
same
feature
with
the
same
ux.
If
you
want
it
to,
and
it
provides
a
way
for
platforms
to
control
whether
app
specified
docker
files
work.
A
So
the
idea
is,
I
just
introduced
a
single
directory
in
the
builder
cnbhooks.d.
This
is
like
a
place
where
you
could
have
executables
that
are
in
this
format.
The
only
accepted
format
to
start
would
be
dockerfile
so
like
an
example,
would
be
cnb
hooks,
and
then
this
one
is
called
app
and
then
this
hub
affects
the
build
image
and
it
outputs
a
docker
file.
A
This
one
is,
you
know,
affects
a
run
image
and
outputs
a
docker
file
in
this
example.
This
this
actually
implements
app
specified
docker
files.
So
these
hooks
run
in
the
context
of
the
app
directory,
and
so
this
just
reads
build.docker
file
and
runs
that
dockerfile
from
the
app
directory
and
provides
it
back
out
and
so
adding
these
hooks
to
the
builder.
B
A
A
dockerfile,
so
these
are,
these
hooks-
are
hooks
that
don't
modify
the
image
when.
A
In
the
context
of
the
app
directory
they
live
on
the
builder
when
you
run
them,
you
know
in
the
with
app
directories
the
current
working
directory,
they
output
a
docker
file
in
the
future.
They
could
output
llb
json.
Instead,
I
left
it
so
there's
like
this
format
field.
So
if
we
wanted
to
it's
like
no
generating
a
docker
file,
is
not
the
you
know
nicest
thing
in
the
world.
Some
people
might
want
to
do
more
complex
things.
Basically,
the
previous
proposal
was,
you
have
a
run.docker
file
and
a
build.file
in
your
app
directory.
A
B
Interesting,
okay,
so
it's
the
format
is
not
the
file
extension.
Essentially,
it's
the
output
format
right.
Okay,
that's
a
little
confusing,
but
I
can't
think
of
alternatives
right
now.
Yeah.
A
A
For
the
app
specified
docker
files-
yes,
it
does,
and
so
we
could.
We
could
specify
that
somewhere
else
that
if
you
have
docker
files
in
your
app
directory,
this
is
how
you
do
it,
but
I
couldn't
figure
out
a
way
to
let
to
not
implement
two
things
to
let
app
developers,
you
know,
specify
docker
files
and
to
let
be
able
to
turn
it
off
easily
and
to
let
people
who
make
builders
create
builders
that
could
have
a
little
more
be
able
to
dynamically.
Install
rpms,
for
instance,
was
the
big
ask.
A
It
does
not,
so
this
is
an
example
where
it
would
have
a
shell,
but
these
can
be
executables
that
are
binary
executables.
They
don't
have
to
be
scripts.
They're,
not
sourced
they're,
they're
executed.
B
What
is
the
order
of
operations?
Is
it
like
file
based
or
file
name
based,
similar
to
other
linux
conventions?
I
think
it
says.
A
A
Yeah,
that's
missing
here.
I
will
add
it
so
the
platform
specified
docker
file
stays
the
same
right.
The
I
updated
these
examples
to
make
more
sense.
So,
like
you
know,
here's
this
is.
This
is
still
the
same
app
specified
docker
file,
but
it
assumes
that
the
app
docker
file
hook
is
present.
A
C
I
think
charles
had
a
couple
of
questions
around
like
so
this
would
be
the
first
time
we
are
bundling
something
in
the
builder:
that's
not
a
lifecycle
or
buildback.
How
would
you
actually
put
them
there
like?
Would
you
put
them
on
the
stack
image
or.
A
I
think
to
avoid
complexities
around
different
operating
systems,
I
think
is
motivation.
The
other
thing
I'm
very
worried
about
is
if
a
build
pack
can
specify
the
dockerfile
hooks,
then,
as
soon
as
any
popular
build
pack
specifies
docker
files
that
install
os
packages,
they
break
rebasing
for
every
app
that
uses
it.
There's
like
no,
we
can't
do
rebasing
and
operating
system
package,
installation
together,
and
so
I
I'm
concerned
about
adding
a
feature
in
the
build
pack
api
that
provides
functionality
that
removes
the
most
of
the
features
of
the
buildpack
api.
A
If
that
makes
sense,
that
removes
the
kind
of
key
you
know,
security
feature
of
the
buildpack
api
at
least
so
the
idea
was
is
that
these
would
be
separate,
they'd
be
more
attached
to
the
builder
itself
than
to
build
packs.
A
Although
you
could
imagine
like
I
thought
about,
maybe
some
interactions
could
be
allowed
like,
because
these
hooks
run
in
the
context
of
the
builder
right
they
could
have
access
to
the
build
packs,
and
so
it
could
be.
You
know
some
builders
could
support.
Reading
information
from
the
build
packs
to
install
operating
system
packages.
I
kind.
C
A
A
B
Is
it
possible
that
this
that
the
that
this
could
actually
happen
after
detect
such
that
you
could?
I
haven't
really
thought
through
this
such
that
you
could
have
a
different
hook
per
group.
So
if
you
detected
the
java
group,
for
example,
you
might
do
one
thing:
if
you
detected
a
python
group,
you
know
loosely
a
python
group.
You
might
do
a
different
thing,
I'm
not
I'm
not
actually
sure.
If
that's
advantageous,
I'm
just
curious.
If
you
thought
through
that.
A
So
the
the
run
docker
file
is
applied
after
detection,
so,
like
emily
said
earlier,
these
would
happen
before
detection
the
hooks
run
before
detection,
but
the
run
docker
file
happens
after
detection
because
of
dynamic
run
image
selection.
If
sorry,
if
dynamic
run,
image
selection
is
implemented,
that's
what
it
would
need
to
apply,
and
so
that
gives
you
some
control
over
the
base
set
of
packages
that
are
used
at
runtime.
A
B
Yeah
yeah
yeah,
I
know
again
I
mean
I
haven't
thought
through
it,
but
my
first
thought
was
like
that
might
be
a
way
to
take
advantage
of
things
like
detect
without
actually
having
the
stack
pack
detect
kind
of
mechanism.
But
I
could
imagine
like
a
python
app
having
very
different
conventions
or
needs
for
doing
this
than
like
a
java
app
or
a
go
app
yeah.
I
don't
know
I
I'll
think
I'll,
read
the
rfc
and
think
through
it.
B
Maybe
that
if
it's
app
specified,
it
really
doesn't
matter
because
then
you're
just
you're
just
specifying
as
an
app
developer,
you're
just
specifying
whatever
you
need,
so
it
doesn't.
It
may
not
make
sense,
but
I
could
definitely
see
like
not
wanting
to
support
that
for
a
java
app
or
something
in
it,
but
supporting
it
for.
A
B
A
I
think
that
some
of
the
feedback
that
I
was
most
interested
in
from
charles
here,
I
think
he
had
just
had
some
questions
about
the
notation
and
things
like
that.
But
there
was
a
good
question
about
rebasing.
So,
like
you
know
what
we'll
work
around
as
rebasing
as
a
key
feature,
I
just
don't
think
it's
possible.
I
think,
is
you
know,
that's
probably
something
to
chat
about
with
charles,
but
you
can't.
D
D
A
A
C
B
B
B
A
Yeah
you
could,
we
could
put
them
on
the
registry,
and
then
you
could
reference
them
in
builder,
tomball
by
registry
locations.
If
you
wanted
to,
you
could
really,
you
know,
create
a
repository
there,
but
I
I
kind
of
feel
like
we
want
to
encourage
people
to
use
the
build
pack
api
as
much
as
possible.
A
Right
hooks
are,
like
a
you
know,
way
to
add
app
developer
features
way
to
add
kind
of
stack
level,
features
that,
let
you
you
know,
sacrifice
a
little
bit
of
performance
for
having
more
tuned
app
specific
base
images,
not
not
a
tool
for
build
tank
authors
to
circumvent
the
build
pack
api,
essentially
as
kind
of
the
reason
for
keeping
them
separate.
So,
like
you
know,
I
they're
an
escape
hatch
that,
like
I
feel
like
putting
them
on
the
registry.
You
know,
making
them
really
accessible,
is
maybe
working
against
the
goal.
B
A
A
Like
pac,
create
builder,
could
you
know
take
like?
I
think
this
makes
the
builder
important
right.
You
could
imagine
an
interface
for
pacquiao
builder,
where
there's
a
flag
you
passed
and
that
app
specified
docker
file
hook
automatically.
Then
the
project
could
provide
that
hook
right.
Those
executables,
the
you
know
create
builder,
could
also
take
the
docker
files
directly.
So
you
don't
have
to
run,
create
stack
on
the
first
right.
It
could
just
be
a
one
stop
command
for
creating
a
builder
for
a
bunch
of
different
languages.
Together.
A
That
would
kind
of
encapsulate
that
interface,
then
it's
it's
no
longer
like
hooks,
aren't
a
feature
that
an
app
developer
would
use
because
they
already
have.
If,
if
they're
supposed
to,
they
already
have
app
specified
docker
files,
they
can
use
to
make
those
configuration
changes
and
then,
if,
if
you're
a
kind
of
platform
level
like
you
know
what
charles
and
aussie
you're
talking
about
with
installing
rpms
and
those
things,
then
this
gives
you
that
functionality
at
the
builder
level,
if
you
really
need
it
at
the
cost
of
you,
can't
replace
anymore.
C
C
A
C
A
No,
no,
no,
the
the
gem
package
of
stuff
is
just
for
when
you
create
a
stack
initially,
that's
the
only
time
when
you
have
to
think
about
gender
packages
and
there
could
be
a
flag
to
create
stack
that
automatically
adds
gen
packages.
It
can
be
a
no
op.
It's
only.
A
A
C
A
It
could
also,
you
know,
replace
the
whole
builder
with
a
different
thing:
yeah
they're,
on
your
own.
You
know
this
is
also
why
it's
really
not
buildpack,
provided
it's
very
much
because
of
the
power
right.
It's
very
much
know
close
to
the
person
who's,
providing
the
stack
or
the
image
itself.
That's
doing
the
build.
It's
it's
again
like
my
model,
for
this
is
basically
what
if
you
could
run
on
build
instructions
in
your
stack,
creating
docker
files,
so
that
when
you
do
a
build,
it
executes
the
on
build.
A
A
Yes,
it
can
do
anything
it
could
it
could
from
you
know,
we
could
do
a
multi-stage
darker
file
and
blow
away
the
entire
original
thing
and
replace
it
with
a
completely
different
image.
As
long
as
it
accepts
the
arc,
it
could
probably
it
could
accept
the
arg
and
then
do
from
something
else
if
it
wanted
to
no
no
restrictions,
you're
responsible
for
maintaining
adult
pack
api.
When
you
use
the
feature,
although
it
you.
A
C
C
Me
so
I
think
the
only
changes
I
made
was
like
an
example
of
how
to
take
an
existing
bomb
and
convert
it
to
the
cyclone
dx
version
for
it.
C
I
I
don't
know
if
we
how,
like
what
kind
of
backwards
compatibility
you
expect
in
terms
of
the
existing
label,
that's
put
out
there
and
like
how
platforms
interpreted
so
the
backwards
compatibility
I
have
here
would
ensure
that
whatever
data
that
build
packs
output
is
preserved,
but
the
structure
of
what
the
output
in
the
final
image
would
be
very
different
than
what
a
platform
currently
expects.
C
So
that
was
like
the
only
open
question
I
had
like
this
would
preserve
the
data,
but
the
output
format
would
be
completely
different.
Is
that
backwards
compatible
enough,
or
are
we
expecting
it
to
even
like
put
the
existing
labels
and
existing
files
of
the
platform,
expects
and
put
these
things
in
separate
places.
D
I
don't
think
if
someone's
using
an
old
platform
api,
we
can
totally
break
the
format
because
people
might
be
relying
on
it,
so
we
might
have
to
do
something
in
the
other
direction
for
older
platform.
Apis
like
take
the
cyclone
dx
stuff
and
stuff
it
all
in
our
existing
metadata,
like
it's
a
little
bit
weird,
but
I
think
it
you
know:
we've
guaranteed,
this
schema
exists
and
people
have
integrations
against
it.
So
I
don't
think
we
can
radically
break
it
for
an
older
api.
C
C
D
Like
you
could
do
what
you're
doing
here,
at
least
with
the
name
and
version
fields
could
could
still
exist,
like
at
least
name
is
something.
Maybe
we
could
extract
from
the
components
and
make
different
entries
for
like
make
one
bomb
for
each
component.
We
find
in
the
cyclone
dx
or
something
like
that.
C
You
could
also
just
put
the
entire
thing
inside
the
metadata
table
like
just
take
the
entire
cycle
on
dxjs
and
put
it
show
it
inside
metadata,
put
the
top
name
as
cyclone
dx
form
and
be
done
with
it.
It
would.
D
C
D
D
But
it's
already
a
little
risky
because
any
build
pack
can
just
change.
However,
it's
structuring
the
data
under
metadata
anyways.
There
isn't
a
lot.
You
can
do
with
it
other
than
sort
of
like
list
the
entries
or,
if
you
know,
you're,
using
a
specific,
build
pack
pull
out
a
specific
data
right,
but
you
know
that
will
still
continue
to
work
until
the
build
pack
upgrades
and
then
that
was
always
what
was
going
to
happen
if
the
build
pack
changes
its
format.