►
From YouTube: Buildpack Authors: 2021-07-02
Description
Meeting notes: https://bit.ly/38pal2Z
A
B
I
I
thought
about
that,
but
that
was
just
like
that's
like
a
different
thing:
everything
uses
the
same
link
and
the
same
doc
and
everything.
Well.
I
guess
you
don't
change
the
thought,
but
I
know
just
what
everyone
else
uses.
So
I
don't
know
I
think
it'd
be
fine.
Someone
from
vmware
would
show
up
who
has
the
powers
right
most
likely.
C
A
B
A
A
I
am
also
a
maintainer
of
the
learning
team
so
help
you
know,
produce
the
docs
and
the
website
and
stuff.
Like
that.
The
reason
I'm
in
this
particular
meeting
it's
really
more
to
be
a
fly
on
the
wall,
but
also
get
some
insights
from
buildpack
authors
right
to
see
what
more
or
less
they
might
want
from
pac,
where
it
kind
of
provides
a
set
of
tooling.
That's
you
know
not
just
for
building,
but
also
for
creating
a
whole
bunch
of
other
things
within
the
ecosystem.
C
A
D
I
guess
I'm
last
so
I'm
dan,
I
work
on
the
java
bill
packs
at
vmware
and
it's
david
and
I
working
on
a
small
team,
and
so
I
basically
joined
because
I've
got
a
vested
interest
in
lib
cnb
since
we
use
it
in
like
50
or
so
build
packs,
and
I
also
have
a
lot
of
maybe
crazy
ideas
about
things.
I'd
like
to
do
with
build
packs
and
developing
build
packs.
D
B
B
B
D
Do
do
folks
have
a
preference
or
feeling
in
terms
of
like
how
we
should
try
to
pace
releases
for
lib
cnb
that
would
be
like
feasible
to
maintain,
like
I
know,
for
us,
a
new
lip
cnb
release
creates
a
reasonable
bit
of
work
because
we
have
you
know
to
integrate
it
into
a
whole
bunch
of
build
packs.
So,
like
I'm,
just
curious
for
others
like
what's
too
often,
what's
not
often
enough
that
type
of
thing,
maybe
just
something
to
think
about
too,
we
don't
have
to
answer
it
right
now,
but.
B
C
D
I
think
it's
historically
has
been
something
that
we
try
to
integrate
whenever
the
releases
come
out
like
we
have
ci
that
picks
up
the
change
right
away
and
then
we'll
kind
of
merge
it
in
as
we
as
we
can,
but
especially
for
things
that
are
non
like
non-breaking,
that
don't
update
the
like
the
apis
and
stuff,
but
it
still
is
some
work.
So
I
guess
it's
just
a.
D
B
D
D
Yeah
yeah
I'd
almost
be
curious
about
like
a
some
sort
of
like
timed
cadence.
You
know
for
releases
that,
like
quarterly
or
something
like
that,
I
almost
think
that
would
force
us
or
help
motivate
us
to
complete
some.
You
know
outstanding
issues
or
something
too
because
he's
like
oh
there's
a
release
coming
up.
If
I
want
to
get
it
in,
you
know
now's
the
time
or
something
so.
B
I
know
in
the
past
there
hasn't
been
time
releases
because
it's
just
been
like,
as
stuff
has
updated
through
the
api
and
whatnot.
I
know
some
of
that's
going
to
change
going
forward
with
the
creation
of
this
team.
Do
you
are
there
things
that
you
want
to
change
on
a
quarterly
cadence
to
kind
of
warrant,
a
release
of
recorder
that
is
not
dependent
on
like
the
spec,
changing
and
whatnot.
D
Yeah,
I
don't
know,
I'm
not
really
sure
I
guess
it
could
potentially
be
a
quarter
where
we
just
we
don't
cut
our
release
because
there's
nothing
to
release.
But
my
real
only
concern
with
doing
like
a
time-based
release
is
if
there
is
a
big
spec
change
you
know
like.
I
don't
want
to
have
to
wait
two
months
or
something
you
know
based
on
the
timing
of
when
that
releases
and
when
we
have
to
release
you
know
like
that
would
be
the
only
downside.
C
B
Yeah
that'd
be
my
big
hesitation
for
kind
of
wanting
to
commit
to
time
stuff.
Also,
I
mean
in
my
ideal
world
we're
also
cutting
out
lip
cmd
releases
when,
like
life
cycle,
also
cuts
a
release
of
like
here's,
a
new
spec
change,
and
ideally
it's
like
yup.
Now
you
can
use
it
as
a
build
pack,
author
for
gold
packet,
stuff
right.
D
B
Cool
all
right,
so
standing
rc's.
I
guess
I
can
share
my
screen,
there's
only
some
new
stuff,
I
guess
from
last
time,
like
the
I
don't
know,
if
there's
particular
ones
that
dave
and
daniel
you're
interested
in
talking
about
both
here,
but
I
kind
of
just
picked
all
the
ones
that
had
built
back
author
as
that's
kind
of
what
the
link
is-
and
I
know
we're
not
always
the
best
in
the
working
group
meeting
at
tag
me.
B
D
I
was
looking
at
that
yesterday
and
I
I
generally
like:
what's
there,
I
think
it'll
create
a
little
bit
of
work,
but
I
think
it's,
I
think
it's
good
for,
for
what
we're
doing.
I
do
think
there's
some
opportunities
in
that
change
too,
for
lip
cnb
to
perhaps
offer
some.
You
know
additional
help
to
authors
on
things
that
have
changed
in
doing
them.
The
new
way.
D
D
B
Yeah,
I
guess
in
my
mind
I
think
that
sounds
good,
though
I'm
not
sure
in
practice
what
that
actually
means
for
something
like
ellipse
and
b,
because
I
don't
think
it.
I
don't
think
like
exactly
is
necessarily
one
to
one
to
profile
d
right
like
in
profile.
You
can
do
basically
anything
in
dash
exactly
you
essentially
have
to
output
to
that
specific
format.
B
D
I
wonder
I
wonder
if
there's
something
we
can
do
like
notification
wise
to
to
like
to
authors
or
users
that
that
those
types
of
changes
are
occurring,
like
certainly
with
the
you
know,
with
the
dot
profile
going
away.
That
impacts
users,
you
know,
and
so
there
could
be
some
sort
of
like
warning
like
okay,
you
might
have
had
this
and
it's
suddenly
not
going
to
work.
B
B
B
B
B
Sense,
I
feel
like
this.
I
feel
like
when
daniel
thornton
originally
proposed
the
asset
packaging
thing.
It
was
kind
of
meant
to
not
completely
solve
that
problem,
but
at
least
help
mitigate
like
and
correct
me
if
I'm
wrong,
but
I
think
the
keto
bill
packs
also
limit
what
jdks
are
available
like
you,
don't
allow
the
world
list
of
like
I
want
this
old
jdk,
that's
not
supported
like
you,
don't
let
them
use
it
right
so
yeah.
B
I
know
there's
a
balance
of
like
bloating
the
bill
pack
or
the
built
package
of
like
too
many
jdks,
because
you
don't
want
to
force
people
to
download
like
a
20,
gig
bill
pack
file
or
whatever
right,
but
it
that
hasn't
kind
of
shipped
right.
So
it's
not
a
thing.
You
can
tell
users
to
use
today,
but
does
that
get
you
far
enough
to
solve
that
issue?
Because
I
don't
even
know
in
this
original
proposal
if
they
save
the
cash
on
a
failed
bill.
D
D
The
one
that
daniel
thornton
proposed,
I
think
that
was
like
rfc
73
and
on
the
surface
it
kind
of
seemed
to
address
some
of
the
issues,
but
there
were
there
were
some
challenges
to
it,
because
it's
I'm
trying
to
remember
emily
had
a
better
handle
on
this
than
me.
The
way
that
it
was
cat
it
was
making
that
stuff
available.
D
D
So,
if
you
pull
in
say,
like
you
know,
500
megs
of
pre-cached
assets
it'll
sit
there
for
a
solid
minute
easy
before
it
does
your
pack
build.
So
I
think
that
was
a
similar.
I
think
emily
was
thinking
that
would
be
similar
with
the
way
that
rfc
73
was
doing
things
as
well,
so
it
just
like
yeah
it
just
kind
of
was
a
little
awkward.
A
I
mean
I
think
this
ties
very
well
with
the
topic
I
added.
I
don't
know
if
you
want
to
get
into
it,
but
yeah
happy
to
move
like,
I
guess,
maybe
daniel,
if
you
could
speak
a
little
bit
to
to
asset
packages
right
and
what,
especially
when
we're
talking
about
the
offline
capability,
which
is
what
this
feature
is,
is
really
trying
to
provide.
A
A
D
A
D
So
it
would
be
like
that
would
would
be
okay,
but
it
would
just
have
some
awkward
points
to
it
like
like
what
I
had
mentioned
about
the
slowness
of
importing
those
large
layers.
This
particular
one
that
emily
has
proposed
is
it's
it's.
I
guess
it's
a
simpler
approach,
but
it
kind
of
takes
the
opposite
approach.
Instead
of
like
pre-loading
stuff,
it's
just
letting
the
build
pack
run
and
kind
of
accumulate
things,
so
it's
it's
certainly
not
going
to
solve.
You
know
like
the
offline
case
or
something
like
that.
A
Right
and
in
my
mind,
those
are
two
very
different
features
right,
one
of
them
is
is
essentially
having
a
more
robust
caching
mechanism
across
multiple
builds
right
or
multiple
unassociated
applications.
If
I
understand
it
correctly,
right,
yeah
and
then
the
other
one
is
being
able
to
reference
almost
like
co-located
information
right.
So
that's
the
asset
packages.
B
Yeah,
I
think
the
other
big
advantage
of
asset
packages
from
I
think
a
lot
of
steven's
kind
of
input
into
that
design
was
in
a
registry.
Since
it
is
a
layer
on
there
from
the
build
package,
it
will
be
the
same
layer
across
all
the
apps.
Like
you
don't
have
to
move.
You
don't
have
to
move
that
asset
package
into
like
a
another
layer
in
that
app
right.
B
B
D
D
A
D
So,
for
me,
the
the
asset
packages,
the
work
that
daniel
thornton
was
doing.
I
we
don't
have
a
burning
need
for
that,
because
we
have
an
existing
solution.
That's
maybe
not
optimal,
but
it's
working.
You
know
for
our
users
we
haven't
really
received
complaints
of
like
oh,
it's,
you
know
xyz
or
whatever
doesn't
work,
so
that
would
be
something
that
even
if
it
were
implemented,
it'd
be
like
we'll
get
to
that
at
some
point.
You
know
on
switching
what
we
have
now
to
the
official
you
know
stuff.
D
So
it's
not
a
big
deal,
I'm
I
don't.
I
certainly
don't
want
to
speak
for
emily,
but
in
our
conversation
yesterday
I
think
I
was
kind
of
hoping
that
that
that
might
be
held
off
just
because,
like
you
said,
there's
questions
with
that
potential
rfc
on
removing
stacks
there's
questions
on
like.
Is
it
really
the
right
way
that
we
want
to
do
offline
too
I'd
hate
to
put
something
out
and
then
immediately
like
rfc
and
change
it?
You
know
in
two
or
three
months:
that's
just
not
a
good
experience
for
people.
A
I'm
finding
it
very
difficult
to
justify
holding
off
on
a
feature,
that's
again
like
ready
to
go
out
the
door
for
a
potential
change
that
might
come
up
in
months
from
now
right.
So
that's
kind
of
what
doesn't
seem
to
align
for
me
where
the
way
I
would
see
it
is
I
we
would
release
the
feature
that
we
have
based
on
the
original
proposal
and
yeah.
A
If
there's
a
new
change,
because
to
me
it
sounds
like
there's
always
going
to
be
new
changes
so
kind
of
delaying
stuff
and
definitely
doesn't
make
a
lot
of
sense
and
yeah,
that's
kind
of
where
my
mindset
is
coming
from
right.
So
that
being
said,
if
there,
if
really
nobody,
is
looking
forward
to
this
change
being
available
or
this
feature
being
available,
then
yeah.
It
doesn't
make
sense
for
us
to
release
it
at
all
right,
and
so
I
don't
know
yeah
just
trying
to
get
as
much
data
as
I
can.
There.
D
B
Yeah,
I
guess
I
share
javier's
silver
supplement
like
I,
don't
necessarily
disagree
with
the
remove
stack
proposal.
I
have
some
questions
and
stuff
on
it,
but
it
is
not
a
rfc
to
merge
them
lightly.
Even
if
it's
the
better
rfc
like
it,
is
only
burning
the
entire
world
of
like
how
build
packs
are
built
right.
Okay,
it
changes
builders,
it
changes.
Obviously
this
asset
package
thing
because
the
assets
are
tied
to
it.
B
I
mean
it
changes
the
bill
pack
registry,
like
like
we,
we
list
the
stacks
that
bill
packs
are
compatible
with
it.
Changes
build
packs
directly
right,
like
like
you're
talking
about
like,
like
literally
torching,
like
a
foundational
component.
You
know
mixins
as
well,
though
I
think
maybe
people
use
mixons
not
as
much
but
like
you
literally
can't
build
you
can't
do
a
build
without
stacks.
B
Right
like
stacks,
are
a
core
concept
and
we're
talking
about
like
throwing
that
throwing
that
out
the
window,
which
doesn't
mean
we
shouldn't
do
it,
but
it
is
very
much
a
like
like.
Should
we
hold
on
off
on
basically
releasing
anything
that
touches
stacks
like
that's,
basically
like
everything
right
like
like?
Are
we
are
we
freezing
the
project
now
because
this
proposal
came
in,
like
I
don't
know
like,
I,
I
feel
like
it'd,
be
potentially
different
for
me.
B
If
this
proposal
was
like
an
fcp
already
and
like
it
was
gonna
happen
and
I'm
confident
that
it
will
probably
go
through,
but
I
do
feel
like
the
rc
today
just
focuses
on
the
change,
but
not
the
implications
like
like
how
do
we
actually
migrate
and
deal
with
this
like?
Is
it
like
what
happens
if
I'm
in
a
build
pack
like
group
building
and
one
build
pack
uses
this
new
stack
mechanism
that
doesn't
have
stacks
and
every
other
build
pack
relies
on
like
stacks
right
like
what?
B
A
Know
yeah,
I
think
that's
definitely
gonna
be
hard
cool,
so
I
I
mean
my
takeaway
from
this.
Is
it
doesn't
seem,
like
you
know,
at
least
to
your
knowledge,
daniel
there's
anybody,
that's
really
waiting
for
it
on
vmware
or
potato
side
I
might
poke
around
and
see
if
there's
any
other
sense
of
of
urgency
or
people
that
are
waiting
for
it
and
then,
if
not,
then
it
might
be
worth
holding
off.
D
B
Yeah
I
mean
it
came
out
of,
I
think
the
work
from
probably
that
team
and
I
think
they
just
wanted
a
thing.
That's
not
like
a
homegrown
kind
of
thing
and
if
it's
built
into
build
packs
directly,
I
think
you
get
the
probably
the
biggest
advantage
is.
I
think
the
layering
thing
that
you
can't
do
today
right,
like
you,
can't
create
a
layer,
that's
shared
across
the
registry,
and
I
think
that's
the
one
thing
that
a
homegrown
solution
cannot
do
that
this
would
provide.
So
I
don't
think
it's
burning
as
in
like
they
have.
B
I
mean
if
you
want
to
do
it
today,
you
have
something
in
place,
so
you
know
it's
not
gonna.
Stop
stop
that,
but
I
think
moving
over
to
it
means
that
you
get
kind
of
this
advantage.
I
know
on
the
salesforce
side,
we
were
looking
forward
to
this
feature,
but
it's
not
like
a
make
or
break
for
us
right
like
it's
not
and
we're
not
necessary,
even
trying
to
support
the
offline
use
case.
It
is
very
much
for
the
shared
asset,
kind
of
thing
right
and
where's.
B
B
It's
good
it's
I
I
think
we
probably
would
just
use
both
right.
It
kind
of
depends
on
the
download
stuff.
I
mean
the
one
thing
the
the
volume
doesn't
do
is
create
a
layer
in
the
registry.
Right,
that's
shared
so,
like
you
still
run
to
the
like.
If
you
do,
if
you
didn't
put
jdks
in
the
kind
of
asset
package,
it
means
every
java
app
in
salesforce
would
recreate
this
jdk
layer
regardless.
B
Not
have
to
basically
do
some
work
that
is
expensive,
whether
that's
network
or
something
else
I
imagine
as
well,
and
so
that's
just
going
to
be
shared
between
builds
but,
like
you
know
like
if
you're
talking
about
like
a
jerry
or
something
that
has
to
be
built
at
launch,
like
that's
just
a
thing
that
is,
that
is
not
a
problem.
It's
trying
to
solve
right.
D
B
Yeah,
I
know
I
I
know
that's
a
thing:
ben
ben
hale
complained
about
a
lot
was
just
like
and
we
had
all
these
customers.
I
think
it
was
like
dealing
with
like
in
slugs
and
just
like,
and
we
have
like
literally
the
jdk
being
jerry
being
duplicated
everywhere,
yeah,
so
yeah
I
mean,
I
think
they
sell
somewhat
different
use
cases.
Zelda
cache
things
interesting.
B
There
was
talk
about
that
with
it
being
shared
across
different
builds
too,
like
between
apps
like,
and
I
know
that
was,
I
feel
like
somewhat
controversial
because
of
security
and
other
things
like.
I
don't
know
how
reasonable
it
is,
even
for
like
a
node
app
to
share
even
like
potentially
like
npm
downloads
or
something.
D
Yeah
that
that
is
another
problem
that
that
we
have,
but
I
think
we
were
just
looking
to
not
address
that
particular
issue
with
this
pr,
because
it's
it's
it's
different.
Like
you
said
it's,
you
really
want
to
scope
that
stuff
to
the
application
and
not
not
multiple
applications
like
for
java,
it's
not
as
big
a
deal,
but
what
I
think
what
we
see
people
wanting
to
do
more
is
like
when
they're
using
pack.
They
want
to
be
able
to
say
hey.
D
D
B
C
B
This
is
just
a
volume
and
like
you're
responsible
for
cleaning
up
like
if
this
build
fails,
because
of
something
that
you
put
in
there
like
that's
on
you
to
like
figure
out
or
deal
with
it,
which
is
a
very
different
prop
like
like
kind
of
properties
from
like,
I
guess,
like
the
the
normal,
like
just
layer,
builds
of
what
people
are
thinking
about
caching
today
and
then
there
was
also
like
sam's
rc.
That
kind
of
I
guess
got
postponed,
but
then
there
was
like
his
like
global
writable
layer.
B
B
D
B
D
D
So
but
hopefully
we
can
kind
of
help
him
through
that
and
do
a
little
bit
of
training,
and
then
I
think,
maybe
maybe
30
or
60
days
after
you
know,
we'll
sit
down
and
kind
of
do
a
retrospective
and
see
what
he
thinks
and
what
we
can
improve.
It
could
be
good
feedback
just
for
for
build
tools
in
general.
D
D
B
She
had,
obviously
you
can't
speak
for
everyone
there,
but
she
had
insightful
things
to
say
there.
One
of
the
things
that
I
was
trying
to
push
towards
was
trying
to
figure
out
where
lip
syndi
falls
short
not
to
like
migrate.
All
the
their
bill
packs
to
lipstick.
But
more
can
we
migrate
packet
to
sit
on
top
of
look.
B
Sandy
was
the
thing
that
I
would
like
to
see
happen,
and
I
don't
know
exactly
what
those
changes
are,
but
I
would
love
to
see
lip
cmb
be
the
at
bare
minimum
like
the
low
level
binding
with
and
if
it
has
opinions
on
stuff.
Maybe
it's
just
like
a
higher
level
distraction
that
can
sit
kind
of
separately
on
top,
but
at
least
it's
providing
all
the
api,
primitive
stuff,
and
so
I
know
one
of
the
complaints
that
sam
had
about
packet
was
that
it
doesn't
provide
all
the
api
stuff.
That
is
current
right.
B
D
B
C
D
B
Yep,
I
guess
the
probably
last
thing
in
the
last
three
minutes.
We
were
talking
about
kind
of
the
scheduling.
Do
you
have
a
preference
on
meeting
every
week
every
other
week?
I
think
javier
was
proposing
on
just
moving
all
the
sub
team
sinks
kind
of
every
other
week,
so
just
to
kind
of
cut
down
on
the
number
of
meetings
for
people
who
are
attending
a
lot
of
this
stuff
and
some
of
the
attendance,
I
guess,
has
also
dropped
off
on
some
of
the
other
symptoms
meetings.
D
A
Yeah,
I
think
that'd
be
great.
I
don't
know
how
much
I
guess
assistance
you
would
need
from
the
learning
team
just
for
some
context.
The
way
that
our
docs
website
operates
is
the
learning
team
is
more
or
less
just
a
facilitator
for,
like
the
area
of
documentation,
styling
that
sort
of
stuff,
but
a
lot
of
the
documentation.
That's
you
know
pertinent
to
individual
sub
teams,
it's
more
or
less
on
them
and
their
responsibility
to
produce
that
documentation.
D
A
Yeah,
that's
a
I
mean.
That
is
a
really
good
question.
I
I
will
say
that
we
do
have
a
tool
section
where
maybe
it's
worth
putting.
You
know
libsy
and
b,
even
just
mentioning
it
there
on
the
tools.
I
know
we
wanted
to
split
that
up
into
different
type
of
tools.
Right.
Some
of
them
are
like
platforms.
A
A
D
B
Yeah,
I
definitely
am
not
do
not
want
to
propose
any
of
the
stuff
we
do
replaces
any
of
the
bash
things,
because
I
don't
think
having
to
know
go
should
be
a
requirement
for
how
we
tell
people
to
write
bill
packs.
But
I
do
agree
that
if
we
have
a
library,
that's
officially
part
of
the
the
project,
it
would
be
nice
to
have
documentation
on
how
to
actually
get
started
and
use
it.
D
A
He
took
it
and
created
a
catacota
workbook
out
of
it.
We
are
hoping
to
be
able
to
embed
catacota
workbooks
into
the
doc
site
so
that
we
don't
have
to
manage
two
of
them.
So
I
think
that
would
impose
some
sort
of
limitation
on
whether
we
could
do
this
whole.
Like
you
know,
change
the
code
or
change
the
language
on
the
tutorial.
We
might
just
end
up
with
two
different
workbooks
right,
one
for
go
lib,
cnb
and
one
for
bash,
and
you
know
figuring
out
how
that
works
out.
D
Probably
not
in
the
short
term,
but
I
think
like
I,
I
definitely
have
kind
of
something
in
my
backlog
to
I
guess,
discuss
more
about.
You
know
how
to
write
build
packs.
I
think
we
do
want
to
promote
that
and
promote
the
tools
and
stuff,
so
I
couldn't
commit
to
anything
in
the
next
couple
weeks,
but
you
know
maybe
a
little
further
down
the
road
like
when
david
gets
up
to
speed.
We
can
take
some
of
his
feedback
and
start
authoring.
Some
talks
on
that.
B
D
I
think
it
happens.
You
know
we
do
find
customers
that
want
custom,
build
packs,
whether
they
write
them
or
whether
they
have
you
know
someone
from
vmware
write
them
for
them.
You
know
on
their
behalf,
it's
you
know
601,
but
you
know
having
a
clear
path
and
clear
set
of
tools
and
stuff
that
helps,
pays
dividends
down
the
road
in
terms
of
supporting
them
and
keeping
them
up
to
date
and
stuff
too.
So.