►
From YouTube: Working Group: 2020-10-15
Description
* Stack Buildpacks
A
B
B
I
think
the
pack
registry
is
in
good
shape
and
I
don't
think
we'll
have
any
trouble
shipping
that
fairly
soon,
but
I'm
a
little
bit
worried
about
os
packages
and
really
stack
build
packs,
just
because
it's
such
a
big
thing
and
it's
got
a
lot
of
dependencies
and
so
that's
kind
of
down
to
that
next
bullet
there.
I
was
wondering
if
we
could,
like
formalize
the
like
the
steps
that
need
to
happen
in
order
to
pay.
B
B
I'm
in
particular
want
to
hear
from
you
on
this,
but
I
think,
like
the
very
first
thing
is
finalizing
the
stack
bill,
packs
rfc,
which
I
said
yesterday,
but
I
want
to
just
remind
everyone
that,
like
within,
like
by
next
wednesday,
I'd
really
like
to
have
this
go
to
fcp,
so
I'm
happy
to
do
whatever
work.
I
need
to
do
to
the
rfc
itself,
but
the
thing
I
can't
do
is
review
it,
for
you
so
definitely
take
a
look
and
make
sure
you're
comfortable
with
it.
B
For
the
experimental
stuff,
I
guess
I
probably
need
to
review
that
rfc
myself,
but
I
feel
like
both
the
rfc
and
the
implementation
are
prerequisites
for
certainly
for
the
stack
build
pack
implementation,
but
not
necessarily
for
the
spec.
But
I
was
also
thinking
that
the
after
the
rfc
is
complete
I'll,
probably
start
on
spec
changes,
but
I'm
not
sure
if
those
are
like
dependent
on
some
of
the
decisions
in
the
experimental
api
rfc
or
not.
A
A
B
B
Is
there
anything
else
that
I'm
missing
or
not?
Thinking
about
in
terms
of
like,
I
guess
what
I'm
trying
to
do
here
is
think
about
it,
such
that
when,
when
it
comes
time
to
like
take
the
existing
pull
request
and
like
treat
it
as
a
like
a
poc
and
re-implement
it
with
the
experimental
api
stuff
on
whatever
changes
are
in
life
cycle
that
we
don't
run
into
any
blockers
that
you
know
it's
like.
Oh
yeah,
we
didn't
do
that
thing,
and
now
we
have
to
do
that.
A
A
B
C
Yeah
I
do
like
having
this
spec
up
there,
because
then,
if
there
are
certain
like
you
know,
I
don't
know
like
disagreements
when
you
get
to
the
point
of
implementation,
it's
like
well,
this
is
what's
in
the
spec,
we
can
follow
up
with
a
spec
change
and
a
change
later
on
right.
It
gives
you
the
target,
that's
not
so
moving
right
now,.
A
Yeah,
I
think
the
perfect
middle
ground-
and
we
don't
have
to
hold
ourselves
to
this,
but
when
we
can
get
there,
it's
nice
is
to
merge
the
spec
change
to
a
branch
start
implementation
before
that
branch
is
released.
So
you
can
use
the
implementation
of
feedback
on
small
changes
if
you
got
it
wrong
in
the
spec
and
then
release
both
of
them.
In
short,
succession.
B
Yeah,
I
think
like
along
with
that-
and
maybe
that's
the
point
where
we
make
this
call,
but
it's
like.
I
would
like
to
pick
a
version
and
block
on
this.
For
that
version.
You
know
what
I
mean
and
like
if
we're
not
there
like,
we
do
everything
we
like.
We
don't
do
other
things.
We
do
the
the
things
we
need
to
do
to
unblock
that
release
like
we're.