►
From YouTube: Working Group: 2020-10-01
Description
* Close GCP Project?
* Asset Packages: https://github.com/dwillist/rfcs/blob/offline-buildpackages/text/0000-offline-buildpackages.md
* Process Types: https://github.com/natalieparellano/rfcs/blob/buildpacks-default-process/text/000-buildpacks-contribute-default-process-type.md
C
I
heard
some
like
like
a
beep,
but
you
were
muted,
so
I
guess
maybe
it
wasn't
you.
I
don't
know.
D
C
A
A
A
Looks
like
we
don't
have
natalie
this
time,
but
I
know
she
had
some
questions
for
you,
emily
about
the
or
there
were
just
general
questions
yesterday
about
use
cases
for
having
as
many
states
and
process
types
or
something
overriding
the
default
versus
overriding
the
command
versus
something.
I
think.
A
I'll
put
that
at
the
end
of
the
agenda,
then
then
we
can
cool.
A
And
then,
before
we
kick
things
off
as
a
reminder,
we're
trying
to
figure
out
if
we
can
close
the
gcp
project,
we
deleted
a
cluster
there,
it
didn't
seem
like
it
was
being
used
for
anything
and
does
anybody
know?
A
B
I
know
we
just
moved
release
automation
over,
so
we
can
decommission
concourse,
which
is
the
big
thing
that
was
in
there.
There
are
a
bunch
of
historical
artifacts
in
the
s3
buckets
that
I
don't
know
if
we
want
to
delete
all
that
history
also,
I
think,
has
been
used
in
the
past
to
develop
the
tecton
template.
I
mean
you
can
do
that
locally
with
kind,
but
I
do
think
it's
useful
to
have
some
infrastructure
for
that
purpose.
B
A
Are
we
are
the
costs
under
the
100
something
dollars
a
month?
Now
that
the
cncf
said
they'd
pay.
B
A
Sounds
good
I'll
add
a
resolution
there.
B
A
Sponsor
should
move
on
to
asset
packages.
D
Doesn't
work
that
well
so
just
computer
audio
for
me,
okay,
so
this
has
changed
a
little
bit
since
last
time.
I
guess
I
can
kind
of
talk
more
generally
about
it.
That's
a
good
place
to
start,
but
I
guess,
let's
kind
of
like
go
over
those
small
changes,
because
there
wasn't
that
much
extra
stuff
that
needed
to
be
added
and
then
go
over
any
other
questions.
So.
D
I
think
that
pretty
much
what's
been
added
here
is
that
matt
mcnew
wanted
a
lot
of
additional
information
about
asset
packages
pushed
into
the
builders
and
build
packages,
so
basically
kind
of
we're
going
to
have
this
generic
structure
that
it's
a
list
of
assets
uri
to
the
asset
package.
It's
digest
some
id
inversion
information
and
then
the
layer
div
ids,
along
with,
like
the
shaw,
the
asset
that
that
specific
layer
can
contain
and
all
that's
going
to
get
kind
of
pushed
around.
D
D
I
guess
the
second
thing
was
that
originally
there
was
kind
of
a
addition
here
to
each
asset
package
that
had
some
additional
paths
that
we
would
make
artifacts
available
at
because,
but
now
because
we're
just
using
like
archives,
we're
not
letting
people
unzip
their
acids
directly
directly
into
a
layer.
We
don't
really
need
that
anymore
and
yeah.
I
guess
just
some
generic
like
naming
changes
so
like
you
can
use
any
digest
algorithm.
You
want
to
package
your
assets
in
case
you're,
not
comfortable
using
sha
256,
but.
A
One
thing
I
wanted
to
bring
up
is
the
framing
so
yeah.
We
said
we
like
assets
versus
dependencies.
I
I
think
I
like
I
like
that
direction.
One
thing
I
would
I
would
change,
though,
is:
if
you
change
it
to
assets,
then
I
think
you
kind
of
lose
this
expectation
that
they
might
not
be
present,
and
these
cases
we're
looking
at
it's
like.
A
We
want
platforms
to
be
able
to
decide
whether
or
not
assets
are
available
in
some
cases.
In
other
cases,
and
so
I
I
I
propose
that
we
change
the
title
from
asset
packages
to
asset
cash
packages.
Instead.
A
Does
anybody
feel
strongly
like
that's?
We
shouldn't
set
that
expectation.
A
We
expect
build
packs
to
work
without
assets,
also
right,
it's
like
to
let
give
you
offline
support.
So
if,
if
ruby's
available
locally,
the
bill
pack
doesn't
have
to
go
and
reach
out
and
download
it
right,
for
instance,
if
we,
if
we
get
this
through
as
generic
asset
support,
then
if
you
read
everything
verbatim,
it
just
looks
like
it's
saying:
this
is
a
way
you
can
include
assets
with
the
build
pack.
A
You
you
might
create
a
build
pack,
that's
wholly
dependent
on
those
assets
where
the
platform
wouldn't
be
safe
for
a
platform
to
say,
I'm
gonna
run
a
build
without
these
assets,
so
you
have
to
you
get
into
a
situation
where
you'd
need
a
copy
of
the
build
package
that
didn't
have
them
in
order
to
be
feel
to
feel
safe,
running
up
in
a
platform
without
them,
and
I
think
we
we
don't
want
that.
A
A
A
D
D
A
I
just
I
just
wanted
to
ask
the
last
time
that
I
discussed
this
with
you.
There
was
some
discussion
about
there
also
being
need
for
these
kind
of,
like
meta
asset
packages,
to
be
able
to
say
like
oh,
I
have
you
know
some
particular
assets
say
for
like
ruby
and
maybe
or
like
mri,
and
then
I
have
some
subsets
for
say
like
jruby,
and
I
want
to
be
able
to
like
have
those
as
separate
asset
packages,
but
then
maybe
have
like
a
parent
ruby
asset
package.
That
collectively
includes
both
say
like
mri
and
jruby.
A
D
C
A
D
I
think
that's
what
everything
else
is
called
like
if
I
inspect
the
labels
on
a
build
package
or
builder,
that's
like
the
term
that
we
use.
D
Okay,
well,
I
love
any
of
that
feedback.
Oh
right.
A
There's
a
question
about
id
inversion:
yes,
the
currently
at
the
top
level
we
have,
or
we
define
the
package
by
a
digest,
an
id,
a
version
and
it
says
uri,
but
it
probably
is
like
supposed
to
be
a
ref
or
something
I'm
looking
to
build
package
label.
But
I
think
it's
the
same
stuff
there
yeah
yeah,
the
id
and
version
are
necessary
or,
like
I
think,
nick
new
wanted
the
idn
version
there.
A
B
B
A
It
could
be
a
way
to
find
it
from
the
build
package,
no
matter
where
you
are
right.
It's
like
it's
like.
Without
that
information
coming
from
the
build
package
to
get
to
the
asset
package,
you
know
what
digest
is,
but
you
have
no
idea
where
it
could
be.
It
could
be
just
like
a
canonical
location
where,
if
you
don't
have
it,
you
could
go
here
to
get
it.
That's
why
I
kind
of
like
the
idea
of
having
the
ref
in
the
build
package
thing.
A
I
was
more
wondering
if
maybe
id
and
version
should
be
name
or
something
like
that,
just
like
descriptor,
so
that
people
can,
you
can
call
it
something
in
log
output.
If
we
don't
have
a
it's,
not
really
a
unique
idea,
that's
you
know
being
enforced
that
it's
not
other
things
right.
It
seems
like
we're
using
the
digest,
for
that.
I
think,
maybe
just
to
name
for
both
those
fields
together
would
be
be
sufficient.
D
Yeah,
the
kind
of
reason
I
wanted
to
thought
about
having
two
was
just
that
there's
this
kind
of
linkage
to
like
build
packs.
A
I
think
you
wouldn't
want
a
version
of
the
same
as
the
build
pack,
though
right,
because
the
build
pack
may
change
without
the
dependencies
changing
and
then
then
you
end
up
with
slightly
offset
versions
which
are
like
worse
than
it's
like
two
versions
that
look
similar,
but
aren't
you
know
I,
unless
we
have
a
use
for
the
id
and
version
there
like,
I
think,
just
some
descriptors.
They
understand
this
is
the
potato
ruby
asset
package.
You.
D
C
B
Right
now
we're
saying,
like
a
bill
pack
to
get
around
the
fact
that
an
asset
isn't
in
a
registry.
A
bill
pack
contains
like
a
reference
for
a
place.
They
might
want
to
look
up
in
asset,
but
then,
maybe
later
we
have
a
different
place.
They
might
want
to
look
it
up,
but
if
instead
it
just
has
the
id
inversion
coordinates,
then
you
know
that
you
need
to
configure
whatever
system
you're
using
have
a
registry.
A
The
reason
I
was
part
of
the
reason
I'm
suggesting
name
is
because
for
build
packs
we
have
a
name,
an
id
and
a
version,
and
so
if
we
start
with
name
as
a
just
a
log
descriptor,
then
we
can
add
90
inversion
later.
If
we
need
it
and
they
all
everything,
still
works
together.
It's
purely
additive
change,
yeah,.
C
A
A
C
Now
I
definitely
liked
emily's
idea
of
the
registry
down
the
line.
As
a
thing,
I
can
imagine
potentially
a
service
that,
given
a
one
like
this
file
and
a
build
package,
you
could
for
a
bill
packet,
construct
a
bill
package
based
on
the
assets
from
said
registry.
C
A
C
D
A
A
A
D
Yeah,
I
guess
one
of
the
things
I've
been
thinking
about
recently
around
our
reliance
on
these
diff
ids
is
that
we
have
to
have
some
way
to
take
huge
asset
packages
that
have
too
many
layers
and
squash,
some
of
them
down
into
one
layer
right
and
so
suddenly
we
can
have
diff
ids.
I
think
that
change.
D
And
so,
at
the
end
of
the
day,
like
the
most
reliable
thing
that
you
can
use
to
figure
out,
if
you
actually
have
an
asset
available
to,
you
is
the
like
digest,
because
it's
just
kind
of.
A
Like
I,
I
see
there
that
the
individual
layer
diff
id,
has
multiple
assets
under
it.
I
thought
that
was
to
account
for
that,
so
that
that,
in
the
future,
if
you
had,
if
we
had
to
squash
them
together
when
we
built
the
package,
because
it
was
too
many
things,
you
could
just
collect
all
the
different
assets
inside
of
the
that
one
def
id
into
the
list.
B
I
think
it's
just
grabbing
the
assets
that
are
in
that
layer.
So
if
you
change
the
number,
if
you
change
the
assets,
you
would
change
the
later.
I
think
to
do
it.
Steven's
subscribing,
which
is
not
how
I
originally
read
this,
but
now
I'm
looking
closely.
I
see
that
that
makes
sense,
but
the
id
and
version.
B
I
thought
we
were
talking
about
the
idea
version
of
an
asset,
but
I
guess
we're
talking
about
the
idea
version
of
a
what.
What
are
they
referencing.
D
B
D
B
B
I
guess
if
I
I
can
imagine
a
world
where
I
want
to
fetch
a
asset
by
id
and
version
out
of
a
registry,
but
I
don't
know
why
I'd
be
referring
to
an
asset
package
at
that
point.
Does
that
make
sense
from
referring
to
a
package?
I
might
as
well
refer
to
the
image.
B
B
Yeah,
if
I
know
that,
like
ninety
percent
of
my
applications,
use
java
11
and
only
a
couple
are
still
in
shop
at
eight-
I
might
say
it's
worth
it
to
me.
For
those
java,
eight
builds
to
be
slower
and
download,
but
I'd
like
to
cache
java
11
for
the
bulk
of
the
apps
in
the
builder
image.
Something
like
that.
D
C
A
Same
the
reason
going
back
to
the
layer,
squashing
problem,
so
layer,
squashing,
is
only
a
problem.
Each
time
you
decide,
you
need
to
generate
an
image
right,
and
so,
if,
if
you
generate
the
asset
package,
you're
going
to
have
a
fixed
set
of
diff
ids
that
you
can
reference
and
build
package
right
and
at
that
point,
there's
no
point
where
you'd
want
to
do
squash.
A
You've
already
squashed
you've
already
put
the
assets
together
because
it's
already
a
list
right
per
diff
id
and
then
next
the
next
time
you
want
to
construct
an
image
is
when
you're,
maybe
constructing
a
builder.
But
at
that
point
you
can
use
the
build
package.
Metadata
use
the
asset
metadata
join
everything
together
and
then,
if
you
had
to
regenerate
devides,
you
could
regenerate
them
for
whatever
you
want
to
put
on
the
builder
about
the
asset
package.
But
but
it's
already
resolved
at
that
point.
So
I
don't
think
it's
going
to
be
a
problem.
D
Yeah,
so
the
kind
of
the
case
that
I
was
thinking
about
is
you
have
a
builder
already,
and
one
of
the
build
packages
in
your
builder
represents
or
references
an
asset
image.
That's
not
in
the
builder
right
so
like
you've,
partially
vendored
your
builder,
just
like
what
emily
was
talking
about
earlier,
where
you
just
have
java
11
present
and
there's
a
ton
of
layers,
so
you've
squished
some
of
them
down.
D
B
D
How
does
the
platform
figure
out
so
one
of
the
things
that
this
outlines
is
like?
Oh,
the
platform
should
have
the
ability
to
like
pull
asset
packages
from
somewhere.
If
it
wants
to
right,
it
can
figure
out
how
but
should
have
that
ability,
so
the
platform
needs
to
figure
out.
Oh,
I
have
a
builder
that
has
some
asset.
D
B
This
is
something
I
was
thinking
about,
that
sort
of
goes
against
what
stephen
was
saying
about
not
having
ids.
I
was
wondering
if
we
wanted
to
have
the
lookup
table
be
up
like
you're
looking
up
assets
by
id
and
then
within
that
you
find
out
what
diff
id
describes
the
layer
that
your
asset
is
in
and,
like
maybe
the
two
different
assets
end
up
listing
the
same
diff
id,
but
is
that,
like
a
more
useful
way
to
read
the
data,
I
think
in
either
case
you
could
do
what
you
wanted,
though,
because
it's
all
there.
D
Yeah
yeah,
I
think,
yeah.
I
think
that
would
totally
work
anything
where
you
have
like
all
of
the
leaf
like
nodes
in
an
asset
package
kind
of
like
labeled
in
a
very
specific
way
or
in
a
unique
way.
Lets
you
just
like
construct
this
set
and
say:
oh
everything
I
want
is
here
or
I'm
missing
something.
I
think
I
think
we
can
get
around
this
by
just
using
like
digests
as
long
as
you
can
say,
they're
unique
you
should
be
okay,
but.
A
D
D
A
I
I
think
I,
like
emily,
suggested
structuring
of
the
data
a
little
bit
better.
I
think,
because
carrying
around
that
digest,
as
the
thing
that
build
packs
say
they
depend
on
seems
safer
because
it's
it
it
does,
even
though
I
don't
think
we'll
necessarily
have
def
id
problems.
You
know
it
gives
you
a
permanent
reference
to
exactly
that.
Artifact,
when
the
build
packs
need
it
as
long
as
the
you're
willing
to
decorate
the
everything
with
all
of
those
digest
with
all
of
the
individual
asset
digests
and
not
layered.
A
If
I
digests,
if
that
makes
sense,
which
is
a
question
because
we
have
a
lot
of
those
in
some
places,
but
I
think
it's
probably
the
safer
thing
to
do.
It
avoids
this
multi-level
problem
right
and
then
then
pushes
the
how
the
data
is
structured
into
the
no
details
of
of
each
sort
of
asset.
A
A
So
your
question
of
like
when
you're
constructing
a
builder,
what,
if
you
already
have
a
builder
and
you
want
to
construct
more
I'd,
say
defer
that
until
you
have
that
problem,
because
in
many
cases
you
you
probably
would
just
regenerate
your
builder
for
your
build
packages.
If
that
makes
sense,
it's
like
that.
That
situation
is
like
when
you
already
have
a
builder
right
and
you're,
trying
to
extend
the
builder
with
more
things
that
weren't
included
in
it.
Originally,
I
don't
know
if
I
have
examples
of
platforms
where
they
would
need
that
functionality.
D
B
B
A
Because,
like
the
build
pack
is
going
to
reach
out
to
get
the
asset
anyways,
if
you
have
a
online
builder,
it's
like
doing
two
kinds
online
builder,
an
online
builder
that'll
pull
required
all
the
required
assets
for
build
pack
ahead
of
time
if
it's
an
asset
cash.
At
that
point,
don't
you
just
wanted
to
reach
out
to
the
one
asset
that
you
actually
need
during
your
build
with
the
detection
logic
in
there
to
refine
that
down
to
exactly
one
asset
that
you
need?
That
seems
better
yeah.
I
would.
I
would
not
worry
about
that
case.
D
It
does
give
like
some
of
the
users,
something
that
they
have
kind
of
been
asking
for,
which
is,
if
I
have
this
behavior
and
I
do
one
build
with
java
11.
and
then
I
do
another
build
with
the
same
builder
and
make
a
totally
different
image.
Suddenly
that
asset
cache
has
been
pulled
down
and
I
can
potentially
reuse
it
on
the
second
build
right.
D
A
If
it's
going
to
be
that
dynamic,
I
feel
like
you,
should
not
be
pulling
all
the
assets
ahead
of
time.
The
build
pack
should
just
be
downloading
the
asset
it
needs
right
because,
like
the
problem
is
that
the
build
pack
can
always
download
less
than
we
can't
the
platform
can,
because
it
can
know
what
it
needs
during
the
build.
It
could
be
optional,
build
packs
that
don't
run
that,
therefore,
don't
pull
the
dependency.
A
But
if
you
try
to
do
anything
static
ahead
of
time
in
trying
to
figure
out
what
what
you
know,
what
you
don't
need,
it's
going
to
be
less
efficient
because
you're
going
to
download
more
stuff,
and
so
it's
like
it
kind
of
kind
of
makes
sense
like.
If
you
have
room
to
you,
know,
fill
up
all
these
asset
packages.
It's
not
expensive
to
have
all
those
presents
and
do
it
otherwise
you're
building
on
the
edge
somewhere.
A
D
Okay,
all
right
I'll
think
about
flipping
this
around
and
would
love
some
of
the
kind
of
like
naming
and
other
concerns
that
you
have
stephen
in
your
head.
B
I'm
concerned
that
the
if
this
is
necessarily
the
uri
that
you
created
the
package
from
that,
it's
not
always
something
that
we
want
to
be
for
the
asset
uri.
It's
not
the
exit
package,
not
necessarily
something
we
want
to
be
sharing,
especially
like
you
can
create
it
from
a
local
tar
or
something
private.
On
your
registry.
D
Okay,
all
right
thanks
for
the
feedback,
I
guess
before
I
take
up
all
the
time,
sir.
I
think
there's
some
other
stuff
on
the
agenda.
A
Yeah,
I
think
process
types
was
next.
A
I
think
we
have
natalie.
We
did
some
discussion
yesterday
about
process
types
where
we
we
just
try
to
summarize
at
a
high
level.
It's
like
they're.
We
think
we
have
five
states.
It's
like
you
can
override
a
command
can
override
another
command.
Should
you
be
able
to
say,
like
don't
override
web
process,
if
there's
already
a
web
process
or
don't
override
a
worker
process,
if
there's
any
work
process
and
there's
also
expressing
this,
this
process
type
should
be
the
default
process
type.
You
know
like
with
a
key
attached
to
that
particular
process.
A
Type.
You
know
be
a
web
or
worker
whatever
this
is
the
one
that
should
do
that
then
there's
maybe
another
set
of
state
another
another
single
state
or
something
that's
in
the
case
that
you've
specified
that
you
want
this
process
type
to
be
the
default
process
type
and
something
else
has
specified
that
this
process
type
wants
to
be
the
default
process
type.
Should
we
have
a
flag
that
says
yes
override
that
versus
no
don't
override
that
right?
A
So
you
could
express
this
with
three
booleans
where
one
one
combination
of
the
three
booleans
is
is
not
allowed
or
just
doesn't
mean
anything
different
from
another
one
or
we
could
use
a
series
of
names
or,
and
then
simon
brought
up
an
idea.
That
was
we
could
use
integers
or
or
some
you
know,
like
five
states,
essentially
to
just
purely
express
priority.
A
Instead
of
that
whole
system,
and
you
could
get
roughly
the
same
outcome
because
you
could
still
for
any
given
process
type,
you
could
say
this
is
really
important
and
it
always
ends
up
doing
that
or
you
could
say
this
is
not
very
important
and
it
never
does.
And
then
you
know
how
the
states
are
relative
to
each
other,
actually
give
you
the
same
roughly
the
same
gradient
as
those
five
states
without
having
to
worry
about
the
semantic
meaning
of
each
each
flag.
A
I'm
going
to
summarize
that
well
one
last
time,
so
I
think
the
question
the
end
we
had
emily
for
you
was,
do
you
have
before
we
start
thinking
about
which
interesting
ux
we
want
to
use
to
express
the
five
states.
Do
we
have
a
need
for
all
three
of
those
toggles.
B
B
The
reason
I
wanted
it
there
in
the
first
place
was
so
that
some
of
the
stuff
is
less
order
dependent
like
if
I
wanted
to
add
a
build
pack
to
my
build
that
I'm
consuming
a
bunch
of
other
build
packs.
But
I
want
to
add
one
to
every
group:
that's
like.
If
nothing
else
is
going
on
here
should
be
the
default
process.
I
don't
have
to
think
about
exactly.
B
I
guess
you
could
just
go
in
the
beginning
if
you
really
want
to
do
it
that
way,
but
I
think
we're
leaning
into
the
order
dependence
now
with
the
override
and
therefore
that
motivation
doesn't
feel
as
important
to
me
now.
You've
said
the
order
dependent
part
of
this
is
okay
and
we're
going
to
structure
more
around
it,
and
I
think
we
just
take
it
out.
A
And
to
summarize
there'd
be
two
billions
like
override
yes
or
no
in
default,
yes
or
no
on
each
process
type
yeah,
not
only
any
any
thoughts.
C
B
A
As
a
as
an
edge
case,
if
you
had
a
worker
process,
that
was
a
default
worker
process
set
in
a
previous
build
pack
and
you
set
override
equals
false
default,
equals
true
on
your
web
process
in
a
subsequent
build
pack.
Would
you
that
would
the
override
would
be
meaningless
because
there's
no
existing
web
process
and
you
would,
even,
though
you
didn't
set
override
to
true
you-
would
change
the
default
from
the
worker
process
to
the
web
process
and
that's
expected
behavior.
B
B
Although
I
think
what's
interesting
about
this
solution,
is
that
in
some
ways
override
ends
up
being
a
feature,
we're
adding
that
has
nothing
to
do
with
defaulting,
which
was
the
original
point
of
this
rfc
right
like
we
think
we
introduced
it
to
solve
some
problem
that
was
introduced
by
defaulting,
but
I
don't
think
it
solves
that
problem
anymore,
because
it's
orthogonal
to
it
it's
about.
Can
I
override
web
or
not,
which
is
a
problem
that
people
already
have,
and
we
always
say
last
ones.
C
I
I
think
it
only
came
in
because
of
the
edge
case
that
jesse
brought
up
right.
It's
like
what
do
you
do
if
you
set
something
like
if
I
set
web
to
default
and
then
some
other
build
packs
that
some
other
process
to
default,
like
worker
or
whatever,
and
but
like
another,
build
pack
rate
defined
worker
like
does
that
change
it?
B
C
Yeah,
I
think
so
yeah.
I
think
that's
basically
it
because
you
kind
of
have
to
have
knowledge
that
there
is
a
default
in
order
to
not
clobber
the
default
before
you
yeah,
it's
okay.
I
think
it's
all
right
personally,
if
we
just
like,
don't
have
a
default
in
that
situation,
but
it
does
mean
that
buildbacks
may
be
a
little
too
brittle
to
like.
You
know,
interplay
in
that
way
or
confused
yeah
yeah.
C
C
B
C
Pre
the
override
flag
right,
the
functionality
would
be
I
defined
process
b
and
process
a
right
and
another
build
another.
Build
pack
also
define
these
process
types
and,
since
I'm
later,
in
the
cycle
override
by
default
is
true
or
not.
By
default
like
it,
the
way
it's
written
now
is
override
equals.
True,
all
the
time
right.
B
A
B
C
Steven
had
this
suggestion
yesterday,
I.
A
A
C
C
The
I
I
guess
I'm
just
trying
to
think
of
like
like
these
are
all
great
theoretical
use
cases,
but
I'm
just
trying
to
map
it
to
like
a
real
world
use
case
of
like
something
in
practice
where
you'd
actually
want
to
redefine
a
thing
but
not
set
the
default
if
it
got
overwritten.
That's
what
we're
saying
we
want
to
happen
in
that
weird
case.
B
B
So
realistically
none
of
these
edge
cases
matter
to
me
as
a
build
pack,
author.
A
C
I
mean
I
definitely
have
a
use
case
that
we've
seen
at
heroku.
I
think
this
definitely
comes
up
more
when
you
have
ecosystem
of
bill
packs
versus,
if
you
are
a
company
that
has
built
packs
where
you
can
coordinate
it.
It's
just
like
okay,
well
as
a
company,
just
make
sure
your
stuff
works
together.
If
that
was
yeah.
B
C
I
mean
maybe
like,
but
then
you
still
have
to
coordinate,
to
make
them
different
names.
I
guess
like
a
co
like
a
the
use
case,
I'm
thinking
of
is
like,
if
I
have
a
say,
like
I
don't
know,
react
app
right
that
just
uses
the
note
bill
pack,
initially
right
or
some
combination
that
becomes
the
node
built
back
right
and
I
want
to
serve
those
assets.
You
know
like
in
development
I
use
node
to
serve,
and
you
know
my
initial
deployment
will
just
use
the
node
web
server.
C
You
know
I'll
run,
you
know
node
node,
start
or
npm
start,
and
it
runs
my
web
server
and
just
you
know
not
very
optimally,
but
node
has
a
web
server
that
can
just
serve
out
these
stack
assets
right
and
does
the
right
thing
like
it
does
locally
and
then
maybe
down
the
line.
It's
like.
Oh,
I
learned
like
I
need
to
add
some
front
like
a
proxy
or
some
front
end
thing
in
front
like
an
nginx
or
apache
right
for
performance.
I
think
it's
like
a
common
pattern.
C
I've
seen
and
like
you
know,
like
it's
also
going
to
set
a
thing
similar
to
web
for
sure
you
could
call
it
some
something
else,
but
there's
not.
I
don't
think
it's
particularly
a
great
reason,
necessarily
to
name
it
something
differently
right.
I
I.
B
C
A
I
think
this
is
why
either
last
ones
or
user
selects
the
name
of
the
process
type
they
want
to
run
for
the
build
pack
are
attractive
because
that,
like
you're
expressing
a
situation
where
you
don't
want
the
build
pack
to
have
a
say
in
what
happens,
because
the
build
pack
doesn't
know
how
it's
being
used
right.
If
it's
going
to
be
first
or
last
or
or
whatever
right
like
it,
doesn't
know
if
it
should
override
the
thing.
So
the
decision
that
can
be
put
on
the
user
and
a
way
to
do
that
is
either
use.
C
C
That
kind
of
lets
you
at
either
end
set
default
as
like
the
first
build
pack
that
and
if
no
one
else
has
built
back
that
you
can
run
all
the
namespaced
webs
of
new
ruby,
slash
web
ninja
next
web
yeah
anyway,
I
think
that's
I
like
that.
The
best
okay,
I
think
in
v2
land.
We
use
basically
the
thing
that
no
one
else
likes
to
use
the
bin
release
script
is
we
can
set
basically
process
types
in
there
and
then
later
build
packs
can
override
them
and
that's
how
we've
solved
that
use
case.
B
I
feel
like
well,
it
would
be
nice
to
be
able
to
access
every
bill
pack
name
space
right
now.
We
can't
do
that.
I
think
there's
a
win
here
to
get
just
by
setting
a
process
to
default.
I
think
some
of
the
stuff
we've
done
to
make
it
more
complicated
came
out
of
a
time
when
the
default
process
wasn't
like
default.
Boolean
wasn't
a
field
of
the
process
itself
right.
It's
because
you
could
reference
a
process,
but
then
what
that
was
referencing
could
change.
I
feel
like.
B
B
A
B
B
Too
much
I
don't
know
if
I
want
infinite
configurability,
I
want
like
certain
things
to
be
not
infinitely
configurable.
So
then
I
ask
like
I
can't
do
what
I
want
and
then
I
come
up
with
a
simpler,
better
way
to
solve
it,
which
is.
I
should
just
give
this
process
a
different
name
and
set
it
to
the
default.
C
Yes,
go
ahead
just
on
the
more
granular
configurability
of
the
default.
What's
the
reason
we
turned
away
from
the
suggestion
to
have
default,
instead
of
being
a
boolean,
be
sort
of
like
three
different
things.
C
B
B
Because
then
you're
overriding
it,
even
though
you
said
you
didn't
want
to
that's
sort
of
why
it
gets
confusing.
In
my
mind,
I
think
my
overall
take
would
be.
We
should
drop
it
for
simplicity,
not
because
it's
inherently
a
bad
idea,
but
because
we're
keep
having
these
complicated
conversations,
which
makes
you
think,
maybe
it's
too
complicated,
and
we
should
just
leave
it
out
and
then
we
can
introduce
it
later
if
people
feel
like
they
need
an
out
from
the
order.
A
Does
anybody
know
of
use
cases
for
additional
functionality,
aside
from
a
per
process
default
flag,
that's
namespace
to
that
process
such
that
it's
meaningless?
If
that
process
is
overwritten,
does
anybody
have
remember
or
have
have
real
world
use
cases
for
the
override
functionality
or
kind
of
any
of
the
other
case
combinations
we
talked
about
in
the
past.
C
Is
that
like,
when
a
bill
pack
defines
default
but
doesn't
define
that
process.
A
Only
only
function
in
the
simplest
case
we
just
implement
a
single
default
equals
true
or
false
boolean
on
each
individual
process
such
that
it
means
this
should
be
the
default
and
if
another
process
over
rides
over
the
process
of
the
same
name,
then
that
information
is
lost.
It
can
never
be
the
default
because
another
thing
overwrote
it
and
that
thing
may
or
may
not
be
the
default,
but
that's
irrelevant.
A
The
confusing
part
about
the
order,
like
the
disadvantage
of
using
the
order
for
everything,
is
that
the
order,
the
primary
use
of
order
and
like
where
I'm
trying
to
I'm
hoping
we
can
avoid
using
order
in
too
many
different
unrelated
places,
is
the
primary
usage
of
it
is
a
build
time,
dependency
between
x
and
y
right,
like
when
you're
thinking
about
okay,
I'm
going
to
design
my
build
and
I
have
a
series
of
stages
for
the
user.
It's
easiest!
If
the
only
thing
they
have
to
worry
about
order.
Wise
is
thinking
this.
A
You
know
I
need
node
to
be
able
to
run
npm.
Therefore,
I'm
going
to
put
node
before
npm
right
and
if
we,
if
we
keep
having
the
order,
mean
a
whole
bunch
of
different
things,
then
suddenly
you
get
conflicts
between
well,
no,
it's
supposed
to
be
in
pm,
but
actually
I
wanted
node
start
command
on
mp.
I'm
starting
right,
so
that'd
be
my
caution
against
or
that
that
might
be
why
a
override
boolean
might
be
better
in
the
future
or
name
spacing
or
having
process
types
that
never
override
each
other
or
something
like
that.
C
B
C
It
only
matters
if
like
if
you
had
riff
and
you
were
overwriting
web
or
something
like
that
like
they
have
web
and
it's
not
default
today
and
you
have
web
and
it's
not
default
today.
Everything
today
boots
up
with
web
being
the
default
from
pack
right
when
you
build
it
from
pack
tomorrow,
if
riff
updates
it
with
default,
equals
true
because
they're
like
yeah,
I
always
want
to
have
this
as
process
type
well,.
C
Okay,
that
kind
of
brings
up
one
of
the
last
outstanding
questions,
which
is
you
know
what
pac
should
continue
to
do,
because
you
know,
obviously
we
can
introduce
this
functionality
into
the
api,
but
there's
no
guarantee
that
build
packs
are
going
to
immediately
start
declaring
default
processes
and
then,
if
pack
decides,
you
know
what
I'm
not
going
to
override
what
build
packs
are
doing.
C
C
B
My
church
solves
the
problem
with
the
migration,
because
this
would
still
require
education
before
we
took
away
pac,
but
because
the
time
when
you
want
pac
to
stop
passing
web
is
when
your
whole
ecosystem
of
bill
packs
has
agreed
to
move
over
to
deciding
their
own
defaults
right.
But
because
you
can
set
default
process
type
with
a
environment.
Variable
like
a
builder
could
bake
in
default
process.
Type
web,
like
the
kettle
builder,
would
do
that.