►
From YouTube: Working Group: 2021-08-26
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
I
don't
know
if
amman
has
been
here
in
the
past,
but
I
don't
want
to
call
him
out
either.
C
Yes,
hello,
everyone,
myself
aman,
so
yeah,
I'm
new
to
the
buildback
community
and
I
actually
wanted
to
join
the
office
hours.
But
it's
too
late
for
the
indian
time.
It's
around
11
30
p.m.
Night.
So
just
wanted
to
say
hi
to
all
of
you
and
wanted
to
contribute.
Even
just
now
made
my
first
pr
to
build
packs.
A
All
right,
we'll
jump
right
into
release,
planning
and
updates.
B
I'm
not
prepared
for
this,
but
four
pack
we
did
discuss
it
during
our
sink
that
we
are
going
to
be
releasing
an
rc
next
week
september,
the
1st
and
then
releasing
september
the
8th,
that's
the
anticipated
period.
So
if
there's
anything
that
you'd
like
to
see
going
to
pack
create
a
pr-
and
you
know-
try
to
get
it
in
there
before
that-
those
time
frames.
A
A
On
the
last
issues,
mostly
around
adding
tests
and
validation
for
the.
A
Just
to
talk
through
maybe
some
of
the
remaining
questions,
I
guess
emily
you're
gonna
propose
some
changes.
D
Yeah
I
wanted
to
pr
and
some
changes
to
this
mostly
so
that
we
can
to
sort
of
control
the
life
cycle
of
restoring
the
build
bomb
right
now,
we're
keeping
it
with
the
launch
bomb.
D
But
in
cases
where
layers
are
cached,
but
not
in
the
image,
then
it
might
get
out
of
sync
with
what's
actually
being
restored.
So
I
think
there
are
just
some
logistical
details
around
restoring
this
data
for
on
a
per
layer
basis
that
need
to
be
addressed,
but
I
feel
really
good
overall
about
the
general
structure
of
the
pr
and
just
want
to
work
out
these
gadgets.
D
I
know
also
during
the
core
team,
seeing
terence
had
asked
some
questions
about
the
decision
to
go
ahead
with
multiple
formats
instead
of
one,
which
is
one
of
the
reasons
we
want
to
talk
about
it
today.
But
I
also
don't
see
him
here
to
sort
of
ask
those
questions
so.
D
At
first
I
was
skeptical
about
the
multiple
formats,
but
I've
been
convinced
by
sam's
arguments
that
it's
the
right
thing
to
do.
So
my
approval
is
mostly
just
holding
out
on
some
of
these
boring
gotchas
in
the
life
cycle,
rather
than
sort
of
the
division.
A
All
right,
I
guess,
does
anybody
know
if
terrance
plan
to
attend
part
of
this
or
maybe
we'll
skip
it
and
defer
to
the
next
sink.
B
I
do
have
a
very
minor
comment
or
question:
it
has
to
do
with
one
of
the
open
questions
talks
about
stacks
and
the
way
I'm
reading
this
rfc
is
that
it's
very
specific
to
the
build
packs
provided,
s-bomb
functionality
right
and
one
of
the
things
that
I
believe
I
saw.
I
can't
pull
it
up,
I'm
getting
the
unicorn
for
the
other
rc,
but
so
I
believe
that
one
makes
mention
to
like
s-bombs
as
well-
and
I
guess
maybe
my
my
question
is
more
revolving.
D
I
can't
speak
for
exactly
what
sam
was
imagining,
but
I
think
if
we
figure
out
a
structured
s
like
right
now,
we
don't
have
a
way
for
stacks
to
contribute
to
the
s
bomb.
So
I
think
we
could
do
this
rfc,
so
we're
moving
our
existing
s-bom
functionality
into
a
more
useful
format
and
then
from
there
it
would
be
easier
to
layer
in
the
stack
changes
in
a
separate
rfc.
D
And
then,
if
we're
talking
about
sort
of
this,
remove
stacks
and
mixins
rfc,
which
is
discussing
like
potentially
validating
a
rebase
using
the
s-bomb
according
to
steven's
rc.
That
is
not
something
the
life
cycle
would
do,
but
it
leaves
open
the
idea
that
platforms
could
choose
to
do
that
to
provide
extra
safety,
and
it
might
be
something
that
we
would
like
pack
to
do.
B
All
right,
yeah,
okay,
we
could
discuss
this
there,
but
it
sounds
like
we're
still
kind
of
holding
up
on
that
a
little
bit
or
it's
up
in
the
air
all
right.
It's
good
with
that.
A
Just
so
I
understand
reading
over
this,
it
doesn't
seem
like
it
talks
about
how
you'd,
like
start
with
the
s-bomb
of
a
stack
of
a
build
time,
run
image.
I
guess
and
then
extend
it
with
the
s-bom
metadata
coming
from
the
build
pack.
So,
in
the
end,
I
don't
know
if
we'd
end
up
with
a
valid
s-bomb,
I
didn't
realize
it
was
missing
that
that
part
is
that
the.
D
D
B
D
D
A
I
got
the
unicorn
okay,
let's,
let's
try
again,
I'm
I'm
assuming
it's
a
docker
file.
One
then.
A
So
I
think
I
recommended
we
talked
about
this
one,
I'm
mostly
just
looking
for.
A
Approvals
or
any
additional
comments,
if
people
you
know,
have
different
ideas,
I
think
joe,
you
had
some
comments
in
there
about
the
api
version
and
about
yeah.
Sorry,
god.
E
Yeah
I
originally
had
some
concerns
about
the
hook
construct,
but
the
way
you've
changed
it.
I
really
like
it.
I
think
it's
very
approachable.
E
The
one
thing
so
I
would
approve
the
rc
is,
is
the
one
thing
I
feel
we
could
maybe
do
better
at
and
maybe
I'm
just
being
like,
maybe
I'm
carrying
too
much,
but
the
hook
like
the
hook
tommel
and
then
even
the
name
hook.
E
I
feel
like
I
don't
know,
there's
something
about
it
that
I
feel
like
we
could
do
better,
and
but
I
don't
have
any
suggestions
for
improvements,
so
I
I
wanted
to
think
about
it,
some
more
and
see
if
anybody
else
had
thoughts
on
you
know,
there's
basically
it's
so
close
to
build
pack
and
build
pack
tommle
that
it
feels
like.
Oh,
why
do
we
need
to
even
introduce
a
new
file
format
and
all
that?
But
I
don't
I
don't
see
any
other
way
really
so.
E
God
yeah,
I
said
the
name
like
is
fine.
I
guess
like
I
would
have
gone
with
extension
or
something
like
that,
but
I
don't
care
it's
more,
that
it's
like
really
really
close
to
build
pack,
and
it
just
makes
me
wonder
if
there's
anything
else,
we
can
do
to
to
make
it
one
less
thing
you
have
to
learn.
Well,
like
I
said
I
would
approve
it,
as
is.
A
A
E
E
I
do
like
the
new
hook,
tommle
and
stuff
better
than
the
previous
iteration.
I
feel
like
I
feel
like
the
near
parity
with
build
pack
is,
is
a
virtue,
so.
B
Yeah,
so
it's
been
a
while,
since
I
looked
at
this
rfc,
could
you
explain
why
that
change
occurred?
Like
I
guess
to
me
at
this,
you
know
like
at
first
glance.
It
looks
like
it's
a
little
bit
more
complex
right
because
it
adds
this
sort
of
idea
of
things
that
sort
of
look
like
build
packs,
but
they're
called
hooks,
and
then
they
have.
It
looks
like
binaries
very
similar
to
build
packs
with
the
detect
and
the
build
that
then
ultimately
produce
or
create
docker
files.
B
A
What's
the
absolute
simplest
thing,
we
could
do
and
then
work
that
into
you
know
something
that's
close
to
stack
packs,
but
you
know
is
driven
out
use
case
by
use
case
and
avoids
complexity
for
each
of
those
use
cases
right,
and
so
what
we
ended
up
with
is
something
that
is
close
to
stack
packs
but
different
in
some
very
specific
ways
that
I
think
we
figured
out
along
the
way,
and
so
one
of
those
was
the
instead
of
we,
a
lot
of
the
complexity
of
the
previous
api
came
from.
A
We
wanted
the
stack
packs
to
modify
the
images
as
they
run
and
that
that
created
a
lot
of
restrictions
like
we
need
to.
You
know
we
can't
have
the
app
directory
there.
We,
you
know,
like
all
the
dependencies
of
the
things
when
they
get
applied
to
the
images,
have
to
be
there
as
they're
getting
applied
to
the
image
and
so
by
having
them
generate
doctor
files
like
just
the
instructions
for
it.
We
can
apply
those
things
afterwards
and
those
dependencies
don't
have
to
be
there
while
they're
executing.
A
A
You
know
slightly
two
slightly
different
versions
of
the
stack
pack
on
on
multiple
different
images.
The
you
know,
another
big
change
is
instead
of
saying
we're.
Gonna.
Do
we're
gonna,
try
to
replay
changes
for
rebase
instead
we're
going
to
let
the
author
of
the
hook.
I
guess
in
this
case
declare
whether
or
not
you
can
rebase
out
from
under
what
the
hook
is
doing.
So
if
you
only
modify
things
dropped,
you
know
it's
safe
to
rebase
rebase.
This
happens
immediately.
A
So,
at
least
those
are
the
changes
coming
from
the
stackpack
perspective
to
what
this
looks
like,
what
were
you
asking
about
that,
or
are
you
asking
about
changes
from
some
point
in
the
what
the
hooks
rfc
used
to
be
to
this
point.
B
I
mean,
I
think,
everything
that
you
just
explained
was
definitely
insightful
and
beneficial.
To
my
understanding,
the
I
guess
one
question
that
is
still
in
the
back
of
my
mind
that
I'm
not
sure
I'm
gathering
explicitly
is
when
are
the
doctor
files
themselves
actually
executed
in
the
whole
process.
A
A
The
docker
files
extend
the
build
image
and
the
run
image,
and
then
the
build
pack
build
process
happens
if
that
creates.
If
extending
the
build
process
creates
a
new
builder
or
if
it
could
be
implemented,
such
that
extending
the
build
image
you
know
runs
directly
on
top
of
the
builder
and
modifies
the
builder
live
and
then
the
layers
it
generates
are
cached
somewhere.
It
could
be
implemented
with
build
kit
locally,
to
actually
extend
the
builder
image
directly
and
then
the
next
step
happens
on
a
new
image.
A
B
Yeah
and
then
the
other.
This
is
more
or
less
just
a
comment.
B
So
there's
a
lot
of
files
that
are
somewhat
being
reused,
file
names
that
are
being
reused
from
buildpacks,
but
they
have
a
lot
of
caveats
of
things
that
they
don't
support,
and
I
could
definitely
envision
a
lot
of
confusion
on
sort
of
the
context
in
which
a
file
is
present,
and
I
think
we've
seen
that
for
a
lot
of
different
files
that
we
have
like
build
package
or
sorry,
the
package
tamil
versus
the
build
pack
tunnel
and
that
sort
of
stuff.
B
Yeah,
I
mean
those
less
so
because
they're
not
configuration
files,
but
if
I
were
to
like
google
right
or
go
to
our
website
and
say
I
want
to
look
up
what
a
buildup
tomorrow
or
launch.
looks
like
now.
I
have
oh,
are
you
talking
about
in
hooks
or
are
you
talking
about
in
a
build
pack?
And
now
I
have
to
know
the
difference
of
the
context
in
which
I'm
looking
at
these
files.
A
I
think
the
files
are
really
similar.
I
can't
load
the
maybe
I
can
load
the
files.
Let's
see
in
a
minute,
I
might
be
able
to
see
what
the
files
look
like,
but
actually
there
we
go.
So
what
restrictions
are
we
talking
about?
A
Yeah
build
args,
that's
right,
so
yeah
so
they're
similar
in
that
they
hold
the
s-bom
information
right.
They
had
that
same
interface
for
capturing
s-bomb
information.
It's
just
the
launch,
one
doesn't
have
you
know,
processes
and
slices,
and
they
both
get
args
are
exist,
build
args
for
the
docker
file.
So
you
don't
have
to
templatize
your
docker
files,
just
feedback
from
sam.
You
can
just
put
builders
in
common
and
they'll
inject
it
automatically.
A
A
On
the
other
hand,
you
know,
I
think
I
agree
that
you
know
it's
confusing-
to
have
the
same
file
with
different
con.
You
know
in
really
different
contexts.
It
kind
of
feels
similar
about
been
build
and
been
detected,
because
those
also
have
very
similar
interface.
But
you
know
the
app
directory
is
read
only
and
you
know
the
there's
just
some
small
different,
the
layers
directory.
You,
output,
docker
files
instead
of
outputting
layers
right.
D
Well,
we're
talking
about
naming
I've
been
thinking
about.
So,
first
of
all,
I
don't
like
hook.
I
feel,
like
it's
evolved
enough,
that
it's
not
a
hook
and
it's
confusing,
and
I
also
agree
that
we
shouldn't
just
go
with
build
pack.
I
think
the
fact
that
we
called
what
I'll
call
meta
or
multi-build
packs,
also
build
packs,
has
actually
been
persistently
confusing
when
we
tried
to
explain
to
people
what's
going
on,
especially
because
we
did
not
canonicalize
either
of
those
terms
in
the
spect
to
refer
to
them.
D
C
D
C
A
Is
that
we
shouldn't
invent
more
words,
we
have
too
many
words
made
up
words
already,
and
the
other
is
that
which
is
very,
you
know
like
I'm,
not
I'm
not
super
attached
to
that,
but
the
other
is
that
I
do
think
of
the
meta
build
like
to
me.
A
So
I
to
me,
I
like
that
those
two
things
are
called
build
packs,
but
I
agree
that
this
thing
is
not
a
build
pack,
because
you
can't
use
it
in
all
those
places.
It's
the
places
you
can
use.
This
are
very
different,
but
I
don't
think
we
should
make
up
a
new
word
for
it.
If
that
makes
sense.
First
of
all,.
E
Just
with
meta
build
packs,
I've
actually
had
the
opposite
experience
just
anecdotally
that
I
think
it
helps
people
understand
it.
I
agree
that
we
don't
have
it
defined
well
and
that
has
been
challenging
for
people,
but
I
think
it
clicks
very
very
quickly
based
on
what
it
is,
and
I
went
down
this
exact
same
line
of
thinking
as
you
like.
Is
it
the
hook
pack?
This
is
the
base
pack
but
yeah.
I
think
I
kind
of
landed
where
stephen
said.
D
Hooks
also
don't
make
any
sense
like
if
someone
says
this,
there
are
hooks
that
you
can
add
to
the
life
cycle
or
you
can
insert
hooks
into
your
building.
I'm
imagining
something
really
specific
that
isn't
this
right.
A
D
D
A
D
A
A
It's
like
a
consistent
thing
that
can
do
arbitrary
things,
because
they
can
make
arbitrary
changes
to
the
base
image
that
you
know
build
packs
can't
make.
They
could
replace
the
whole
base
image
with
something
else
right.
They
have.
They
do
have
that
quality
to
me,
but
I
agree.
It's
not
a
perfect
analogy.
C
Yeah,
I
like
the
word
extensions
better,
like
exts,
but
I
don't
know
like
you
know
it
kind
of
reminds
me
of
like
a
kernel
extension
like
you
said
it's
sort
of
like
something
that
everything
that
built
off
this
builder
probably
gets
and
yeah.
I
did
have
one
question.
I
can't
comment
on
github
because
it's
busted
but
I'd
like
to
see
an
example
that
uses
the
provides
the
way
that
you've
described
it.
C
I'd
like
to
kind
of
understand
like
what's
the
purpose
of
having
provides
in
the
anyway
it's
just
kind
of
hard
to
understand
what
that.
What
the
examples
are,
because
there's
not
an
example
of
ben
detect
that
I
know
of
and
that
I
see
currently.
A
The
use
case
for
provides
this
originally
didn't,
have
any
build
plan,
interaction
or
was
like
very
separate
from.
There
was
at
least
two
or
three
iterations,
where
it
was
still
very
separate
from
the
build
pack
api,
and
I
was
convinced
to
add
that
and
also
to
switch
the
interface
to
bin
build
and
then
detect,
based
on
some
use
cases
where
folks
want
to
build
packs
later,
to
be
able
to
say
these
are
the
things
I
need
these.
A
So
the
way
provides
would
work
is
like.
If
you
had
a
you
know,
app
build
pack,
it
could
provide
package
installation
and
later
build
packs
could
require
that
these
packages
get
installed
or
something
like
that.
If
you
had
a.
C
A
C
A
That
right,
yes,
that's
right!
You
couldn't
you
couldn't
use
this
to
make
base
image
extensions
that
are
that
the
build
pack
detected.
F
Is
it
running
after
the
tech
phase,
a
big
I
feel
like
that
removes
potentially
stuff
like?
Oh,
I
want
to
install
jq
because
it's
on
the
stack
image
or
something
like
use
case,
which
we've
seen
a
lot
over
here,
so
you're,
still
kind
of
forced
to
basically
put
all
those
things
in
the
stack.
I
guess
beforehand.
A
The
original
version
was
like
that,
but
I
got
blocked
by,
I
think,
there's
feedback
from
charles
and
then
also
from
some
folks
at
google
that
they
really
need
their
build
packs
to
be
able
to
affect
which
operating
system
packages
get
installed,
and
so
then
we'd
have
to
create
another
pre-detect
phase
that
happens
before
the
normal
detect
phase
have
two
two
executions
of
something
like
a
build
plan
in
a
row.
I
you
know.
I
think
it
would
be
really
hard
to
figure
out
how
that
would
work,
but
we.
D
Can
only
solve
one
problem
like
either
installing
dependencies,
so
they
can
be
used
during
detect
or
like
using
detect
to
figure
out
which
dependencies
need
to
be
installed.
I
think
that
second
problem
has
a
much
broader
set
of
people
who
want
it
and
use
cases
for
it
in
general.
I
think
it
should
be
possible
to
have
a
detect
script
that
runs
with
as
few
dependencies
as
possible
and
if
you
really
need
something
like
jq
like
the
pillpack
author
could
vendor
it
into
the
build
pack
or
something
if
they
really
wanted
to.
B
C
A
And
if
there's
nothing
else
on
this,
I
actually
want
to
go
back
to,
because
now
we
have
terrance
here
on
s-bomb.
I
think
terence,
who
had
some
feedback
about
multiple
formats.
Should
we
should
we
go
back
to
that
for
a
minute.
F
A
So
the
feedback
there
was
just
you,
you
had
some
concerns
about
supporting
multiple
s-bomb
formats.
Initially,
do
you
want
to
talk
about
that?
A
little
bit.
F
I
mean
it's
probably
similar
to
your
original
comment
on
the
rfc,
but
I
mean
I
get
the
ecosystem
thing,
but
also
also
just
like
more
choice
and
more
support.
I
think
potentially
just
also
just
makes
it
more
challenging
because
we
still
it's
not
like
we're,
also
ditching
the
original
bond
format,
either
right
like
that,
that's
there
for
backwards
compatibility,
and
so
we
have
yet
another
thing,
and
I
mean
I
guess
if
people
feel
super
strong
but
like
what?
What
do?
What
do
people
do?
F
I
guess
with
like
kind
of
the
bombs
after
the
fact
and
kind
of
what's
the
expectation
on
the
project
to
kind
of
provide
a
thing,
that's
useful
to
kind
of
be
used,
and
then
I
guess,
an
ecosystem,
which
is
probably
something
we
care
about.
A
lot
at
like
broken
sales
forces
like
if
we
pull
in
third-party
build
packs
right
and
someone
uses
basically
spx,
but,
like
our
entire
thing,
uses
cyclone
dx
like
do
you
pull
the
do?
F
You
merge
everything
that
is
cyclone
dx
and
then
also
provide
the
like
one,
build
pack
or
two
build
packs
that
are
sgx
separate.
You
know
individual
ones
like,
I
feel,
like
kind
of
really
hurts
kind
of
the
advantage
of
having
and
favoring
something
like
cyclone
dx
the
moment
you
kind
of
have.
I
mean
you
already
have
this
problem
for
the
non-sbom
case,
which
is,
if
they're
using
the
existing
thing,
but
I
do
feel
like
it
does
like
anytime
you
you
have
like
that
one
that
does
not
conform
like
it.
A
I
I
agree
you're
like
I
by
all
of
those
arguments.
That's
that's.
You
know
I
put
that
in
the
issue.
At
some
point,
I
think
if,
if
the,
if
cyclone
dx
had
you
know
general
consensus
that
it's
the
you
know
direction,
people
are
going
to
move
eventually,
especially
if
it
were
easy
to
convert
between
different
formats,
then
I
would
agree
completely.
I
would
say
that's
what
we
should
do.
A
Some
of
the
things
sam
brought
up
just
because
he's
done
a
lot
of
research
on
what
are
the
different
formats,
who's,
supportive
of
them
who's
using?
What
for
what
is
that
they're?
Both
they're
different
groups
are
entrenched
in
both
both
of
those
different
formats.
You
know
cyclone
gs,
cat
dx
has
olasp
and
a
lot
of
security.
Vendors
on
board
spdx
has
a
lot
of
large
open
source
projects
on
board,
as
pdx
is
like
really
is
used
heavily
in
like
open
source
compliance
licensing
and
that
stuff
and
supports
some
features
that
cyclone
dx
doesn't
cyclon.
A
Dx
supports
a
bunch
of
security
features
around
provenance
and
things
that
spdx
doesn't,
and
so
people's
use
cases
for
the
two
differ
a
lot,
and
sometimes
people
will
only
be
able
to
use
one
or
only
be
able
to
use
the
other
they're,
not
as
convertible
as
like.
Yes,
you
can
convert
like
maybe
five
or
six
fields
of
a
cyclone
dx
s-bomb
per
entry
into
something
that
you
know
is
that
into
spdx
format,
but
it
doesn't
it
it.
Doesn't.
It
can't
like
if
people
are
using
spdx
do
anything
more
advanced
than
something
very
simple.
B
A
Works
in
simplest
case,
if
that
makes
sense,
there's
there's
not
a
way
to
convert
from
spdx
to
cyclone
dx
reliably
in
that
direction
at
all,
so
the
they're
two
competing
things,
it's
very
hard
to
tell
which
will
win
some
days
like,
depending
on
who
I
talk
to,
I
feel
like.
Oh,
yes,
clearly,
we
should
do
one
or
the
other
one.
If
that
makes
sense,
you
know
if
I'm
talking
to
people
who
are
more
kind
of
secure,
I
don't
know
how
you
describe
that
more
security
focused.
Then
you
know
spdx
tends
to
be
the
preference.
A
F
A
D
To
the
build
pack
api
that
sort
of
like
it
tells
a
build
back
which
format
to
use
and
when
someone
runs
a
build,
they
can
pick
which
format
and
then,
if
a
build
pack
does
not
support
a
format.
Sort
of
like
your
build
fails,
if
which
might
be
good
anyways.
I
think
right
now,
it's
very
hard
to
know
whether
all
your
build
packs
are
contributing
to
the
bomb
or
not.
It
might
be
good
if
like.
If
you
want
the
bomb,
it
might
be
good
if
the
build
fails.
F
D
A
I
I
don't
think
our
our
format,
because
we're
talking
about
json
for
both,
I
don't
think
our
format-
is
any
different
than
if
you
took
a
bunch
of
spdx
and
cyclin
dx
entries
and
put
them
next
to
each
other,
because
we
didn't
standardize
the
contents
of
any
of
the
entries.
And
what
we're
talking
about
here
is
the
contents
of
the
entries.
B
But
then
it's
either
all
the
build
packs
that
were
used
to
do
the
build
used
spdx
or
they
all
used
cyclone
dx
and
you
get
like
a
really
nice
output
or
if
there's
a
mix
match
you
could
have
something
that
essentially
merges
them.
You
know,
but
then
you
only
have
two
formats
to
deal
with,
as
opposed
to
an
undefined
amount
per
build
pack
right.
A
It's
like
you
can't
merge
spdx
and
you
can't
reliably
really
reliably
convert
in
either
direction,
and
so
the
artifact
you
end
up
with
at
the
end
is
a
oci
image
and
cosines
s-bom
format
that
has
a
bunch
of
different,
separate
s-bombs
in
it
that
contains
all
the
s-bombs
anything
ever
output,
if
that
makes
sense
and
that
so
that
would
either
be
spdx
per
layer
for
layers
to
output,
spdx,
cyclone
per
layer
and
then
merge
cyclone
and
then
eventually,
if
we
can,
if
somehow,
if
somebody
want,
if
we
come
up
with
an
interface
for
providing
logic
that
lets,
you
merge
the
spdx
things
which
you
can't
do
in
an
automated
way
right
now,
then
you
know
you
could
have
a
joined
spdx
s-bomb
also,
but
you
do
get
one
artifact.
A
That
has
everything
in
it.
At
the
end.
B
A
F
F
D
C
It
is
kind
of
asking
platforms
to,
but
if
your
platform
is
fully
open
to
any
build
pack,
I
I
find
this
like
almost
impossible
to
really
like
present
to
produce
anything
that
you
know
like
if
this
was
on
heroku
today,
like
no
one
bill
packs
are
coming
from
all
over
the
place
and
those
buildback
authors
are
not
are
not
doing
this,
and
maybe
that's
just
the
wrong
target
thing,
which
is
why
I'm
mostly
staying
out
of
it,
but
the
yeah.
I
don't
know
it's
like
our
bill
pack.
C
Author
is
going
to
do
both
of
these
formats,
who
are
not
like
a
part
of
a
mega
corp.
I
don't
know.
I.
E
Doubt
it
yeah.
I
totally.
I
totally
agree
with
that
and
I
think
initially
that
was
a
concern
of
mine,
but
I
think
on.
If
it's
really
as
open
as
heroku,
you
can't
do
anything
because
people
are
just
I
mean
the
bill.
Pakistan
could
lie
to
you,
they
could
not
do
it
at
all
right.
So
I
think
at
that
point
it
might
just
be
like
nope.
It's
on
end
users
to
figure
it
out.
D
E
C
F
D
A
Maybe
a
more
philosophical
argument
for
why
we
should
support
both.
It's
like
something
we've
talked
about
before
is
like.
Sometimes
we
treat
the
project
as
if
we're
building
one
platform
that
runs
build
packs,
but
we're
really
building
tools
and
specifications
for
how
to
do
different
things
with
build
packs
and
so
something
that
kind
of
changed
my
mind
that
made
me
feel
like
we
should
do
both
is
that
you
know
I
don't
know
if
it
makes
a
lot
of
sense
for
this
kind
of
like
generic
way
of
building
containers,
to
express
a
hard.
A
You
know
an
opinion
that
no
all
s
problems
may
be
in
this
group's
particular
format.
That
is,
you
know
not
necessarily
widely
accepted
right
compared
to
you
know
the
other
formats.
I
think
a
platform
that
implements
build
packs
could
say
yes,
one
or
the
other.
If
that
makes
sense,
could
enforce
that.
You
know.
No,
we
don't
run
build
packs
here
that
are
as
pdx,
but
it
it
feels.
A
It
does
feel
a
little
weird
to
me
to
say
that
we're
you
know
our
specif
with
build
packs,
you're,
never
able
to
generate
s-bomb
in
any
other
format,
except
for
this
one
right,
because
you
know
we're
really
trying
to
build
tool,
tools
and
specifications
for
building
container
images
that
solve
problems
in
a
certain
way,
not
on
a
highly
opinionated
platform
for
doing
that.
But
that
doesn't
mean
that
platform
couldn't
exist.
It
just
means
that
I'm
not
I'm
not
super
convinced
that
that
should
be
how
it's
the
right
place
to
express
the
opinion.
C
I
agree
I,
but
I'm
a
little
the
other
way
where
I
think
like
I
rather
almost
have
like
a
band
slash
s
bomb
where,
like
every
bill
pack
can
contribute
whatever
they
want
to
s
bomb
and
we
just
kind
of
slurp
that
up
and
put
it
somewhere
and
then,
if
there's
another
hook,
that
we
need
to
write,
so
they
can
potentially
merge
them
yeah.
But
I
know
that
that's,
like
you
know,
we've
already
sort
of
had
that
discussion
and
that's
fine,
but
that's
kind
of
where
I'm
at
like.
B
So
I
know
we're
running
out
of
time,
but
I
was
very
interested
on
the
last
rfc
the
project
descriptive
one.
I
do
wonder
if
maybe
we
could
take
that
on
to
office
hours
after
the
community
speaks.