►
From YouTube: Working Group: 2020-10-21
Description
* Stack Buildpacks
* Asset Packages
* Default Process Types
A
C
B
D
A
A
B
E
C
E
C
B
E
B
C
B
D
C
B
A
E
E
D
A
B
B
So
I
think
I
like
I
like
reusing
the
files
we
have
already
too,
since
that's
where,
like
I
think,
launch
tunnels
or
slices
live
right
now
and
they're
superficially,
you
know
kind
of
a
similar
concept
so
to
me
having
a
separate
file
for
each.
You
know
is
maybe
a
little
bit
more
robust
long-term,
but
I
don't
have
a
strong
opinion
as
long
as
it's
not
launched
in
the
case
where
you're
just
talking
about
build
layers
that
could
never
end
up
in
any
kind
of
launch
related
context.
B
B
Top
of
my
head,
the
use
case
for
excluding,
is
for
being
able
to
introduce
that
caching
mechanism,
so
so
that
I
mean
a
big
goal
of
this
thing
is
that
operating
system
package
installation
shouldn't
take
forever
every
time
right
and
a
big
time
suck
part
of
that
is
downloading
the
package
indices
right
and
keeping
those
up
to
date
right.
Those.
A
B
A
B
By
default,
because
if
you
cache
the
whole
layer
together,
then
you
have
to
throw
away
the
whole
layer
when
there's
a
new,
build
image.
Like
there's
an
update
to
the
builder.
That's
going
to
happen,
like
you
know,
every
couple
days
right,
maybe
like
any
time
there's
an
update
to
the
building.
You
can't
recover
any
of
the
snapchatted
layers
you
have
to
replay
them
and
so
the
that
that
exclude
and
and
cache
mechanism
as
a
way
to
say,
okay,
this
stuff,
but
just
this
stuff
is
actually
safe
to
reap.
B
So
I
think
I
think
there
are
two
kinds
of
caching
right:
there's
the
caching,
where
you're
making
changes
to
the
layer
and
then
in
each
case,
as
long
as
you
have
what
non-item
potent
equals
false.
I
guess
the
the
whole
layer
comes
back
right
and
the
next
build
happens
on
top
of
that
layer.
But
as
soon
as
that
base
image
changes,
you
can't
you
can't
just
take
that
old
layer
and
put
it
on
top
of
the
new
base
image
right
right,
and
so
we
came
up
with
this
mechanism.
B
Just
thinking
about
the
launch
case
right
to
say:
okay,
this
amount
shouldn't
end
up
in
the
final
image
right,
but
but
it
does
come
back.
You
know
on
subsequent
builds
and
I
thought
the
build
thing
was
just
the
same
as
that,
but
without
the
without
that,
you
know
exclude
meaning
or
like,
but
with
reference
to
the
the
whole
layer
snapshot
that
comes
back
next
time.
Right,
like
don't
include
that
whole
layer
snapshot
exclude
it
from
that,
but
include
it
in
this
other
cached.
B
So
that
way
like,
if
you
had
made
a
whole
bunch
of
big
temporary
files
during
build-
and
you
didn't
want
those
to
get
stored
off
in
this
separate
layer,
you
could
exclude
them
from
the
build
build
layer
right,
but
you
can
also,
but
you
can
also
say,
actually
cache
these
permanently.
So
you
get
the
opposite.
Behavior
always
comes
back,
even
if
the
base
image
changes,
because
you
know
it's
there,
so
is.
C
B
E
Somewhat
radical
process
suggestion
here
because
it's
been
hard
to
get
the
stack
packs
all
the
way
through,
because
there's
so
many
details
and
points
of
things
to
talk
about
what.
If
we
just
cut
everything
that
wasn't
necessary
out
entirely
like
yes
to
make
this
usable
in
the
long
run,
we
need
capturing,
but
it
might
be
easier
to
think
about
having
a
stack
pack,
cache,
rfc
and
just
removing
all
of
it.
From
this
one.
E
Well,
since
we're
so
close
to
improving
the
experimental
api
right,
this
rfc
could
be
about
the
first
version
of
an
experimental
feature,
and
we
know
we're
gonna
need
to
elaborate
on
it
over
time.
I
think
it
might
help
us
make
progress,
because
I
feel
like
just
the
number
of
things
in
this
rfc
makes
it
hard
to
make
progress,
and
it's
also
hard
to
like
keep
all
the
context
in
our
heads
about
each
point
that
we've
been
discussing.
B
B
Point
in
mind,
I
think
everything
is
cache
by
default
at
build
right
unless
the
base
image
changes
and
then
it's
not.
And
then
you
have
that
cache
flag
in
order
to
get
past
that.
But
but
I
don't
think
there
was
ever
an
idea
that
we
would
cache
the
whole
layer
and
then
re
try
to
rebase
that
on
top
of
the
previous
image,
because
I
think.
C
B
E
We
can
ship
without
any
cashing
at
all,
that's
safe,
it's
slow,
but
it's
safe
and
I
feel,
like
we've
worked
this
out
enough,
that
I
don't
think
we're
in
danger
of
saying.
If
we
approved
it,
we
wouldn't
be
able
to
add
catching
it
later,
which
I
think
was
the
original
fear
why
we
didn't
want
to
approve
the
slow
but
safe
version
of
these
things.
I
think
it
could
help
the
conversation
a
lot
to
be
able
to
break
this
up
into
discreet
chunks.
B
But
but
instead
of
making
the
decision
now,
we
schedule
a
meeting
just
to
talk
about
stack
packs
where
we
decide
whether
or
not
caching
makes
it
in
or
out,
but
at
the
end
of
the
meeting
it's
either.
We
agree
completely
on
caching
and
feel
totally
aligned
of
what's
going
to
go
in
or
if
the
case
is
that
we're
really
not
that
far
away
from
it
or
we
agree
that
it
has
to
go
into
a
separate
rfc.
E
B
A
A
A
A
B
The
idea,
though,
is
when
I
talked
to
emily
about
this:
build
pack
can
statically
define
mixins
and
build
pack
tommle,
but
it
must
explicitly
state
which
subset
of
those
mixins,
including
those
are
not
that
it
can
provide
dynamically
during
detect.
Also
that
the
once
they're
they're,
statically
and
built
back
tomorrow,
just.
A
B
B
It
would
there
would
always-
or
I
think
the
thing
I
care
about
is
if
there
are
no
static
mix-ins
in
build
pack
tamil,
then
we
can't,
you
know
a
platform
can't
guarantee
that
any
build
can
or
if
there
are
stack
packs
there.
There
can't
be
any
static
validation
ahead
of
time
that
a
build
could
happen.
So
we
are
going
to
put
them
in
in
buildpectomy
is
all
right.
B
A
C
D
E
B
A
The
problem
it
will
know
if
it
is
compatible,
there's
no
way
for
it
to
know
that
100
that
it
is
not
compatible
like
you
could
say
it
could
say.
I
am
not
compatible,
but
it's
sort
of
a
false
negative
because
it
provides
the
thing
it
needs
dynamically
right,
but
there's
no
chance
of
a
false,
positive.
A
You
could
so
you
could
go
through
the
list
of
possible
possibilities
and
some
might
fail,
even
though
they
would
have
provided
the
mix
in
dynamically,
and
you
might
arrive
on
an
image
or
stack
that
that
does
work
or
you
might
not
find
anything.
And
then
you
would
have
to
fall
back
to
actually
running
the
detect
phase
in
order
to
get
those
dynamically
provided.
Mix-Ins.
B
I
think
the
really
specific
case
is
like,
if
you
introduce
a
ca,
serp
build
stack
pack
right,
for
instance,
now
you're
unable
to
valid.
Now
you
you
may
reject
see
it's
not
a
mixing
yeah,
but
like
life
cycle
is
not
going
to
know
that
the
case
or
build
pack
is
special
and
can't
secretly
be
providing
mix-ins
dynamically
at
build
time.
B
Yeah,
but
it's
a
stack
pack
and
it
it
can
provide
mix-ins
like
a
platform,
wouldn't
know
specifically
that
it
must
exempt
this
case
or
build
pack
from
these
rules,
because
it
can't
provide
mix-ins
because
we're
saying
that
it
can't
provide
a
static
list
of
like
there's
no
way
for
it
to
communicate.
Hey.
I
don't
provide
mix-ins
if
that
makes
sense,
because
it
could.
E
B
I
think
just
saying
that
you
have:
we
already
have
a
mix
sense
too,
which
is
like
sending
mix
into
asterisk
right,
statically
and
then
or
whatever
interface.
We
came
up
with
that
right.
The
ability
to
say
can
provide
any
mix
in
if
that's
part,
if
that's
a
way
that
you
can
statically
express
hey,
you
know
I
could
provide
anything.
I
want
during
the
build
process
or
during
the
detect
process.
Then.
B
B
C
I
think
we're
kind
of
circling
on
the
actual
issue,
this.
What
we
were
trying
to
optimize
for
is,
like
the
pack
crate
builder
case,
when
you
have
a
list
of
build
packs,
and
you
want
to
know
when
you're
creating
the
buildback
that
that
build
back,
never
actually
has
a
chance
to
succeed,
because
it's
missing,
because
there's
no
stack
pack
that
can
provide
the
mixing.
That's
right.
B
In
the
kpac
case,
I
think
there
were
there's
some
particularly
like
bad
outcomes
that
I
remember
we
brought
up
at
some
point
where,
like,
if
you
introduce
any
stack
packs
to
the
build,
if
you
can't
know,
if
they're,
if
they
have
there's
no
way
to
tell
that
they
aren't
going
to
provide
any
mixing
in
the
world,
then
you
lose
a
lot
of
validation.
That
is
important,
like
you'd,
never
really
be
able
to
tell
if
a
build
pack
could
or
couldn't
run
on
a
stack.
C
B
A
It
doesn't
say
anything
about
it
right
what
that
means.
The
implica,
like
one
of
the
implications
of
that
I
can
add
that
to
this
pr
here,
the
draft
pr
is
what
mcnew
is
talking
about,
which
is
it
becomes
more
likely
that
you
can
create
build.
You
can
create
builders
that
will
never
work
ever
for
any
app,
because
pac
create
builder
cannot
validate
the
mix-ins
at
create
builder
time.
B
C
C
B
A
A
B
A
A
A
Okay,
yeah
like
if
you
could
put
those
in
and
like
note
them
in
the
comments
like
I
think,
we'd
all
be
happy
to
just
do
it
via
the
pr
asynchronously
for
now
and
hopefully
get
it
done
before
next
wednesday,
and
if
not,
we
can
pull
it
back
up
on
wednesday.
But,
like
would,
I
am
highly
motivated
to
respond
to
you
in
any
manner
that
you
need
to
make
sure
that
happens.
C
C
C
Sorry,
while
I'm
pulling
it
up,
I
think
the
sticking
point
right
now
is
the
pack
migration
path,
because
at
the
moment
let
me
just
zero
in
on
the
conversation
at
the
moment,
pac
is
always
passing
process
type
of
web
to
the
life
cycle.
We
added
that
when
the
life
cycle
started
defaulting
or
the
life
cycle
stops
defaulting
to
web.
C
Quite
a
long
conversation
happening
somewhere
around
here
and
so
yeah,
basically
like
if
you're
in
a
world
where
every
build
pack
is
implementing
the
new
api
and
declaring
a
default
process.
If
that's
applicable,
then
pac
doesn't
need
to
pass
web
at
all.
But
if
we
kind
of
rip
it
out
too
soon,
we'll
get.
You
know
a
lot
of
application
images
that
just
aren't
runnable
because
they
won't
have
a
default
process,
and
so
I
guess
the
question
is:
how
do
we
make?
A
D
C
A
E
E
D
A
E
Yeah,
I
don't
know
if
it's
an
error
like
if
that
error
happened
to
me.
I
would
still
want
my
image
to
finish
exporting
right.
It's
not
like
an
error
that
I
want
to
drop
hard
for,
I
kind
of
want
to
know
what
happened
and
then
I
can
run
it
with
a
different
process
type,
which
makes
it
more
of
a
worn
situation.
I
don't
want
it
to
like
barf.
B
E
B
In
ci,
I
would
really
want
this
to
fail
if
the
build
pack
changes
the
process
type
up
stream.
I'd
want
a
red
pipeline,
saying:
oh,
I
gotta.
I
gotta
fix
this,
so
it
works.
I
wouldn't
want
to
like
see
a
warning
that
I
don't
notice
and
then
the
images
that
get
deployed
to
production.
Suddenly,
you
know
don't
have
default
processes
or
whatever
right.
It
seems
like
it's
really
an
error
case.
C
I
think
the
context
probably
matters
of
like
how
you're
using
it,
because
I
agree
with
like
what
steven's
saying
like
in
a
ci
pipeline.
I
definitely
want
to
error,
but
if
I'm
doing
like
a
pack
build
locally
and
say
I
maybe
I
even
just
like
typo
the
default
process
thing
and
it
didn't
exist
like
I
misspelled
web
or
whatever
right,
I
probably
potentially
still
want
the
image,
because
I
don't
want
to
pay
the
cost
rebuild
it.
C
A
There's
a
failure
there.
We
don't
create
an
image,
but
if
you
had
to
go
rebuild
it
again,
you're
not
really
starting
from
scratch.
At
that
point,
most
of
those
caches
are
going
to
hit
on
your
way
there
and
the
last
thing
of
setting
the
proper
default
process
type.
Is
you
know
quick
and
easy
as
you
go
from
there.
B
I
was
going
to
say
exactly
that
the
problem
seems
like
our
caching
isn't
is,
is
you
know,
has
a
deficiency
and
that
it's
not
you
know
you
have
to
throw
the
whole
thing
away
if
something
at
the
very
last
thing
ends
and
the
way
we
should
fix
that
isn't
make
the
failures
at
the
end
not
really
failures
and
export
images
that
don't
you
know,
look
exactly
like
what
you
requested
but
actually
make
the
caching
thing.
You
know
efficient
enough
that
you
can.
A
On
the
platform,
api
side
pack
can
say:
okay
like
as
long
as
I'm
working
on
platform
up
to
some
point,
I'm
going
to
pass
in
dash
web
every
single
time
and
then,
when
I
move
beyond
whatever
the
spec
limit,
inflection
point
is:
I
will
stop
passing
in
anything
at
all
right
unless
it's
actually
requested
by
the
user.
So
like
behave
appropriately
from
that
direction
and
then
on
the
build
pack
side
say
after
the
inflection
point,
where
we
expect
to
build
packs
to
be
setting
their
own
default
process
types.
They
do
that.
D
D
A
A
A
If
there
is
a
platform
api
change,
I
mean
I
guess
I
could
do
an
inflection
on
the
life
cycle
version
potentially
as
well,
but
I
think
an
api
changes
the
appropriate
way
to
do
that,
because,
right
so
imagine
imagine
we
do
jesse's
thing
right,
like
the
early
ones,
all
assume
web,
but
the
later
ones
don't
assume
web
right.
They
have,
you
know
executable
jar
and
they
have
war
file
or
something
like
that
right.
E
The
easiest
thing
for
users,
even
if
it's
not
the
most
beautiful,
would
be
to
change
the
platform
api
so
that
if
no
build
pack
specifies
a
process
type
you
get
web,
regardless
of
what
the
platform
does
like.
The
life
cycle
has
a
default
process
type
web
and
then
the
feature
that's
missing
is
you
can't
basically
create
an
image
that
has
no
default
process,
but
that
could
be
a
special
value
that
you
pass
the
process
type.
A
D
Oh
sorry,
I
was
just
going
to
kind
of
point
this
out.
I
think
we're
going
to
end
up
in
the
case
where
we
might
do
some
things
that
we'll
later
wish
to
have
included
for
1.0,
or
you
know
and
add
to
that
list
of
things
that
we
want
to
change,
even
if
just
for
aesthetic
purposes
right
like
I
don't
think
we
want
a
special
value
for
the
process
type.
I
think
we
all
agree.
That's
not
ideal
aesthetically,
even
though
it
could
technically
solve
the
problem.
A
Right
so
the
the
thing
I
was
trying
to
say,
as
my
network
broke
up,
is
I
I
don't
want
to
walk
backwards
from
that
idea.
That,
like
we,
don't
like
this
as
a
default,
where
I
am
willing
to
caveat,
is
for
compatibility
for
a
temporary
period
to
get
us
to
the
other
side
of
that
having
it
as
part
of
the
life
cycle.
Shimming
all
of
these
things
together,
I'm
okay
but
like
when
we
get
to
1-0
it
shouldn't,
be
there
anymore.
C
E
C
Yeah
so
like
you
could
still
get
the
no
launcher
thing.
It's
like.
If
platform
says
web,
it
doesn't
know
what
the
bill
packs
are
specifying,
but
then
you
still
get
that
compatibility
thing
and
it
doesn't
have
to
fail
the
build.
But
if
a
user
specifies
web
and
it
doesn't
exist,
then
you
would
fail
to
build.