►
From YouTube: Working Group: 2021-07-08
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
Notes,
if
not,
we
can
just
write
things
as
the
come
up.
It's
no
problem.
B
I
can
give
a
quick
update
for
the
life
cycle.
I
think
we've
been
hinting
for
a
while
now
that
we're
getting
close
to
releasing,
but
I
think
some
of
the
features
that
we're
targeting
for
the
next
release
are
shifting
a
little
bit
so
we're
still
working
on.
It
is
what
I
can
say
right
now,.
C
B
A
D
C
Not
really,
I
think
there
are
some
suggestions
to
add.
C
A
Good
next
one
is
our
dynamic
base
image
generation.
I
think
I
responded
to
most
feedback
here.
A
D
A
The
discussion
here
I
think
there
was
some
interesting
you
know
push
back
along
the
lines
of
like
if
we're
not
doing
stack
packs,
it
doesn't
add,
like
build
packs,
can't
install
operating
system
packages.
So
you
know,
when
are
we
gonna
do
that?
A
A
I'll,
take
a
look
at
those
again
for
all
three
of
these.
You
know
they're
missing
some
detail
and
I'll
go
back
and
add
more
things,
but
if
any
or
like
feel
free
to
review-
or
you
know
treat
them
like
real
rfcs,
I
think
there's
enough
in
there
that
at
least
for
to
remove
stacks
and
make
sense,
you
could
probably
get
consensus.
A
Next
one
is
looks
like
a
dependency
bump
issue
generation.
It's
not
an
rfc
for
another
rfc.
Remove
shell
specific.
F
D
It's
all
the
way
at
the
bottom
that
I
I
don't
think
it's
like
a
blocker
thing,
but
it's
probably
a
good
thing
to
call
out
like
that.
That
is
a
change
of
stuff
that
bill
pack.
Authors
have
to
take
in
account
in
their
direct
processes.
I
mean
that's
always
been
true
for
direct
bosses,
but
now
everyone's
defaulting
into
it
right
so.
B
D
Yeah,
I
think
so
cool
like
that.
We're
accepting
this
complexity,
because
that
is
a
change
I
think
for
built-in
conference.
A
Support
for
structured
bomb
format.
I
think
this
was
upgraded
out
of
a
draft
recently
any
updates
on
this.
This
week,
sam.
E
B
E
A
Cool,
I
think
this
is
something
that
we've
been
talking
about,
like
like
also
stopping
work
on
the
asset
packages
rfc
or
reconsidering
some
things
there,
the
there's
a
bunch
of
things
around
caching.
This
is
this
kind
of
feels
like
related
to
caching,
that
maybe
I
kind
of
want
to
take
a
step
back
and
think
of
a
more
unified
model.
Before
we
end
up
with,
you
know,
five
different
ways
to
cache
things
the
so
maybe
this
is
something
that
could
be
accounted
for
as
part
of
that
effort.
A
B
A
B
F
I
suggested
that
we
add
this
to
the
agenda,
because,
during
review
of
the
pre
and
post
build
pack
spec,
an
issue
came
up
sort
of
around
how
all
these
features
fit
together
and
override
each
other.
So
if,
in
a
project
tommle,
you
have
pre
and
post
build
packs,
but
you
also
have
an
order.
How
do
folks
expect
that
to
behave?
And
then,
if
you're
overriding
the
order
on
the
with
pax
cli,
do
we
expect
that
to
override
pre
and
post
build
packs
or
not
override,
pre
and
post
build
packs?
F
F
My
straw
dog
proposal
was
that
we
should
accept
both
pre
and
post,
build
packs
and
order
and
project
tomml,
and
they
should
get
combined
just
like
they
would
if
there
was
no
order
and
then
the
overrides
on
the
pax
cli,
you
know
if
we're
adding
pre
and
post
build
pack
flags
as
well
as
our
normal
order
flags,
you
should
explicitly
just
override
that
part.
So,
if
you're
passing
build
packs
in
a
way
that
overrides
order,
you
just
override
the
order
and
you
still
get
your
pre
and
post
build
packs.
F
F
I
know
some
other
folks
thought
that
was
a
little
bit
weird
to
still
get
a
combined
version
of
the
flags
in
the
project
tunnel
order.
So
I
want
to
argue,
for
the
other
other
point
of
view,.
D
Here
I
mean,
I
think
the
original
thing
that
came
up
was,
if
you
control
the
complete
dill
pack
order.
Why
would
you
use
premium
post,
it's
kind
of
use
case
there
there's
some
there's
an
open
question
of
for
me
like
you,
can't
have
pre
and
post
and
builder
today.
Do
we
want
that?
Do
we
want
this
just
to
be
a
non
kind
of
builder
level,
config
that
users
can
control?
D
Is
it
obvious
to
users
that,
if
I
use
dashb
that
pre
and
post
would
still
run
when
traditionally,
I
think
before
this
feature,
dash
b
basically
takes
over
the
entire
bill
pack
list?
So
that
is
a
change
in
behavior
to
some
degree.
C
I
think
so
for
the
builder.
We
have
the
intention
of
a
pre
and
post-like
thing,
but
we
don't
know
what
that
is
going
to
look
like
yet,
so
I
think
we
kind
of
have
to
imagine
what
what
we'd
want
there
like
in
some
sense.
C
I
like
the
sort
of
orthogonality
of
like
having
just
pre
and
post,
is
like
this
thing
and
it
works
in
the
builder
and
it
works
in
the
project
tumble,
but
then
using
the
same
keys
or
names
or
for
that
thing
opens
up
all
these
questions
about
how
they
work
together.
C
I
think
what
emily
described
is
fine
with
me,
but
it's
also
very
like
not
like
house
of
cards,
but
like
it's,
this
fragile
thing
like
if
you
take
one
thing
out
of
it,
it
starts
to
not
make
sense
so
like
having
pre
and
post
and
an
order
in
the
project.
Tom
all
makes
sense
to
me
if
the
use
case,
where
I
want
to
use
dash
b
and
still
have
pre
and
post
run
is
a
valid
use
case,
and
I
think
it
probably
is.
C
I
could
totally
see
like
pre
and
post
utility
build
packs
in
your
project.
Tamil
and
then
in
ci,
you
run
one
build
pack,
but
then
locally
you're,
like
dash
b,
my
debug
build
pack
or
something
like
that,
and
you
still
want
the
pre
and
post
to
run.
So
I
think,
that's
probably
valid,
and
I
think
that
is
sufficient
to
require
that
they
work
together
in
the
project
normal.
Even
though
I
was
kind
of.
D
C
No,
I
meant
more
like
yeah
yeah
no,
but
I
meant
more,
like
I'm
building
a
ruby
app
and
then
I
have
some
problem
locally
or
I'm
doing
something
special
locally
or
I
have
like
some
development
thing
locally,
and
so
I
just
have
like
ruby
dash
dev
build
pack
where
I
kind
of
instrumented
it
or
something
along
those
lines.
C
C
I
guess
another
possibility.
I
don't
like
this.
One
is
platforms
that
don't
support
the
build
pack
group,
but
would
support
pre
and
post.
I
I
that
kind
of
grosses
me
out,
but
I'm
curious,
if,
like
that's
a
thing
that
might
be
a
thing
for
k-pac
or
other
platforms,.
B
E
D
D
Utility
bill
pack
rc,
but
it
definitely
adds
a
lot
more.
I
think
interesting
color
to
pre
and
post,
especially
with
builder
of
like
how
you
want
to
do
it,
because
I
think.
B
D
I
would
I
wouldn't
want
to
be
at
the
same
level.
I
think
you
mentioned
the
show
with
like
the
keys
and
stuff
like.
I
wouldn't
expect
my
pre
and
post
to
messy
override
what
is
in
the
builder
right,
but
that
seems
to
be
how
we're
treating
it
with
pax
cli,
with
the
thing
that
emily
mentioned,
which
makes
sense
like
that
it
would
work
that
way.
But
it's
definitely,
I
feel
like
we're.
D
We've
been
trying
hard
with
some
of
these
recent
rc's
to,
I
think,
move
in
the
opposite
direction
of
complexity,
and
I
feel
like
we're
adding
a
much
higher
mental
tax.
I
think
potentially
moving
that
direction.
C
Yeah,
maybe
it
would
help
so
like
we're
talking
about
something,
that's
very
abstract
and
doesn't
have
like
a
concrete
proposal.
So,
like
the
utility
build
pack-
or
I
can't
remember
the
name
of
the
rfc-
that
I
have
open
right
now-
actually
doesn't
address
this
right
like
that.
Rfc
is
really
just
about
like.
Should
the
project
take
on
some
build
packs
and
doesn't
say
how
they're
gonna
be
used
so,
like
I
just
haven't
had
time,
but
I
was
gonna
write
another
rfc
for
that
mechanism,
whether
it's
pre
and
post
and
builder
or
whatever.
C
So
maybe
what
we
should
do
is
say
the
pre
and
post
or
group
editions
rfc
is
finalized,
but
before
we
finish
speccing
it
out
and
certainly
implementing
it,
we
would
finalize
this
default
mechanism
default,
build
pack
mechanism
rfc
because
it
potentially
like
this,
like
that
rc
ends
up
not
being
a
pre
and
post
and
builder,
and
we
ship
them
with
lifecycle.
That's
definitely
an
option
that
would
make
this
more
complicated
or
maybe
resolve
some
of
the
problems.
I
don't
know
so,
maybe
that's,
maybe
that's
how
we
should
go
forward.
D
F
I
feel
like.
If
we're
gonna
do
the
rfc
as
written
right
now,
we
should
decide
how
the
things
that
are
in
there,
how
we
deal
with
edge
cases
that
we
didn't
elaborate
on
in
the
rfc
right,
but
I
think
there's
another
conversation.
That
sounds
like
what
this
has
turned
into,
which
is
the
should
we
pause
this
because
we
think
that
we
see
other
complications
in
the
near
future
and
we
would
like
to
resolve
them
before
we
add
this
complexity.
E
C
No,
no,
I
think
so.
I
think
the
predominant
use
case
is
in
project
tamil
and
like
this
came
from
people
asking.
Basically,
this
replaces
the
from
builder
thing
which
people
use
already
right
where
it's
like.
I
want
to
supplement
the
build
packs
that
are
auto
detected
and
I
don't
want
to
specify
an
order
and
so
actually
like
the
pre
and
post
on
pack
was
just
like,
oh
well.
We
might
as
well
do
this
to
match
or
override
what's
in
project
tumble,
but
the
main
use
case
is
like.
E
C
I
mean
that's,
that's
what
the
group
editions
rfc
was
about.
We
could
I
mean
we
could
revisit
that,
and
I
still
think
that
there's
like
I,
I
still
think,
there's
another
mechanism
besides
pre
and
post.
That
is
more
like
override
this
specific
build
pack
with
my
own
build
pack
but
yeah
I
mean,
I
think,
that's
a
whole
can
of
worms.
You
know
like
it
could
get
really
hairy
if
you're
trying
to
like
insert
into
the
middle
of
the
group
or
something
like
that,
which
was,
I
think,
that's
what
came
out
of
that.
C
That
rfc
was
like.
I
had
originally
had
pre
and
post,
and
then
I
had
some
other
I'd
propose
some
other
mechanism
where
it
was
like
in
like
after
it
was
before
and
after
where
you
could
like
target
a
build
pack
id
and
say
run
before
that,
and
we
ended
up
mixing
it
because
it
was
really
hairy.
So
I'm
not
against
some
mechanism
like
like
that
or
like
overriding
a
build
pack,
but.
E
F
C
Yeah,
I
think
it's
still
in
there
and
then
there's
like
there's
some
build
packs
out
there
that
recommend
using
it
and
it's.
It
feels
really
hacky
and
I
think
that's
why
we
need
either.
We
either
need
to
have
whatever
the
mechanism
is
like
like
what
sam
described
as
fine,
but
I
think
that
would
that
would
we'd
have
to
like
rfc
that
and
have
it
supersede
the
existing
rfc.
C
I
think
we
just
need
to
like,
instead
of
having
like
a
from
builder
hack,
we
just
need
some
kind
of
official
like
spec
mechanism
for
this,
so
that
we
can
exactly
for
all
the
reasons
we're
describing
like
how
does
it
interplay
with
this
other
thing,
and
if
we
want
to
add
this
to
the
builder,
I
just
want
to
make
sure
that
all
that
stuff
is
that
we
have
a
way
to
make
it
crystal
clear.
So.
D
Yeah
I
mean
a
nuance
here.
Also,
is
that
builder
is
an
extension
stack
that
hasn't
released
yet,
but
this
would
then
also
only
be
an
extension
feature,
whereas
I
think
pre
post
is
not
dependent
on
anything
related
to
builder.
D
Which,
I
think
is
some
reason
why
we
want
to
just
work
regardless
if
they
specify
the
group
list
or
not
in.
C
I
mean
like,
I
think,
the
thing
that
makes
sense,
I
think,
is
to
figure
out
the
other
part
of
default,
build
packs
at
least
a
proposal,
so
that
we
can
weigh
this
all
together.
I
I
do
I'm
a
little
concerned
like
the
reason
I
initially
created.
The
group
editions
rfc
was
that
from
builder
started
popping
up
in
like
the
astana,
build
packs,
documentation
and
stuff
like
that,
and
so
it
was
like.
Oh
man,
we
need
to
nip
this
in
the
butt
or
it's
gonna.
C
We're
gonna
have
to
support
it.
So,
right,
like
I,
haven't
seen
that
happen
again
other
than
I
think
the
two
use
cases
like
there's
a
goo
like
google's
doc,
say
it
and
then
estan
and
bill
packs
say
it.
C
C
F
B
F
F
B
So
again
we
don't
need
to
talk
about
it
here,
but
I
would
love
to
get
your
opinions
about
the
discussions
like
on
the
discussion
that
I
created
about
the
difference
between
the
working
group
and
office
hours,
because
I
feel,
and
from
what
I
heard
from
others,
they're
also
having
the
same
feeling
that
the
working
group
office
hours
started
to
become
like
the
same
eating.
F
B
B
I
edit
a
reference
to
natalie's
pr
in
my
discussion.
B
It's
kind
of
relate
to
each
other,
but
we
used
to
have
like
two
working
group
sessions
and
we
changed
one
of
them
to
be
in
office
hours,
which
is
supposed
to
be
a
bit
different,
but
in
the
last
few
weeks
it
looks
like
it
become
like
another
working
group
session.
B
A
I
think
like
it
seems,
like
people
want
about
two
hours
of
face
time
to
talk
about.
You
know
whatever
things
per
week
as
opposed
to
an
hour
or
we
tried
to,
we
suggested
you
know,
do
we
need
two
meetings
a
week
to
be
good
on
to
less?
You
know,
I
think
the
feedback
was
it's.
It's
still
helpful
to
have
time
to
communicate,
synchronously
be
great
to
add
more
structure
though,
but
you
know
I
wonder
if
people's
thoughts
have
changed
about
how
much
time
we
need.
B
Yeah,
it's
also
like
something
that
we
can
discuss
in
as
part
of
this,
this
github
discussion.
Maybe
we
should
cancel
one
of
the
meetings.
I'm
not
sure
this
is
what
we
we
should
do,
but
again
I
I
we
can
open
it
here.
I
mean
it
looks
like
people
want
to
talk
about
it
here.
A
All
right,
so
no
more
questions
about
that
pausing,
asset
packages.
F
F
The
motivation
behind
this
is
that
there's
been
a
a
bunch
of
use.
Cases
related
to
caching,
including,
like
I,
created
a
writable
asset,
cache
rfc
that
is
still
in
draft
sam,
has
the
shared
layers
rfc,
and
we
have
this
asset
packages
rfc
that
we've
already
approved.
I
think
each
one
of
these
rfcs
introduces
some
amount
of
complexity
and
they're
all
solving
slightly
different,
but
very
related
problems
in
in
different
ways,
and
I
think
there's
a
feeling
from
all
of
these
discussions
that
we
have.
F
D
D
Yeah
I
mean
I,
I
think
it's
a
good
thought,
along
with
all
the
cash
and
stuff
I
do
think.
Asset
packaging
is
slightly
different
in
the
nuance
that
it
is
like
pre-work.
That
is
done
ahead
of
time,
whereas
I
feel
like
are
the
other
two
proposals
from
that
have
come
in
from
you
and
sam
happen
during
build,
even
though,
like
you
said,
they're
all
related
to
caching
and
kind
of
reducing
build
time.
I
think.
E
D
E
F
I
think
the
big
difference
is
so
right
now
we
say
a
build
pack
is
a
single
layer,
so
you
include
your
vendor
assets
in
the
layer
in
your
buildback
layer,
and
this
would
be
about
creating
a
schema
for
assets
to
have
their
own
layer,
which
allows
for
some
deduplication
on
the
registry
and
some
efficiencies
there.
So
if
you
have
many
versions
of
a
build
pack,
but
they
all
share
one
large
asset,
the
registry
can
dedupe
that
blob
and
well.
I
do
eventually
want
to
get
that
efficiency.
F
E
E
F
D
F
But
I
can't
speak
for
everyone's
priorities,
and
the
reason
I
feel
like
it's
high
is
because
the
users
I
interact
with
complain
a
lot
about
it.
A
To
me,
it's
one
of
those
things
where
we're
trying
to
reduce
complexity.
Before
we
say
the
something
is
100
whatever.
That
thing
is,
and
you
know
some
of
that
stuff
is
removing
terms.
Some
of
that
stuff
is
more.
A
D
Horizon
it
like.
B
D
I
I
just
remember
how
long
we
put
kind
of
daniel
through
kind
of
the
ringer
for
asset
packaging.
I
feel.
D
Rfc
was
like
months
long
to
kind
of
put
this
stuff
through,
but
we.
D
This
renaissance
of
basically
revoking
many
rpcs
that
we've
kind
of
been
putting
through
the
ringer
so.
F
C
For
this
just
give
stephen's
rfc
some
time
I
think
it'll
I
mean
I
think,
look
at
the
comments
on
some
of
those.
I
don't
think
they're
a
hole
in
one
right
so,
like
I
don't.
F
F
F
C
A
Well,
something
I
hear
a
lot
is:
there's
a
lot
of
terms,
they're
very
confusing.
It's
really
hard
to
understand
how
you
know
it's
like
it's
actually
not
hard
to
make
a
build
pack,
but
there's
this
large
amount
of
context-
and
you
know
in
some
ways,
complexity.
You
have
to
understand
kind
of
as
a
prerequisite
to
feeling
comfortable,
writing,
pullback
or
kind
of
understanding
the
project,
and
so
that's
made
me
feel
really
nervous
about
adding
more
things
before
we
look
at
each
of
those
things
where
people
have
said.
A
C
A
Right,
the.
B
A
C
C
It's
like
sometimes
the
complexity
that
we
take
on
like
things
that
are
you
know,
this
is
sort
of
against
some
of
the
proposals
but
like
taking
on
complexity
in
the
life
cycle
might
mean
that
people
don't
have
to
learn
about
pre
and
post
build
packs
in
the
builder
right
like
if
we
we
may
like
we're
able
to
make
decisions
where
it's
like
yeah.
This
is
a
lot
harder
for
us
to
support
and
maintain,
but
the
end
result
is
like
less
complexity
outward
facing.
So
that's
why
I
think
it's
yeah.
A
A
Where
you
really
need
to
know
about
it,
you
know
in
just
certain
cases
right
then,
I'm
you
know
I
I
don't
have
a
problem
with
it,
adding
that,
but
a
lot
of
the
places
where
you
have
complexity
right
now
are
as
a
build
pack
author,
you
need
to
maybe
know
about
like
four
types
of
caching,
soon,
five
types
of
caching,
you
know
if
we
keep
going
on
that
track.
As
a
stackpack
author,
you
need
to
know
about
seven
different
contexts
where
your
stackpack
can
execute
and
a
different
api
for
the
rules.
A
For
what
you
know,
stackpack
is
supposed
to
do.
You
know
like
when
that
proposal.
I
just
I
feel
like
it's.
It
hasn't
been
the
case
that
we've
added
features
or
like
the
features.
Sorry,
the
features,
we've
added
that
hide
complexity,
not
that
you
know
adequately
are
not
the
features
I'm
great
about
right
now.
C
That's
fair,
but
in
that
case
there's
an
existing
from
builder
thing
and
like
so
it's
not
like,
but
there
is
a
thing
and
that
the
purpose
of
that
proposal
was
to
address
user
feedback
stuff,
that's
in
google's
and
in
sana's
docs
right.
So
just
I
I
do
think
like
it's
sort
of
a
good
example,
but
it's
also
a
little
bit
different
in
that
it's
addressing
something
that
exists
and
trying
to
actually
reduce
the
complexity
and
formalize
it
yeah.
D
I
yeah
I
mean
you:
could
you
can
make
that?
I
think
a
similar
organ
about
acid
packaging
too
right,
like
the
cattle,
is
right
doing
it
in
the
wild,
and
so
people
have
had
to
take
on
the
complexity
figuring
out
how
to
do
this
for
standardizing
it.
I
feel
like
in
the
past,
we've
also
talked
about
progressive
complexity
of
like
yes,
there
may
be
x
ways
to
do
caching,
but
when
you're
running
bill
packs,
you
don't
need
to
learn
all
all.
D
Them
to
get
a
bill
pack
working,
and
so
I
wonder,
there's
there's
that
mean
truth
to
all
things.
People
said,
but
I
wonder,
is
it
just?
We
are
forcing
people
to
have
to
learn
all
these
things
to
do
it.
Even
even
though
we
we
say
that
we
want
to
have
progressive
complexity
like
like
packaging.
D
Is
a
complex
problem
and
building
abstractions
around
it
to
do
the
things
we
want
is
complex
right,
so
there
is
going
to
be
this
level
complexion.
How
do
we
hit
that
right
balance,
I
guess
of
giving
people
enough
power,
but
also
having
the
right
abstractions,
but
also
not
forcing
them
to
have
to
rebuild
everything
from
scratch?
F
C
C
I
don't
yeah,
I
I
don't
know
what
to
suggest
but
to
table
this
or
finalize
it
or
whatever.
D
C
I'm
not
sure
who
added
this
but
I'll
start
talking
about
it,
because
I
do
have
concerns.
So
we
have
we've
done
rfcs
for
the
the
changes
to
project
descriptor
that
are
going
into
zero
two,
and
I
think,
from
you
know,
from
my
side
eager
to
get
those
implemented
like
I
have
for
inline
build
packs.
I
have
a
pr
that's,
I
think,
like
two
almost
three
months
old
now
and
it's
something
that
you
know
solves
real
problems.
C
I
know
the
changes
to
the
name.
Space
are
important
to
some
folks,
so
you
know
I'd
like
to
figure
out
what,
whether
we're
going
to
ship,
2.,
0.2
or
or
what.
D
Yeah,
I
know
in
I
don't
know
what
forms
you've
brought
this
up
emily,
but
you
mentioned
concerns
about
migration
and
support
within.
D
I
guess,
like
platform
operators
having
to
support
multiple
project
descriptors,
despite
it
being
an
extension
and
something
about
a
tamil
tamil
utility.
So
I
just
kind
of
wanted
to
get
this
out
of.
I
think
that's
coming
from
leadership,
but
like
something
more
transparent
and
open
and
more
in
the
public,
but
also
just
to
have
a
path
forward
in
a
potential
path,
to
a
plan
of
record
that
we
can
move
forward.
F
C
D
C
C
Hold
pull
that
out
yeah
we
could
yeah,
we
could
pull
pre-post
out,
that's
fine
and
that
wouldn't
we
could
introduce
that
in
another
version.
That's
not
great.
You
know
it
doesn't
break
anything
necessarily.
F
B
F
How
users
can
expect
project
tunnel
to
affect
different
platforms
right
and
how
we'd
like
to
implement
this
in
a
sustainable
way?.
F
Okay
sure,
my
big
concern
here
in
some
ways
is
like
so
we're
about
to
release
this
big
breaking
spec
change
and
like
pack
will
be
prepared
to
handle
both
formats,
but
there
are
older
platforms
so
like
if
an
app
updates
their
project
demo,
like
the
support
that
was
added
in
kpac
for
project
tunnels.
All
of
a
sudden,
it's
going
to
break
stuff
like
that.
D
Well,
there's
basically
like
if,
when,
when
this
releases
out
there'll
be
potentially
two
versions
so
like
kpac
will
continue
to
support
point
one.
That
already
is
out
right.
So
it's
more
about.
F
F
F
C
Is
it
just
that
kpak
should
not
be
doing
this,
like,
I
feel
like
the
the
spec,
the
spec
is
a
spec,
it
has
been
the
spec
and
it
exists
because
pac
users
needed
these
things
and
I
feel
like
what
what
we're
stuck
up
against
is
kpak
wants
to
do
this
weird
thing,
which
is
like
support.
Half
of
it,
and
now
like
I
just
feel
like
it-
should
just
have
a
different
thing
like
like.
B
F
C
Well,
that
yeah
and
that's
why
I've
wanted
to
either
push
it
out
into
its
own.
Like
library
like
like
the
image
util
or
something
like
that,
and
even
potentially
the
prepare
phase
you
know,
could
parse
it
turn
it
into
some
intermediate
form
intermediate
format
where
the
life
cycle
could
read
that
instead,
but
I
would
I
wouldn't
say
it's
just
pac
right,
like
pac,
has
become
the
foundation
for
many
platforms,
including
our
jenkins
integration
circle.
Ci,
I
forget
the
other
one
I
was
going
to
go
to
was
but
like.
F
A
C
A
I
think
I
I
at
least
agree
with
the
need
for
a
project
descriptor
that
covers
almost
all
of
these
things.
I
would
like
it
to
be
more
portable
across
or
like
very
portable
across
everything
that
supports
build
packs,
but
there
are
a
lot
of
details
that
I'm
worried
about.
If
that
makes
sense
so
like,
I
think
I
think
people
are
pretty
aligned,
it's
just
a.
F
F
Yeah,
I
guess
the
reason
I
don't
tend
to
think
it's
specific
to
k-pac
sometimes,
is
because
we're
trying
really
hard
to
do
everything
in
the
spec
in
a
super
generic
way
on
kids,
I
feel,
like
many
of
these
limitations
are
also
hard
on
other
platforms,
like
other
kids-based
platforms,
or
even
in
a
like
half
kids-based
platform
like
tecton.
D
B
C
Yeah
I'd
like
to
I
mean
I'd
like
to
push
this
forward.
I
mean,
like
I
said:
I've
got
a
pr.
That's
three
months
old
this
all
the
rfcs
were
resolved
like
it's
kind
of
frustrating
that
we're
just
sitting
on
it
because
we're
uncomfortable
or
something
like.
We
should
try
and
move
this
forward.