►
From YouTube: Working Group: 2020-06-10
Description
* Publish a Buildpack with pack: https://github.com/buildpacks/rfcs/pull/75
* Launcher Arguments: https://github.com/buildpacks/rfcs/pull/84
* Pack Image Pull Policy: https://github.com/buildpacks/rfcs/pull/80
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
B
B
B
C
Shipped
the
patch
release
I'm
just
kidding
yeah,
we
did
ship
a
patch
release.
What
was
it
yesterday
and
it
had
to
do
with
a
bug
that
we
found
in
relation
to
mounting
volumes
for
the
Creator
flow
we
have
found
another
bug
in
relation
to
you
know
kind
of
the
new
untrusted.
Slash
creator
feature
we're
still
in
discussions
as
to
whether
or
not
that
warrants
a
patch.
B
A
A
B
B
D
D
D
B
B
A
B
A
B
B
A
D
B
B
C
A
B
D
D
Yeah,
so
what
was
I
saying,
yeah,
there's
two
conflicting
concerns
here:
one
is
the
the
desire
to
use
github
identity
as
a
source
of
truth
for
ownership
of
a
build
pack,
and
the
other
is
I,
think
the
one
that
Steven
brought
up,
which
was
not
wanting
to
create
anything
on
github,
including
an
issue
on
behalf
of
a
user
without
actually
opening
a
browser.
So
those
two
things
like
wanting
to
have
both
of
those
is
not
basically
not
possible
to
have
had
lists.
D
So
we
have
to
compromise
on
one
of
them
too
to
get
somewhere
but
I,
don't
think
just
after
putting
some
thoughts
into
it,
I
don't
I,
don't
think
we,
whatever
we
end
up
doing
there,
we'll
compromise
or
change.
What's
the
the
non
headless
route.
So
that's
why
I
think
I'm
comfortable
going
forward
with
an
RFC
that
just
doesn't
have
anything
about
it
in
there.
It
doesn't
mean
that
for
the
time
being,
there's
no
solution
for
headless,
so
I
think
that's
really
the
thing
we
should
need
to
confirm.
D
A
A
A
D
I
called
the
argument:
what
Genesis
talking
about
is
for
the
argument
for
a
published,
buildpack
was
called
URL
but
I
think
that's
not
accurate.
It's.
It
could
be
a
URL
in
the
docker
colon,
slash,
slash,
slash
format
like
in
the
build
pack.
You
are
URI
RFC,
but
it
will
most
likely
be
a
tag
with
no
prefix
like
dot
like
host,
prefix
or
anything.
So
I
think
we
should
support.
You
know
anything
in
that
format
and
can
yeah.
A
D
C
D
Yeah,
the
other
yeah
we're
saying
so
you're
an
as
part
of
the
registry
spec
specification.
We
are
saying
that
the
build
package
has
to
exist
in
a
docker
registry,
so
the
register
Bell
pack
registry
would
not
be
compatible
with
seem
like
dot
CMD
files
or
seen
us
build
packages
and
formats
other
than
a
no
CI
image.
D
A
D
Think
I
could
still
default
to
that,
although
it
does
change
well,
okay,
so
actually
that
might
come
time
to
the
next
thing
that
I
wanted
to
bring
up
I
prototype,
what's
in
the
RFC
impact
and
was
just
playing
around
with
it,
and
one
of
the
things
that
kind
of
came
across
to
me
is
like
awkward.
Is
the
flow
between
package
buildpack
and
published,
build
pack
we're
like
I
created
a
new
build
pack
I,
do
what
I
need
to
do
I
test
it
I'm
playing
around
with
it
awesome
now,
I
want
to
publish
it.
D
I
have
to
create
a
package
Tom
all
wrong
package,
build
pack
and
then
run
published,
build
pack
with
the
thing
that
I
just
pushed
we're
like
really.
What
I
want
to
do
is
just
from
that
repo
run,
published,
build
pack
and
so
I
was
I
was
just
arting
to
wonder
if
we
need
to
do
account
for
that
in
the
RFC.
D
C
One
thing
like
that
you
could
foresee,
as
a
you
know,
in
some
sort
of
shortcut
fashion
would
be
nice,
but
I
mean
I,
don't
know
if
that's
really
what
we
want
to
focus
in
on
first
versus
just
providing
all
the
separate
commands,
because
we
know
that
we
need
what
we
are
proposing
in
this
RFC
right,
like
people
are
going
to
have
their
build
packs
in
a
docker
image
somewhere,
and
they
just
wanna
on
to
a
registry.
So
I
think
that
that
commanded
itself,
it's
necessary
I,
think
are.
D
D
Naturally
right
so
like
I
think
what
I'm
thinking
is
that
published,
build
pack
should
run
packaged,
build
pack
on
a
single
build
pack
without
needing
a
package
tamil,
and
it
should
be
able
to
do
that.
Like
just
from
the
built
back
directory,
you
should
be
able
to
point
to
a
build
pack.
Tamil
file
run
published,
build
pack
and
up.
It
goes
so.
A
C
And
then
pushing
it
somewhere
to
your
registry
and
then
adding
that
to
our
build
pack
registry
right,
so
those
three
operations,
you're
saying,
should
really
just
be
one
operation.
I
agree
with
that.
You
know
completely
I
think
it
would
change
the
RFC
significantly.
That
conversation
would
maybe
start
over
again
yeah.
A
B
A
D
A
D
A
I
didn't
comment
on
this
out
on
the
obstacles.
Thinking
about
the
other
day,
you
haven't
known
about
basically
not
having
anything
else
open
with
regards
to
issues
or
PRS
and
I
wonder
if
we
should
just
use
labels
or
something
so
I,
if
potentially,
there
is
like
a
thing
that
we
do
want
yeah
like
people,
people,
including
ourselves,
to
open
issues
or
something
and
have
that
route
where
it's
like
anything,
that's
automated
to
the
bot,
but
goes
on
to
a
very
specific
label
anytime.
That
makes
sense
mm-hm.
D
D
A
D
I
don't
know,
given
the
discussion.
I,
don't
have
a
good
I'm.
Sorry
I,
don't
have
a
good
idea
of
what
we
think
the
more
the
tighter
set
up
that
can
be
loosened
in
the
future
is
right,
like
I
think
that
goal
of
we
should
do
what
it
takes
today
to
make
sure
that
it
is
unambiguously
a
docker
image
URL
and
then
give
us
the
flexibility
to
loosen
that
in
some
way,
but
I'm
not
sure
if
that
means
locking
down
the
argument
or
not
yeah.
A
I
mean
I.
Guess
in
my
suggestion,
know
if
you
saw
it
then
was
like
if
everything
is
a
docker
like
registry
type,
like
your
eye
kind
of
thing,
like
most
people
are
probably
gonna,
publish
the
deck
up
so
like
the
dagger
client,
most
people
being
most
people
who,
like
that's
the
only
one
we
could
probably
assume
reasonably
and
so
I.
D
A
D
B
Like
how
I'm
imagining
the
other
cases
working,
you
would
still
always
need
a
docker
registry
address
right
because
you're
either
you
know
doing
a
couple
steps
and
then
putting
it
in
a
registry
and
then
putting
in
a
docker
registry
and
then
putting
it
in
our
registry
or
you're
just
putting
something.
That's
already
in
a
docker
registry
in
our
registry
I
think
we
still
wanted
to
move
to
a
docker
registry
anyways
right.
So
wouldn't
you
just
need
a
docker
registry
argument
and
then
later
you
could
add
something.
B
D
That's
the
one
like
once
you
introduce
the
path
to
a
build
pack
on
the
file
system.
That's
we
run
into
the
problems
that
pack
build
be
argument,
but
that
we
would
only
be
talking
about
in
the
context
of
the
to
be
described,
publish
build
pack
for
this,
the
one
that
will
be
renamed
in
this
RFC.
It
will
not
accept
the
path
to
a
build
pack.
As
an
argument,
ever
it'll
only
release
a
and
already.
D
Public
I
could
just
build
pack
with
published
flag
I,
don't
want
to
call
it
something
on
a
registry
or
right,
and
if
so,
one
of
the
things
I
want
to
push
back
on
Emily
I.
Don't
think
that
we
have
like
a
very
strict
belief
that
everything
will
the
canonical
representation
of
all
these
things
will
be
an
image
in
a
registry
or
layers
in
a
registry.
You
could
imagine
a
CNB
hosted
as
a
github
asset,
and
the
buildpack
registry
could
point
to
that
particular
tarball
asset
right.
B
The
build
package
extension
was
was
to
make
that
the
canonical
representation
and
like
everything
else,
is
a
convenience,
and
we
can
make
it
easy
to
get
from
your
convenience
to
there.
But
there
is
a
canonical
representation.
I
think
does
keep
things
simple
at
the
end,
especially
we're
talking
about
authentication
when
you're
trying
to
pull
these
things
down
like
when
everything
is
a
docker.
It's
easier,
yeah.
D
D
Right
and
so
I
don't
want
to
plan
I,
don't
want
to
say
that's
a
thing,
but
I
also
don't
want
us
to
pick
a
syntax.
That's
going
to
put
us
in
the
pack
build
territory
again
where
we
said.
Oh,
it's
always
going
to
be
something
that
doesn't
need
to
be
qualified
and
now
we're
having
to
do
some
sort
of
backwards,
incompatible
or
heuristic
changes
to
it.
Yeah.
A
D
D
D
D
D
B
The
other
change
here
is
one
of
the
sticking
points
we
were
running
into
before
is
how
we're
gonna
add
arguments
to
a
batch
process,
because
the
way
we
were
evaluating
batch
processes
before,
if
you
put
them
in
the
arguments
array,
wouldn't
use
them
in
an
intuitive
way
and
just
adding
them
to
the
command
string
introduced
a
lot
of
problems
with
shell,
parsing
and
tokenization.
So
I
spent
some
time
playing
around
at
the
launcher
and
created
some
somewhat
complicated.
C
C
B
Suggestions
welcome
there,
I'm
not
tied
to
particularly
Wed.
The
over
I'd
heard
me
thought,
like
the
environment.
Variable
Fermi
thought,
leaving
it
unset
in
some
ways,
was
the
most
intuitive
by
after
thinking
about
it.
That
has
always
meant
web
and
I
think.
Even
though
it's
intuitive,
it's
not
worth
changing
that
on
our
users.
D
B
B
B
All
of
the
different
information
we
needed
into
the
fields
we
have
at
our
disposal
having
two
different
ways
to
set
the
process:
type
like
the
environment
variable
and
the
command
line
felt
unnecessary
to
me:
I'm,
okay,
with
their
dress
being
one
cuz
they're,
both
fairly
easy
to
set
in
most
cases,
you'd.
Be
writing
a
container.
B
D
C
D
Same
it's
used
in
a
lot
of
like
blog
posts
and
stuff
like
that
now,
but
I
think
people
definitely
found
it
unexpected.
Even
though
I
used
to
all
the
time
I
think
people
eventually
learned
it
would
use
a
lot
it
didn't.
It
didn't
expect
it
to
work
and
then,
when
you
start
throwing
in
the
oh
well,
there's
this
launcher
thing
and
it's
actually
good
wrapping
you're,
you're,
commanded
yeah.
A
B
D
B
B
Still,
can
you
just
need
to
set
the
process
type
to
override
before
you
bashed,
which
is
some
ways
it
makes
sense
to
me,
because
if
you
had
a
container
with
an
entry
point,
you
wouldn't
be
able
to
docker
run
bash
it
without
disabling
and
I'm,
been
thinking
about
CMV
process
type
mystery,
but
now
I
guess
to
the
entry
point.
In
this
case.
B
B
A
Think
a
lot
of
people
are
day
bash
in
and
they
don't
realize
that
they've
also
gotten,
although,
like
launcher,
you
know,
environment,
variables
and
stuff
and
so
like
as
soon
as
we
do
make.
This
change
then
having
to
CNB
process
type
of
override.
It
makes
it
more
explicit,
but
it
does
mean
that,
like
what
what
they
might
have
been
able
to
do
in
bash
before
they
won't
be
able
to
do
without
going
through
the
launcher
explicitly
to
get
there
again.
Yeah.
B
B
A
Where
I
think
like
people
might
naturally
try
the
bash
thing
in
the
existing
CV
thing
and
then
the
fact
that
it
worked
is
probably
a
pretty
nice,
like
I,
remember
like
when
people
would
Heroku
run
bash
and
realize
that's
a
thing
that
lets
them
get
access
to
the
Dyna
whatever
and
do
whatever
in
it.
That
was
a
pretty
powerful
moment.
B
C
Yeah,
so
if
we
think
about
like
what
the
default
experience
should
be
right
like
which
one
do
we
really
think
that
one
is,
is
it
the
one
where
you
treat
your
app
image
container
as
something
that
you
could
just
execute
any
command
on
or
as
being
the
default?
Or
is
it
that
you
execute
this
app
image
container
and
adding
any
flags
to
it
essentially
provides
those
to
the
process?
Type
I
definitely
see
the
value
for
the
latter
part,
because
I
was
kind
of
hoping
to
dog
food.
C
You
know
CNB's
to
produce
that
pack
image
that,
then
you
could
just
pass
in
arguments
to
that
pack
image
and
actually
execute
it
and
run
it
right.
So
that
seems
really
really
nice
and
useful,
but
I
see
the
other
point
as
well,
so
I'm
not
sure,
but
I
do
feel
like
we
need
to
make
that
decision,
as
which
one
of
those
is
the
primary
default
or
use
case.
B
I
do
think:
we've
got
a
lot
of
feedback
that
people
expect
the
arguments
to
work
and
be
arguments
there
process
like
across
many
different
slacks
and
life
cycle
impact
issues.
That's
why
I
leaned
towards
the
argument
being
the
default
I
think
if
we
wanted
a
more
intuitive
experience
for
some
of
the
other
things
we
might
reconsider,
having
like
a
background
or
something
where
we're
controlling
the
experience
of
running
it
with
our
platform,
I
think
when
we're
talking
about
just
the
rock
container
experience
I
feel
like,
given
the
trade-offs
I
personally
feel
pretty
strongly.
A
A
A
A
D
I
think
yeah
yeah
I
was
gonna,
say
the
same
thing,
I
I
kind
of
actually
think
that
what
you're
seeing
might
be
specific
to
the
like
environment,
that's
created
by
your
bill,
packs
like
we,
we
put
rocks
with
the
box
I'll
build
pack
in
every
group
and
people
very
frequently
write
a
proc
file
just
totally
override
the
command.
We've
totally
had
people
ask
for
this
like
it's
not.
You
know
unheard
of
requests,
but
I.
D
Think
the
like
the
ecosystem
that
we're
building
from
that
people
expect
is
to
have
run
bash
work
and
to
sort
of
favor
overriding
the
command
as
a
whole.
So
that,
like
all,
that
is
to
say
that,
like
while
I
acknowledge
that
you're
seeing
it
very
frequently,
is
it
really
the
case
that
it's
a
that
that's
true
across
all
of
the
build
pack
ecosystem.
D
D
B
Could
try
to
find
a
less
and
it
did
a
way
to
answer
the
question
right.
We
could
pull
cmp
slack
and
pull
like
potato
sack
or
other
places
where
people
interact
with
built
packs
could
answer
the
question.
I
think
the
reason
the
args
default
feels
compelling
to
me
is
because
it
is
docker
default
in
a
way
like
what
you
had
in
the
command
become
arguments
to
the
entry
point
rather
than
overriding
it's
fairly
normal.
B
But
since
we're
doing
a
entry
point
launcher
and
then
a
little
special
process
type
thing,
it
becomes
less
exactly
the
same,
but
I
do
think
having
all
the
options
available
without
some
of
the
drawbacks
of
potentially
error-prone
disambiguation
every
platform
can
provide
whatever
default.
They
want.
On
top
of
that
right,
I.
C
Do
wonder
if
there's
maybe
a
third
solution
that
we
haven't
really
dug
into,
which
is
very
similar
to
how
you
know
docker
itself
would
work
where
it
provides.
You
two
configuration
elements,
the
entry
point
or
the
command
right,
and
so,
when
you're,
creating
your
image,
you
could
specify
like
hey.
If
I
want
them
to
be
arguments
to
the
thing
that
I'm
gonna
start
up,
then
I'm
gonna
put
it
in
the
entry
point.
If
not,
then
I
put
them
into
the
command
right
and
so
like.
A
C
There,
if
somehow
in
the
project,
tumbler
I,
could
specify
do
this
right
and
then
it's
set
up
so
that
everybody
that
consumes
this
docker
image
there
now
additional
arguments
to
my
process
type
versus.
If
I
don't
set
that,
then
it
becomes
the
standard.
You
know
way
that
it
would
work
for
any
other
docker
image
without
an
entry
point.
B
Like
this
complicated
about
that
as
different
processes
and
different
built
tags
have
sort
of
might
be
driving
some
of
the
differences
in
opinion
about
which
way
they'd
like
to
accept
arguments
more
than
the
user
up
front
like
right
now,
if
you
said
default
process
over
run
at
Build
time,
you
would
get
a
process
that
only
overrode
things
but
I.
Don't
think
that's
actually
what
anyone
wants
you
either
they
wanted
default
process
to
be
a
process
and
then
override
to
be
an
override.
C
C
Cool
so
show
my
screen,
so
it
has
to
do
with
the
image
pool
policy.
There's
apparently
been
a
lot
of
conversation
about
this
recently,
that's
not
allowed
for
now
and
I
think
it
comes
from
different
angles
and
so
far
I
think
the
the
reception
has
been
positive,
with
the
exception
of
the
default
right.
So
this
proposal
to
speak
to
is
more
about
two
things
really
is
kind
of
allowing
for
the
image
pool
policy
to
go
from
two
options
right
now
to
three
options
and
then
changing
that
default.
C
When
you
don't
specify
any
flag
to
be
that
new
third
option
right,
which
is
pull
it
if
it
doesn't
yeah
pull
it
it
only
if
it
doesn't
exist-
and
it
seems
like
the
point
of
contention-
is
whether
or
not
that
really
should
be
the
default.
So
I,
don't
think
anybody
has
any
problems
with
adding
the
third
option.
I
think
there
might
be
some
conversations
we
could
have
about
whether
to
use
boolean
flags
which
maybe
now
I'm
in
favor
of
versus
a
parameterised
one,
but
this
one
I
kind
of
wanted
to
talk
about.
C
So
even
if
you
have
it
locally,
for
whatever
reason
you
created
some
other
image
that
has
the
same
name
and
because
you're
testing
with
it
or
whatnot,
and
then
it
comes
along
and
you
execute
the
command
and
it
like
takes
over
that
image.
That's
really
unexpected,
so
that
there's
that
and
obviously
the
performance
aspect
of
it.
D
D
B
A
B
A
We're
building
images
meant
for
production.
That's
my
caveat
is
I
think
that
if
the
image
is
like,
if
you
did
it
with
no
pool,
we
should
print
a
warning
of
like
how
old
your
base
builder
is,
or
something
like
that
like
I,
don't
know
like
I
feel
like
there
needs
to
be
something
because
you
are
building
production,
grade
images
and
I.
Don't
know.
D
Yeah
I
think
one
of
the
other
ways
to
look
at
this
is
that
we
are
talking
about
pack
a
CLI
tool
that
certainly
can
be
used
in
CI
systems,
but
traditionally
isn't
going
to
be.
There
are
other
strategies,
whether
it's
tucked
on
pipelines
or
whether
it's
kpac
or
whether
it's
whatever
undergirds
evergreen
like
they
can
make
a
different
decision
that
always
request
the
latest
images
for
these
things,
in
a
way
that
our
target
audience
doesn't
expect
that,
when
dealing
with
the
CLI.
B
Well,
I
understand
the
security
concerns.
I
agree
that
I
prefer
to
optimize
performance
and
predictability
impact
I.
Do
wonder
if
we
could
have
a
default
poll
policy
option
and
the
PAC
config,
so
that
someone
can
set
it
once
to
always
if
they
prefer
the
other
end
of
the
trade-offs
without
having
the
Remer
to
pass
it
in
each
command.
B
Me
because
it
doesn't
conflict
with
anything
in
this
RFC
and
it
is
an
ice
pack
convenience,
but
a
fairly
I'll
when
I
I
feel
like
it's
a
kind
of
thing
that,
in
my
mine,
doesn't
even
need
an
RFC.
If
you
like,
once
we
have
pull
policy,
if
pack
wanted
to
add
a
default
whole
policy
in
the
config
file,
I,
don't
think
that
needs
them.
A
vote
from
everyone.
I.