►
From YouTube: Working Group: 2020-10-07
Description
*Lifecycle Experimental API Mode: https://github.com/buildpacks/rfcs/pull/115
* Offline Buildpackages: https://github.com/dwillist/rfcs/blob/offline-buildpackages/text/0000-offline-buildpackages.md
A
B
B
B
B
B
All
right,
I
guess
we
have
a
small
group
today.
Let's
kick
off
with
introductions
and
new
faces
frankie.
Have
you
been
to
one
of
these
before
want
to
just
introduce
yourself
the
broken
people
which
I
guess
is
just
jesse
right
now.
C
Sure,
hey,
I'm
frankie,
I'm
on
the
vmware
and
buildtax
feature
engineering
team.
B
C
A
One
out
shortly
after
oh
fourteen-
oh
I
don't
know
if
that's
new
this
week,
but
other
than
that
we're
we
don't
have
anything
that
I'm.
D
Aware
of
planned.
A
For
the
immediate
future
and
we'll
be
working
on
the
o15
release
cycle.
A
B
And
reminder,
as
I
go
through
this,
if
you
think
of
things
you
want
to
talk
about
this
week,
please
put
them
on
the
agenda
list
all
right.
So
first
thing
is
issues
and
labels.
Oh
and
important
thing.
This
time
forrest
was
very
keen
on
reminding
me.
We
should
be
adding
when
things
have
to
do
with
the
spec.
We
should
be
adding,
according
to
another
irc
that
got
merged
earlier,
we
should
be
adding
labels
to
them
to
correspond
to
their
platform
or
whether
they're,
I
don't
know
something.
C
Speaking
of
that
rfc,
the
thing
we're
looking
at
now
isn't
a
real
rfc.
It's
updating
the
rc
repo
to
describe
changes
we
made
in
that
rfc,
so
how
we're
going
to
label
issues-
and
it
also
describes
the
workflow
for
creating
issues
and
updates
our
automation
so
that
the
merge
rfc
script
will
add
issues
into
the
rfc
text
when
it
merges
so
for
folks
that
don't
need
to
approve
things
going
to
this
repo.
C
Hopefully
everything
in
here
should
match
what
you
expected
after
approving
the
other
rfcs,
and
then
you
can
take
a
look
and
you
can
merge
this
and
where
there
are
other
rfcs
that
are
ready
to
merge,
but
we'll
see
as
we
go
through
the
list
that
I
haven't
merged,
because
I
would
like
to
use
the
script
in
the
process
here.
B
Awesome
is
this
an
rfc,
or
is
this
a
change
to
the
rs
repo
that
does
this.
B
A
E
Yeah,
I
think
it's
still
subject,
because
it's
like
just
a
repo
owned
by
the
core
team
yeah.
A
E
E
Yeah
I
was
wondering
if
we
want
to
clarify
for
people
following
directions
like
what
the
actual
options
are.
I
think
spec
probably
maybe
doesn't
need
to,
because
that
matches
what
is
in
bill
pack,
slash
spec,
but
for.
C
Yeah,
given
that
it
wasn't
outlined
in
the
original
rfc,
I
didn't
want
to
introduce
anything
potentially
controversial
here
like
deciding
what
the
different
options
for
audience
are.
Just
that.
E
E
A
B
A
E
I
guess
this
would
be
an
extension
spec.
Maybe
I
don't
know
new
acceptance.
Specs
maybe
go
under
section.
I
think
that's
like
partly
the
point
of
my
previous
comment
in
the
other
rfc
was
that
it
would
be
good
to
be
just
be
clear
what
we
should
be
doing
here.
A
No,
I
left
it
intentionally
generic
to
sort
of
allow
for
this
to
turn
into
what
it
should
be.
I
my
thought
going
into.
It
would
be
that
it
would
be
something
along
the
lines
of
distribution
platform
build
pack
and
extension
for
the
spec
and
for
authors.
I
was
kind
of
under
the
impression
that
we
would
come
up
with
some
predefined
set
of
labels
for
audience.
A
So
like
build
pack,
authors
platform
developers
build
pack
distributors,
whatever
that
sort
of
that
sort
of
line
of
audiences,
but
I
didn't
have
any
super
strong
opinions
on
it.
C
B
Cool
to
kind
of
move
us
along
do
we
have
dave
this
week
to
chat
about
extensions
back.
I
know
I
think,
he's
out
for
an
amount
of
time,
and
we
said
this
is
going
to
pause
until
then.
It's
all
right,
yep
still
out
back
monday
cool
pre-release
version
and
life
cycle,
experimental
api.
E
Mode
yeah,
that's
mine.
I
incorporated
updates
based
off
of
our
conversation,
stephen
and
the
discussion
from
two
thursdays
ago.
I
think
so.
I
split
out
the
experimental
key
as
a
mode
versus
what
I'm
calling
pre-releases
as
the
alphanumeric
thing,
and
then
I
flushed
out
a
little
bit
more
one
of
the
alternatives.
Around
kind
of
unstable
features
being
a
thing
we
can
also
do-
or
I
guess
not
unstable
features
but
like
features
as
experimental
inside
the
spec.
B
Okay,
we'll
get
to
it
when
we
go
around
there.
Well
does
this
need
a
spike
label.
B
Move
us
along
build
run
image.
Configs
must
contain
it
in
path.
B
C
B
Cool
application
mix-ins,
we
said
we're
always
going
to
skip
over
until
stack
taxes
through
any
stack
packs
updates.
E
Do
you
know
what
the
blockers
are
of
like
what
you're
looking
for
for
the
stackpack
rc
for
comments
and
stuff
or
you'd?
Most
of.
A
I
don't
know,
what's
yeah
I
don't
know.
What's
blocking
on
the.
B
E
Pretty
is
there
stuff
coming
out
of
your
implementation?
That's
going
back
to
this
rc.
A
From
implementation
and
kind
of
been
pushed
into
rfc,
I
think
he's
got
most
of
those,
if
not
all
of
them
in
there
somewhere.
A
A
D
B
B
C
I
don't
think
so.
I
updated
the.
B
Cool
I'll
make
sure
I
get
added
to
that.
This
got
way
simpler
since
last
week,
right
yeah,.
A
B
Moving
down
the
list,
oh,
this
needs
a
spec
label
too
yeah
yeah.
This
is
build
text
back
right.
E
Oh,
I
think
yeah
we're
ready
to
merge
it,
but
I
think
you
were
going
to
respond
back
to
david
as
well
as
a
to
do
unrelated
to
the
merging
right.
B
Yeah
we'll
do
this
is
also
means
a
spec
platform
label.
B
This
is
a
draft
sorry.
I
should
click
on
that
layer,
origin
metadata,
any
updates
from.
A
B
B
A
Here
yeah
so
last
week
there
was
just
some
like
renaming.
That's
discussion.
That's
been
kind
of
done.
I
think
that,
like
the
proposed
changes
are
all
pretty
much
functionally
equivalent,
just
like
shuffling
around
some
maps
and
stuff
like
that,
so
you
can
talk
about
it
today,
yeah.
A
E
E
Yep,
okay,
so
the
changes
I
made
was
mostly
adding
separating
out
kind
of
the
original
proposal
I
had,
which
kind
of
combined
pre-release
api
stuff
with
both
the
external
mode.
I
think
this
was
steven's
request,
and
maybe
this
just
split
into
two
rfcs.
If
we
actually
want
to
go
down
that
path,
so
experimental
mode
is
specifically
about
the
implementation
and
that
maps
to
the
experimental,
the
lifecycle
descriptor
key
of
experimental.
E
So
you
could
have
say
a
release
version
of
the
spec
that
you
know
is
something
where
we
want
to
test
implementation
where
we're
or
we've
stabilized
the
kind
of
spec
and
finalized
it,
but
we're
not
sure
of
kind
of
the
implementation
underneath
it.
So
it
gives
us
that
flexibility
and
then
also
the
idea
about
pre-release
apis,
which
I
think
from
talking
that
time.
E
We
talked
about
how
they
would
actually
be
treated,
go
through
a
process
of
them
actually
being
cut
and
tagged
off
of
that
branch
off
some
working
branch
was,
I
think,
what
we
decided
on,
and
so
that's
an
example
of
that.
So
that
can
it's
treated
like
any
other
kind
of
version
in
the
sense
of
like
it.
E
Can
go
in
any
of
the
kind
of
modes
that
what
the
lifecycle
descriptor
supports
there
for
both
platform
and
buildback
api,
and
then
they
map
to
kind
of
the
labels
that
get
set
that
was
described
from
emily's
rfc.
So
I
think
those
are
most
of
the
changes.
So
I
think
I
put
experimental
modes
specific,
like
these
m
bars
specific
to
the
experimental
mode,
but
did
not
have
any
mvars
or
things
related
to
the
pre-release
api.
I
don't
know
if
that's
something
we
wanted
or
if
this
is
the
right
direction.
C
E
Yeah,
I
guess
it
depends
on
how
much
we
want
to
follow.
Sember
ranges,
maybe
that's
a
thing
to
do
under
prerule's
api
to
kind
of
elaborate
on
that.
My
inclination
is.
That
is
not
implied
as
supported
and
that's
how
sember
works
as
well
like
if
you
say
I
wanna.
E
I
guess
different
languages
use
different
operators,
but
normally
in
most
versions
of
sunburst
spec
like
if
you
say
I
want
a
like
release
of
a
thing.
The
alpha
releases
do
not
count
as
less
than
they're
kind
of
like
an
external
kind
of
concept.
In
that
sense,
so
my
inclination
is
to
just
follow.
Probably
what
december
does
there
and
I
think
that
probably
maps
of
what
we
actually
want
to
support
there
too,
like
I,
don't
think
one
two
should
imply
like
1.0
alpha
one
as
supported,
I
think.
E
Ideally,
we
want
to
be
able
to
probably
release
this
stuff
and
then
be
able
to
probably
drop
them
in
a
reasonable
fashion
without
being
on
the
hook
for
maintaining
them
forever,
because
they're
meant
to
be
experimental
and
you
probably
should
upgrade
to
the
actual
1-0
release,
instead
of
being
stuck
on
one
alpha
one.
You
know.
E
E
Spectrum
and
the
other
change
I
made
was
the
experimental
section
api,
which
I
think,
kind
of
expands
upon
unstable
features,
but
I
think
fits
kind
of
our
use
case
a
little
better
than
unstable
features,
which
is
the
experimental
section
inside
of
an
api.
So
we
can
release
an
official
api
but
have
experimental
features
or
an
experimental
section,
not
features
necessarily
inside
of
that.
E
So
we
don't
feel
the
pressure
to
get
it
right
or
block
a
release,
but
then
that
experimental
section
evolves
over
time
and
then
outline
as
one
of
the
downsides
of
this
is
that
since
it's
an
official
release
as
part
of
the
api,
any
implementation
of
lifecycle
or
not
any
information,
but
probably
our
implementation
of
lifecycle-
would
have
to
basically
support
potentially
varying
versions
of
said
feature.
E
And
so
that's
like
one
of
the
trade-offs
there.
Whether
every
implementation
has
to
support
experimental
features.
If
it's
in
the
spec.
I
was
unclear
of
what
we
where
we
landed
on
that.
But
I
assume
not.
B
Yeah,
I
mean,
I
think
it
separates
the
the
version
of
the
specification
representing
you
know
how
we
feel
about
the
definition
itself
from
the
descriptor
file
saying
the
life
cycle
has
experimental
support,
for
you
know
for
a
particular
version
of
that
which
I
think
is
important.
C
I
feel
like
the
distinction,
makes
sense
and
that
we
wanted
to
call
out
the
difference
there.
I'm
not
sure
if
in
practice
I
feel
like
these
are
all
tools
we're
gonna
reach
for,
but
I
don't
see
the
harm
in
having
them.
C
E
I
think
what
was
said
in
steven's
thing
is
their
version
inside
of
the
api.
It's
just
like
you
can
mark
a
basic
section
in
the
api
as
experimental,
so
it
could
be
in.
I
don't
know
like
wherever
you
want
right
like
for
stackpack.
We
could
have
a
thing
and
say:
distribution
as
or
not
distribution,
but
inside
of
both
platform
and.
E
C
E
The
benefit
is
like
it's
not
locked
to
basically
a
like
minor
series
line
or
whatever
which
like,
if,
if
we
did
say,
put
a
bill
pack
api
in
like
point
seven
alpha
one.
The
implication
of
that
is
it's
going
to
make
it
into
like
we're
kind
of
blocking
point,
seven
on
the
release
of
stackpack,
maybe
finalizing
or
whatever
right.
E
So
I
think
the
benefit
of
experimental
is
that
we
don't
know
how
long
it's
going
to
take
to
get
to
an
api
we're
happy
with
and
so
we're
okay
with
it
evolving
over
many
releases.
The
downside
is
that
lifecycle
will
have
to
support
potentially
many
versions
of
that
thing
as
long
as
we
keep
it
around
right.
So
that's
kind
of
the
trade-off.
B
We
don't
have
to
define
here
what
that
means,
because
that's
what
the
spec
is
for
right,
that's
why
we
have
must
and
should-
and
you
know
in
the
experimental
thing
you
can
just
describe
in
the
spec-
that
this
may
do
this
and
it
may
not-
and
you
know,
if
you're
using
the
feature
you
have
to
your
build
tech
has
to
account,
for
this
experimental
feature
may
be
there
or
may
not
right
or
if
you're
a
platform,
that's
consuming
lifecycle
version
port.
It's
like
what
I
like
about
this
is.
B
It
gives
us
tools
at
every
level
if
we're
trying
to
get
some,
you
know
create
a
pre-release
version
of
the
spec
that
adds
some
stuff
that
we're
not
sure
of
yet
we
can
create
a
version
of
the
spec.
That's
marked
as
a
pre-release.
If
we're
trying
to
have
a
long-running
experimental
feature
that
that
anybody
who's
using
should
be
very
cautious
about.
You
know
changing
over
time
because
it's
not
stable.
Yet
we
can
put
that
in
the
spec
conversion
like
everything
else
so
yeah,
it
seems
like
it's
a
pretty
good
path
forward.
E
E
Yeah,
so
I
I
guess
one
of
the
things
is:
do
you
want
me
to
move
this
into
the
actual
proposal,
the
experimental
section
in
api,
because
it
currently
is
under
alternatives?
I
just
wanted
to
flush
that
out,
because
that
was
the
thing
we
talked
about,
but
I'm
happy
to
move
it
up.
If
that's,
if
you
want
to
have
different
ways
to
do
different
things,.
B
E
Yeah,
I
I
actually
think
maybe
stack
packs
is
not
the
place.
You
want
to
do
pre-release
api
stuff,
but
I
imagine
it's
I
mean.
Maybe
it
is.
I
think
you
could
definitely
use
that
tool,
but
I
think
it'll
be
much
more
helpful
for
stabilizing
at
100
is
probably
where
we
want
to
reach
for
that.
E
So
I
don't
know
I
just
trying
to
combine
all
the
things
as
ahead
of
time,
but
yeah
just
want
to
make
sure
everyone
is
also
wants
to
move
in
this
direction.
E
Cool,
so
I
guess
changes
from
what
I've
heard
is
flesh
out
support
under
prerelease
api
from
emily's
kind
of
concern
around.
What
does
this
mean
for
what
lifecycle
has
support
for
versions
that
are
greater
like
violist
one
two?
What
does
it
mean
for
kind
of
the
pre-release
apis
that
are
less
than
that
and
moving
basically
experimental
section
in
the
api
up
on
the
spec.
C
C
I
wonder
if
that
particular
option,
like
the
experimental
option
to
me
this
seems,
like
the
one,
we're
least
likely
to
use
like
we've
defined
an
api,
but
we're
saying
our
support
of
that
particular
api
is
experimental,
like
usually
we
put
out
what
we
think
supports
that
api
sometimes
there's
something
wrong
with
it,
and
then
we
put
out
a
patch
version
that
actually
supports
it.
I
don't
know
when
we'd
actually
do
the
experimental,
and
I
wonder
if
taking
that
out
and
then
there's
one
fewer
option.
C
C
C
B
Like
if
we
release
the
spec
but
don't
have
life
cycle
implemented
yet
and
then
like
say,
stack
packs
get
through
the
the
rfc
and
spec
pr's
get
merged.
We
have
stack
packs
in
the
spec
version,
but
the
life
cycle
implementation.
We
don't
quite
trust,
yet
it
could
be
an
experimental
version
in
the
life
cycle.
C
C
E
Yeah,
I
guess
this:
it
wasn't
in
my
original
rfc,
this
kind
of
came
out
of
ex
people
being
not
happy
with
the
experiment
key,
and
I
think
steven
also
latched
on
to
the
that's.
What
experimental
key
means
to
him
when
he
sees
it
in
life
cycle
descriptor.
E
I'm
happy
to
scratch
that
out.
If
that's
the
direction,
people
want
to
take.
B
C
We're
just
not
leaving
it
or
taking
it
out.
I
think
if
we
can
add
it
later,
maybe
we
should
just
take
it
out,
because
if
you
don't
know
why
we
want
to
have
it,
I
think
it
could
add
confusion.
The
difference
between
that
and
unstable
features
because
we'll
probably
want
I
have
environment
variables
to
turn
on
and
off
both.
B
C
E
Do
you
think
it?
If
is
there
a
case
where
we
finalize
one
now,
but
we're
not
sure
how
it'll
all
work
together
until
it's
used
to
practice
a
little
more.
E
I,
I
guess
that's
the
quote
of
urges
summary
it's
the
equivalent
of
like.
Would
you
do
pre
or
rc
releases
of
the
1l
implementation
of
the
lifecycle.
C
E
I
I
think
the
major
versions
are
maybe
different
from
the
miner,
in
the
sense
that
potentially
you
are
making
some
backwards,
breaking
things
potentially
or
kind
of
incorporating
some
things
that
we've
put
off
a
little
more.
E
C
C
Frequently
a
patch
comes
out
afterwards,
but
you
know
if
you
express
that
in
the
calling
that
an
experimental
api
I
don't
know,
I
guess
it
doesn't
matter
to
me
that
much
I'm
happy.
We
can
leave
it
if
everyone
wants
it.
E
I
guess
as
we're
thinking
about
1-0,
are
we
expecting
to
do
that
because
I
feel
like
that's
probably
out
of
all
the
things?
That's
probably
the
either
stack
packs
or
that
are
probably
the
biggest
use
cases
of
it.
I
would
think.
E
E
So
you
would
rc
lifecycle
instead
for
like
a
1
0.
E
C
If
we
had
finalized
the
spec,
we
implemented
it
I'd,
probably
just
ship
it
and
say
it
supported
one.
No,
and
if
we
found
something
that
was
broken
in
it,
I'd
ship
a
patch
up
to
the
life
cycle
and
continue
to
say
it's
a
410
but
there'd
be
a
bug
fix
in
the
release
dumps.
That's
generally
what
I
would
do,
but
if
people
wanted
to
use
this
workflow
because
they
thought
it
indicated
something
important,
I
would
use
it.
B
A
B
Dan,
you
want
to
take
it
from
here.
Yeah
happy.
A
A
D
Yeah,
I
believe
my
concern
was
about
relocated
assets
and
the
ability
to
still
utilize
them,
especially
if
they
were
no
longer
at
their
initial
canonical
location
like
if
the
platform
didn't
have
access
or
didn't
want
to
pull
from
this
gcr
location,
for
example,
it
seems
like
ref
now
is
more
of
a
like
soft
pointer,
similar
to
our
run.
A
D
My
understanding
was
this:
was
the
image
location
that
was
used
to
generate
the
s
to
generate
the
build
package?
D
B
Assets
don't
go
inside
of
the
build
package,
it's
a
separate
image
right.
This
is
just
a
reference
and
this
this
this
reference.
Would
you
know
it's
not
you
don't
have
to
use
it
to
pull
it
from
that
location.
But
if
you
want
to
know
the
canonical
location
of
the
assets,
then
you
can
use
this
optionally
to
do
that,
but
you'd
still
have
the
digest
of
the
image
and
the
layer
def
ids,
oh.
B
A
We
did
so,
I
think
that
after
poking,
through
this,
like
functionally,
it's
totally
the
same.
In
fact,
I
just
like
have
all
of
these
sitting
down
here
at
the
bottom
and
I'm
happy
to
like
copy
paste
of
this
stuff
in.
I
feel
like
it's
the
right
direction
after,
like
writing
this
out,
it
seems
a
little
bit
cleaner
to
have
the
map
go
from
each
asset
digest
to
the
layered
id,
and
that
was
a
really
good
idea.
B
Just
some
very
minor
formatting
stuff
there
I
wouldn't
use
that
shot
to
56
colon
notation,
that's
like
for
images
usually-
and
this
is
like
specifically
not
an
images
thing-
it's
the
sha
of
the
the
object
and
then
that
maps
down
into
layer,
diff
id
right,
there's
like
formatting
stuff
there
that
we
can
deal
with
in
the
rfc.
B
B
D
We
look
at
the
builder
contents
again
or
the
builder
metadata
it's.
The
addition
here
with
this
asset
cash
per
build
pack
is
unique
because
in
a
build
package
the
assets
aren't
inside
the
build
package.
This
is
this
is
merely
to
correlate
which
build
packages
are
pulling
in
the
assets.
I'm
trying
to
understand
why
this
is
needed
here,
yeah,
so.
A
A
So
I
don't
think
it
matters.
I
don't
think
that
we
would
be
able
to
change
the
behavior
of
like
I
don't
know.
If
that
would
change
any
of
the
behavior,
I
think
it
all
of
the
assets
will
be
available
to
any
build
right
and
because
we
can't
make
an
ephemeral
builder
with
just
some
of
the
assets
once
we
know
which
build
packages
will
actually
run.
A
An
extra
label,
so
I
think
I
think
we
could
definitely
pull
it
out.
The
reason
that
I
think
I
put
this
in
here
in
the
first
place
was
that
if
I,
I
guess
yeah,
we
could
totally
pull
this
out.
It's
just.
We
already
had
a
label,
it
seemed
like
it
had
a
bunch
of
information
about
the
build
packages
and
because
we're
already
adding
this
field
into
the
build
package
information,
it
seemed
like
a
natural
place.
To
put
it.
B
Yeah,
you
actually
have
a
mapping
of
build
pack
to
asset
that's
available
or
like
how
would
you
get
that
metadata
under
a
build
pack
id
in
the
builder,
because
I,
if
I
think
we
have
a
build
package
to
asset
cash
association,
but
I
don't
think
we
have
a
bill
pack
to
asset
cash
association.
So
what
we're
looking.
B
If
you
go
up
to
the
build
package,
asset
association
or
the
build
package
package
file
right,
there's
like
you
can
say
here,
assets-
and
you
can
say
here-
build
packs.
A
B
D
So
that
would
be
a
reason
to
not
put
that
asset
cache
underneath
the
build
packs
on
the
builder
metadata,
because
the
platform
couldn't
necessarily
figure
out
which
asset
correspond
to
which
build
pack.
But
I
think
kpac
itself
would
have
additional
problem
that
if
an
asset
package
is
correlated
with
the
build
package.
D
A
A
So
all
build
packages
contain
information
about
their
assets
and
if
you
are
a
build
package
that
includes
other
build
packages,
you
are
responsible
for
maintaining
that
correlation
in
the
label.
Right
because
you
as
a
build
package,
don't
actually
require
any
assets.
So
there
are
none
at
your
top
level,
but
you
nest
other
things
underneath
you
and
those
may
be
nested
as
well,
and
that
sort
of
nesting
association
between
the
actual
build
pack
and
the
assets
of
that
actual
build
pack
wants
to
do.
Even
if
you
are
a
meta,
build
pack.
B
A
B
What
I'm
saying
is
like
kpac,
the
inputs
are
all
build.
Packages
right
and
those
build
packages
have
into
that
store
and
those
build
packages
have
assets
associated
with
them.
You
can't
figure
out
what
you
definitely
can't
do
it
in
a
granular
way,
but
you
could,
at
whatever
coarse
screen
level
the
operator
provided
the
build
packages
into
that
store.
You
could
pull
all
of
the
assets
for
the
associated
build
package
when
any
of
the
ids
are
referenced.
To
make
sure
you
have
it.
I'm.
B
C
I
wonder
if
we
should
put
assets
there,
like
name
and
digest
in
build
pack
tumble.
So
even
if
you
never
package
them
offline,
never
make
an
asset
cash
wherever
your
bill
pack
metadata
goes
metadata
about
assets
that
it
is
aware
of,
goes
with
it
and
then
sort
of
what
caches
exist
and
which
assets.
Certainly
cache
is
a
different
label
right.
B
It's
already
there,
it's
already
there
in
many
cases
right,
because
there's
that
metadata
field
and
a
lot
of
build
packs
happen
to
put
the
digests
of
the
individual
dependencies
that
we're
going
to
key
the
top
level
with
into
that
file
already,
it
would
just
be
codifying
that
for
build
packs
that
are
using
it
already.
It
kind
of
fits
together.
C
C
A
That's
basically
the
break
between
or
the
separation
between,
build
pack,
tumble
and
package,
toml
right
yeah,
and
so
we
could
move
that
same
kind
of
information
into
build
pack
tommel,
which
makes
sense
and
then
have
an
asset
or
a
package
tunnel
or
something
or
another
entry
and
package
tommle.
That
tells
you
where
to
get
those
things.
B
We've
said
that
over
time
we
want
to
get
rid
of
package
tommle
once
we
have
a
registry
right
packaged
almost
like
a
just
a
thing
for
sourcing
things
where
it,
we
don't
want
to
put
the
real
locations
into
pack
tumble.
But
we
don't
have
that
problem
here,
because
we're
not
talking
about
sourcing,
build
packs,
we're
talking
about
sourcing,
something
that's
native,
it's
important
to
the
build
pack
itself,
which
is
like
dependencies
that
it's
going
to
install.
So
I
would
definitely
support
pushing
that
into
to
build
pectomal.
D
B
B
We
are
right
at
time
dan.
Is
this
helpful
to
get
get
good
stuff
out
of
it
and
then
come
back
sorry?
I
know
it's
been
many
many
iterations,
but
I
think
we're
very
close
to
having
a
super
useful
thing.
You
want
to
bring
it
back
next
week
or
tomorrow.
You
can
keep
trying
cool
and
feel
free
to
add
everybody
for
approvals.
Once
it's
in
the
state,
you
don't
have
to
wait
for
a
working
group
meeting.
I
think
we
all
know
it's
know.
What's
going
on.
Okay,
all
right
sounds
good.