►
From YouTube: Working Group: 2020-10-14
Description
* Builder Extension: https://github.com/buildpacks/rfcs/pull/116
A
C
C
B
B
C
C
B
B
B
C
Yeah,
I
think
I've
addressed
most
or
maybe
all
of
the
feedback
certainly
could
be
potentially
more.
That
needs
to
be
added,
but
I'd
like
to
try
and
drive
this
one
to
a
close
within
the
next
week
or
so
so
I'm
I'd
like
some
advice
on
what
we
think
needs
to
happen
to
make
that
happen,
but
I
think
one
of
the
things
would
be
to
review
jesse's
pr,
because
it
you
know,
gives
you
a
little
bit
more
concrete
sense
of
what
might
be
missing
or
or
whatever,
from
this
rfc.
B
C
It
was
a
proof,
but
I
think
it
changed
since
people
added
their
approval,
so
I
don't
know:
if
there's
a
can
we
like
alert
people
who
have
approved
maybe
to
give
it
one
more
read
yeah.
I
reviewed
those
changes,
but
maybe
we
should
just
refresh
all
of
them
and
then
because,
like
just
to
make
it
obvious
that
they
were.
B
B
C
C
B
B
B
B
B
A
C
D
Sorry,
I
didn't
interrupt
you.
I
think,
there's
a
little
bit
of
a
lag
there
on
the
mvar
thing,
I
was
wondering
we
have
gone
out
of
our
way
to
make
things
like
after
and
things
like
that,
configurable
and
I
feel
like
if
we
made
it,
we
made
it
configurable
for
a
reason,
because
there
might
be
platforms
that
want
to
have
an
opinion
that
the
name
of
the
aperture
shouldn't
be
workspace.
D
It
should
be
the
name
of
their
platform
or
something,
and
then
therefore,
in
the
builder
spec,
instead
of
saying
we
have
to
set
things
to
the
default
value,
saying
that
we
have
to
set
the
environment
variable
to
a
valid
value.
I
think,
gives
people
an
option
to
to
take
advantage
of
some
of
that
flexibility.
That's
sort
of
my
feeling
on
the
environment
variable
stuff
and
also
gives
us
a
chance
to
change
default
someday.
D
D
Sometimes
there
can
be
weird
permissions
issues
with
the
parent
directories
when
you
automatically
mount
something
in
depending
on
the
you
mask
in
the
image,
so
I
think
creating
those
variables
in
advance
and
then
pre-configuring
it
sort
of
helps
you
get
around
those
issues.
Those
are
the
the
reasons
behind
some
of
those.
A
So
in
that
case
you
know
there
is
a
bunch
of
sub
things
within
the
c
c
b
directory
and
then
there's
layers
platform
and
workspace.
Stephen.
Are
you
saying
that
that
perhaps
cmbs
shouldn't
be
like
the
cmb?
We
should
kind
of
you
know
restrict,
or
we
should
have
some
more
opinions
on,
but
otherwise
for
layers,
platformer
and
workspace.
We
should
we
can
use
and
bars.
B
I
think
that's
my
opinion,
like
cnb
we've
called
out
as
cnb
on
purpose
to
be
like
yes,
this
is
you
know
inflexible.
I
don't
know
if
we
meant
to
define
it
as
slash
cnb
or,
if
that
even
that
should
be
configurable
right,
but
the
structure
inside
shouldn't,
but
for
the
outside
stuff,
that's
injected
like.
B
B
Can
you
provide
some
context,
so
this
environment
variable
is
like
part
of
that
upstream,
new
service
mining
thing
that
ben's
been
working
on
some
folks,
the
and
it's
like
this
environment
variable
has
to
be
present
runtime
or
something
for
to
find
what
services
and
we're
defining
the
build
time
version
of
that,
and
so
during
build
time
should
that
have
to
be
set.
I
kind
of
feel
like
if
the
upstream
thing
doesn't
say
this
is
only
for
apps
at
runtime
right,
then
that's
the
con.
B
C
B
Like
should
you
restrict
it
so
that
it's
like
this
must
be
the
value
of
environment,
variable
version
of
cnb
platform,
dir
right,
slash
and
then
the
word
bindings.
I
I
would
be
okay
with
an
additional
restriction
in
the
cnb
context
that
that
directory
must
be
the
this
subdirectory
of
this
other
environment
variable
that
seems
reasonable
to
me
to
make
everything
fit
together.
D
Yeah,
I
guess
it
should
say
like
it
should
be
set
to
whatever
the
environment
variable
that
points
the
platform
is
said
with
bindings
after
it
right.
I
don't
think
that
stops
you
from
at
runtime,
mounting
your
binding
somewhere
else
and
setting
the
environment
variable
somewhere
else,
but
the
idea
that
it
comes
with
an
environment
variable
set
gives
platforms
the
option
to
just
mount
something
in
without
worrying
about
setting
it.