►
From YouTube: CNB Weekly Working Group 2021-10-21
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Cool
on
the
distribution
side,
we
did
a
release
of
we.
I
did
a
release
of
github
actions
this
week,
with
the
only
update
was
a
significant
update
to
crane.
So
just
let
us
know
if
you
see
any
issues,
registering
build
packs
in
the
registry.
B
Any
life
cycle
updates
for
release
planning.
B
All
right,
you
want
to
talk
about
rfc
or
pull
request.
175.
B
Yeah
yeah,
it's
largely
my
fault.
I've
had
pto
and
then
a
couple
other
things
over
the
last
like
three
weeks,
maybe
months.
So
I
kind
of
lost
track
of
this.
I
I
do
think
it's
in
really
good
shape.
I
changed
some
things
like
the
name.
Space
was
cmb
and
I
think
everybody
agreed
to
change
it
to
build
packs.
I
o,
so
I
did
that.
B
C
B
Oh
yeah,
doesn't
that
just
go
away
though
like
doesn't
it
isn't
it
just
like
a?
It
doesn't
have
to
specify
anything
right.
C
Yeah,
well,
I
guess
that's
the
question
was
like
do
we
do
we
want
to
what
do
we
want
to
enforce?
I
mean
we
can
definitely
have
this
stack
requirement
for
backwards
compatibility
legacy
reasons,
but
I
think
even
sam's
question
about.
Would
we
have
a
linux
only,
like
I
think,
emily's
point
of
even
the
profile
de
bill
pack,
like
wouldn't
support
windows,
but
potentially
you
can
imagine
some
capability.
We
would
want
to
either
pull
out
or
have
exists
that
wouldn't
support
linux.
C
Support
windows,
and
so
we
even
like
I
get
the
intention
behind
wanting
this
of
like
you-
want
to
build
things
that
are
generically
applicable,
not
like.
This
is
a
thing
just
for
centos
or
something
right,
but
yeah
I
mean
it.
I
think
like
is
that
just
a
guideline
like
it's
a
should
of
like
what
our
intention
is
versus
like
a
hard
requirement.
B
Yeah,
that
makes
sense.
I
agree
with
all
that,
if,
if
you
think
you
can
reword
it,
I
can
probably
find.
B
C
B
Yeah,
I
wasn't
really
happy
with
the
mushiness
of
a
co-located
api.
It
does
mean
it
like.
The
idea
would
be
that
there
would
be
a
spec
and
it
would
be
actually
I
mean
I
still
think
I
disagreed
with
emily
on
this,
but,
like
I
was
saying
a
specification
for
how
the
build
pack
worked
and
what
its
api
is
existing
in
the
repository
with
the
build
pack,
which
means
it
is
a
part
of
the
project,
but
it's
not
a
part
of
our
specification
repo
or
has
any
ties
to
it
and
the
versioning
of
it.
A
Okay,
could
you
all
elaborate
on
that
real,
quick
like
what
is
the
the
context
behind
I'm
assuming
these
are
the
build
pack
apis
of
which
the
build
pack
itself
is
defined.
B
Yeah
so,
like
I,
I
think
for
like
a
profile
build
pack,
the
api
would
be
the
dot
profile
file
right,
like
the
api
for
this
build
pack.
Is
you
put
a
dot
profile
in
the
workspace
and
that's
how
you
interface
with
with
that
build
pack,
I
mean
there
could
be
other
build
packs
where
the
api
is
a
set
of
environment
variables,
it
could
be
a
build
pack
where
the
api
is.
B
You
know
something
another.
Some
other
kind
of
configuration
file.
A
Okay,
so
when
we're
talking
about
api
in
this
sense,
we're
talking
about
the
contract
for
this
sort
of
build
pack
and
how
it
behaves
or
interacts
with
essentially
the
source
code.
In
most
cases.
C
Interesting
there
was
mention,
I
think,
of
ways
to
like
one
of
your
requirements
was
the
detect
thing
of
like
it
has
to
have
a
way
to
fail.
Detection.
C
I
assume
that
would
be
part
of
the
api
as
an
example
too
right,
like
yeah,
describing
the
way
that
you
can
disable
this
thing
without
people
having
to
either
reorder
or
whatever
yeah.
B
And
I
think
part
of
that
is
like
also
you
can
imagine
like
these
utility
build
packs
exist,
because
we
want
to
decouple
some
of
this
logic
from
the
implementation
or
something
core
in
the
platform
of
the
engine
or
whatever,
and
you
can
imagine
some
other
implementation,
some
other
platform
wanting
to
implement
this
a
different
way
than
a
build
pack.
Maybe
they
already
have
some
machinery
that
they
want
to
leverage
and
it
and
it's
not
a
build
pack.
B
They
would
be
able
to
implement
that
api,
essentially
without
using
the
build
pack
and
that's
sort
of
the
goal
is
to
you
know,
have
something:
that's
yeah
more
of
a
contract
than
just
a
a
bunch
of
behaviors
that
you
have
to
sort
of
suss
out,
what's
actually
happening.
A
B
I
think
it's
twofold:
it's
one
a
way
for
consumers
of
that
build
pack
to
understand
how
it
works
and
be
able
to
read
and
learn
about.
B
What's
going
to
happen,
if
you
do
this
or
that,
rather
than
just
you
know,
using
it
and
finding
out
that
way,
so
in
some
sense
it's
documentation
in
that
way,
but
you
know
very
rigid
documentation
and
thorough
and
complete
the
other
end
of
it
is
for
people
who
are
potentially
platform
implementers
that
want
to
have
that
same
behavior,
but
for
whatever
reason,
don't
want
or
need
the
build
pack.
So
I
mean,
like,
I
think,
a
top
profile.
B
Again,
you
can
imagine
a
platform
that
has
its
own
init
containers
or
something
like
that,
and
they
don't
want
the
build
pack,
injecting
something
into
the
image.
That's
going
to
run
the
dot
profile.
They
would
rather
use
their
own
mechanisms
to
source
that
profile
or
you
know,
maybe
it's
you
know.
B
Maybe
it's
something
else
like
like
a
proc
file,
type
thing
where
they
don't
want
the
entry
point
to
be
such
and
such,
although
that
might
be
a
bad
example,
because
that's
probably
part
of
the
part
of
the
contract,
but
maybe
they
they
want
to
process
that
proc
file
or
that
that
project
tamil
processes
table
in
a
different
way,
and
they
should
be
able
to
do
that
and
still
implement
that
specification
and
really
like.
B
The
the
driver
for
having
these
build
packs
is
that
we
had
specified
behaviors
in
the
implementation
or
or
in
in
the
specification
that
we
wanted
to
decouple
implementation
wise,
like
the
actual
mechanisms
in
the
life
cycle,
for
doing
these
things
for
the
purposes
of
cleaning
up
code,
but
that
shouldn't
necessarily
manifest
itself
as
a
like,
like
this
is
how
it
works
like
it
has
to
be
this
way
to
to
end
users.
A
Okay,
so
that
this
might
be
of
a
a
side
altogether,
but
I
guess
taking
like
a
very
practical
and
recent
example
with
ca,
certs
right.
The
the
thing
that
came
up
yesterday
was
the
current
ca.
A
Cert
build
pack
strategy
that
what
is
it
the
pocato
project
has
that
doesn't
necessarily
work
for
all
the
cases,
especially
when
we're
talking
about
the
docker
registry
for
analyze,
and
so
what
comes,
to
my
mind,
is
is
basically
the
new
mechanism
that
we'll
have,
which
is
the
extensions,
and
I
am
curious
how
we
envision
extensions
fitting
into
kind
of
this
same
sort
of
strategy.
B
Think
it
would
I
mean,
unless
I'm
missing
something
because,
as
far
as
I
know,
we
don't
have
any
part
of
that
proposal
that
talks
about
like
packaging
and
distributing
extensions
as
discrete
things
like
they
are
coupled
to
the
builder
image.
B
A
I
guess
have
us
think
through
how
we
would
solve
the
ca
cert
situation
right,
because,
if
extensions
need
to
be
built
into
builders,
does
essentially
every
organization
have
to
rebuild
the
ca
cert
mechanism
via
extensions.
Would
we
then
want
to
present
sort
of
you
know,
utility
extension
that
people
could
reutilize.
B
B
That
was
because,
like
the
main
thing
with
the
ca
search
is
like
you
need
root
to
do.
The
thing
that's
expected
is
that
right,
so
that
you
can
scan
the
image
and
have
it
and
that's
why
you
need
the
that's
why
you
have
to
have
an
extension
but,
like
I
could
imagine
a
lot
of
cases
where
you
have
an
extension.
That
does
the
thing
that
needs
privileges
and
that's
it
and
then
later
on
a
build
pack.
B
A
I
I
guess
I
didn't
have
like
a
solution
in
mind
right.
It
was
more
food
for
thought
as
to
this
use
case
that
I
think,
ultimately,
it
sounds
like
we
wouldn't
be
able
to
handle.
I
guess
nicely.
I
was
wondering
if
we
could
kind
of
piggyback
on
this
sort
of
same
strategy
for
distributed
or
efficiently
supported
utility
build
packs
with
you
know,
officially
supported
utility
extensions.
C
C
Would
that
be
a
different
rfc
that
follows
this
model,
then,
because
extensions
in
theory
aren't
built
packs
per
se,
yeah.
B
B
I
think
it's
important,
because
the
the
important
piece
of
it
is
that
there's
an
interface
to
this
mechanism,
whether
it's
a
utility
build
pack
or
an
extension,
and
it's
something
that
we
want
to
or
need
for
multiple
personas
to
interface
with
so
like,
like
you
said
like
when
it
comes
to
like
a
ca
extension,
each
platform
or
each
builder
provider
has
to
do
that
themselves.
B
There's
just
no
way
around
that
right,
and
so,
if
we
want
consistency,
especially
if
there's
something
downstream,
that
has
expectations
about,
what's
going
to
be
where
and
how
it's
going
to
work,
then
we
want
to
specify
that
behavior,
or
at
least
I
feel
like
if
emily
was
here,
she
would
push
back
on
me
using
the
word
specify
there,
but
I'm
trying
to
think
of
another
one.
B
Just
you
know
strongly
define
how
that
how
that
works
so
that
we
can
have
consistency
across
people
that
are
using
it,
people
that
are
consuming
it,
people
that
are
providing
it,
and
I
think,
that's
very
similar
to
the
the
goal
of
having
a
specification
api
specification
for
the
utility
buildbacks.
B
B
She
wanted
it
to
be
documentation
only,
and
so
that's
where
we
I
think
compromised
was
that
it
would
be
a
specification
but
scoped
only
through
that
build
pack,
and
there
would
be
like
this
stronger
contract,
but
that
stronger
contract
wouldn't
be
coupled
to
the
spec
repo,
even
as
an
extension
which
I
disagree
with.
I
think
I
think
I
still.
B
If
I
change
the
state,
it
would
be
an
extension
spec
for
each
of
these
utility,
build
packs
would
be
required,
and
I
struggle
to
see
how
that's
problematic,
because
there
really
isn't
any
versioning
like
those
those
all
have
their
own
version
schema,
and
I
don't
really
see
how
it's
any
different
than
putting
it
with
the
build
pack.
C
Yeah,
I
guess
my
comment
on
the
rfc,
which
was
I
don't.
This
is
a
whole
new
net
construct,
but
it
does
seem
like
it's
just
a
requirement
of
like
letting
something
in
versus
like
any
any
kind
of
oversight
or
like
you.
Could
it's
not
you
make
any
build
pack
right
like
it's?
Not
it's
not
really,
there's
no
gate
behind
it.
C
Besides,
you
have
to
do
the
work,
whereas,
like
an
extension,
spec
requires
something
to
get
into
the
spec
right,
and
so
I
guess
I
was
trying
to
understand
you're,
basically
saying
if
you
create
a
build
pack
in
that
repo.
With
that
thing,
like
that
extension
api,
there
really
isn't
it.
This
thing
isn't
really
dating
anything
besides
telling
you
you
have
to
do
the
work
to
do
it
right,
like
I
guess,
that's
the
thing
I'm
trying.
C
B
B
Yeah
no
you're
right
and
I
I
mean
I
think,
there's
always
going
to
be
a
judgment.
Call
I
mean
the
the
the
things
these
utility
build
packs
do,
although
do
I
think
we
said
there
needs
to
be
an
rc
for
each
one.
If
I
don't
say
that
I
probably
should
so
I
mean
it's
a
judgment
call
but,
like
I
think,
that's
just
that's
how
these
are
going
to
get
into
the
project
is.
B
But
in
that
case
the
gate
would
be
the
rc.
If
that's.
C
Not
which
is.
B
C
Yeah,
which
was
implied
okay,.
B
Well,
I'll
change
that
at
a
minimum,
I
still
think
it
should
be
an
extension
spec,
but.
B
Okay,
I
think
we
can
wrap
on
this
unless
you
have
anything
else,
there's
definitely
some
changes
required.
C
C
B
Yeah
yeah,
as
long
as
the
bat
team
is
okay
with
that,
because
I
proposed
implementation
team
right.
A
A
As
I
said,
I
think
there's
a
pretty
good
opportunity
for
a
segway
here
when
we
talk
about
the
spec
repo-
and
I
guess
your
your
desire
for
it
to
be
extensions
per
build
pack
in.
I
think
one
of
the
things
steven
mentioned
yesterday
was
the
idea
of
changing
the
strategy
in
which
we
have
the
the
repo
organized
and
that's
to
create
documents,
not
so
much
per
api,
but
per
component.
A
So
I
don't
know
exactly
you
know
what
the
direct
correlation
there
could
be.
But
again
I
think
it's
a
pretty
good
segue
to
have
that
same
thought
where
it
seems
like
you're,
proposing
a
document
per
build
pack
to
then
also
have
like
a
document
for
let's
say
the
life
cycle
right.
A
document
for
the
I
don't
know
the
platform,
the
the
build
pack
for
sure
right
and
then
any
sort
of
association
or
any
sort
of
reference
to
an
api
number.
I
think
that's
the
challenge
that
we
would
be
faced
with.
B
It
probably
depends
on
what
sort
of
consumes
that
interface
like
if
it's?
If
it
really
is
always
the
end
user.
B
Like
I
think,
one
of
the
challenges
we
have
with
other
things
is
that,
like
project
tamil
well,
pac
reads
that
and
so
pac
needs
to
support
multiple
different
versions
and,
and
that's
where
some
of
the
complexity
comes
in,
whereas
the
build
pack
is
very
is
I
I
think
I
can't
think
of
a
case
where
it
is
something
that
the
okay,
I
just
thought
of
something
I
would
say
I
couldn't
think
of
a
case
where
the
like
the
platform
or
the
life
cycle
would
care
about
the
version
of
that
spec,
but
it
where
it
could
matter
is
incompatibility
with,
like
the
build
pack
api.
B
C
It
doesn't
doesn't,
doesn't
it
aren't
the
target
end
users
of
that
actually,
like
everyone
like
there's
the
platform
who
is
either
pulling
it
in
or
it's
pulled
in
by
default,
so
they
have
to
be
aware
of
it
to
some
degree.
So
the
version
of.
B
C
That
matters
there's
a
bill
pack
author,
if
you're
doing
like
the
profile
or
whatever
thing
right
like
it
has
to
be
there.
So
you
care
about
that
contract
and
what
that
api
is,
especially
if
that
changes
over
time
and
then
potentially
the
end
user.
If
you
have
a
way
to
view.
B
B
Yeah,
I
think
I
mean
I
think,
that's
probably
why
emily
was
against
having
a
version
spec
for
it
and
but
I
feel
like
what's
the
alternative
like
we
just
trust
that
they're
gonna
always
work
or
something
like
that
doesn't
seem
great,
because
I
do
think
I
think
there
were,
I
think,
there's
some
concern
around
like
versioning
all
these
things
and
then
having
to
like
have
that
complex
matrix
of
this
is
supported
with
this
with
that,
but
not
with
these,
but
I
kind
of
feel
like
that's.
That's
the
boat,
we're
in.
B
I
mean
honestly
where
this
started
was:
okay,
they're
build
packs,
but
they
ship
with
the
life
cycle
and
for
me
they're
still
they
they
remain
in
the
life
cycle
spec
or
something
like
that.
But
yeah,
that's
that's
not
where
we're
at
now
yeah.
B
A
So
I'm
trying
to
think
of
maybe
we'll
step
back
for
this
particular
conversation
on
the
spec
repo
but
and
I'll
bring
up.
Maybe
my
my
biggest
pain
point,
which
is
sort
of
like
the
branching
strategy
that
we
have
for
it
is,
is
very
cumbersome
to
to
work
with,
and
I
know
that
using
yeah
yeah
like
both
from
a
consumer's
perspective
and
also
from
a
maintainer's
perspective.
I
I've
I've
seen
and
have
heard
a
lot
of.
Oh,
I
have
to
manually
go
do
this
for
you
so
that
you
can
get
this
axe.
A
You
know
to
merge
in
properly,
and
so
I
was
curious
how
open
we
would
be
to
kind
of
changing
that
to
to,
I
think
something
that
was
proposed
as
an
alternative
at
the
time
where
this
was
decided
and
just
to
kind
of
throw
it
on
the
on
the
table
right
now.
I
think
my
my
hope
or
idea
would
be
to
have
a
sort
of
like
a
directory
structure
and
then
the
different
versions
within
that
directory
structure.
A
So,
for
instance,
like
distribution,
right
distribution
would
have
an
o2
directory
within
it,
a
file
right,
an
o3
directory
or
file,
and
basically
everything's,
always
at
main
there
could
be
a
dev
version
right,
the
one
that's
currently
being
worked
on,
and
basically
we
still,
I
think
the
release
would
actually
be
even
more
simplistic,
because
essentially,
we
would
be
tagging
a
very
specific
commit
that
is
then
still
associated
with
that
sort
of
spec
right,
as
opposed
to,
I
guess
what
it
is
now.
A
Any
major
pushback
on
any
of
that
before
I
start
drafting
something
up.
C
A
Yeah,
I
think
I
did
at
the
time.
I
could
definitely
dig
them
back
up,
but
there's
there's
definitely
specs
that
have
it
laid
out
that
way.
C
C
B
C
Yeah
I
mean
I,
I
think
I
think
you
have
a
fair
point
anthony,
but
I
think
one
of
the
differences
is
that
I
think
most
software
projects
don't
have
like
five
branches
or
whatever
for
like
the
different
specs
right.
So
like
there's
the
platform
branch
right
with
the
different
versions
in
it,
which
would
be
fine
if
it
was.
That
was
the
only
thing
so
we'd
be
like
on
point.
Seven
point:
eight
point:
nine.
I
think
where
it
gets
complicated,
there's
like
a
branching
strategy
for
every
single
spec
right.
C
You
need
to
point
it
to
like
this
new
branch,
but
then,
if
in
between,
while
you're
working
on
that
something
gets
merged
into
main
your
net,
your
thing
is
like
now
behind
and
I
I
guess
it
would
be
somewhat
similar
to
like,
if
you're,
maintaining,
multiple,
like
stable
versions
of
a
piece
of
software,
but
we're
essentially
doing
that
for
like,
however
many
ver.
However,
many
like
spec
documents,
we
have
right
of
like
the
different
tags.
So
we
tag
like
platform
o7,
which
we
just
was
the
last
one
right.
C
But
then
now
we
have
a
new
branch
for
platform,
eight
and
there's
bill
paco,
seven,
which
was
branch
like
I
feel
like
half
a
year
ago,
because
we
haven't
spec,
released
that
right
and
then
but
there's
been
changes
that's
brought
in.
C
But
it
has
not
pulled
in
stuff
from
maine
for
six
months
right
because
you
just
have
to
do
the
overhead
of
like
keeping
all
those
branches
up
to
date,
to
ensure
that
when
an
user
who
is
not
as
familiar
with
the
spec
or
just
trying
to
make
a
change,
that's
like
a
typo
fix
or
something
right.
It's
just
like
they
have
to
know
which
one
to
point
this
stuff
to
and
kind
of.
A
A
A
And
then
I
think
the
the
like
much
more
complex
use
case
is
any
sort
of
restructuring
that
we
want
to
do.
For
instance,
right
now,
I
know
dan
ran
into
this
issue
where
basically
the
thing
that
he
needed
to
do
cut
across
multiple
api
specs
right,
he
created
apr
but
then
had
to
like
break
it
up
into
all
these
different
ones.
A
Because
again
it's
a
different
branch
for
every
single
spec,
and
so,
as
you
see
like
the
next
one
that
we're
working
on
right
now
for
distribution,
three
right
like
we're
changing
some
things
from
platform,
for
instance
right.
So
now,
there's
like
two
concurrent
pieces
of
work
trying
to
achieve
the
same
thing
or
the
same
goal
and
that's
again
a
lot
more
cumbersome,
and
you
have
to
know
that
right
as
an
external
contributor
and
that's
where
that
pretty
big
hurdle
comes
in.
A
So
it
seems
like
at
least
the
the
people
in
this
meeting
are
okay
with
kind
of
moving
in
that
direction,
so
I
could
propose
something
there.
I
think
the
one
thing
that
maybe
it
would
have
been
nice
to
have
steven
here
for
is
the
api
versus
components.
Conversation
right,
so
I
think
the
way
I
I
caught
this
is
like
the
base
image
would
have
its
own
sort
of
document.
A
The
run
image
would
have
its
own
document,
the
life
cycle,
it's
on
document
and
so
forth.
Right
so
like
we
talk
about
components
as
opposed
to
apis
and
then
in
my
mind
the
only
sort
of
complexity
or
overhead
is
associating
all
these
right.
Like
lumping
all
these
and
say,
okay,
these,
when
we're
talking
about
this
section
here,
it
refers
to
the
build
pack
api,
as
opposed
to
where
we're
talking
about
this
other
part.
It
might
refer
to
the
platform
api.
C
I
mean
there's
if
you
actually
have
the
folder
structure,
there's
ways
you
could
branch
that
out,
though
right
like
or
not
press
it
out,
but
like
distribute
that
where
like,
if
we,
for
instance,
had
a
bill
pack
as
a
folder
instead
of
a
file
right
in
there,
you
could
list
components
and
you
could
have
those
components
in
both
the
platform
folder
and
the
built
back.
Folder.
C
Potentially,
I
don't
like-
maybe
that's
confusing,
but
that's
one
way
you
could
do
it
where
you
don't
break
the
kind
of
apis
as
we
find
them
today,
but
you're
able
to
basically
write
write
them
differently
right.
You
don't
need
to
have
one
large
markdown
file.
That
is
a
thing
that
is
just
the
api
right.
B
A
B
Totally,
I
think,
stack
and
maybe
even
mix-ins
too.
I
know
we
had
talked
about,
or
at
least
I
talked
to
emily
in
in
some
conversation
about
like.
Are
there
some
set
of
things
that
are
like
cross-cutting
and
need
to
just
be
like
not
in
either
or
so
yeah?
I
was
gonna.
C
C
B
Kind
of
hand
waved
over
the
specification
changes
which
we
haven't
done
in
the
past
and,
I
think
might
be
might
bite
us
in
the
end,
because
there
are
going
to
be
some
tough
questions
like
that,
and
even
though
we
all
agree
on
the
big
picture,
that's
why
we
did
that's.
Why,
for
like
stack
packs,
we
spent
an
enormous
amount
of
time.
B
C
Yeah
you
weren't
you
weren't
here
yesterday
during
the
cartoon
sync
joe,
but
I
brought
up
like
does.
The
extension
toml,
for
instance,
need
to
be
versioned
doesn't
need
to
be
an
api
version
which
any
kind
of
leads
into
some
of
the
spec
layout
stuff,
but
like.
Where
does
that
go?
There
was
talk
about
it
going
in
buildpack
api,
but
I
feel
like
one
thing,
that's
weird
about
that
is
like
as
a
bill
pack
author.
Why
do
I
need
to
know
anything
about
the
expensive
novel
right,
like
that's
not
like.
B
Yeah,
the
reason
why
the
reason-
and
maybe
this
gets
back
to
like
what
I
was
asking
about-
the
descriptor
files
is
like
the
reason
to
tie
that
to
the
build
pack
api
is
that
it
has
so
much
in
common
with
it.
Like
the
extension,
tumble
looks
almost
exactly
like
a
buildpack
tomml
with
a
different
table
name,
and
I
think
that
was
the
motivation
for
tying
it
to
that
specification
version
is
to
keep
those
in
line.
But
again
maybe
it
doesn't
belong
in
the
build
pack
api,
but
rather
some
core
set
of
like
descriptor
like
do.
B
A
So
I
think
so
yeah
I
mean
maybe
that's
another
thing
to
discuss
in
this
right
now
right,
it's
like
what
do
we
want
to
rename
extensions
to
as
extensions
come
in.
B
B
Images,
yeah
sure
sure
images
image,
extensions,
yeah
that
makes
sense,
so
it
might
be
fine.
Otherwise
I
mean
spec
extensions
is
pretty
arbitrary,
like
we
could
call
it
spec
editions
probationary
specs,
I
don't
know,
I
mean,
there's
a
whole
bunch
of
options
that
we
can
just
and
it's
not
that's,
not
really
part
of
the
developer
experience
for
buildback.
So
I
don't
really
care
what
we
know
about.
A
C
C
B
A
C
But
the
I
mean,
regardless
of
whatever
the
naming
thing,
is
an
extension
for
the
extension,
an
extension
spec
for
the
extension
thing.
I
I
feel
like
that's
our
actual
place,
where
we
put
cross-cutting
things
like
builder
and
distribution.
Well,
I
guess
distribution
is
just
a
whole
news.
No.
B
C
A
B
Oh
yeah
yeah.
No,
I
agree
with
that.
I
think
it's
well.
We
should,
I
think,
to
your
point.
We
should
suss
that
out
during
the
the
rc
process,
but
I
yeah,
I
think
that
could
be.
I
think
extensions
could
be
an
extension
or
maybe
optional
specs
because,
as
you
said,
javier
they're,
like
optional,
in
terms
of
being
cmb
compliant.
B
And
I
think,
honestly,
like
anything
that
can
be
optional,
probably
should
be.
It
shouldn't,
be
a
gargantuan
task
to
re-implement
life
cycle
or
whatever.
C
B
C
B
A
So
I
guess
to
lean
on
that
a
little
bit
more.
Does
that
mean
that
if
I
have
a
builder
that
has
extensions
right,
it
essentially
shouldn't
work
on
these
platforms
that
don't
support
extensions.
A
C
Or
it
could
work
fine,
I
guess
like,
but
it's
probably
contingent
on
what
those,
how
mandatory
those
extensions
are.
A
What
is
the
I
heard
the
downside
to
making
it
not
optional?
I
think
from
a
platform's
perspective
right
what
are
the
downsides?
I
know
I
heard
that
basically,
everything
currently
would
be
non-compliant,
but
ultimately
that's
true
for
any
platform.
Api
change
that
we
do
right.
So
I
don't
think
that
that's
a
real
deal
breaker.
C
I
guess
the
the
other
downside
is
what
happens
if
you
are
say
an
air
gap
or
like
a
really
tight
kind
of
environment
that
you
want
to
have
as
a
platform,
and
you
don't
want
to
allow,
even
if
it's
on
the
builder
right,
you
just
don't
want
to
allow
extensions.
I
guess
it's
just
you.
Don't
pull
that
builder
in
you.
Just
don't
have
a
builder
that
has
extensions.
That's
how
you
solve
that
problem,
but
even
the
stevens
point
like
his
intent
is.
The
builders
are
an
example.
C
C
C
B
I
think
yeah
I'm
into
there
what
is
possible
that
this,
I
think,
there's
a
lot
of
overlap
in
people
that
don't
want
that
and
don't
want
custom
builders,
so
it
sort
of
solves
itself
in
that
sense.
But
as
soon
as
you
have
a
platform
that
allows
custom
builders,
but
then
doesn't
want
extensions,
I
maybe
that's.
B
A
Yeah
because,
ultimately,
I
would
think
one
of
two
things:
you're
deferring
the
complexity
to
the
builder
or
the
builder
provider.
To
say:
oh,
hey
did
my
extensions
run,
so
I
could
do
a
b
or
c
or
they
didn't
run.
So
I
could
provide
a
useful
error
that
says
like
hey,
I
don't
have
what
I
need
right
or
you
give
that
sort
of
condition
to
the
platform
and
the
platform
is
the
one
that
says.
A
A
A
C
I
think
you
may
run
them,
it's
probably
the
right
thing
versus
like
you
must
run
them
where
it's
like,
not
optional.
I
think
the
must
would
be
if
you
choose
not
to
run
it.
You
must
throw
an
error
of
this
on
the
builder.
A
A
In
in
the
scenario
that
we
just
talked
about,
it
made
a
lot
of
sense
for
it
to
be
in
platform,
at
least
that
portion
of
it
right
because
you,
you
know,
that's
kind
of
the
area
that
we're
looking
at.
I
don't
know
about
where
you
define.
C
Well,
you
have
to
define
extension
tunnel,
at
least
and
and
the
specification
around
like
there's,
essentially
all
of
what
build
pack
api
does
right.
You
need
that
for
the
extension,
which
is
what
what
are
the
like,
how
does
cmd
bill
factor
like
where
that
environment
variable
comes
from
the
the
like?
The
two
arguments
that
get
passed
in
the
you
know
bill
by
the
bill
id
and
the
base
image
right
like
those
are
defined
somewhere
and
they're
different
from
the
bill
pack?
Api?
C
Those
don't
exist
in
the
bill
pack:
api
yeah,
the
tamil
file
format,
what
that
looks
like
if
that
ever
changes
or
evolves
the
bin
build
been
detect
similar
to
the
buildback
api,
those
that
need
to
find
the
output.
The
lb
like
how
we
that,
when
the
output
gets
run
like
exact
d,
it
will
output
this
thing
that
is
going
to
be
a
docker
file
that
has
to
be
defined
somewhere.
The
fact
that
we
won't
support
l
will
be
the
gate
is
a
thing
that
has
to
be
defined
right.
C
The
only
format
will
support
that
you're
expected
to
output
is
docker
file
the.
If
you
don't
have
detect,
it
will
automatically
pass
there's
a
difference
in
built
pack.
Api
there's
actually
like
I
feel
like
coupling
with
built
packet
is
api,
is
like
somewhat
dangerous
because
it
is
very
similar,
but
it's
also
very
different,
like
it
does
not
it's
not
like
a
thing
here
or
there.
It's
like
it's
like
inheritance,
where
it
takes
this
thing,
but
then
replaces
like
a
large
part
of
it
right.
A
Yeah,
I'm
very
much
against
you
know,
it's
being
it
a
part
of
build
pack.
For
that
reason,
I
I
think
it
should
be
its
own
and
I
think,
as
I'm
kind
of
drafting
some
of
this
stuff
out
having
a
mention
in
platform,
you
know
of
extensions
and
how
you
would
call
the
extension.
That's
like
a
contract
there,
the
inner
workings
of
the
extensions
themselves,
that's
essentially
a
separate
contract
in
my
mind
right
so
how
you
would
get
called
and
so
forth,
but
I
don't
know
because
no,
it
would
be.
B
A
That's
how
I
initially
envisioned
it
yes,
but
I'm
still
thinking
through
it,
because
it's
not
the
platform
that
calls
extensions
right.
The
platform
just
has
to,
if
I'm
not
mistaken,
it's
the
life
cycle.
C
C
Yep,
but
the
life
cycle
does
all
the
work
for
everything
right
for
that
sense
of,
like
once,
you're
on
the
platform.
It's
a
thing
that
executes
both
the
bill
packs
and
same
with
the
extensions.
B
Right
time
and
I
need
to
drop,
I
think
like
in
summary,
like
a
very
supportive
of
the
spec
repo
changes
that
you're
proposing
javier,
I
feel
like
we
could
do
that
independent
of
the
dockerfile
rfc,
and
I
I
think
I
think
we
probably
should
figure
out
in
the
rfc
for
that
how
it
fits
into
whatever
model
we
have
for
the
spec
repo.