►
From YouTube: Working Group: 2021-03-24
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
Alrighty,
everyone
sign
into
the
document.
B
I
can
give
an
update
about
the
life
cycle,
we're
in
pretty
good
shape
kind
of
in
the
territory
of
writing,
release,
notes
and
doing
validation.
So
hopefully
this.
A
Week,
cool
and
platform
just
had
a
release,
so
I'm
guessing
there's
not
much
to
say.
B
C
B
A
All
right,
outstanding,
rc's
I'll
go
ahead
and
share.
A
Take
a
look
fixed
grammar
and
markdown
and
asset
cash
rfc.
Oh,
I
think
this
is
not
an
rfc.
This
is
a
retroactive
pedantic
correction
of
our
grammar.
D
A
D
A
A
A
A
D
Let's
see
since
this
one
is
me
wow,
that's
a
lot
of
votes.
Three
four
emily,
it
seems
like
you've,
still
got
outstanding
questions.
D
Nope,
okay,
who
actually
opened
this
forest,
is
that
you
can
you
do
a
update
that
branch
when
you
get
a
moment,
please
for
us.
B
D
A
We
talked
about
well
that
was
two
weeks
ago.
We
talked
about
it
in
the
learning
sub
theme
scene,
david.
D
A
All
right
issue
generation.
G
B
A
In
all
right
project,
descriptor
domain
rfc
has
been
open
for
22
days
and
I
think
there
hasn't
really
been
any
like.
I
think
terence
updated
it
to
include
the
underscore-
and
we
discussed
it
last
week
and
there
hasn't
been
any
movement
since
so
I
think
we
should
really
try
to
get
this
one
merged.
Can
we
put
it?
No,
I
only
have
two
votes
I'll
approve
it
right
now.
I
think
yeah.
I
think
this
is
blocking
some
stuff,
so
it'd
be
nice
to
move
it
forward.
A
Cool
and
then,
if
you
can
move
it
to
fcp
that'd,
be
awesome,
javier
wait.
Why
does
it
have
two
assignees.
D
A
D
A
All
right
package,
refactoring.
C
A
Yeah,
I
just
had
a
couple
questions
about
it,
both
throughout
prior
art
and
then
just
curious
if
there
are
other
examples
that
use
that
same
kind
of
layout
yeah.
So,
oh
you
might
yeah.
You
look
like
you're
addressing
the
one
yeah.
A
All
right,
adding
builder
key
in
project.
E
F
B
A
G
Yeah,
I
think
the
issues
have
been
created
unless
we're
talking
about
implementation
based
issues
which
I
don't
think
apply
to
this.
G
D
E
D
It
seems
that
seems
like
a
good
idea
who
was
the
sherpa
for
that
particular
issue.
G
Yeah
and
then
I'm
assuming
the
the
later
part
of
that
right,
like
the
follow-up,
would
be
getting
that
repo
accepted
in,
and
someone
from
the
core
team
needs
to
do
that.
D
F
E
Where
this
rc
was
written,
it
was
like
a
pack
create
stack
feature.
I
guess
there's
a
stackify
component
that
gets
copied
into
the
stack
image.
So
I'm
guessing
this
repo
is
the
one
we're
talking
about
is
for
that
component
or
is
it
for
sort
of
the
whole
existing
implementation
of
stackify
as
a
separate
binary
and
then
we'll
take
it
as
is
and
merge
it
in
to
pack.
E
Yeah,
I
guess
my
question
was
more
around
the
fact
that
the
rfc
is
sort
of
focused
on
a
pack
use
case
and
I
think
had
changed
such
that
it
wasn't
specifically
referencing
a
repo
that
we
were
adopting,
but
rather
a
new
pack
feature.
Are
you
adopting
a
repo?
Is
an
implementation
detail
of
how
we
want
to
start
incorporating
the
feature
we're
just
clarifying?
What
exactly
needs
to
be
done?.
H
G
B
C
Cool-
let's
do
that,
so
I
guess
just
answering
some
of
these
questions
that
came
up
my
review.
C
So
I
think,
like
simply
all
this
is
doing,
is
imposing
a
little
bit
of
additional
structure
on
the
pack
repo.
This
is
kind
of
what
we
have
now.
This
is
more
of
what
we
would
like
there's
a
lot
of
resources
for
what
a
golang
project
should
look
like.
I
think
that
there's
some
recommendations
by
the
core
team
that
they
put
out-
and
this
fits
in
with
kind
of
what
we've
come
up
with,
or
I
guess
we
follow
these
guidelines.
C
Yeah-
and
I
think
it
was
also
have
a
single
place-
to
have
multiple
people
kind
of
discuss
this
right.
It
wasn't
just
a
discussion
board
like
we
have
this
formal
proposal
process.
We
would
like
to
use
it
for
other
stuff
other
than
like
large,
total
rfcs
for
the
entire
project.
E
B
G
So
I'll
step
in
here,
because
I
believe
I
was
the
one
that
proposed
that
we
create
an
rfc
for
this,
I
think
we
wanted
to
start
leaning
towards
the
direction
of
creating
sub-team
specific
rfcs,
something
that
I
know
we've
discussed
in
the
past,
and
then
you
know
to
to
dan's
point
like
we
wanted
to
make
sure
that
the
platform
maintainers
right
agreed
on
some
sort
of
vision,
since
this
is
like
impacting
an
entire
repository
of
what
we're
trying
to
achieve,
and
there
were
some
ideas
that
came
about
through
a
discussion
board
that
jesse
you
know
brought
up
and
so
we're
kind
of
like
again
kind
of
leaning
into
this,
like
we
have
a
lot
of
really
good
ideas
and
we
want
to
like
have
a
place
for
us
to
be
able
to
comment
on
them
and
more
or
less
approve
them,
and
we
already
have
that
mechanism,
which
is
the
rfc
right
so
like.
G
I
think
we're
kind
of
meeting
in
this
middle.
So
now
to
answer
your
question
right,
like
our
hope
from
like
the
rfc
process
on
the
sub
team
side
of
things,
is
to
get
it
fleshed
out,
and
you
know
I
think
we've
done
that
and
we're
just
coming
over
here
to
more
or
less
like
for
the
ceremonial
purposes
of
saying,
like
hey,
we
want
to
merge
this
in
as
an
rfc,
so
I
think.
A
Go
ahead,
I
think
this
one
goes
a
little
bit
beyond
that,
just
because
of
the
potential
to
impact
anyone.
That's
using
pac
as
a
library
like
at
that
point,
it
kind
of
becomes
like
a
project
scope
concern,
at
least
like
because
there's
we
need
to
do
some
comms
about
that.
So,
like
I'm
totally
in
support
of
like
the
autonomy
of
doing
this,
the
t-level
rc's,
but
like
I
think
I
would
be
concerned
if
that
kind
of
change,
just
kind
of
went
under
the
radar.
You
know
what
I
mean.
G
Yeah-
and
I
think
maybe
that's
why
this
is
a
good
pilot
for
that
right,
like
we're,
bringing
it
up
to
this
audience
so
that
we
could
more
or
less
cross
our
t's
and
dot
our
eyes.
You
know
to
your
point,
you
know,
I
don't
think
that
that's
something
that
we've
considered
significantly,
because
you
know,
I
think,
a
lot
of
the
times
we
we
would
justify
it
as
they
would
have
to
update
their
dependencies
and
therefore
they'd
have
to
adjust
right
like
it's
not
like.
G
We
have
a
backwards
compatibility
concept
of
using
pac
as
a
library,
and
I
don't
think
that's
our
least
our
goal
at
this
point
in
time.
But
anyway,
that's.
D
That's
an
interesting
statement
that
you
don't
think
that
you
have
a
backwards
compatibility
guarantee
there.
It
would
explain
certainly
why
there's
no
assessment
of
that
anywhere
in
the
rfc.
That's
gonna
break
people
who
are
using
it
that
way,
but
like
isn't
the
fact
that
your
apis
are
public,
your
compatibility
guarantee.
G
Not
necessarily
especially
when
you're
talking
about
a
pre
1.0
right
yeah,
I
mean
we,
we
definitely
try
not
to
ruffle
too
many
feathers,
but
we're
definitely
not
making
any
guarantees
right
now,
sir,.
B
A
Yeah
and
I'm
not
saying
that
we
can't
do
that-
I
just
I
brought
it
up
because
you
said
it
was
ceremonial
and
I
just
thought
it
was
a
little
bit
more
than
that.
Yeah.
G
A
Would
yeah?
I
would
like
to
think
about
what
we
need
to
do
like.
I
think
I
feel
like
with
these
kinds
of
things
it's
about
expectations
and
like
where
would
people
expect
to
be
notified
about
this?
I
mean
we
can
do
this
slack
email
tweet,
that
kind
of
stuff,
but
yeah,
I
don't
know,
I
don't
know
who
all
is
using
pack
as
a
library
and
if
there's
any,
that
aren't
a
part
of
this.
You
know
frequently
part
of
this
working
group.
E
I
don't
know
if
I
would
go
over
the
top
communicating
this
particular
iteration,
but
I
might
do
that
once
we
reach
a
point.
That's
more
stable
or
more
comfortable,
saying
like
yeah,
you
should
use
peck
as
a
library
and
maybe
we'll
change
a
couple
things,
but
you
can
trust
that
this
is
the
general
architecture.
G
Cool
and
again
going
back
and
poking
at
emily's
statement.
I
think
we're
definitely
beyond
the
point
of
bike
shedding
right.
So
bigger
concerns,
you
know
of
impact
and
stuff
like
that.
I
think,
are
very
valid
and
reasonable.
A
Yeah,
I
think
like
as
as
a
result
of
finalizing
this,
could
we
create
an
issue
or
something
like
that
on
pac,
that's
like
a
reminder
to
make
a
little
bit
of
noise
about
it
when
we
do
the
next
release
or
the
release
that
includes
this.
Does
that
seem
like
an
okay
path
forward.
G
I
do
wonder
just
a
curiosity
whether
or
not
it'd
be
reasonable
to
expect
that
we'll
make
the
entire
change
in
one
release
right
like
that.
That
would
be
another
thing.
I
because
I
guess
maybe
in
my
mind
this
was
like
a
transitional
thing
right.
That
might
happen
over
a
few
releases
versus
like
saying.
Oh,
you
know,
o19
is
going
to
like
completely
just
have
a
whole
refactor
in
every
pr
that
you
put
in
between
that
point
in
time.
G
It's
just
gonna
have
so
many
merge
conflicts
like
that's
what
I
was
hoping
to
avoid,
but
again,
maybe
there's
a
reason
why
we
want
to
do
that.
I
Yeah,
I
may
have
missed
some
of
the
discussion,
but
like
life,
cycle's
kind
of
going
through
the
same
thing
as
well
right
we've
moved
packages
around
and
I
don't
think
we've
made
any
noise
about
it.
There
could
conceivably
be
consumers
of
life
cycle
as
a
library
as
well,
and
we
have
made
no
sort
of
it's
probably
more
likely
to
use
impact.
But
we've
made
no
sort
of
announcements
about
creating
additional
packages
or
moving
things
from
one
package
to
another
that
I'm
aware
of.
E
I
have
to
say
I
think
I
brought
this
up
in
the
comments,
but
the
one
thing
that
makes
this
hard
to
prove
for
me
is
it
seems
like
coming
along
with
the
re-architecture,
is
the
idea
that
we're
going
to
break
pack
out
into
multiple
clies,
which
seems
sort
of
like
a
bigger
question
than
what's
in
here?
I
know
this
is
like
how
we
would
organize
multiple
cdli's.
Maybe
it
isn't
saying
that
this
approval
is
for
breaking
pack
into
multiple
clies,
but
I
worry
that
when
we
merge
this
in
it,
it
looks
like
with
that.
E
G
I
And
I
don't
think
anything
in
this
is
necessarily
saying
that
only
downloading
build
packs
would
happen,
like
pack
would
call
out
to
fetcher
necessarily
right
like
it
could
be
a
standalone
binary
that
fetches
things
in
addition
to
pack
doing
it
through
the
same
library
interface
that
fetcher
uses,
because
I
think
when
we
discussed
this
early
on,
it
was
like,
if
I'm
not
running
pack,
but
I
want
to
make
sure
that
I
download
build
packs
in
the
very
same
way.
Then
it
pack
kind
of
bundling
along
a
fetcher
binary.
I
That
does
that
one
thing
and
that
one
thing
only
without
me
having
a
wrap
in
my
own
go
library
would
be
useful
but
yeah.
I
agree.
That's
a
bigger
decision
to
you
know
having
more
binaries
bundles
pack.
E
Yeah
or
you
could
leave
the
package
structure
in
the
possible
future
structure.
I
just
feel
like
the
new
binary
is
coming
in.
Like
is.
It
is
an
another,
bigger
question
that,
like
doesn't
really
need
explicit,
answering
because
we're
following
this
project
structure
model.
So
if
we
ever
edited
a
new
binary,
that's
where
we
put
them.
I
think
there's
no,
no
question
to
be
needs
to
be
resolved
there
with
an
example.
B
C
A
Which
is
allowing
different
users
during
the
build
process
is
that
sam
yeah.
J
This
so
sorry,
I
wasn't
in
the
last
meeting
when
this
rfc
was
discussed,
and
I
tried
to
put
some
of
the
comments
in
the
request
and
the
slack
channel,
but
I
think
there
are
two
different
use
cases
that
I
was
thinking
of
when,
like
I
created
this
rfc
one
is
like
the
permissions
of
the
different
files
and
directories
you
create
during
the
build
process
and
which
users
own
them,
and
one
is
the
user
that
actually
is
the
default
user
for
for
the
runtime
image.
J
So,
although
the
examples
I
put
in
that
rfc
are
for
like
securing
your
runtime
image
by
making
some
of
the
directories
not
writable,
there
are
also
alternative
cases
where,
like
the
user,
that's
that's
the
default
user
in
the
iran
image
has
some
files
or
other
permissions
associated
with
them
that
come
from
the
start
and
not
from
the
buildbacks,
and
the
idea
was
to
simply
allow
switching
between
different
users,
which
is
different
from
like
changing
the
permissions
or
the
owners
of
the
files
created
during
the
build
process
and-
and
this
this
thing
that
I
currently
put
in
the
agendas
about
the
latter,
which
is
during
the
build
process.
J
J
So
again,
I
I
don't
know
if
this
would
fit
in
with
the
current.
This
might
be
a
bigger
change
than
the
one
that
was
proposing
originally
in
that
rfc,
which
sort
of
already
works
with
the
two
platforms.
I've
tried
it
in
which
is
back
in
kpac,
but.
G
J
Was
more
around
like
could
build
packs,
say
that
the
I
I
want
to
run
as
a
specific
user,
or
could
they
use
something
like
so
we
have
like
slices
for
the
app
directory
which
export
them
into
different
layers,
but
could
we
have
like
an
equivalent
sort
of
representation
where
you
could
say
these
are
the
file
paths,
and
this
is
the
user
or
the
group
I
want
them.
J
I
want
those
directories
to
be
owned
by
so
during
the
export
process,
the
life
cycle
could
change
the
owners
or
like
accordingly,
and
the
build
pack
would
still
run
as
the
build
user.
So
those
were
like
the
two
points
that
I
wanted
to
cover
in
this
know.
F
Is
there
value
in
being
able
to
use
different
users
during
the
build
process
to
create
those
files
or
assign
different
users
to
different
groups
of
files,
and
I
think
the
value
that
occurs
to
me
as
well.
If
you
want
to
create
some
files,
you
can't
create
them
as
root
right,
but
you
might
not
want
to
have
access
to
be
able
to
write
to
them
at
runtime,
and
so
that's
like
two
users
that
you
might
need
there,
but
you
know
a
feature
that
lets.
You
use
two
users
during
the
build
process.
F
You
know,
I
wonder
if
you
know
really
we're
saying
that
there
are
some
files
that
should
be
root
owned
and
therefore
not
writable
by
the
user,
or
if
you
know
we
could
say
that
there
could
be
a
runtime
user
and
a
build
time
user.
You
know
like
I
don't
know
if
we
need
to
open
this
up
for
as
much
extensibility
as
like,
you
can
have
many
users
and
lots
of
files
within
the
you
know,
layers
directory
your
app
directory
can
be
owned
by
any
any
number
of
different
users.
F
H
I
think
I'll
add
the
open
shift.
Scenarios
should
probably
not
be
forgotten
at
this
point
as
well,
because
openshift
has
this
tendency
by
default,
to
run
all
of
the
images
that
it
sees
as
a
random
user
id
with
a
root
group
id.
So
if
you
start
allowing
build
packs
to
customize
that
user
id
we're
still
going
to
need
a
way
when
we
build
an
image
to
specify
that
that
user
id
can
be
random
at
runtime,
you
see.
H
E
H
E
I
feel
like
if
you
have
a
user
run
time
and
a
different
one
at
build
time
or
maybe
the
same
like
we
all
out
both.
But
you
know
they're
in
the
same
group,
then
you
can
use
sort
of
group
permissions
as
a
proxy
for
runtime
permissions
and
you'll
have
all
of
the
all
of
the
ability
that
you
need
to
fine
tune.
F
F
Do
worry
about
the
complexity
for
buildback
authors
if
they
have
to
manage
group
permissions
separate
from
user
permissions
a
little
bit,
but
maybe
it's
more
about
making
that
possible,
as
opposed
to
you
know
like
if
you
just
allow
configuration
of
the
uid
and
gid
at
runtime,
then
buildpacks
can
you
know,
set
those
group
permissions
up,
so
you
could
take
advantage
of
that
right.
It's
how
the
original
thing
was.
E
I
think
the
defaults
are
pretty
good
for
build
pack
authors.
If
we
do
this,
even
if
they're
different
users,
like
most
things,
would
be
writable
by
the
build
time
user,
but
only
readable
by
the
group.
I
mean,
depending
on
what
you
mask,
people
have
in
the
stack
images
right,
but
I
don't
think
that's
a
bad
default
that
people
would
have
to
learn
more
to
deviate.
E
A
What's
the
last
item
on
the
agenda
did,
did
you
want
to
talk
about
any
of
the
other
rfcs
sam.
J
There's
another
one
that
I
put
in
yesterday,
which
was
around
something
we
discussed
last
time,
which
was
a
overriding
default
arguments
and
I
think
the
main
thing
I
wanted
to
discuss.
There
were
the
two
options
that
I
proposed.
J
Screen,
okay,
so
the
so
so
the.
J
Like
both
the
oc,
docker
and
kubernetes
have
this
idea
that
you,
you
have
a
list
of
strings
which
are
like
the
defaults,
which
cannot
be
overwritten
by
a
user
unless
they
change
the
entry
point.
And
then
you
have
a
bunch
of
default
arguments
which
are
a
hint,
but
if
the
user
provides
some
arguments,
those
are
overwritten
currently
that
sort
of
behavior
is
not
possible
with
bill
patch,
because
the
launcher
simply
appends
any
arguments
from
from
like
docker
on
to
to
the
current
set
of
arguments.
J
But
let's
say
the
user
doesn't
provide
any
arguments.
There
are
some
additional
default
arguments
which
are
appended
back
to
like
these
args.
So
let's
say
you
have
something
like
this.
Like
echo,
hello
world,
if
the
user
doesn't
provide
it,
it
would
translate
to
something
like
this
in
the
existing
spec.
J
But
let's
say
the
user
provides
a
docker
on
the
entry
point.
High
universe,
in
which
case
world,
which
was
an
additional
default
argument,
would
be
replaced
by
universe
and
it
would
translate
to
echo
hero
universe.
The
drawbacks-
I
guess
I
have.
I
didn't
put
it
here,
but
the
drawbacks
here
are
the
the
complexity
and
the
deviation
from
like
existing
terminology
that
people
may
be
familiar
with
so
command
and
args
like
in
at
least
the
case
container.
J
J
J
The
possible
issues
I
see
with
this
is
that
one
it's
a
backwards
and
compatible
change,
and
also
since
it's
using
existing
terminology
that
build
path.
Authors
are
familiar
with
and
we
are
changing
the
behavior
entirely.
They
might
get
confused,
which
is
why
this
was
as
an
alternative,
but.
J
E
I
feel
like
this
all
started,
because
in
the
beginning,
we
didn't
support
direct
processes
and
there
were
no
args.
There's
just
command
and
command
was
a
bash
script
that
got
passed
to
bash,
and
then
we
wanted
to
like
extend
this
to
support
other
types
of
processes
and
sort
of
grew
that
model
out
from
what
we
had
and
because
we
didn't
have
because
command
was
always
a
single
string
and
we
definitely
wanted
to
support
appending.
E
But
we
had
no
way
to
support
multiple
arguments
that
got
appended
to,
rather
than
just
the
one
that's
sort
of
how
we
ended
up
in
this
place,
I
would
say:
sort
of
like
evolving
the
model
we
had
instead
of
stopping
back
and
rethinking
it
all
the
way.
E
So
I
feel
like
a
rethink
of
this
model
might
actually
do
something
different
with
a
shell
script,
where
you're
explicitly
saying
like
this
is
a
shell
script
and
it's
going
to
get
passed
to
bash
rather
than
sort
of
reusing,
the
same
same
fields,
and
then
we
could
refactor
command
and
args
to
look
more
like
entry
point
and
command
in
docker
or
command
in
args
and
case.
E
E
Same
fields
and
they
would
have
to
relearn
new
meanings
for
them.
I'm
slightly
inclined
to
do
it
anyways,
because
I
think
the
way
we
got
to
a
place
where
things
are
kind
of
weird
was
by
evolving
it
in
such
a
way
that
bill
peck
others
could,
for
the
most
part,
leave
what
they
had
and
it
would
keep
working.
But,
as
you've
pointed
out,
it
left
us
in
an
unintuitive
place
for
people
who
are
coming
in
fresh
right.
E
E
E
In
my
mind,
the
interesting
question
like
if
we
move
to
something
where
command
was
to
array
we'd
be
like
when
we
went
to
implement
this.
We
want
to
leave
it
all
in
the
file
and
have
the
launcher.
Do
this
math
and
figure
it
out
or
would
we
want
to
do
something
like
actually
put
the
additional
arguments
and
command
in
in
the
image
entry
point
itself
right
and
then
it
would
kind
of
just
happen
at
launch
that
it
would
work
that
way
using
the
mechanisms
like
the
set
of
args.
You
would
get.
E
It
really
only
works
for
the
default
process
right.
So
that's
the
big.
E
Shouldn't,
I
feel
like
frequently
the
fact
that
we
support
multiple
processes
leads
us
to
solutions
that
don't
use
oci
primitives,
like
setting
lunchtime
environment
variables
when
they're
static
directly
in
the
oci
environment
and
the
same
thing
with
like
entry
point
and
command
like
places
where
we
could
do
this
and
where,
like
people,
look
know
to
look
for
these
things
to
understand
how
their
image
works.
E
E
It's
been
a
nice
long
silence
here.
Does
this
mean
we're
ready
to
wrap
up
like
everyone
should
go,
take
a
look
and
give
sam
some
comments
on
the
rfc,
or
is
there
anything
else
we
want
to
discuss
synchronously
while
we're
here.
J
There
was,
I
think,
I
believe,
also
some
comments
on
that
rfc
about
disambiguating
the
layer
metadata
files
from
from
the
from
the
special
metadata
files.
I
I
don't
know
what
the
conclusion
from
that
discussion
was
like.
Oh.
B
J
A
Yeah,
I
put
a
suggestion
that
I
think
we
could
make
that
like
optional,
where,
like
you
could
use
that
like
we
could
basically
restrict
layer
dot
and
then
you
could
use
that
to
prefix
build
or
whatever
build.tom
or
whatever,
and
that
would
be
backwards
compatible
and
probably
a
little
bit
more
digestible
for
for
anyone
that
wouldn't
need
it.
It
might
not
be
as
discoverable
or
super
super
obvious,
but
I
worry
that,
like
it
won't
be
discoverable
or
super
obvious.
B
J
A
A
It
I
mean,
I
feel,
like
I
think,
really
what
we'd
be
saying
is
layer
dot
like
you
can't
use
that
prefix,
which
is
like
a
little
bit
more,
I
think,
makes
more
sense
than
like
here's,
a
bunch
of
names
you
can't
use
like
we've
grabbed
a
name
space
sort
of.
B
E
D
It's
a
one-time
thing,
the
number
of
images
that
are
currently
alive
like
I,
I
don't
think,
that's
the
expense.
You
think
it
is
it
sucks
for
some
particular
person
on
one
particular
day
when
they've
got
to
re-expand
java
recompile
some
dependency
but
like
as
a
long-term,
like
countering
a
significant
long-term
improvement.
I
don't
think
you
should
weigh
that
in.
E
F
F
A
F
F
H
Yeah
in
most
of
the
build
packs
I'm
dealing
with,
I
delete
the
workspace
because
it's
got
all
the
source
code
in
there.
I
don't
want
that
stuff
persisting
throughout
the
run,
I
found
it
really
weird
that
whole
yeah
the
workspace
automatically
getting
its
own
free
layer
that
wasn't
part
of
the
layers
directory.
All
that
I
kind
of
imagined
it
was
all
going
to
be
consistent
in
a
line,
but
it
wasn't
quite
that
way.
F
H
Yeah,
I
kind
of
felt
that
it
would
almost
be
handy
if
there
was
just
a
switch.
I
could
apply
to
workspace.
To
say
just
don't
include
this
because
you
know
at
the
end
of
the
day,
I'm
doing
a
weirdo
find
command
to
delete
all
the
files
under
that
directory,
because
you
can't
delete
the
directory
because
it's
a
mount
point
and
it
won't.
Let
you
kill
it.
So
you
do
what
you
can.
E
Once
upon
the
dawn
of
time,
there
was
a
workspace
directory
and
underneath
it
there
was
the
after
and
the
layers,
and
we
changed
everything
probably
too
aggressively
to
be
compatible
with
k
native
build,
which
doesn't
exist
anymore
and
required
that
the
app
was
in
a
directory
called
workspace.
H
Yeah
I
mean
mine's
in
a
directory
called
slash
app
and
then
under
that
there's
a
directory
called
slash.
Contact
called
content
and
under
content
is
the
the
app
directory
and
I
had
to
go
two
layers
deep,
because
at
some
point
the
build
pack
tries
to
change
the
permission
on
the
directory
that
you
give
it
as
the
the
app
location
as
the
workspace
directory.
So
it
wants
to
change
the
directory.
H
The
permissions
on
slash
app,
slash,
content
online,
which
is
acceptable,
but
when
it
tried
to
change
the
permissions
on
slash
app,
because
that
was
actually
the
volume
melt
point,
it
wasn't
allowed
and
bad
things
started
happening
there.
So
I
ended
up
having
to
move
everything
down
a
layer
to
make
it
work.
But
anyway,
this
is
all
platform
implementation
weirdness.
But
it's
interesting
because
some
of
it
bubbles
over
into
stuff,
because
I
noticed
that,
like
my
run,
images
have
the
layers
directory
as
slash
out.