►
From YouTube: Working Group: 2020-09-30
Description
* Stackpacks
* Buildpack Registry trials
* Test Cluster
* Default Process Types: https://github.com/buildpacks/rfcs/pull/110
A
A
A
A
C
I
can
speak
for
javier,
he
and
I
touched
base
just
before
so
yeah.
Basically,
our
plan
is
to
continue
with
releasing
today,
but
we
do
have
a
couple
of
outstanding
pack
issues
regarding
the
registry
that
we're
about
to
merge
in
shortly.
So,
besides
that,
the
main
thing
is
we
are.
We
are
hoping
and
planning
to
move
forward
with
that
release.
Sometime.
D
A
A
Cool
well
wait
till
he
gets
back
experimental
api
mode.
I
think
this
is
terrance's
and
I
definitely
encourage
people
to
look
at
it.
There's
some
strong
opinions
about
how
I
should
handle
experimental
versions
and
like
it's
a
more
general
thing
now.
It's
like
I
want
to
introduce
an
experimental
feature.
It
can
just
go
into
a
regular
version,
marked
as
experimental
some
important
implications
on
registry
and
stack
pack
stuff.
Terence
and
I've
been
chatting
a
lot
about
that,
but
I
think
we
should
wait
for
him
to.
A
A
F
A
A
G
Oh
yeah,
I
think
I
think
these
rfcs
are
still
kind
of
in
a
in
the
same
spot.
They
were
last
week,
but
the
code
is
probably
ready
to
start
reviewing
in
its
current
early
state.
We
don't
have
the
guards
around
the
experimental
stuff
since
it's
still
pending
but
kind
of
the
you
know.
Conceptual
bits
probably
are
worth
kind
of
reviewing.
A
A
I
just
I
just
didn't
see
it
there,
we'll
take
a
look
for
sure.
Sub
team
maintainer
creates
repo
issues.
This
is
fcp
should
probably
go
in.
I
think
all
the
fcp
ones
need
to
get
merged.
Yep
today,
draft
layer,
origin,
metadata
from
paul.
Anybody
have
a
context
on
that.
I
know
emily
was
working
with
them
a
bit.
F
G
No,
not
since
the
last
like
I
was
kind
of
just
making
sure
that
it
was
ready
for
a
broader
review
trying
to
and
and
then
I
think
he
got
a
bunch
of
comments
the
last
time
he
was
here.
So
I
think
at
this
point
either
there's
comments
outstanding
or
maybe
we'll
just
wait
till
he
comes
back
to
present
any
changes.
I
guess.
F
This
was
about
especially
for
pac
and
the
platform
team.
If
I
recall
this
was
joe's
previous
rfc,
I
had
some
comments
and
I
guess
when
you
have
comments,
you
end
up
owning
the
thing
so
joe
asked
me
to
take
it
over,
so
I
reworked
it.
I
want
to
say
like
two
weeks
ago
or
something,
and
so
since
I
made
a
decent
amount
of
changes,
I
wanted
to
other
people
to
re-review.
It.
A
A
A
G
G
So
it's
like
you
know,
slash
c
and
b:
slash
stack,
slash
order,
dot,
toml
for
the
order
that
they
run
in
and
make
that
a
requirement
of
the
stack
author.
So
that's
question
one.
I
guess
I
don't
like
looping
through
the
directory
in
the
code
wise.
It
got
weird
you
have
to
like
make
assumptions
about
versions
a
bit
and
like
there's
some
to-do's
that
just
haven't
been
done
around
that
area.
G
So
I
kind
of
wish
it
was
more
explicit,
but
I
think
the
rfc
calls
out
the
order
to
be
specified
in
the
builder
tunnel,
so
I'm
kind
of
wondering
like
do.
We
really
want
to
add
it
to
builder
tomorrow,
or
could
we
just
do
we
think
it
may
be
makes
sense
to
add
a
explicit
like
default
file,
path
of
order
to
the
sn.
H
A
A
H
G
Since
stack
authors,
it
seems
like
it's
probably
fine
to
just
like
put
that
in
the
hands
of
the
stack
author.
I
know
there
was
some
discussion
about
whether
these
build
packs
could
probably
just
be
in
the
build
packs
directory,
but
after
kind
of
thinking
about
it
a
little
bit
more,
I
do.
I
think
they,
I
think,
I'm
okay
with
it
being
in
a
separate
directory,
mostly
because
of
volume
mounting
and
like
platforms.
A
H
A
G
Do
we
think
there
is
some
advantage
in
the
code
of
having
it
all
just
in
the
bill,
packs
directory,
because
it's
sort
of
one
of
the
weird
places
it
shows
up
a
few
times
you
kind
of
have
to
know
whether
it's
a
stack
pack
to
like
swap
directories
when
you're
sort
of
deciding
to
execute
the
pin,
detect,
build
or
whatever?
So
I
don't
know
we
could,
if
we'd
like
them
in
just
the
bill,
packs
directory,
then
that
makes
things
maybe
a
little
simpler
on
the
code
side.
A
To
me,
if
you
keep
it
in
the
build
packs
directory
which
I'm
not
opposed
to
or
like
like
it
does
seem
cleaner
in
some
ways,
but
if
you
keep
it
in
the
build
packs
directory
it
starts
feeling,
like
you
know,
you
can
distribute
build
packs
on
stack
images
because,
like
there's,
a
built-in
build
packs
directory
on
stack
images
and
you
put
build
packs
in
there
which
kind
of
starts
feeling
like
you
have
builders,
and
the
separation
implies
that
no
this
isn't
you
can
ship
build
packs
and
stacks
directory.
It's
just
another.
A
G
A
B
C
I
didn't
add
this,
but
javier
might
have
added
it
and
I'm
thinking
based
on
the
conversations
we
had.
This
is
probably
referring
to
just
giving
a
heads
up
that
we
are
quickly
approaching
a
trial
time
where
we
can
actually
start
putting
what
we
have
so
far
implemented
regarding
pac
registry
in
front
of
interested
parties.
A
F
C
C
C
As
far
as
I
know,
on
the
on
the
heroku
side,
we
we
know
who
to
talk
to
to
to
start
that
process
and
how,
to
you
know,
kind
of
present
getting
started
guide.
If
you
will,
we
could
probably
extend
documentation
and
things
of
that
nature
to
anyone
else
or
maybe
there's
even
I
don't
know
what
the
the
proper
media
is
for
announcing
it
or
if
we
want
to
announce
it
very
broadly
or
just
try
it
internally
and
coordinate
with
other
direct
members
of
the
pocato
team
as
well.
E
I
I
would
say
I
would
say
that,
like
any
getting
started,
material
that
you
do
have
for
the
registries
would
be
much
appreciated
by
like
myself
and
my
team.
If
we
wanted
to
look
into
picking
some
of
the
stuff
up,
and
you
can
either
do
that
by
reaching
out
to
like
me
personally
or
we
have
a
slack,
if
you
really
want
to
blast
it
to
everyone.
H
C
B
Yeah,
hopefully,
a
quick
one:
does
anybody
care
about
a
gke
cluster
named
test
cluster
that
lives
in
our
ci
project
in
gcp,
because
I
think
I
want
to
delete
it.
It's
due
to
get
an
upgrade
like
a
forced
upgrade
sometime
in
october,
but
I
think
we
just
don't
care.
If
we
do
care,
we
should
manage
the
upgrade.
B
A
B
B
H
A
F
B
A
That
was
great.
Let's,
let's
kill
it.
That's
what
I
say
unless
somebody
disagrees
and
then
I
put
a
note
in
future
topics.
Can
I
close
gcp
project
and
I'll
bring
it
up
next
time
too
then
or
like
for
a
couple
weeks,
make
sure
everybody
here
is
who
has
a
chance
to
say?
No,
we
need
ucp,
for
something
has
a
chance
to
say
so
and
then,
if
we're
not
using
it
anymore,
nobody
thinks
we're
going
to
use
it.
A
D
When
we
discussed
it,
we
kind
of
decided
that
the
current,
I
guess,
the
current
implementation,
which
had
actually
let
me
show
that
the
schema
well
so
the
schema
as
it
existed
before
had
launched
tomil.
There
was
a
separate
key
for
the
default
process
and
then
build
packs
could
set
that
to
be
a
named
type
and
it
led
to
all
these
confusing
scenarios.
D
So
I
believe
the
consensus
that
we
reached
at
last
week's
meeting
was
that
the
default
part
of
the
process
type
specification
should
live
under
processes
and
that
you
know
if
one
process
like
let's
say,
there's
two
build
packs
that
both
specify
web
and
the
later
build
pack
overrides
the
first
build
pack.
Then
you
know
whatever
default,
designation,
that
the
later
build
pack
had
would
be
the
thing
that
we
ended
up
with.
So
it's
very
clear
what
happens
when
there
are
override
scenarios,
and
I
went
away
with
that
and
started
to
update
the
rfc.
D
D
This
is
like
a
lot
of
words,
I'm
not
sure
if
what
I'm
saying
is
getting
across,
but
basically
I
think
what
we
had.
We
had
aligned
on
last
week
wasn't
exactly
what
we
wanted
and
I
updated
the
rfc
to
have
something
that
I
think
will
work
and
that
I
like,
but
I'm
just
hoping
to
get
buy-in
and
feedback.
D
A
D
D
Just
override
and
and
so
there's
you'll
notice,
there's
two
overrides
right,
one
is
to
say,
like
I
am
process
type
web
and
I
would
like
to
override
another
build
packs
process
type
web.
That's
what
this
override
means
and
this
override
means
I'm
declaring
this
particular
process
to
be
default,
but
I
would
like
it,
you
know,
to
override
another
default.
Whatever
that
happens
to
be.
A
A
So
so
this
relies
on
there
being
a
semantic
difference
between
empty
table
default
and
default,
not
being
a
table
right
because
empty.
If
you
have
the
empty
default
table,
it
means
this
process
should
be
default
and
if
you
don't
have
the
empty
table
default,
is
that
just
is
that
right?
It's
at
the
antenna.
A
And
so
you're
trying
to
express
four
states
right
override,
true
or
false,
maybe
it's
more
than
four
states,
it's
like
override,
true
or
false
default,
true
or
false,
and
then,
if
default,
true,
special
extra,
override,
true
or
false
right
yeah.
So,
just
like
thinking
about
the
ux
a
little
bit
everywhere
else
where
we
have
booleans,
we
try
to
make
false
the
default.
So
it's
like
the
zero
or
like
we
tend
to
go
with
like
zero
value.
A
F
H
A
I
I
have
a
little
bit
of
the
same
concern
with
having
an
empty
table:
that's
different
from
not
specifying
the
table.
If
that
makes
sense,
if
you
have
an
empty
table
as
a
user,
my
expectation
isn't
that
that,
like
you
know,
they're
definitely
things
that
are.
It
is
different,
but
you
know
the
my
assumption
is
generally
that,
like
just
just
defining
the
table,
there
doesn't
change
the
behavior
and
so
like
something
to
think
about.
A
D
D
D
It
would
be
nice
to
have
the
defaults
be
consistent
with
what
the
behavior
is
right
now
for
build
packs
so,
like
later
build
packs,
always
override
earlier
build
packs
in
terms
of
like
people
specify
process
type
web
right
and
so
having
that
kind
of
stay.
The
consistent
behavior,
when
you
don't
specify
anything,
seems
less
confusing.
A
I
I
really
like
all
the
behavioral
decisions
and
what
this
implements
like.
I
think
I
think
the
underlying
thing
the
user
is
expressing,
you
know,
like
seems
really,
like
checks,
all
the
boxes.
If
that
makes
sense
to
me,
the
the
only
thing
I
would
change
is
like
just
how
exactly
we
format
the
tommel
right.
I
wonder
if
anybody
has
feedback
on
the
behavioral
part
before
we
talk
about
like
we
could
probably
talk
about
what
the
table
should
look
like
for
a
long
time,
but
does
anybody
have
feedback
on
that?
F
D
D
D
Falls
here
that
just
means
that
I
won't
overwrite
another
process
with
the
same
type.
But
if
I
say
default
true
and
I'm
the
last
build
pack,
then
I
win
right.
There's
no
way
for
me
to
say
I
want
to
be
the
default,
but
only
if
there
isn't
already
a
default
so
like
that
distinction
between
overwriting
the
process,
type
definition
and
overriding
like
collectively.
What
all
the
build
packs
say
should
be
the
default
process.
A
Do
we
need
that
functionality?
Do
we
need
to
be
able
to
say
only
override
the
default
like
the
way
it's
kind
of
or
like
an
alternative,
would
be
just
to
assume
that
the
last
thing
that
says
it's
the
default
as
long
as
it
hasn't
been
overwritten
completely
by
another
command?
That's
what's
the
default
right
is.
D
A
If
we
don't
do
that
a
whole
lot
right,
but
I
wonder
if
that's
enough
of
a
control
over
that
functionality,
you
know
like
usually,
if
you're
thinking
like
I'm
building
my
application
and
it's
going
to
go
through
a
bunch
of
stages
and
the
last
stage
is
like
okay,
it
builds
all
my
static
assets,
and
now
I
want
to
host
it
with
nginx,
since
you're
like
engine
x
is
the
last
one,
because
that's
the
thing,
that's
gonna,
that's
the
last
last
step.
Is
you
know
doing
that
last
mile
of
getting
it
hosted
right?
D
D
A
D
D
F
F
A
A
A
A
A
F
It
brings
back
bad
memories
of
our
caching
table
yeah
that
feels
complicated.
I
I
do
agree
that
I
think
this
covers
all
the
possible
use
cases
we
want.
I
think,
in
the
past
we
had
override
when
override
was
set
to
true
that
it
meant
that
you
could
override
this
value.
Is
that
correct
was
that
in
the
original?
Or
did
I
misread
that.
G
F
A
Well,
I
was
wondering
we
can
do
three
booleans.
If
we
really
need
all
five
states,
we
could
do
three
booleans,
you
know,
and
then
one
combination
of
the
three
booleans
is
not
valid
right
or
is
like
ignored
one
of
them's
ignored
or
if
we're
not
sure,
we
need
that
that
state,
the
ability
to
say
like
not
just
this
process
type's
going
to
override
this
process
type
or
this
process
type,
should
be
a
default.
A
But
this
process
type
should
be
default,
but
only
if
no
other
build
packs
have
said
that
they
should
have
a
default
right.
If
we
don't
need
that,
if
we
don't
have
a
use
case
for
that
fifth
state,
it
gets
a
lot
simpler
for
people
to
think
about
if
it's
just
two
booleans,
if
that
makes
sense
default
override.
But
it
seems
like
we
do.
F
E
A
E
I
mean
kind
of
at
the
end
of
the
day
if
we
were
to
click
them
together
using
like
like
if
we,
if
I
were,
to
try
and
do
that
now.
I
would
just
call
in
like
our
node
engine
our
npm
pill
pack,
and
then
an
engine
x,
build
pack
and
then
the
engine
x
build
pack
is
responsible
for
writing
the
start
command.
B
B
Like
yes
sure
so
I
would
it's
just
forming
the
thoughts
in
my
mind
as
we
speak,
so
it
might
not
be
too
coherent,
but
I
would
imagine
you
could
have
sort
of
a
generic
integer
and
the
lower,
probably
is
the
best
way
around
would
be
the
highest
priority.
So
in
this
instance,
if
you
wanted
something
to
say,
I'm
a
default
and
I'm
override
is
true.
You
would
say
that
was
a
priority
of
one
or
you
could
say
that
was
a
priority
of
one.
B
B
I'm
imagining
you
could
have
two
things
that
said
that
they
were
the
default
process
and
what
override
is
true
and
we
would
select
the
later
one
so
like
I
said
that
could
be
represented
by
one.
If
you
didn't
want
to
override
at
all,
you
could
choose
a
very
high
number
if
you
didn't,
if
you,
if
you
knew
you,
never
wanted
to
be
a
runner,
you
could
maybe
use
a
negative
integer.
B
Yeah,
I
I
I
think
in
my
mind
the
having
sort
of
generic
integers
and
and
and
maybe
we
don't
just
sort
of
choose
one,
two,
three,
four
five.
Maybe
we
we
have
patterns
where
it's
like:
okay,
we're
actually
gonna
go
with
5
10,
20,
30
or
whatever.
It
gives
us
some
flexibility
in
the
future
to
introduce
new
states
that
we
are
not
anticipating.
If
we
don't
need
them,
we
don't
need
them.
But
if
we
do,
then
we've
got
that
flexibility.
A
H
F
B
A
The
nice
thing
about
the
integer
is
that
it
works
in
a
lot
of
different
cases
so
like
if
you're
talking
about
you,
want
to
find
the
best
web
process
right,
not
just
the
best
like.
What's
the
candidate
process
for
the
whole
build,
but
what's
the
best
web
process,
you
can
scan
through
all
the
web
processes
that
were
contributed
by
the
build
packs
and
then
pick
the
highest
number
one
right
and
that's
the
best
candidate
for
web.
A
If
you're
trying
to
find
the
best
general
process
same,
let's
get
through
all
the
processes
and
pick
the
highest
number
one
and
that's
the
best
candidate,
for
you
know
it's
very
flexible
in
that
way,
and
it's
simple
and
that
you
don't
have
to
worry
about
a
whole
bunch
of
booleans
just
like
yeah.
This
is
really
important.
No,
this
is
less
important
right
generally,
but
it
does
introduce.
So
it's
a
little
bit
looser.
A
F
E
H
Number
well,
but
first
I
think
most
and
probably
the
80
will
not
use
it
at
all
and
that's
I
think,
that's
why
that's
an
okay
option.
Otherwise
I
don't
think
I
would
support
that
option,
but
yeah
you'd
have
to
look
it
up.
I
think
the
explicit
like
if
we
used
explicit
values
that
sort
of
you
know
explain
themselves.
That
would
be
helpful
too,
but.
A
E
I'm
just
concerned
about,
like
I
I
don't
about,
I
have
to
add
an
extra
layer
of
complexity
to
writing
a
start
command
for
my
build
pack,
when
I
feel
like
a
large
majority
of
people
that
are
going
to
write
a
simple,
build
pack,
don't
necessarily
super
care
about
getting
into
the
nitty
gritty
of
the
priority
of
their
override
of
a
process
and
tandem
with
other
large
sets
of
build
packs.
That
just
feels
that
feels,
like
you
know,
a
shotgun
to
do
something
that
a
slingshot
would
do
right.
E
I
don't
know
that
I
have
a
super
strong
opinion
about
what
direction
you
would
move,
but
that
would
be
something
that
I'd
want
to
sort
of
make
sure
is
kept
in
mind
of
like
it
just
feels
like
sometimes
it's
like
in
reading
some
of
the
stuff.
I
just
feel
like
there's
just
complexity
where
it's
hard
for
me
to
understand
where,
if
I
wanted
to
write
a
simple
build
pack,
what
I
could
ignore
and
what
I'd
have
to
add.
A
That
makes
sense
it,
so
it
seems
like
we
have
two
high
level
models
we're
talking
about
now.
One
is
where
you
have
an
expression
of
priority,
either
by
fixed
strings
or
by
an
integer
or
whatever
right,
where
you
can
express,
or
the
difference
between
saying
this
is
the
global
default
for
everything
versus
this
is
like
you
know,
the
default
for
web
processes
comes
down
to
like.
If
you
pick
the
highest
setting,
then
it's
probably
going
to
override
everything
else
that
says
the
highest
setting.
A
Do
we
like
that
model
better
due
to
the
simplicity
of
the
user
user
interface
versus
having
explicit
flags
for
this
overrides
things
of
the
same
type?
This
overrides,
you
know
everything
else,
because
they
they
do
have
different
implicat
like
you,
can
generally
achieve
the
same
outcomes,
but
they
do
have
different
implications
on
how
the
user
understands
them
are
there
preferences
between
those
two
models.
A
Well,
either
numbers
or
an
expression
of
priority
one
one,
one
key
that
expresses
priority
on
a
scale
right
versus,
even
if
it's
fixed
number
of
you
know,
options
on
the
scale
versus
flags
that
control
specific.
To
like
this
name
overrides
this
name,
this
name
doesn't
override
things
under
the
same
name.
This
thing
should
override
anything,
regardless
of
what
its
name
is
to
be
the
default
process.
In
the
end,
do
we
like
that
granular
control,
or
do
we
do?
A
F
D
F
The
the
other,
the
one
that
you
came
up
with
came
out
of
was
that
like
jesse's
example
of
like
what
happens
if
you
override
the
web
process,
but
I
set
the
value
to
something
like
I
set
this
as
the
default
like
I
say
I
set
web
to
default,
but
then,
like
a
bill
pack
later
down
the
line
overrides,
what
web
is
should
web
still
be?
The
default
right
was
that
that
edge
case.
D
I
believe
so
yeah
and
that
later
build
pack
saying
that
its
default
designation
should
not
be
overriding.
It
kind
of
creates
this
conflict
between
I'm
an
important
process
because
I'm
coming
later,
but
I'm
not
an
important
process,
because
I've
specified
override
false
sort
of
it's
weird
and
and
that's
what
prompted
us
to
move
everything
under
a
single
as
opposed
to
having
a
separate
key
that
specifies
the
default.
It's
just
clearer.
G
A
It
seems
like
there
are
questions
about
use
cases,
though,
like
emily,
we're
not
sure
if
we
need
to
override
at
the
top
level
and
emily
wants
to
override
an
inside
be
good
to
hear
from
her,
and
then
she
might
have
opinions
on
the
priority
thing
too,
because
I
think
the
use
cases
on
the
java
bill
peck's
side
that
she's
working
on
you
know
kind
of
driving
it
out.
I
think
it's
just
super
helpful
to
chat
about
the
different
options.
It's
maybe
we
can
put
it
on
the
agenda
again.