►
From YouTube: Working Group: 2021-07-01
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
Looks
like
jesse
has
already
volunteered
to
be
today's
scribe.
Thank
you,
jesse
up
next
on
the
agenda
any
new
faces.
A
Theme
I
can
give
a
quick
update.
I
think.
B
B
Buttoning,
all
of
that
up
so
more
to
come,
the
release
candidate
will.
A
Come
out
first,
thanks
for
the
update,
natalie
platform
team,
we
have
any
platform
releases
coming
up.
B
We
do
we're
still
finalizing
a
lot
of
the
stuff
that
will
go
into
pack.
0.20,
that's
still
a
little
bit
nebulous
right
now
we
did
punt
it
from
or
postpone
the
release,
and
it
looks
like
we're
still
working
on
some
of
those
issues
so
stay
tuned.
Hopefully,
next
week
we
have
a
little
bit
more
of
a
concrete
date,
but
yeah
need
to
reach
out
to
david
dfr
for
more
details.
A
Sounds
good,
I
think
that's
about
it.
We
usually
don't
do
registry
distribution
stuff,
but
it's
been
a
while
any
updates.
There.
C
D
A
Awesome,
thank
you.
Okay,
so
next
standing
item
our
review
of
outstanding
rfcs.
A
D
D
And
there
were
some
concerns
about
like
this
moving
time
from
the
export
phase
to
the
build
phase
which
users
might
perceive
as
the
bull
phase
taking
longer.
But
I
am,
I
don't
know
what
people's
thoughts
are
on
that.
I
think
stephen
also
had
this
comment,
that
we
can
do
it
in
parallel,
so
that
it
feels
less
of
an
issue.
D
The
other
thing
I
was
thinking
that
we
could
do
was
use
like
f
log,
to
log
the
directory,
which
wouldn't
be
as
time
intensive.
What
may
serve
the
same
purpose,
but
I
haven't
looked
into
how
that
would
actually
work,
but
that's
pretty
much
it
like
in
in
terms
of
the
original
version
of
this
rfc
that
we
discussed.
A
Yeah,
I
guess
my
question
here
would
be
you
know:
can
we
actually
do
some
parallel?
If
the
point
is
to
do
it
in
advance
of
the
next
build
pack
running,
so
they
can't
modify
it.
You
know
yeah,
but
we
don't
need
to
dive
into
that
in
the
roundup.
This
is
something
we
want
to
talk
about
more
either
in
this
meeting
or
in
office
hours,
or
we
can
just
do
this
asynchronously
if
we'd
prefer
yeah.
I.
D
D
D
I
converted
this
from
a
draft
to
an
actual
rfc
and
trimmed
down
a
bunch
of
things
for
separate
rfcs,
given
that
we
we
thought
it
might
be
better
to
keep
them
a
separate
rfc,
so
one
of
them
is
moving
the
bomb
from
a
label
to
a
file.
How
bombs
for
stacks
would
work,
which
I
think
steven
was
also
working
on
and
then
how
much
the
stack
bombs
with
the
buildback
provided
bombs
during
build
and
rebates.
D
A
Everyone
take
a
look
at
that
remove
shell
specific
logic.
I
just
updated
this
to
change
the
environment,
variable
interpolation
format,
but
put
that
on
the
agenda
to
talk
through
a
little
bit
today.
A
These
are
not
rfc,
so
I'm
going
to
skip
them,
remove
stacks
and
mix-ins.
I
need
anything
to
say
on
this
one
right
now,
stephen.
B
So
I
split
the
can
you
hear
me
yep?
I
split
the
original
remove
stacks
rc
into
this
one
and
two
others
I'll
put
something
on
the
agenda
at
the
end,
to
just
kind
of
chat
a
little
bit
about
what
the
different
parts
are.
D
E
A
Review,
I'm
just
gonna
skip
over
the
next
two
because
I
think
you'll
probably
just
say
the
same
thing
about
them
right
and
then
last
but
not
least,
joe
cuttner,
officially
supported
utility
bill
tax.
C
Yeah
I
just
opened
this
so
give
it
a
look.
I
probably
won't
bring
it
up
today,
except
a
little
bit
in
the
context
of
emily's
bash
pr.
A
Great,
I
think
that
is
our
full
slate
of
rfc
statuses
up
next
in
the
agenda,
remove
shell
specific
logic
and
interpolation
options.
This
is
what
I
was
alluding
to.
So
I
guess
I
shouldn't
have
stopped
sharing
my
screen
hold
on.
Let
me
do
this
again,
okay,
so
I
just
wanted
to
call
out
to
folks
that
I
did
make
one
change
here.
A
Actually,
let's
look
at
the
readable
version
before
I
had
been
suggesting
that
we
use
bash
style
notation
for
environment
variables,
but
I
think
there
starts
to
be
some
ambiguity
there.
When
people
are
trying
to
use
bash
in
a
command,
we
might
be
jumping
in
there
and
evaluating
things
early
and
decided
that
going
with
the
kate's
option
was
probably
more
explicit.
A
A
Sorry,
there's
an
extra
parenthesis
here
that
I
need
to
get
rid
of.
You
have
to
escape
this
reference
in
your
command,
but
I
think
that
is
okay,
because
it
only
happens
in
certain
specific
situations,
and
it
feels
better
to
me
than
either
the
the
downsides
of
the
bash
option
or
inventing
a
totally
third
option
that
we
would
have
to
document
and
socialize.
A
Yeah,
that's
sort
of
what
I'm
trying
to
get
at
with
these
examples
here,
where,
first
of
all,
if
you
don't,
if
you're
not
specifying
it
in
explicitly
in
the
m
section,
you
don't
need
to
escape
it
anyways
because
case
won't
do
anything,
and
then
you
only
really
need
to
care
enough
to
escape
it
if
you're
expecting
the
launcher
to
apply
modifications,
so
I
feel
like.
Hopefully
this
is
a
minority
of
use
cases
and
when
they
arrive,
are
explicit
enough.
B
C
I
like,
I
think,
there's
plenty
of
other
problems
if
you're
trying
to
match
the
bash
syntax,
including,
as
I
mentioned
earlier
or
in
the
in
the
comments
like
I
think,
potentially
accidentally
leaking
things
that
people
don't
mean
to
leak
if
they
used
like
secrets.
So.
C
A
B
I
looked
for
examples
a
little
bit
of
different
notations
for
doing
this
and
the
most
similar
one
I
could
find
was
systemd
so
like
in
a
systemd
service
file.
They
do
use
a
bash
notation
with
or
without
the
curly
braces.
I
don't
know
if
systemd
is
the
best
example
of
a
great
user
interface
for
anything,
and
I'm
not
I'm
not
advocating
one
approach
over
the
other,
but
I
thought
it
was
kind
of
similar-ish
to
build
packs
sort
of
in
a
way.
B
A
Yeah
I
looked
up
the
whole
journey
kate's
been
through
because
they
started
with
fashion
notation,
and
then
people
are
asking
what
about
this
case.
What
about
that
case?
What
about
this
and
finally
someone's
like
scrap
it?
We're
doing
this
different
thing,
because
it's
very
explicit
and
simple-
and
I
think
you
know
all
of
that
logic
applies
to
us
too,
but
luckily
we
have
the
the
convenience
of
being
able
just
to
piggyback
on
their
notation
instead
of
having
to
socialize
a
new
one.
A
D
D
No,
I
I
was
just
saying
that
the
only
thing
I
wanted
to
add
here
was
like
being
able
having
the
ability
to
specify
defaults.
That
would
be
useful,
even
if
you
don't
support
the
rest
of
the
bash
syntax.
D
Over
having
a
default
environment,
variable
yeah,
it's
just
more
explicit
and
then
the
config,
that's
like
one
of
the
issues
I
have
with
environment
variables
in
general.
Is
that
since
they're
all
launch
time,
it's
very
hard
to
know
what's
said
beforehand,
so
if
a
user
wants
to
know
what
the
default
value
a
particular
process
is
going
to
export
like
currently
we
we
have
that
invocation
logged
in
a
label
right
like
we
say
this
is
the
process.
This
is
what
it
will
involve
if
we
had
like
a
default
notation.
C
Yeah
port's
a
really
good
example:
there
are
some
fringe
web
frameworks
that
don't
accept
or
don't
read
the
environment,
variable
port
themselves
and
don't
have
a
good
file
system
way
to
do
it.
So
you
have
to
pass
it
in
on
the
command
is
like
a
dash
dash
port
option
and
then
in
those
cases
it
can
be
really
annoying.
If
you
don't
have
the
default
8080,
you
know
colon-8080
or
something
after
it,
but.
A
C
Oh,
that's
alright,
but
that
already
exists.
I
mean,
like,
I
feel
like.
There
are
many
layers
to
where
you
put
those
like,
because
then
you
get
into
the
web
frameworks
themselves
and
they
have
their
own
like.
Oh,
I'm
gonna
look
at
application
properties
in
it.
So
I
don't
think
we're
like.
Yes,
that's
a
problem,
but
I
don't
think
it's
a
new
problem.
A
C
Yeah,
I
think
I'd
still
want
to
talk
about
it.
Username
like
usernames
and
passwords.
I've
seen
it
too,
where
the
default
is
just
like
some.
You
know
something
they're
using
on
localhost
or
something
I
mean
it's
not
a
showstopper,
but
you
know
we
should
think
about
it,
but.
A
A
D
It's
also
weird
to
me
like
where,
like,
if
you're,
if
a
buildback
is
specifying
a
process,
it
should
be
able
to
specify
the
defaults
for
that
process
while
at
the
same
time
say
that
hey,
if
you
don't
use
this
default,
you
can
override
it
with
this
environment
variable,
whereas
in
the
case
where
you
can't
specify
default
whatsoever,
you
have
to
separately
put
the
environment
variable
somewhere
and
the
process
somewhere
else
which
decouples
them
with
they're
tightly,
coupled
together,
like
that
environment
variable
is
only
used
by
that
process.
For
example,.
A
I
propose
a
a
compromise
right
now.
You
can
only
do
this
like
defaulted
environment
variable
in
a
command
like
this.
If
you're
writing
a
batch
process
right
and
if
your
bill
pack
is
contributing
a
batch
process,
you
can
still
do
this
with
batch
notation.
So
maybe
it
is
okay
to
leave
it
out
of
this
rfc
and
then
we
could
have
a
different
rfc
if
we
wanted
to
add
more
launch
features
like
this.
E
D
E
That
is
in
default.
Do
how
do
I
override
these
new
k8
style?
One?
Can
I
use
k
styles
in
the
entry
point?
Will
it
be
interpolated
sort
of
the
same
way.
A
So
if
you're
doing
another
process-
and
you
set
your
launcher
to
be
the
other
process
so
far-
you've
not
used
any
environment
variables.
But
let's
say
you
wanted
to
append
an
argument
and
you
wanted
the
value
of
that
argument
to
be
the
interpolated
environment
variable.
You
could
just
use
this
same
style
reference
which
I
think
actually
does
help
people
avoid
some
gachas
where
they
end
up
accidentally
evaluating
it
on
their
workstation
right
now.
E
E
C
So,
just
as
maybe
a
final
note,
I
don't
know
if
there's
more
to
talk
about,
but
this
was
this
rfc
was
kind
of
what
motivated
me
to
open
the
officially
supported,
build
packs
rfc,
because,
as
I
was
going
through
it,
you
know,
I
was
uncomfortable
sort
of
jettisoning
some
of
the
capabilities
like
the
dot
profile
and
the
app
repo
and
after
talking
with
emily
and
even
independently
thought
of
this
on
my
own
realized
that
what
I
care
about
is
the
capability
and
not
how
we
do
it
right,
and
so
I
kind
of
like
what
I
wanted
to
do
is
come
at
this
from
a
different
side
like
rather
than
like,
I
think,
emily's
thinking
more
from
like
life
cycle
implementation.
C
How
do
we
have
a
better
architecture?
That's
more
sustainable
lets
us
iterate
better.
We
don't
have
to
worry
about
changes
in
api
compatibility
and
things
like
that
as
much
and
I'm
thinking.
How
do
we
preserve
the
user
experience
and
I
think
the
way
we
one
way
we
can
do
that
and
what
I'm
proposing
is
by
moving
some
of
these
capabilities
that
are
problematic
or
complicate
the
implementation
life
cycle
into
build
packs
and
potentially
make
those
build
packs
even
default
like
we,
you
know,
I
like
I'll,
probably
have
another
rfc
coming
for
some
kind
of
default.
C
Build
pack
thing:
maybe
pack
injects
them
into
the
the
builder
natalie,
even
suggested
they
could
ship
with
the
life
cycle.
I
haven't
thought
about
that
as
much,
but
I
think
I
think,
there's
a
way
there
that
almost
100
percent
preserves
the
experience,
that's
important
to
me,
but
creates
a
better
or
like
a
different
coupling
between
a
different
way
of
coupling
the
build
packs
to
the
life
cycle.
Less
coupling,
but
you
know
it
also
kind
of
fits
with
this,
like
everything's,
a
build
pack
mantra
that
we
have
right.
C
B
I
really
like
sorry
go
ahead
steven.
I
I
I
really
like
the
tools
that
that
gives
platforms
right
because
there's
a
platform
now,
if
you
want
to
like,
I
think
a
great
example
of
this
is
like
the
way
we
did
environment
variables,
initially
with
strict
equals.
True
right,
like
there's
a
pretty
specific
feature
towards
a
platform,
and
if
we
implemented
that
at
the
build
pack
layer,
then
you
could
have
different
implementations
of
you
know:
environment
variables,
with
different
kinds
of
security
without
having
to
kind
of
build
niche
things
into
the
api.
B
I
just
I
keep
thinking
of
examples
of
things
that
we
we
added
for
this
feature
or
that
feature
you
know
for
different
use
cases
that
if
we
had
kind
of
pushed
them
up
a
level
you
know
it
would
have
kept
that
lower
level.
Part
cleaner,
so,
like
super
super
supportive
at
that
direction,.
A
I
think
the
ux
is
mostly
the
same
that
we
get
from
bill
pecks,
but
I
think
there
are
a
couple
areas
where
it's
actually
a
little
bit
better,
because
when
these
things
are
features
of
the
life
cycle,
it
seems
like
you
can
use
them.
You
know
whenever
you
want,
but
a
lot
of
them.
You
can't
use
on
like
different
stacks
and
stuff
like
this,
but
instead,
if
it's
in
a
build
pack
that
describes
like
you
know,
this
only
works
on
a
stack
with
bash,
then
sort
of
that
dependency
tree
starts
to
make
more
sense.
C
Yeah,
I
agree,
I
think
it
preserves
the
current
experience
and
actually
creates
a
like
break
glass
option
like
oh.
I
need
a
different
capability
for
how
I
do
dot
profile
or
I
need
to
update
lifecycle
for
security
patch
and
now
now
I
don't
have
to
worry
about
some
other
change
to
how
bash
works
or
something
so
in
that
sense
yeah.
I
think
it
is
a
burns.
D
The
only
comment
I
had
on
that
was
like
we
should
only
be
implementing
features
that
are
specked
out,
rather
than
any
random
utility
built
back
like.
Ideally,
they
should
be
driven
by
like
a
project,
descriptive,
spec
or
something
else
that's
properly
defined,
so
that,
like
it,
it
doesn't
spawn
multiple
different
implementations
which
have
slightly
different
behaviors.
D
So,
even
if
there
are
multiple
implementations,
you
still
end
up
with
the
same
result.
If
it's
picked
out
versus
like
I,
I
don't
know
how
like
what
the
difference
between
the
pacquiao
and
the
heroku
profile
buildbacks
are
or
like
if
they
work
exactly
the
same
way
or
if
they're
like
platform,
specific
histories
to
each
of
them,
where
certain
users
expect
certain
things
for
from
the
potato
one
versus
the
europa
one.
So
that's
the
only
thing,
I'm
cautious
about
that.
B
I
think,
as
long
as
the
utility
build
packs,
we
add
to
the
project
really
just
implement
the
you
know
underlying
feature.
We
want
right,
aren't
don't
have
platform
specific,
you
know,
conventions
in
them,
you
know
are
really
simple:
it's
not
a
huge
disadvantage
to
you
know,
platforms
that
do
have
those
requirements,
because
they're
simple,
build
packs.
They
could
reimplement
with
their
own.
You
know
functionality,
I
think.
That's
a
big
part
of
the
benefit
to
me
is
that
this
takes
some
of
the
core
functionality
of
spec
lets
platforms.
B
Customize
it
more
easily,
and
so
I
think,
there's
like
you
know.
Hopefully
it
doesn't
lead
to
too
much
contention,
because
when
there's
contention
we
just
say
leave
this
out
or
you
know
nope.
The
future
is
just
this:
that's
all
it's
going
to
do
at
the
project
level
right
or
make
it
configurable
and
work
both
ways
right
at
the
project
level.
B
If
you
know
everybody
thinks
that's
the
better
direction
to
go,
but
you
know
I
I
don't.
I
don't
kind
of
see
it
having
the
same
negative
impact
as
if
we
tried
to
make
all
those
decisions
for
what
a
node.js
build.
Pack
would
look
like
right,
because
it's
kind
of
going
out
of
scope
for
what
the
project
is
trying
to
accomplish
like
in
the
end.
You
know
if
we
want
the
project
to
state
of
the
tooling
and
the
api,
and
all
that
there's
no
reason
that
stuff
can't
live
at
the
build
pack
level.
C
Yeah,
I
think
the
trick
in
the
official
build
packs
will
be
figuring
out
how
to
draw
the
line.
So
I'm
not
sure
I'd
have
to
think
about
what
he
suggested
more
sam,
but
like
yeah,
I
think
we
need
more
conversations.
I
think
that's
what's
missing
from
our
rfc
is:
where
do
we
draw
the
line
between?
What's
a
utility
build
pack
and
what's
a
opinion,
opinionated
vendor
thing
so.
A
I,
like
straw
dog
line
here,
is
that
there's
certain
things
that
build
pack
can
contribute
and
when
it's
doing
that,
smartly,
because
you
know
it's
figuring
things
out
about
the
app
and
decide
making
decisions
it,
it
shouldn't,
be
a
utility
build
pack.
But
there
are
cases
where
you
want
those
build
pack
features,
but
you,
as
a
user,
just
want
to
tell
them
what
to
do.
A
D
C
Think
I
think
the
majority
of
it,
but
like
definitely
that
profile
is
a
little
bit
different.
So
there
are
some
cases
that
fall
outside,
but
I
yeah,
I
agree
with
you
and
like
yeah,
the
project
descriptor
built
back.
I
kind
of
forgot
about
that,
but
maybe
that's
the
usually
unless
we
well,
I
don't
know,
maybe
some
platforms
want
to
break
it
down.
I
don't
know.
D
D
I
was
saying
that
even
the
profile
like
that
that
was
currently
in
the
background,
so
even
if
it's
not
in
the
project
descriptor
it's
in
the
buildback
spec.
So
for
me,
that's
probably
the
boundary
if
you're
comfortable
putting
it
in
the
spec,
either
the
project
descriptor
or
the
built
aspect,
then
maybe
we
could
just
extract
it
out
in
the
future
as
a
officially
supported
pullback.
A
Do
you
think
there's
like
the
one,
the
one
thing
that
I
think
we
also
need
to
solve,
but
don't
need
to
require
it
to
be
solved
as
part
of
this
is
what
happens
when
you're
like
building
apps
from
an
artifact
like
a
jar
or
not
from
source
like
where
you
don't
have
the
project
descriptor
in
the
after.
I
think
we
need
a
way
to
provide
a
project
descriptor
without
coupling
it
in
the
after,
but
I
don't
think
it's
necessary
that
we
solve
that
now.
It
would
just
be
nice
to
create
this
whole
cohesive
ecosystem.
D
I
don't
know
if
you
want
to
continue
that,
but
we
had
this
discussion
in
the
gay
pac
working
group
and
the
option
was
you
could
provide
any
uri
to
the
project
descriptor.
So
the
uri
could
be
like
an
absolute
paths
in
the
workspace,
an
s3
url,
http
or
whatever,
and
that
would
be
the
project
descriptor.
A
Can
that
make
sense
from
a
platform
perspective
from
a
lifetime
classical
perspective?
I
was
wondering
if
like
putting
it
in
the
platform
dir
or
something
like
that,
would
make
sense.
So
then,
like
a
platform,
could
fetch
it
or
do
something
it
wanted
with
it.
But
that's
the
way
you
provide
it
to
the
life
cycle
and
that's
where
the
life
cycle
then
gives
it
to
build
packs.
D
D
The
the
only
change
I've
made
since
the
last
time
we
talked
about
was
like
how
do
we
accommodate
this
into
existing
platform
apis
and
my
solution
was
to
have
this
at
exported
directory
under
the
layer
store
because
currently,
although
buildbacks,
which
are
published
to
the
registry,
require
a
namespace,
that's
not
a
restriction
in
the
spec,
so
someone
could
have
a
buildback
called
exported
and
it
would
still
be
valid.
But
we
don't
allow
like,
at
the
rate
as
a
possible
character
in
the
ide
and
the
platform.
Api
would
roughly
remain
the
same.
D
The
builder
would
still
be
past
the
layers
directory
and
life
cycle
implementation,
but
now
just
put
it
in
the
exporter
directory
and
then
the
exporter
is
again
past
the
layers
directory.
So
we
just
read
from
this,
and
we
could
also
calculate
the
diff
ideas
here
and
store
it
in
some
conventional
format
based
on
the
life
cycle
implementation,
but
that
should
be
the
other
main
question
that
people
had
on
this
rfc
was
around
like
perceived
slowness
during
the
build
process.
D
I
don't
know
if
people
have
any
thoughts
on
this
where,
since
we're
moving
some
part
of
the
responsibility
of
the
export
phase
into
the
build
phase,
people
will
think
that
the
buildback
is
slow
or
like
what
it's
doing
is
slow,
but
maybe
we
could
alleviate
that
by
simply
logging
that
exporting
these
layers
out,
rather
than
saying
that
hey
I'm
running
this
build
back,
I
mean
at
the
end
the
net
time
it's
going
to
take
for
the
whole
image
to
be
built
would
be
the
same.
D
Yeah,
the
the
other
option
that
I
was
thinking
of
was
like
if
we
avoid
all
of
this
and
if
we
could
somehow
lock
the
previous
buildback
directories
to
be
with
the
right
lock
that
the
lifecycle
owns
and
only
release
it
at
the
very
end
when
we
want
to
like
oh
well,
I
don't
think
we
even
need
to
release
it
at
any
point
once
like
the
buildback
has
finished
execution
and
that
could
potentially
prevent
subsequent
build
packs
from
writing
things.
D
D
D
B
B
That
needs
to
happen
no
matter
what
you
can
also
just
copy
all
the
layers
somewhere
else
and
then
process
them
in
parallel
with
the
rest.
But
if
we
want
to
avoid
copying
right,
synchronously
tar
up
all
the
build
equals
two
layers,
take
the
rest
of
the
layers,
move
them
out
and
then
start
targeting
them
up
in
the
background
as
the
rest
of
the
build
packs
execute,
because
nothing
else
needs
access
to
the
rest
of
the
layers.
A
I
said
it
couldn't
be
done
in
parallel.
I
didn't
mean
like
multiple
layers
from
the
same
build
pack,
but
I
feel
like
frequently,
at
least
in
the
wild
I've
experienced
that
most
build
packs
are
not
making
many
layers
at
the
same
time,
they're,
making
like
one
or
two
usually
one
is
the
big
one
and
then
there's
like
some
little
thing
but
yeah.
Maybe
we
maybe
we
could
just
make
this
work.
B
I
think
the
sequentialness
of
the
kind
of
process
right
now
it
like
is
a
place.
We
lose
some
performance,
you
know,
because
we're
usually
running
on
machines
that
have
more
than
one
cpu
right.
I
think
the
more
things.
B
The
only
thing
that's
really
sequential
you
know
that
we
have
to
preserve,
is
all
the
build
scripts
have
to
process
the
app
directory,
and
so
they
they
can't
run
at
the
same
time,
buildpacks
themselves
could
write
layers
in
parallel,
but
they
don't
generally
know
that,
but
so
I
you
know,
I
really
think
that's
kind
of
a
separate
benefit
from
the
proposal
is.
If
we
move
into
the
builder,
then
we
can
really
start
to
have
more
flexibility.
There.
A
I
have
looked
into
parallelizing
sort
of
the
tarring
in
the
exporter
before.
If
you
get
a
little
bit
careful
because
you
can't
just
parallelize
all
of
it,
then
it's
slower
we're
usually
like
cpu
bound
right
and
you
don't
want
to
like
switch
a
bunch
of
different
processes.
D
D
D
D
D
D
A
What
I'm
curious
about
is,
I
think
now
so
I
started
thinking
about
caching
lately
and
I
wanted
to
do
this
asset
cache
thing.
I
think
we
have
lots
of
types
of
caching
in
ways
to
get
confusing,
and
I
think
there
is
another
type
of
caching
that
my
rmc
did
not
solve,
for
which
is
sort
of
like
between
builds
bill.
Packs
want
to
share
things
like
a
maven
cache
right.
A
Doing
this
exact
proposal
doesn't
sort
of
allow
you
to
open
it
up
to
be
cross,
build
because
it's
still
very
much
in
our
layer.
You
know
cache
restore,
be
careful
about
what
you
put
in
there
model
I
feel
like.
We
need
to
come
up
with
something
that
solves
these
similar
use
cases
maybe
differently.
I
don't
know
exactly
what
the
idea
is
here.
You
get
it,
but
I
think
to
totally
solve
all
of
our
caching
needs.
A
A
D
E
Situation
like
if
you're
running
on
your
desktop
and
in
a
bill,
packer
two
build
packs
requests
like
a
maven
directory.
Then
pat
could
just
give
the
host
maven
directory
or
something
like
that.
Then
they
would
benefit
from
that,
but
it
wouldn't
end
up
in
the
image
it's
that
kind
of
what
you're
thinking.
A
D
A
D
D
C
C
E
I
don't
know
yeah,
I
keep
circling
back
around
heroku
just
has
like
a
dumb
cash
thing.
That's
just
always
restored
like
it
doesn't
tie
to
anything.
I'm
like
it's
just
easier
to
reason
about,
even
if
it
does
mean
it
like
grows.
You
know,
platforms
have
to
deal
with
a
way
to
like
dump
it
or
something,
but
I'm
like
eh,
it's
fine.
It
just
doesn't
feel
all
the
ceremony
bothers
me
a
little
bit.
A
C
D
D
E
B
C
Governor,
that's
like
I've
definitely
seen
that
in
other
projects
where
it's
just
like.
This
is
a
great
idea,
but
we're
just
not
ready
to
tackle.
C
B
C
B
C
C
Yeah,
I
think
this
is
just
a
call
to
action.
I'll
speak
on
javier's
behalf
of
something
he's
here.
I
reviewed
it,
but
so
he's
got
a
pr
out
there.
That
does
some
awesome
magic
and
I
don't
think
it
should
be
held
to
the
the
same
voting
restrictions
as
an
rfc.
C
C
A
A
Sounds
like
terrence
sure.