►
From YouTube: Working Group: 2020-08-12
Description
* KubeCon Booth
* Application Mixins: https://github.com/buildpacks/rfcs/pull/87
* Checksums on Releases
* Lifecycle's Default Process Type
* Project Descriptor: https://github.com/buildpacks/rfcs/pull/95
A
A
A
A
A
A
A
All
right
we're
five
minutes
after
should
we
kick
things
off.
Let's
do
it
first
thing
in
the
list
is
sign
into
document.
I
think
still
missing
some
signatures
there.
Just
as
a
reminder,
let
me
know
if
you
don't
have
access
or
anything
next
thing
on
the
list
is
new
faces.
Do
we
have
any
new
faces
here
today?
A
B
B
So
many
mute
buttons
I'll
speak
to
the
life
cycle
side.
Lifecycle09
went
out
on
friday,
thank
you,
natalie
and
yael
for
working
with
emily.
To
get
that
done.
It's
got
a
bunch
of
new
stuff,
including
support
for
pac,
build
packer
for
spec
and
platform.
04
spec,
and
there
are
great
new
features
that
I
can't
wait
for
javier
to
finish
that
pack,
so
we
can
test
and
use.
A
B
A
A
B
A
B
No
yeah
just
some
approvals
there.
The
it
is
a
good
opportunity
to
point
out
that
over
the
last
two
days,
like
five
different
rfcs,
closed
fcp
and
were
merged,
and
even
if
this
hasn't
been
officially
done.
Yet,
if
those
were
your
rfcs,
I
highly
recommend
you
open
issues
against
the
spec
for
them
or
against
the
proper
places.
B
B
A
B
A
A
B
A
B
A
B
I
voted
for
it
because
it
wasn't
blocking,
but
I
was
wondering
if
it
was
before
you
merged
this
in.
If
you
could
just
just
from
the
discussion.
Last
week
we
talked
about
the
distro
stack
thing
being
a
separate
rc.
I
just
wanted
to
put
that
note
in
and
also
ben's
typo
correction,
probably
worth
pulling
that
into.
A
A
A
B
A
We
should
try
to
get
through.
I
agree
layer
or
origin
metadata
draft,
so
moving
on
pack
sub
commands
this
one
came
up
as
something
that
someone
wanted
to
call
vote
on
it
or
something
I
did,
but
I
think
that
was
before
I
realized
that
joe
had
put
something
in
there.
I
think
that
might
be
resolved
now.
I
don't
know
joe
if
you
want
to
continue
to
talk
about
it.
B
A
B
B
A
A
A
A
A
And
then
the
right
remaining,
no
sorry,
then
experimental
features
we
just
talked
about
application
mixes,
those
on
the
list,
so
I'm
going
to
skip
it.
Google,
but
skip
it
offline,
build
packages.
Rfc
do
we
have
dan
here
here?
I
think
that
there
were
some
small
changes
that
needed
to
be
made
to
this.
After
some
conversations
with.
B
B
Kick
it
out
yeah,
you
can't
they
didn't
seem
like.
Maybe
I
misunderstood
the
outstanding
changes
but
like
if
you've
seen
any
of
my
rfcs,
they
go
through
a
lot
of
iterations
without
going
back
to
draft.
So
I
don't
feel
like
that's
absolutely
necessary
yeah.
I
I
don't
think
it's
necessary
now,
but
if
it's
going
to
be
a
while
and
we
should
ignore
it
at
the
next
meeting
sure
that's
a
good
reason.
Yeah.
A
B
B
You
know
I
haven't
been
following
super
close.
I
just
want
to
make
sure
everybody
that
will
be
helping
out
is
on
the
same
page,
and
you
know
if
anybody
just
give
everybody
a
chance
to
ask
questions
if
need
be.
I
know
I
volunteered
to
pick
up
slack
if
it's
necessary,
so
I'd
like
to
know
if
I
need
to
do
that.
That
kind
of
thing
also
for
those
of
us
who
haven't
been
paying
super
close
attention,
can
somebody
involved
tell
us
what
this
ended
up
being
like?
How
is
this
going
to
work.
A
So
this
is
this:
is
a
it's
like
a
it's
supposed
to
simulate.
You
know
people
going
to
booths
in
a
large
conference
center,
but
without
any
any
kind
of
video
chat
or
anything
like
that.
It's
it's
like
a
chat
room
that
you
sit
in,
for
you
know
some
period
of
the
day
and
people
come
in
and
ask
questions
and
then
there's
like
a
virtual
booth
website.
That's
all
decorated
nicely.
You
know
with
like
cnb
stuff
everywhere.
You
know
people
at
the
con
virtual
conference
come
in
and
are
like
hey.
A
I
like,
what's
this
project
about,
tell
me
about
this,
or
does
it
solve
these
problems?
And
then
people
associated
with
the
project
are
marked
as
moderators
or
something
like
that
and
can
answer
questions
and
do
things
like
that?
We
have
a
sign
up
sheet
and
everything
we're
trying
to
fill
out
times.
A
I
haven't
filled
that
out
yet,
but
a
whole
bunch
of
people
have
we
started
with
five
people,
but
then
realized
that
we
can
have
more
people
staffing
the
booth
as
long
as
yeah
thanks
as
long
as
the
they
don't
need
free
kubecon
passes.
That
was
the
limit
of
five
people,
I
think,
and
so
I
think
we
have
10
people
kind
of
signed
up
to
staff
at
different
times.
Now
I
don't
know
if
we
can
add
more.
I
think
it's
locked
at
this
point.
A
You
have
to
have
registered
for
kubecon,
but
we
have
a
good
good
mix
of
people
from
you
know
different
companies
and
I'm
pretty
excited
about
it.
I
think
it'll
go
pretty
well,
I
don't
really
know
when
an
eu
all
those
times
are
still
blank
slots
to
sign
up
for
the
really
really
early
times
yeah,
I
was
going
to
say,
there's
still
a
lot
of
open
times,
so
I
do
feel
like.
Maybe
we
we
might
need
more
assistance
or
more
dedication.
B
B
A
The
the
times
say
recommended
no,
nobody
said
you
have
to
have
somebody
there
for
every
single.
You
have
to
have
complete
coverage
to
make
sure
that
there's
somebody
to
answer
questions
all
the
time
they
were
just
there
for
for
the
four
days
they
said
here
the
recommended
times.
We'd
say
you
should
have
somebody
around
your
booth.
If
you
know
to
simulate
the
what
it
looks
like
in
a
real
conference,
yeah.
B
A
A
B
B
B
I've
noted
that
there
will
be
platform,
api
changes
or
platform
specification
changes,
but
I
it's
just
really
not
possible
to
like
catalog
those
this
time.
It's
going
to
depend
on
the
implementation.
So,
if
need
be
I'll
open,
another
rfc
for
those
you
know
just
like
different
flags
to
build
and
stuff
like
that
to
builder,
not
not
not
to
build
to
builder,
might
have
different
flags.
B
A
I
thought
it
was
something
over
the
weekend
that
I
realized,
I'm
not
sure
if
we
addressed
the
way
mixins
work
right
now
with
stage
specifiers
is
kind
of
weird
it's
like
it.
You
know
if,
if
I
run
image
and
I'm
gonna
open
an
rfc
about
this
eventually,
but
if
a
run
image
says
run
colon,
mixer
name
and
a
build
image
says:
build
colon
same
mix
and
name.
A
You
know
it
implies
that
you
don't
need
that
mixing
to
be
on
either
image
in
order
to
use
the
images
with
each
other
right,
like
you
know,
you
could
take
the
run
colon
mix
and
name
off
the
run
one,
and
it
would
still
work
with
the
build
image
right.
So
it
has
a
meaning,
but
that's
going
to
be
really
weird
with
how
mixons
work
do
we
send
the
pr
prefix
mix-in
names
to
the
run
one
and.
B
I
think
we
talked
about
introducing
an
environment
variable
that
it
can
switch
on
like
I
installed
these
certs
that
build
and
these
certs
that
run
right.
So
that's
how
it
would
do
that.
My
hope
is
that
there
won't
like
a
lot
of
it,
will
just
fall
out
from
how
the
life
cycle
handles
things
like
stack
tommle.
So
like
both
times,
it
runs
it'll
write
this
exact
same
thing
and
then
it
build
it'll.
Just
read
this
and
for
run.
It'll
read
this.
A
Yes,
there
are
some
edge
cases
that
I'm
worried
about
like
if
a
build
pack
you
know
dynamically
requires
run
colon
image,
magic
and
the
stack
image
provides
image
magic
on
the
run
of
the
build
image.
That's
not
gonna
get
matched
by
the
stack
image
and
would
get
sent
to
the
app
build
pack
to
install,
even
though
image
magic
is
already
installed.
Oh.
B
B
B
A
So
that
thing,
if
that's
things
set
to
any
true
right,
you
don't
have
a
list
of
mixes
there,
but
in
the
in
the
actual
in
the
non
non
stack
pack
mix
in
list
where
it
says
requires,
you
know,
run
colon
image
magic.
If
the
base
image
just
has
image
magic
on
it
and
build
in
a
run
image
right,
it
doesn't
have
those
stage
specific
things,
then
it's
not
gonna.
A
B
A
This
isn't
about
the
built
non
stackpack,
build
packs,
built
back
tommel,
it's
about
you
when
the
build
packs
use
the
build
plan.
To
put
you
know,
to
specify
mix
that
they
get
passed
to
a
stack
pack,
there's
there's
a
whole
bunch
of
weird
edge
cases
with
matching
the
mix-in
name
to
the
list
of
mix-ins
the
base
image.
I
think
I'm
going
to
open
an
rfc
about
this,
but
I'm
I'm
worried
that
there's
extra
stuff
we
need
to
specify.
A
B
A
It
makes
sense
I'm
going
to
open
an
rfc
about
changing
the
wave
mixins
or
like
relaxing
the
restriction
on
mixins
generally,
and
I
think
that
will
help.
But
then
then,
after
I
open
that
I'll
come
back
around
to
this
and
then
say
you
know,
but
I
don't
think
we
need
to
block
on
it
or
I'm
happy
with
just
an
unresolved
question
about
it
as
long
as
we're
willing
to
maybe
make
some
changes
to
how
the
matching
happens
in
the
future.
A
A
B
A
A
A
All
right
next
thing
in
the
list
is
checksums
on
releases.
I
put
this
up.
I
this
has
come
out
from
like
a
team
discussion.
I
remember
when
I
was
in
build
packs.
So
then
we
were
very
intent
on
having
checksums
a
checksum
file
with
all
of
our
releases,
and
I
found
it
interesting
when
I
initially
joined
that
we
don't
do
that
before
for
the
releases
that
we
published,
either
with
lifecycle
or
with
or
attack.
A
B
A
B
I
mean
there
are
better
options.
Yes
nah,
I
haven't
seen
them
used
enough
to
put
a
stake
in
the
ground
like
signing
it
with
a
utility
that
nobody
has
or
there
isn't
a
ton
of
stack
overflow
on
how
to
use
to
validate,
might
as
well
not
be
signed.
Do
both
of
them.
If
you
really
care,
but
I
think
we
have
to
do
pgp
for
compatibility.
B
A
A
A
Yeah,
I
want
to
make
sure
to
clear
the
air
so
to
give
you
a
little
history
of
what
I
encountered
the
acceptance
test
when
moving
over
to
platform
04
broke
because
you
know
in
the
history
there's
been
this
assumption-
that
the
default
process
type
that
the
life
cycle
sets
is
web
right
and
that
has
work
has
worked.
Okay,
but
at
some
point
that
went
away-
and
I
think
that's
kind
of
where
everybody
is
right
now
is
we
wanted
to
go
with
this
whole
notion
of
a
default
web
process
type
specifically.
A
We
need
to
be
able
to
tell
the
life
cycle
what
process
type
to
actually
set
as
the
default
process
type
right,
so
the
lifecycle
itself
not
doing
it
automatically,
except
for
it
kind
of
does
right
now,
where,
if
there's
only
one,
it
sets
that
to
be
the
default
process
type.
But
in
our
case
we
have
some
tests
that
have
multiple
process
types
and
the
bug
that
we're
talking
about
is,
if
pac
tells
the
life
cycle
hey.
If
there
is
a
default
or
sorry.
A
If
there's
a
process
type
named
web
set
that
one
as
the
default
it
blows
up
right
it
errors
out,
so
pac
itself
doesn't
actually
know
what
the
process
types
are
going
to
be
during
the
build
process
at
this
point
in
time.
So
we're
asking
that
a
change
be
made
to
the
life
cycle
so
that
it
just
warns
and
sets
the
default
process
type.
If
that
process
type
work
to
exist,.
B
A
A
B
A
A
Yeah,
it
always
did
so.
The
what
I
discovered
is
that
the
exporter
would
always
error
if
the
defined
process
type
did
not
exist,
but
pac
wasn't
passing
anything
oh
correct,
so
lifecycle
had
internally
determined
what
a
default
is
now
we're
trying
to
externalize
that
aspect
of
it
yeah
so
for
for
o3.
If
nothing
is
passed,
it's
going
to
default
to
web.
B
Yeah,
so
so
to
get
the
so
we
could,
like
the
life
cycle,
doesn't
need
anything
other
than
so
we
could.
We
could
go
with
the
minimal
change
where
the
life
cycle
just
warns
instead
of
errors,
and
that
should
be
sufficient
right,
javier,
because
you
can
detect
if
it's
platform
less
than
zero
four,
you
pass
nothing
and
if
it's
platform,
zero,
four
greater,
you
always
specify
web
and
then
potentially
get
a
warning.
Isn't
that
sufficient.
A
Aren't
any
more
questions
about
that?
I
want
to
chat
about
the
behavior
where
you
set
one
process
type
and
we
automatically
set
that
or
the
life
cycle
automatically
selects
that,
regardless
of
what
it
is
as
the
default
process,
type
yeah.
So
that's
a
new
feature,
if
I'm
not
mistaken,
and
are
you
opposed
to
that?
Is
that
what
you're
thinking
I'm
pretty
opposed
to
that?
I
think,
philosophically,
like
the
life
cycle,
should
be
very
transparent
in
what
it
does
right.
A
It's
it
should,
you
know,
give
it
instructions
tell
it
like
faithfully
implement
this
part
of
the
api,
and
it
does
exactly
what
you
ask
it
to
right.
It
seems
surprising
if
you
created
a
worker
process
and
you
forgot
to
add
your
web
process
now.
The
worker
is
suddenly
the
default
right.
It
shouldn't.
I
feel
like
it
shouldn't
make
that
type
of
decision.
For
you,
I
think
pac,
that's
fine.
If
pac
says
web
is,
you
know,
always
says
web
right
or
or
whatever,
or
let's,
unless
the
user
customize
it.
A
But
I
don't
like
that
that
behavior
at
the
life
cycle
level,
so
I
am
curious
how
you
would
from
you
know
the
developer's
perspective
just
running
pack
and
they
use
whatever
build
pack
and
it
doesn't
have
a
web
process
type.
It
has
worker
right.
Does
that
mean
that
the
end
user
needs
to
know
that
they
have
to
set
the
default
process
type,
even
though
there's
just
one
to
that
worker.
B
I
think
the
answer
to
that
is
yes,
like
they're
gonna
see
a
warning
that
says
we
attempted
to
set
web,
but
there
is
no
web.
Therefore,
no
default
process
type
has
been
set
like
that's
what
your
warning
is
going
to
say
and
that's
a
twig
that
either
you
want
to
go
back
and
actually
set
the
default
process
type
or
you
don't
have
to
right,
like
you
can
just
pass
in
in
dockerism,
you
can
just
pass
in
docker,
run
dash
dash
entry
point
worker
and
you
can
go
on
with
your
life.
A
Yeah,
I
guess
I'm
thinking
like
a
better
ux
in
my
mind,
would
be
that
there
is
no
tie
to
web
right
and
ultimately,
if
pac
during
the
build
process,
is
able
to
determine
what
the
process
types
are
and
then
do
the
logic
that's
currently
in
the
life
cycle.
We
could
do
it
in
impact
or
any
other
platform
for
that
matter.
Then
you
don't
have
to
worry
about
it.
B
B
Yeah,
I
like
I,
I
think,
steven's
right
right,
like
the
the
life
cycle,
should
have
no
opinions.
Even
selecting
one.
If
one
exists
is
an
opinion
I
think,
and
we
we
want
to
get
away
from
that.
That's
one
of
the
really
nice
things
about
bringing
the
web
default
out
of
the
implementation
as
well
and
moving
it
into
the
platform,
because
I
expect
platforms
to
have
an
opinion
right.
A
I
think
that
operation
of,
like
baking,
a
process
type
into
the
image
right,
is
it's
not
even
clear
to
me
that
you
want
that
in
all
cases
right
like
that,
should
be
a
very
explicit
instruction.
Hey,
you
know,
create
this
weird.
Some
link
bake
this
process
type
into
the
image
and
make
it
a
default,
not
not
a
thing
that
just
happens
at
the
level
of
lifecycle.
A
A
B
B
B
I
guess
this
was
joe's
rfc,
but
I
definitely
had
opinions
and
helped
kind
of
usher
in
when
we
went
to
like
our
own
project
management,
team
and
other
things
had
a
lot
of
push
back
on
being
able
to
use
it,
and
so
they
definitely
only
want
to
use
like
parts
of
project,
tamil
and
kind
of
so
the
kind
of
context.
Motivation
for
this
rfc
is.
B
B
B
B
B
B
B
The
yes,
the
things
that
are
defined
in
project
tunnel
today
would
also
be
defined
in
the
app.tamil
example.
If
you're
talking
about
things
that
are
outside
of
that,
like
a
heroku
table
or
something
yeah,
I
don't,
I
don't
know,
I
think,
like.
I
definitely
think
our
like
the
product
people
we've
been
talking
to
would
like
to
supplement
the
specification
with
their
own
stuff.
B
In
the
same
way,
they
might
not
write
that
sometimes
it
can
go
under
metadata,
but
there's
definitely
this
sense
of
like
yes,
we
want
to
use
this
file
format,
but
we
want
it
to
feel
first
class,
like
our
things,
our
product
to
feel
first
class
right,
and
so
the
top
level
table
name
being
something
other
than
project
is
80
of
that,
but
the
the
other
keys
like
that
would
that
we
expected
to
go
under
metadata.
I'm
not
sure,
and
maybe
that
is
an
area
where
we
can
compromise
muncher
I
mean
I.
A
A
B
B
You
know,
so
I
guess
the
the
question
I'm
really
asked,
or
the
thing
I'm
sort
of
dancing
around
and
not
driving
to
particularly
well,
is
like
what
the
this
thing
about
having
multiple
file
names
right,
like
not
just
being
project
humble,
but
there
might
be
like
there
could
be
a
heroku
tamil,
for
example
like.
Why?
B
Wouldn't
we
like
what
is
the
advantage
of
having
any
linkage
between
the
name
of
the
file
and
a
table
key
right,
because
why
can't
I
have
heroku
a
heroku
key
and
an
app
key
and
a
project
key
and
a
build
key
and
an
event
key
and
all
of
those
things
just
sort
of
at
the
top
level
of
project
tamil
yeah?
No,
that's
a
good
question.
The
in
this
case.
B
It
would
result
in,
like
you,
have
a
heroku
id
equals
and
then
you
also
have
a
project
id
equals
and
so
like,
then,
there
becomes
this
question
of
like
well.
How
do
you
resolve
like
those
two
things
if
project
id
is
still
maybe
not
required,
but
it's
still
a
first
class
thing
now,
the
the
like,
I
lost
my
train
of
thought.
This
is
just
a
proposal
like
the
goal
is
what
we're
talking
about
so
yeah.
We're
like.
B
So
and
then
that
gets
me
back
to
the
file
but
like
if
there
was
some
sort
of
linkage
between
a
file
name
and
a
top
level
table,
name
like
why,
wouldn't
I
just
have
a
heroku
tamil
and
a
project
tamil
and
an
app
tamil
sitting
in
the
same
directory
yeah,
and
that's
basically
what
we
are
doing
today.
We
have
a
top
left,
we
have
a
table
and
it's
not
spec
compliant.
So
I
think
our
goal
is
like
to
get
to
get
ourselves
a
little
bit
more
in
line
with
the
specification.
B
If
there's
some
way,
one
of
the
other
options
that
we
considered
was
to
make
the
project
tamil
like
to
decompose
it
into
chunks
like
each
table,
would
be
its
own
specification
or
like
its
own,
have
its
own
little
schema,
and
then
you
could
sort
of
construct
your
heroku.tamal
or
whatever.
It
is
out
of
each
of
those
chunks,
and
you
could
even
nest
them
into
places
that
that
you
know
is
just
a
totally
different
structure
than
like
what
we
have
today.
That
would
probably
mean
that
we
need
like
in
pack.
B
If
we
really
wanted
to
be
supportive
of
that,
we
would.
We
would
need,
like
a
project,
build
packs
key,
you
know,
and
then
it
would
you'd
pass
it
your
project,
tumble
and
it
would
just
read
the
project,
build
packs
out
of
it
and
then
you'd
need
a
project
m
key
and
then
it
would
read
you
know
like
you'd
have
to
like
you,
couldn't
just
give
it
a
project,
tommle
and
call
it
spec
compliant,
because
then
all
the
other
other
formats
wouldn't
work.
B
B
B
Right
right,
well,
yeah
yeah,
if
you
can
imagine
event
like
connections
to
event,
sources
that
you
know
hook
in
some
proprietary
event,
types
right
and
you
want
to
configure
those
as
part
of
the
project.
So
I
just
more
config
files,
I
think,
is
certainly
a
goal
for
me
is
to
you
know
not:
okay,
okay,
so
so
there's
so
there's
this
heroku
tamil
file
over
there.
Our
goal
is
to
minimize
the
number
of
config
files.
So
we
remove
project
tamil.
B
We
say
that
heroku
tamil
can
contain
not
only
heroku
specific
stuff,
but
all
the
stuff
we
would
have
put
into
project
tamil
as
well.
How
does
like
pack
know
that
heroku
tom
will
even
exist?
Why
doesn't
it
just
look
at
this
this
directory
and
say?
Oh
there
doesn't
appear
to
be
a
project
tom.
Well,
I
don't
know
anything.
B
B
B
And
so
through
the
heroku
cli,
though
effectively
you'd
always
do
that
yeah,
we
sort
of
override
the
default
right.
Yeah,
okay,
yeah,
okay,
I'm
cool
with
that
yeah.
I
mean
kind
of
right
now.
Just
the
solution
right
now
is
we're
actually
like
kind
of
running
our
own,
our
own
schema
and
that's
kind
of
where
this
came
from.
It's
like.
We
made
a
schema
that
kind
of
like
encompasses
all
project
tommel
and
encompasses
the
heroku
specific
bits
all
right.
Would
it
would
a
would
a
diff?
B
Would
an
alternative,
an
acceptable
alternative,
be
that
there
is
a
heroku
specific
table
inside
of
a
file,
and
then
there
is
the
standard
project
tunnel.
That's
just
under
a
different
top
level
key
or
do
you
want
to
encapsulate
that
whole
thing
and
make
the
heroku
one
a
super
set
of
project
tamil
schema.
B
I
mean
yeah.
The
first
thing
described
is
pretty
close
to
what
we're
doing
yeah
it's
just
yeah.
Then
it's
like
well.
What
is,
if,
then,
you
have
the
whole
like
project
id
because
we're
going
to
have
we're
going
to
have
name
we're
going
to
have
like
and,
and
we
want
those
things
to
be
under
heroku
or
similar-
it's
not
necessarily
heroku,
but
we
can
do
that
yeah,
it's
just
less
desirable
for
us.
B
I
was
saying
the
superset
I
think,
is
attractive
to
product,
for
the
reasons
I
think
not
having
the
superset
originally
for
you.
Ben
is
attractive
to
the
cmb
project
is
like
the
ability
to
extend
the
format
to
adapt
to
different
kind
of
product
use
cases
and
things
as
the
platform
adds
new
functionality.
B
Function,
yeah,
if
the
heroku
one
truly
is
a
super
set,
though
like
what's
the
use
of
like
I
I
keep
coming
back
to
like
it
feels
like
you've
defined
another
file
right.
Another
schema,
it
happens
to
be
the
superset
of
another
schema
but
like
it
is
a
descriptor
right,
it
can
be
passed
in
if
it
is
truly
a
super
set
of
the
project
descriptor,
you
can
just
pass
it
into
pack
with
the
same
flag.
You
always
have
there's
a
bunch
of
extra
keys
that
aren't
used.
B
It
is
a
super
set
sort
of
right
now
only
because
we're
not
like
very
strict
on
our
on
how
we
validate
the
file
like
so
it
happens
to
work
now.
We
just
happen
to
ignore
the
keys
that
we
don't
understand,
but
I
think,
as
the
spec
is
written,
we're
really
not
supposed
to
be
writing
things
into
the
tables.
We're
writing
things.
I
think
it's
more.
B
A
B
Mixing
stuff
you're
talking
about
potentially
too
right.
First
right,
that
kind
of
stuff
yeah,
I
think
that's
going
to
be
a
separate
table,
but
I'm
not
sure,
but
if
pac
doesn't
understand
it
or
if
the
life
cycle
doesn't
understand
it,
it
can
just
be
ignored
right.
Oh,
like
the
heroku
specific
stuff.
A
B
B
I
think
that's
orthogonal
what
that
is,
but
if
that
were
true,
if
the
top-level
key
was
always
project,
including
in
the
heroku
specific
extension
case,
you
could
add
your
extensions
we'd,
ignore
them
and
pack
and
no
one
would
be
the
wiser
right
like
nothing
would
would
break
there,
which
then
puts
with
the
with
the
tweet
to
say
that
all
unknown
all
unspecified
keys
are
ignored,
then
sort
of
orthogonal
to
that
is
the
name
of
the
table.
It's
more
problematic
yeah.
I
think
that's
definitely
like.
One
of
the
two
suggestions
in
here
is
definitely
like.
B
The
things
that
are
unspecified
by
the
spec
are
basically
unspecified
in
because
I
think
the
way
it's
defined
now
in
the
spec,
anything
that
is
unspecified
is
technically
incorrect
right.
I
think
that's
how
we've
defined
it
yeah.
Yes,
I
assume
it
was
written
in
my
speak,
which
was
it
is
reserved
for
our
future
usage,
yep,
yeah,
and
so
like.
Definitely
one
of
the
two
pillars
of
this
rfc
and
I'm
happy
to
split
them
into
separate
ones,
is
about
making
that
more
flexible.
A
A
B
B
Somebody
might
have
like
dash
blue
or
dash
green
in
their
file
names,
or
something
like
that.
Like
that's,
where
things
get
a
little
jumpy
for
me,
I
I
think
we're
expecting
potential
to
have
more
than
one
top
level
table,
but
not
fulfilling
the
same
need
like
you,
wouldn't
see
a
heroku
or
in
a
vmware
table
potentially
in
the
same
file,
but
we
could
have
another
top
level
table
like
how
build
is
a
top
level
table.
That's
like
we
want
this
to
be
not
kind
of
subsection
under
heroku
dot.
B
So
I
am
firmly
in
the
camp
of
no
matter
what
let's
go
ahead
and
relax
the
restriction
about
unknown
keys
and
the
spec
can
say
we
will
just
ignore
them,
which
I
think
gives
a
lot
of
people
a
lot
of
flexibility
to
do
what
they
want
there,
but
rather
than
continue
going
on
here.
I
think
I'd
like
to
see
some
more
iteration
on
how
to
sort
of
reconcile
that
top
level
table.
B
Type
so,
as
I
constantly
tell,
people
like
our
customers
and
cf
lost
their
when
we
asked
them
to
write
three
lines
of
the
ammo
in
a
descriptor
and
like
every
time
I
see
someone
show
me
500
lines
of
yaml
for
kubernetes,
I'm
like
nope,
not
going
to
happen.
I
think
the
same
thing
is
true.
Jesse
like
if
you
start
asking
people
to
write
multiple
tamil
files,
people
like
are
barely
aware.
Tom
will
exist
in
the
first
place
now
you're
asking
me
for
three
of
those:
oh
yeah,
no.
A
The
composability
of,
like
you
know
if
you
translated
app.json
over
to
autumnal
file
like
you,
would
have
like
a
staging
environment
to
your
point
like
the
blue
green,
would
be
in
that
same
file.
And
then
you
would
need
to
tell
pack
about
those
different.
But
they
may
have
different
build
packs
for
blue
versus
green
and
being
able
to
extract
that
out
and
tell
pack
just
just
about
the
buildbacks
without
having
to
understand.