►
From YouTube: Working Group: 2021-08-19
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
Remember
to
sign
in
on
the
document.
If
you
haven't
already
definitely
see
folks
who
haven't,
do
we
have
sorry
jessica
didn't
mean
to
volunteer
you
there?
I
just
copy
pasted
that
do
we
have
a
volunteer
to
take
notes
today,
or
should
we
just
try
to
write
things
down
as
they
come
up.
B
I
think
I'm
a
fan
of
just
taking
notes
of
like
action
items
or
you
know
important
notes,
not
a
full
scribe.
So
I
think
if
we
I'll
work
on
that
that'll
be
good
enough
sounds.
A
A
I
think
I've
seen
everybody
before
so
move
on
to
so
today.
We're
gonna
do
something
a
little
different
for
the
first
30
minutes.
We're
going
to
do
a
roadmap
review
based
on
the
road
map
review
kind
of
first
part
of
a
real
map
review.
We
did
at
the
core
team
sink
oops
yesterday
we
are
right
there,
the
and
then
for
the
rest
of
the
meeting.
We'll
just
do
the
normal
working
group
meeting
and
talk
about
rfcs.
C
D
And
then
implementation
side,
I
think
it's
it's
a
similar
story.
We
had
our
sub
team
sink
yesterday
and
we
decided
that
we're
gonna,
try
and
see
if
we
can
get
arm
support
in
the
next
release,
because
it
might
be
very
close.
E
In
the
last
bat
theme,
sync,
we
went
over
the
redesign
document
for
the
new
version
of
lip
cnd.
Let
me
try
and
find
the
link
for
that.
E
A
B
Yeah,
so
I
put
this
on
here,
proposing
this
be
added
to
the
the
road
map
and
and
what
I
have
in
mind.
Right
does
kind
of
tie
into
the
registry,
but
at
a
high
level
right
it's
about
discoverability,
it's
about
from
a
app
user
or
sorry
a
user's
perspective
them
wanting
to
say.
Okay,
I
want
to
build
a
java
application
right.
What
build
packs
can
I
use
like
they
can
go
to
the
registry
right
now,
but
then
that
tells
them
what
build
packs
they
can
use,
but
it's
not
really
cohesive.
B
To
tell
you,
okay,
this
is
the
builder
that
you
select,
and
these
are
the
stacks
that
you
can
choose
from
that
sort
of
information
isn't
yet
available.
So
it's
that
piece
that
I
feel
is
missing
and
there
does
seem
to
be
some
traction
behind
it,
but
we're
not
putting
enough
focus
on
it
in
my
mind
that
as
much
as
we
should
at
least
that's
my
opinion.
F
A
F
Go
ahead,
I
think
this.
The
stacks
are
there,
but
I
feel
like
stacks
are
not
sufficient
information
to
do
anything
with
it's
more
like
here
we
go
the
builder
yeah,
I'm
not
sure
if
you're
driving
anything
specific
but
like
definitely,
I
think
the
builders
have
a
place,
I'm
not
sure
if
going
from
a
build
pack
to
a
builder.
F
Well,
I
guess
if
builders
are
a
first
class
thing,
we
could
like
cross
reference
or
cross-link
those
without
people
providing
information
right.
So
we
could
say
if
people
register
their
builder,
then
we
could
add
a
list
of
builders
for
the
build
pack
without
anybody
else
providing
other
information
so
yeah.
It
seems
like
part
and
parcel
with
having
builders
in
the
registry.
F
B
And
then
there's
details
on
how
we
could
improve
like
the
association
right
between
builders
and
build
packs
and
how
to
make
it
more
easily
usable,
but
I
think
at
least
for
me
it's
that
aspect
right.
It's
how
easy
is
it
for
the
users
to
say
I
want
this
and
then
go
to
the
registry
and
find
it,
and
I
think,
right
now,
it's
almost
near
impossible,
like
they
need
a
lot
of
hand
holding
and
investigating
where
that
shouldn't
be
the
case
right.
A
A
lot
of
builders
are
language
specific,
and
so,
if
you're
like,
you
wanted
to
find
a
builder
to
build
your
java
app
right.
That
might
be
the
more
useful
thing
than
finding
a
bunch
of
build
packs
that
you
could
use
together
to
build
your
java
app
and
their
associated
stacks,
and
all
that.
So
I
definitely
support
that
making
builders
more
accessible
to
the
registry.
F
Yeah
I
mean
I
do
too,
I
think,
like
the
heroku
build
pack.
Design
is
a
little
bit
different
like
in
that
the
heroku
java
build
pack
is
I'm
at
a
build
pack
with
all
the
various
build
packs
that
go
into
it,
but
yeah
definitely
get
the
water
is
getting
muddy
like
if
you
search
java,
you
end
up
with
a
bunch
of
like
the
finer
grain,
build
packs
that
are
the
package
stuff
and
it's
hard
to
know
what
to
do
with
them.
B
Yeah
we
didn't
know
like,
I
guess
what
I
envision
is
you
search
for
java
right
and
then
it
brings
up
a
whole
bunch
of
stuff,
but
it
didn't
know
it's
like.
Okay,
these
are
builders.
This
is
a
meta
build
pack.
This
is
a
regular,
build
pack
right
and
then
you
can
filter
out
and
yeah.
Maybe
we
have
priority
for
some
things
over
other
types,
but
then
you
know
again.
B
F
But
I
think
the
idea
for
like
for,
like
the
heroku
java
build
pack,
you
know,
like
obviously
like
the
the
heroku
buildpack
design,
I
think
was
kind
of
created
as
though,
like
you,
like,
the
builder,
was
just
a
detail
and
the
unit
of
distribution
was
the
meta
build
pack.
So
the
instructions
here
are
like
complete
in
the
sense
that
this
would
work
with
any
of
the
supported
stacks.
So
you
would
you
could
create
your
own
builder
with
this
build
back
or
you
know
or
whatever
you
don't
need
a
builder
and
that's
fine.
F
F
Oh
yeah,
okay,
sorry,
so
I
don't
think
it
needs
to
be
like.
I
think
this
is
something
that
we
can.
It
seems
like
smaller
in
size
than
a
lot
of
our
other
roadmap.
Stuff
like
this
is
definitely
something
we
can
work
towards,
even
if
it's
not
on
the
roadmap,
so
I
guess
I'm
fine
with
it,
but
it
might
make
sense
as
like
a
sub
thing
of
a
more
north
star
type
road
map
item.
I
don't
know
if
we
have
anything
like
that,
but.
B
That's
why
I
was
proposing
discoverability
right
or
user
journey
or
something
along
those
lines.
Maybe
I
don't
know
if
you
would
want
to
put
it
under
documentation
right,
but
and
the
reason
why
I
propose
for
it
to
be
on
the
roadmap
is
again
because
I
think
we've
all
mentioned
what
we've
stated
here,
but
we
haven't
put
enough
focus
on
it
and
I'm
proposing
that
we
do
put
that
focus
on
it.
A
I
think
I
agree
that
it's
that
getting
started
experience
can
like
it's
very
impactful
right
people
hear
about
the
project
they
go
to
the
website.
If
they
can't,
you
know,
figure
out
how
to
use
it
and
understand
it
in
a
short
period
of
time,
they're
not
going
to
engage,
but
it
to
me
it
maybe
still
goes
under
documentation,
and
it's
just
you
know.
Maybe
we
need
to
clarify
that
documentation
doesn't
just
mean
you
know,
command
line
arguments
and
things
like
that,
but
really
that
that
full
getting
started
experience.
C
D
If
we're
expanding
the
scope
of
that
first
item,
there's
also
the
the
intro
video
that
yeah
has
done
a
lot
of
work
on
to
try
to
better
explain
what
build
packs
are
at
the
first
kind
of
point
of
contact
that
that
might
be
something
that
furthers
that
goal
as
well.
E
A
So
maybe
the
outcome
is
rename
documentation
to
be
more
inclusive
of
discovery
and
onboarding
efforts.
A
Sounds
good
three,
two!
Oh
sorry
for
people
who
didn't
attend
last
time,
thumbs
up
means
you're.
Okay,
with
I
guess
in
this
case,
you're.
Okay,
with
the
decision
want
to
move
forward
with
the
thumbs
down.
Is
you
have
questions
or
or
think
we
should
keep
talking
about
it?
Three
two
one.
A
C
I
put
this
on
here
because
I
feel,
like
we've
spent
some
time
this
year,
just
talking
about
governance,
kind
of
expanding,
trying
to
push
more
towards
sub-team
rfcs.
There
is
the
talk
of
that
ben
brought
up
of
the
we
haven't
done
it,
but
there's
been
discussions
of
potentially
laying
the
groundwork
for
the
kind
of
toc
slash
like
governing
board
kind
of
discussions
and
then
also
just
the
change
in
kind
of
the
meaning
structures,
and
things
like
that
of,
I
feel
like
there's,
just
been
a
focus
on.
C
Maybe
it's
not
governance,
but
just
like
kind
of
just
restructuring
the
project
to
be
less
a
single
point
of
failure
on
the
core
team
level.
A
C
C
A
Is
that
kind
of,
like
you
know,
cool,
to
get?
I
guess
more
contributors
into
the
project
from
you
know
more
than
three
or
four
companies
part
of
that
item,
or
is
it
really
just
more
around
the
governance.
C
I
would
expand
it
probably
to
that,
like.
I
think
the
efforts
that
folks
on
the
project
have
done
with
mentorship
and
other
things
of
growing
the
project
is
a
big
reason
to
do
these
changes
right,
but
whether
that
should
be
real
map
item
or
not,
is
you
know
potentially
up
for
debate,
but
I
think
we're
gonna.
Do
it
regardless.
A
Trying
to
think
of
how
to
describe,
I
think,
have
a
good
grasp
of
what
you
mean,
but
what
the
title
be.
It's
like!
It's
not
adopters.
It's
not
exactly
growing
the
contribution
team.
That's
like.
B
For
me,
I'll
be
honest,
it's
still
a
little
unclear
as
to
whether
or
not
this
is
worth
adding
to
the
roadmap.
Just
because
I
feel
like
it's
always
continuously
going
to
happen,
and
I
don't
feel
like
there's
been
a
lack
of
effort
there
and
but
maybe
that's
just
my
driving
force
as
to
why
it
would
be
added
to
the
road
now.
C
I
I
just
think
it's
a
thing
that
we've
put
more
time
and
attention
to
potentially
this
year
than
we
have
in
the
prior
two
years.
I
won't
be
super
sad.
If
we
don't
add
it
like
is
I
mean
not
a
hill,
I'm
trying
to
put
out
there
because
I
agree
like
I
think
we
will
continue
to
do
it,
but
I
kind
of
just
want
to
call
out.
C
A
We'll
take
a
vote
and
see
what
people,
what
people
think
all
right,
three
two
one
sorry
thumbs
up
for,
I
should
explain
first
thumbs
up
for
yes,
this
should
go
in
the
roadmap
thumbs
down
for
no,
we
should
keep
talking
about
whether
it
belongs
the
roadmap
or
you
don't
think
it
should
go
on
it.
A
All
right
folks
who
voted?
No,
you
want
to
start.
A
A
One
trend
there
is,
I
think,
most
of
the
kind
of
core
team
people
would
have
guessed
and
then
maybe
more
of
the
sub
team
folks
would
have
voted.
No,
I
don't
know
if
that's
something
to
point
out.
A
It's
like,
I
think
my.
G
More
from
a
timing
perspective
I
feel
like
maybe
the
core
team
is
voting,
yes,
because
we
feel
the
pain
of
some
parts
of
our
current
governance
structure,
a
lot
I'm
more
neutral,
because
I
could
see
us
like
really
leaning
into
this
in
2022.
G
D
I
feel
like
I
would.
I
would
reframe
it
slightly
to
be
more
about
like
operational
efficiency,
because
I
think
that's
kind
of
what
we
want
out
of
it
right
and-
and
I
know
that
some
of
the
synchronous
nature
that
we
you
know
that
we
work
with.
It
is
kind
of
been
a
pain
point,
so
I
I
sort
of
feel
like,
and
we
also
talked
about
you
know.
If,
if
there
were
to
be
this
change
in
governance
structure,
it
wouldn't
happen
immediately
right.
D
It
might
just
happen
with
like
changes
to
the
way
meetings
happen
or
like
this
meeting
is
for
this
purpose
and
these
meetings
for
this
purpose
kind
of
separating
those
out.
So
I
feel,
like
those
are
all
things
that
could
be
sort
of
done
incrementally
and
made
progress
on.
You
know
before
we
formally
do
this
like
change
in
governance,
so
I
guess
I
voted
no,
but
I
kind
of
voted
for
like
no,
don't,
maybe
expand
it
or
soften
it.
D
C
Yeah
I
mean,
I
think
governance
is
not
the
right
word
there
from
just
the
discussion.
I
think
like
yeah,
like
operational
efficiency
scaling.
The
project,
which
I
think
is
also
a
very
broad
kind
of
phrasing,
is
probably
what
I
meant
or
was
going
for,
but
yeah
I
don't
know
this
came
from
brainstorming
in
like
the
span
of
three
minutes.
I
guess
yesterday
so
trying
to
find
the
right
words
was.
A
Hard
got
it
so
we
have,
I
think,
one
minute
before
we're
gonna
transition
over
to
a
regular
working
group
meeting
agenda
we'll
do
one
more
vote
over
this
says
operational
efficiency
and
you
know
in
the
end,
unless
there's
a
lot
more
discussion,
I
think
the
core
team
votes
will
be
be
finding
because
core
teams
has
their
own
map
ready,
but
everybody
can
vote
three.
A
Cool,
it
seems
like
that
was
all
thumbs
up,
and
so
I
think,
with
that
rephrasing
more
towards
operational
efficiency
instead
of
governance.
That
makes
it
in,
and
I
think
now
we
have.
It
was
the
last
item
we
said
we
wanted
to
consider
for
adding
if
folks
want
to
take
a
look
at
progress
last
time
over
the
previous
items.
A
B
Yeah,
I'm
summarizing
or
aggregating
everything
below
it
in
our
current
notes.
Right
now,
but
I
can
take
the
action
item
to
at
least
start
the
pr
and
just
get
people's
input.
A
I
think
we
did
there
was
we
needed
benz
and
put
on
one
thing.
There
was
some
wording
that
might
need
to
get
updated,
but
I
think
that
could
happen
through
the
the
pr
javier,
if
you
wanna,
if
you're
gonna,
open
and
then
folks
can
make
suggestions
into
that.
E
So
this
was
an
rfc
I
put
in
last
week
around
unlocking
a
use
case
that
allows
build
packs
to
write
layers
which
do
not
reside
in
the
slash
layers
directory
or
the
app
directory,
with
the
semantics
being
that
these
additional
layers
would
behave
roughly
the
same
as
the
app
like
workspace
based
layers
where,
in
terms
of
the
layer
life
cycle,
where
they
get
blasted
away
each
time,
and
if
you
want
to
preserve
them,
you
have
to
put
it
in
some
layers,
create
some
links
and
launch
layers
stay
the
same
and
whatever
else
the
main
motivation
behind
this
is.
E
There
are
a
bunch
of
use
cases
where
you
want
files
or
other
things
in
certain
directories,
and
these
directories
are
like,
for
all
intents
and
purposes,
rebaseable,
and
you
also
don't
need
root
privileges
to
put
files
there
necessarily.
E
So
some
examples
are
like
any
opt
specific
directories
which
are
like
standalone,
like
aws,
lambda
extensions
or
like,
if
you
want
to
put
it
in
some
other
op
directory,
which
has
its
own
like
entire
directory
structure,
including
dependencies
same
thing
for
like
user
configs.
Typically,
lots
of
software
requires
you
to
have
config
files
in
the
user's
home
directory,
so,
instead
of
like
manually
generating
these
during
run
time
using
an
exec
p
script,
you
could
just
preserve
it
there
and
then
that
would
be
it.
E
E
Extensions
thing
where,
like
you
could
detect,
which
directories
are
supposed
to
be
volumes
and
you
could
dynamically
like
add
them
to
your
stack
or
whatever
the
equivalent
of
stack
comes
out
to
be
the
usefulness
of
having
volume
directives
is
that
if
a
directory
is
declared
as
a
volume
it
just
like
it,
discards
any
changes
that
may
have
occurred
on
it
from
like
subsequent
run
commands.
E
That
can
be
a
good
thing,
as
well
as
a
bad
thing,
because
the
bad
thing
is
people
sometimes
run
talker
file
run
commands
and
those
changes
get
discarded
without
them,
knowing
it.
But
it
also
means
that
if
you
do
it
at
the
beginning,
you
know
that
your
image
would
definitely
be
replaceable,
because
there
won't
be
any
content
in
there
and
also
it's
a
good
signal
for
like,
if
you're
using
pack
to
create
your
image
like
doctor
locally.
If
there
is
a
volume
directive,
will
mount
necessary
volumes
there.
E
So,
if
someone's
creating
layers
or
writing
files
I'll
be
faster
same
thing
for
something
like
kpac,
it
could
just
look
at
the
volume
config
inside
the
inside
volume,
key
inside
the
config
and
figure
out
which
volumes
to
dynamically
mount
to
the
build
port
and
the
same
thing
can
be
applied
to
the
run
image
and
the
build
image.
And
apart
from
that,
it
supports
the
typical
things
we
currently
support
for
app
directories,
which
is
like
slices.
E
If
you
want
to
provide
certain
subparts
and
put
them
on
their
own
layers,
you
can
do
that
and
these
volumes
would
be
exported
or
will
be
available
to
build
packs
by
an
environment
variable
which
is
just
a
json
list
of
the
paths
which
they
can
inspect
and
then
decide
to
fail
to
detect
or
build
if
they
don't
find
appropriate
things.
E
The
alternative
was
to
use
environment
variables
to
specify
these
volumes.
One
additional
thing
I
added
was
specifying
the
workspace
or
the
app
directory
in
a
consistent
fashion
so
that
you
can
use
the
workdir
as
the
common
instruction
instead
of
an
environment
variable,
but
that's
the
gist
of
the
rfc.
G
Leaving
aside
some
details
my
mind,
the
two
things
that
I
would
worry
about
here
are
sort
of
like
build
packs,
coupling
the
stacks
and
so
the
inability
of
very
simple
platforms
like
tekton
to
support
this,
which
doesn't
mean
we
can't
do
it,
but
I
feel
like
you
need,
if
we
did
it,
it'd
have
to
be
a
requirement
that
a
build
pack
could
continue
to
function.
If
there
were
none
of
these
volumes
provided
right
it
has,
it
can't
be
a
requirement.
E
G
E
E
Oh,
I
was
just
going
to
say
the
other
alternative
that
I
can
think
of
is
if
there
is
a
single
volume
for
places
like
tecton
it
it
could.
The
lifecycle
could
possibly
have
an
option
where
you
provided
a
single
volume
and
it
sim
links
certain
parts
to
like
certain
sub
directories
in
that
volume
to
during
the
initial
phases.
E
To
then
have
the
files
in
the
appropriate
places
during
export
or
like
some
conventions,
so
that
some
parts
on
the
single
volume
map
to
some
parts
in
the
output
image,
but
it
should
be
doable
even
with
a
single
volume.
It's
just
a
matter
of
defining
a
convention
so
that
the
life
cycle
can
export
certain
some
directories
and
certain
other
places
in
the
output
image.
G
I
feel
like,
even
if
we
can
solve
for
the
tecton
problem,
I'm
still
inclined
to
say
it
has
to
be
optional,
because
otherwise,
now
you're
deeply
coupling
the
build
pack
to
a
particular
stack
right
that
it
has
set.
These
volumes
like
it
would
not
be
runnable
on
a
different
stack
where
this
wasn't
provided.
E
So
that's
where
I
was
thinking
like
that's
how
most
of
the
build
packs
would
technically
work
right
like
they
require
some
base
dependencies
in
the
stack.
So
if
stephen's
rfc
goes
through,
they
can
also
dynamically
say
that
okay,
these
things
must
be
volumes
or
you
could
expand,
or
you
could
put
these
instructions
in
in
your
builder
image
and
run
image
and
then
that's
all
for,
like
the
dynamics
like
stack,
coupling
part
doesn't
solve
when
you
provide
these
instructions
and
then
your
platform
has
to
mount
all
of
these
volumes.
There.
E
G
A
bit
worried
because
I
feel
like
we're
finally
making
changes
to
move
to
better
build
pack
stack
compatibility
like
for
a
while,
I
think
bill
packs
were
pretty
coupled
to
their
stacks,
even
though
that
wasn't
the
goal
of
the
way
the
spec
was
originally
written.
Put
some
of
these
changes
around
getting
rid
of
make
sense
and
standardizing
around
sort
of
you
know.
Operating
system
features
rather
than
stack.
Ids
is
to
create
a
world
where
everything's
more
interoperable,
with
a
different
base
image,
and
this
is
sort
of
applying
things
in
a
different
direction.
C
I
yeah
I
I
think
I
wrote
basic
concerns.
Emily
has
in
rfc
directly
yesterday
when
I
was
looking
at
it,
not
that.
I
think
this
is
a
feature
we
shouldn't
add,
but
I
think
those
are
probably
concerns
that
we
need
to
resolve
or
address.
C
I
I
do
think
steven
r
stevens
rc
definitely
moves
us
in
the
other
direction
like
emily
is
saying,
I
think,
there's
some
stuff
where
a
bill
pack
that,
if
it
does
depend
on
this
feature,
is
tied
to
very
specific
things
and
kind
of
was
expecting
certain
things
from
that
stack
image
that
it's
running
on,
even
if
it
doesn't
have
a
stack
id
and
we're
not
doing
it
that
way,
and
potentially
we
need
a
way
to
expose
that
up
front,
like
I
imagine
even
like
if
I
am
building
a
builder
or
something,
and
that
is
an
expected
thing
that
I
should
know
when
I
basically
pull
that
bill
pack
in
and
I'm
potentially
building
a
builder
for
it,
that
that
volume
those
volumes
need
to
be
set
right
and
potentially
like.
C
E
A
E
But
I
think,
like
most
of
these
parts
would
be
like
hard-coded
for
each
buildback,
so
I
don't
mind
adding
some
optional
metadata
and
the
buildback
normal.
That
indicates
that
this
build
pack
requires
these
parts,
and
maybe
we
can
fail
to
create
the
builder
up
front.
That
also
works,
but
as
far
as
I
can
see,
it
doesn't
couple
it
to
a
stack
more
so
do
a
list
of
volumes.
As
long
as
any
stack
provides
those
list
of
volumes,
it
should
still
work.
A
I
want
to
maybe
take
a
step
back
from
the
particular
rfc.
I
think
you
have
like
a
critical
use
case
for
a
big
platform.
You're
building
right.
That's
like
you
need
to
put
stuff
in
opt
and
this
it
comes
across
as
like.
A
very
well
thought
out
and
elegant
way
to
you
know,
accomplish
you
know
to
work
towards
solving
that
particular
use
case.
You
know,
except
for
like
kind
of
some
philosophical
questions
right
about
the
coupling,
and
you
know
maybe
some
questions
around
how
we
implement
this
on
different
platforms.
A
I
wonder
if
it's
worth
talking
about
the
use
case,
you
have
a
little
bit
more
first
before
we
talk
about
the
solution,
because
I
I
don't
know
if
everybody
is
aware
of
that
or
like
like,
like,
I
think
it
in
that
context.
The
things
that
are
important
about
this
might
be
a
little
more
obvious
and
we
could
figure
out
how
to
preserve
those
without
you
know
causing
the
same
problem.
So
could
you
talk
a
little
bit
about
the
problem
you're
trying
to
solve.
E
So
the
main
thing
I
need
is
that
any
certain
siblings
in
certain
predefined
parts-
all
of
these
things
are
rebasable.
So
I
don't
want
to
switch
to
like
the
new
stacks
packs
proposal
and
like
lose
out
on
like
performance
or
anything
else,
not
just
rebase
ability,
but
also
that
some
of
these
things
would
have
to
be
done
beforehand
in
a
possibly
less
efficient
manner.
E
A
A
Thinking
about
the
stack
packs
hooks
rfc
you're
concerned
about
so
you
know:
there's
a
label
there,
that'll,
let
you
mark
a
stack
pack
as
rebasable,
so
you
could
rebase
out
from
under
it
and
you're
concerned
about
performance.
In
that
case
you
know,
and
would
it
really
be
less
performance
right,
go
ahead.
A
E
I
mean
that's
one
way
of
accomplishing
things
and
that's
how
I
imagined
I
would
do
it
if
this
rfc
wasn't
there.
That
still
doesn't
feel
right
to
me.
A
I
agree
I
just
just:
does
it
just
to
understand
the
problem
better
that
that
would
technically
solve
your
problem
right?
It
would
be
fast
because
you'd
be
creating
some
lights
first
and
then
they
would
point
to
build
pack
locations.
But
you'd
have
this
weird
thing
where
there
are
magical
stack,
build
packs
that
create
some
links
to
magical,
build
pack,
id
and
layer
locations.
E
The
issue
is
like
introspection
into
the
build
packs
layers
and
then
like
you're
having
another
layer,
that's
looking
into
the
build
pack
layers,
content
and
then
trying
to
create
something.
So
I
wanted
it
from
the
buildback
api
so
that
it
could
control
which
sim
links
it's
creating
from
which
place
so
that
there's
no
possibility
of
like
platform,
api
changing
and
suddenly
my
sim
links
are
broken.
G
E
That
would
also
work.
That
was
something
that
I
proposed
or
asked
before
that.
Why
do
we
not
allow
like
any
arbitrary
parts
to
be
exported
from
under
layers
like
if
you
had
some
convention
under
the
buildback
layers
like
export
it
to,
and
then
you
provide
the
paths
there
from
root
and
it
exports
that
it.
G
A
That
that
worries
me
because
it
has
it
involves
changing
paths.
So
so
far,
we've
been
able
to
avoid
software
that
gets
installed
in
one
place
and
then
runs
in
another
place
and
that
added
a
lot
of
complexity
in
the
past.
The
older
build
pack
apis
so
like,
if
you,
you
know,
set
up
your
layer
in
layers
build
pack
id
whatever,
and
then
you
know
as
you're
setting
it
up.
You
record
paths
into
that
layer
right
that
you
know
internally
reference
the
layer.
G
E
G
A
I
I
feel
like
we
should
have
more
flexibility
or
like
that.
That
goal
is
is
good
and
we
should
work
towards
that
and
if
the
stackpack
rfc
doesn't
provide
enough,
then
you
know
like
something
to
address,
but
I
do
worry
about
the
kind
of
coupling
between
the
stack
and
the
build
packs.
Also-
and
you
know,
having
all
the
build
packs
be
able
to
like
they're
all
going
to
get
these
volume
locations,
and
so
they
can
all
write
into
all
the
volume
locations
and
that
that
worries
me
a
little
bit
too.
A
I
know
we
already
have
an
app
directory
that
behaves
like
that
right
and
so
there's
presidents,
but
the
you
know
it
seems
like.
If
a
lot
of
people
use
this
a
lot
you
get
rid
of,
or
you
know
you
might
create
a
lot
of
instances
where
things
are
accidentally
overriding
each
other
right.
Everything
thinks
they
need
to
install
the
same
dependency
into
opt
and
so
multiple
things
you
know
try
to
write
to
the
same
directory
locations
if
there
were
a
common
dependency
that
had
to
be
installed.
A
G
A
G
A
A
I
guess
sam,
do
you
have
a
reason
to
couple
it
to
the
stack?
Is
there
a
reason
why
you
want
the
stack
to
declare
that
the
locations
are
there,
because
I
think
it
seems
to
be
the
biggest
argument
against
it
and
also
it's
given
your
use
case.
You
know
it
doesn't
seem
like
you
necessarily
need
it.
That's
why
it
doesn't
matter
if
it's
a
build
pack,
thomas
just
it
seemed
like
that
was
the
maybe
the
first
thing
to
change.
E
The
new
stackpacks
rfc
could
still
declare
volumes
dynamically
using
dockerfiles.
It
would
still
work
with
the
existing
concept
of
stacks
that
we
have
and
the
changes
to
the
lifecycle
if
we
implement
implemented
this
way
would
have
been
minimal,
at
least
from
what
I
could
understand.
I
don't
know
if
there
are
some
edge
cases,
I'm
missing.
E
I
mean
you,
it's
it's
an
oci
config
key,
so
it
doesn't
have
to
be
through
docker.
You
can
set
it
in
different
ways.
I
also
propose
an
alternative
way.
You
can
just
set
it
using
environment
variables
that
doesn't
bother
me
too
much.
The
only
reason
I
added
as
a
volume
directive
is
because
of
the
guarantees
that
docker
provides
that
if
you
declare
something
as
a
volume,
you
can't
write
on
top
of
it
anymore.
So,
like
it's
literally
just
a
volume,
your
for
subsequent
instructions
won't
affect
it.
G
Especially
if
we
do
this
as
part
of
creep
builder,
that
I'm
less
worried
about
people
writing
on
top
of
it,
it's
more
like
had
something
happened
underneath
it,
but
I
think,
in
order
to
keep
things
simple
for
platforms,
I'd
rather
get
clever
with
sim
links
than
require
platforms
to
provide
a
bunch
of
extra
volumes.
G
E
G
A
If
you
knew
at
the
beginning
of
the
builder
execution,
what
paths
in
the
file
system
were
going
to
be
written
to,
then
you
could,
at
the
end
of
the
builder
execution,
the
same
container
power,
those
pads
and
move
them
into
the
layers
volume.
And
then
you
wouldn't
need
the
simulink
thing
right,
but
it
would
be
weird
because
you'd
be
tarring
layers
up
outside
of
the
export
phase.
A
G
E
G
Like
I
think
you
could
take
what
happens
at
the
beginning
of
export
and
move
it
into
build.
If
you
wanted
like
the
tarring
of
layers,
just
in
general,
we
could
do
that,
but
I
don't
see
that
being
a
necessary
change.
We
need
to
do
to
accomplish
any
of
these
goals
like
I
think
I
want
things
to
be
simple
for
platforms.
I
don't
want
them
to
have
to
do
a
bunch
of
logic,
to
figure
out
how
many
volumes
per
ride,
which
means
we
need
something
fun
with
sim
links.