►
From YouTube: Working Group: July 25th 2023
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
Let's
start
with
decoupled
dependencies
from
the
bill
pack
start
from
the
bottom
work.
Our
way
out.
C
Yeah,
it's
like,
like
all
these
suggestions
as
meet
us.
That
GitHub
feature
is
just
get
confusing
if
they
just
file
up
so
I
kind
of
condensed.
Some
of
the
suggestions
I
had
and
and
and
and
worked
some
some
other
things
in
and
I.
Think
Daniel
has
already
responded
and
there
was
some
back
and
forth
yeah.
A
I
I
saw
that
I
I
I
saw
this
right
before
I
went
on
lunch
said:
oh
I'll,
look
at
this
right
after
the
working
group
meeting
and
I
came
back
to
already
a
multi
multi
reply
thread.
So
I
will
click
into
this.
C
It's
like
I,
just
tried
to
condense
a
little
better
and
a
little
more
concrete.
My
what
I
think
already
have
said
right.
It
feels
pretty
pretty
concrete.
I,
don't
agree
to
all
the
definitions
and
I
actually
don't
see
why
we
actually
do
this
up
front
because
it's
like
we
have
all
the
pieces
in
our
hands
right.
We
will
develop
a
tool
that
creates
dependency
packages
of
meter
data
and
we
have
the
libraries
that
will
consume
them.
C
So
I
think
we
have
all
the
freedom
to
just
discover,
discover
this
and
see
what's
needed,
but
I
tried
to
get
a
little
more
concrete,
then
also
on
the
on
the
discussion
threat
with
with
Daniel,
with
some
concrete
things
where
I,
where
I
tend
to
see
it
kind
of
differently.
I'd
start
with.
Basically,
it
should
be
simple
to
use,
so
I'd
prefer
a
format
that
allows
somebody
who
wants
to
add
just
a
single
dependency.
A
This
meeting,
no
and
for
sure,
especially
because
I,
have
not
gotten
the
chance
to
to
to
like
dig
into
this
back
and
forth
and
then
just
make
sure
that
I've
reviewed
the
suggestions.
That's
my
plan
to
this
afternoon
get
dug
into
it
all
right.
In
that
case,
then
I
will
I
will
do
that
and
I
will
contribute
to
this,
and
we
can
either
start
a
more.
A
C
A
I
think
there
was
some
discussion
happening,
I
think
it's
probably
still
happening,
so
we're
I
think
that
this
is
still
something
that
we
want
and
I
think
Jericho's
working
on
it
when
he
finds
time.
C
Out
of
curiosity,
like
I,
mean
now,
Jericho
is
not
there,
who
might
be
the
best
to
give
an
answer.
Does
somebody
have
a
have
an
overview
whether
this,
together
with
this
pack,
manifest
stuff?
That's
going
on
in
the
CNB
spec
will
really
deliver
a
similar
experience
than
than
Docker
build
and
just
create
multi
multi-archive
images
that
behave
the
same
I'd
be
interested
to
to
to
know
if
that
is
really
all
it's
going
to
take
some
time
probably,
but
if
that
is
really
all
of
this
meh
more
to
do
to
really
Proclaim
support
from
RDR.
A
C
A
A
Okay,
if
there's
nothing
new
on
this
right
now,
then
I
can't
see
any
reason
to
keep
doing
this
and
then
finally,
we
have
a
new
RFC.
It's
proposal
to
introduce
new
grovel
VM,
build
pack.
A
A
I
think
that
sounds
about
right.
I
think
the
only
thing
hold
on
oh,
never
mind,
I.
Think
then.
The
only
thing
that
this
would
need
is
the
CLA
signing
and
approvals
from
java
maintainers.
C
A
I
see
it
under
text
Java
hello,
but
let
me
run
sec.
A
So
I
think
that
everything's
all
set
up
for
this
to
I
don't
know
that.
To
be
honest,
this
working
group
ever
needs
to
talk
about
this.
Unless
there's
call
for
discussion
on
it,
I
think
it'll
go
through
the
Java
maintainer
channels.
A
Okay,
next
up,
then,
we
have
c
p
updates
I,
don't
think
that
I
have
any
major
CNB
updates,
that's
not
in
mind.
A
Okay,
are
there
any
major
project
updates.
E
E
I
was
wondering
how
the
Ubi
work
is
going.
I
was
kind
of
involved
a
little
bit
in
the
stack
creation
and
I
haven't
been
keeping
up
to
date
since
then.
So
it's
just
looking
for
an
update.
B
B
As
of
a
few
days
ago,
when
I
last
checked,
the
status
was
we've
gotten
the
base
stock
that
the
stock
was
there,
we're
working
on
the
the
bowling
mechanism
for
how
the
stocks
will
be
updated.
That's
what
cost
us
is
currently
working
on.
It's
going
to
look
different
in
that,
instead
of
looking
for
the
usns,
which
is
I.
B
Think
in
the
deputy
kind
of
thing,
it's
going
to
look
for
like
updates
to
the
Ubi
containers,
because,
basically,
when
there's
updates
to
be
had
there'll,
be
a
new
container,
so
then
we'll
we'll
figure
a
build
of
the
stock
we'd
managed
to
get
and
thanks
to
help
her
Force
to
get
the
build
pack
list
Builder
landed.
B
Unfortunately,
the
automation
then
immediately
reverted
the
the
life
cycle,
which
is
why
I
think
there's
last
time
a
little
bit
of
discussion
about.
It
would
be
great
if
there
was
a
published
life
cycle
17
because
it
revert
it.
Basically,
updates
it
to
the
last
published
version,
as
opposed
to
the
last
version,
and
so
it
went
back
so
as
soon
as
that
gets
published,
that
that
will
be
resolved,
that
that
didn't.
B
The
integration
testing
on
the
Ubi
extension
itself,
which
is
good
I,
think
I
saw
a
notification
that
somebody
had
reviewed
and
there
were
some
comments
and
cost
us
was
going
to
update
so
that
that's
good
the
Builder,
which
would
have
the
node
extension
I
think
that
one
might
been
you
know
people
might
have
been
waiting
until
we
resolved
the
life
cycle
issue
because
it'll
apply
similarly
to
the
one
on
the
build
pack
lists
side
of
things.
B
Otherwise,
you
know
a
number
of
the
PRS
I
posted
were
related
to
moving
functionality
into
libno.js,
so
that
we
can
have
one
poppy.
That's
used
by
the
the
the
the
extension
and
the
other
build
packs
and
I
guess.
The
other
significant
PR
that
I
opened
was
to
integrate
basically
reuse.
More
of
the
existing
node
build
path.
We
we
discovered
in
the
integration
test,
which
is
one
of
the
great
things.
B
Is
we
added
those
integration
tests
we
weren't
providing
the
functionality
with
the
environment
variables,
so
there's
a
fairly
simple
change
to
the
existing
build
pack,
where
you
know,
instead
of
just
saying,
hey,
we're
going
to
do
nothing,
we
do
nothing
except
for
the
part
that
has
the
build
packs
and
that
reuse.
It
can
then
reuse
the
like.
B
It's
not
just
the
code
in
that
in
that,
like
the
the
build
phase,
but
it's
also
code
in
like
there's
some
extra
files,
folding
and
stuff
like
that
to
add
into
the
layers
and
all
that
and
that
lets
us
pass
all
of
the
integration
tests
that
we
saw
on
the
Node
engine
itself.
So
I'd
open
that
up
and-
and
you
know,
I
think
there
was
some
discussion.
I
believe
Victoria
had
taken
a
look
at
it
was
kind
of
like.
Are
we
comfortable
doing
that?
B
Or
do
we
want
to
have
a
separate
build
pack
and
so
I
I
haven't
had
I
haven't
seen
if
there's
been
any
more
discussion
kind
of
like
on
on
how
people
feel
about
that?
The
it's?
The
simplest
way
to
reuse
the
most
is
to
have
one
but
I
can't
understand
the
the
sort
of
potential
concerns.
A
On
our
part,
Rob
and
I
did
take
a
look
at
the
full
sort
of
UPI
base.
Builder
I
can't
use
the
word
full
there,
because
that's
an
overloaded
word,
but
the
one
with
the
extensions,
the
biggest
problem
that
I'm
running
into
is
that
it's
all
just
still
so
Cutting
Edge
for
CMB
that,
like
I,
can't
get
a
pack
build
to
work
because
I'm
being
told
that
extension
usage
for
Builders
is
an
experimental
feature
and
embarrassingly
I
must
admit.
A
I
actually
don't
know
how
to
enable
the
experimental
operations
in
pack
I
I
spent
a
little
time
Googling
and
like
looking
around
and
I
couldn't
figure
it
out.
To
be
perfectly
honest,
so
I
couldn't
verify
that
the
Builder
was
actually
functioning.
The
way
that
we
wanted
to
do
through
the
smoke
tests.
B
B
A
If,
if,
if
that's
the
case,
I
I
would
just
need
that
and
then
I
could
verify
that
that's
the
case.
We
would
have
to
then
modify
some
scripts
a
little
bit
here
and
there
and
I'm
I'm
not
sure
like
I,
I,
guess
I
at
that
point.
I'm,
like
I
kind
of,
would
want
to
like
wait
for
the
life
cycle
17
to
be
out
so
that
we're
at
least
like,
even
if
we
are
like
shifting
like
how
we
build
this,
we're
at
least
reliably
getting
updates
out
of
this
I
figure.
A
You
can't
really
do
that
much
harm
with
a
build
pack
list
Builder,
but
like
with
an
actual
Builder
Builder.
People
might
think
that
we
are
actually
starting
to
support
this
in
a
capacity
that
we
are
not
sort
of
up
and
running
with.
Yet.
B
Right
and
I
guess
it
makes
sense
to
build
pack
plus
one
works
because
it
doesn't
have
the
doesn't
have
the
extension
built
into
it.
But
yeah
we'll
need
that
expert
and
thanks
Jen
for
pasting
that
in
there
yes,
basically
like
that
back
config
experimental
just
needs
to
be
added,
and
we
must
do
that
in
our
integration
tester
in
some
of
the
stuff
that
we
do
in
the
extension
testing.
D
It
just
works
for
you,
because
it's
a
print
machine
setting,
first,
not
to
kind
of
take
as
often
to
a
too
much
of
a
debate,
but
I
think
it's
probably
fine
to
have
experimental
features
in
the
like
clearly
marked
experimental
Ubi
extension
in
the
piketa
community
and
I
would
argue
that
it's
probably
even
beneficial
to
do
that,
because
the
CNB
folks
are
looking
for
feedback
on
experimental
features
in
general
right
like
by
the
way
they
go
from
experimental
to
full
is
by
like
getting
feedback,
and
you
know
having
a
concrete
example
that
you
can
point
to
in
the
open
source.
D
That's
clearly
marked
as
like
experimental
for
now
I
think
that's
fine
I
wouldn't
have
any
worries
about
like
putting
in
the
experimental
true
in
CI
for
some
stuff
like
this.
Oh.
A
Well,
if
that's
the
case,
then
by
all
means
I
like
I'm
not
going
to
I'm,
not
gonna
block
that
then
I
I
I
do
not
have
strongly
held
opinions
on
that
I
was
just
like
I
I
was
I,
was
trying
to
sort
of
figure
out
my
way
around
it
and
I
was
like
I'm
I'm
a
little
I'm
a
little
I'm
a
little
gun
shy
on
this
because
I
don't
quite
know
how
this
all
works,
but
if
I
can
get
it
to,
if
I
can
get
a
set
of
smoke
tests
running
locally
for
me,
then
that's
what
I
will
be
happy
with
so
I
will
try
and
get
that
done.
A
I
don't
know
later
today,
I
think
rob
you
had
a
couple
of
just
structural
things
that
you
wanted
to
look
at,
so
those
are
probably
more
worth
your
time
than
my
hey.
My
pack
experimental
doesn't
work
and
I.
Don't
know
how
that
works,
because
I
now
know
how
that
works.
So
we're
we're
getting
there.
D
Yeah
cost
us
addressed
most
of
my
comments
like
structural
comments
about
the
pr
for
the
Ubi
extension
I.
Didn't
I
didn't
do
I
didn't
run
them
so
as
far
as
run
them-
and
you
know
I'm
just
looking
at
the
kind
of
like
code
side
of
things,
I
think
it's
fine
I
mean
it's.
Also,
like
you
know,
it's
like
a
community
feature.
D
It's
experimental
to
start
with,
like
I,
think
it's
fine
to
kind
of
like
iterate
away
through
it
like
there's
a
lot
of
like
like
coupling
and
dependencies
and
ordering
so
it's
going
to
be
a
bit
gross
for
a
while,
but
I
think
we
need
to
like
put
the
pieces
in
place
and
eventually
we
can
like
chip
away
at
it.
So,
like
we'll,
probably
end
up
committing
comment
about
smoke
tests
until
the
node.js
book
actually
works
and
then
we'll
uncomment
the
smoke
tests,
but
I
don't
think
we
should
leave
every
PR
open
right
like
it's.
A
I
I'm
I'm
I'm,
ready
to
I'm,
ready
to
close
it
and
like
get
something
out
there.
I
just
wanted
something
that
wasn't
gonna
have
to
be
like.
Like
every
two
days
you
know,
Michael,
you
have
to
put
in
a
PR
that
you.
C
Yeah
to
Upstream,
were
you
able
to
provide
some
I
I
realized
that,
in
the
middle
of
of
doing
you
realize
that
there's
kind
of
a
disparate
set
of
features
between
build
tags
and
extensions
where
you
realized?
Oh,
we
just
need
also
a
build
pack
for
it.
Maybe
that's
actually
worth
pushing
back
Upstream
if
extensions
should
just
be
allowed
to
do
something
in
addition
to
what
build
packs
can
do,
but
still
also
act
as
a
build
pack.
That
could
be
a
tremendous
change
for
Upstream,
so
maybe
that
would
be
worth
reporting
actually
is.
B
I
think
as
the
it
is
Aussie
would
know
for
sure
he'd
mentioned
that
that
was
something
he
was
going
to
mention
in
terms
of
like.
Maybe
they
should
come
as
a
pair,
because
there
are
some
things,
at
least
with
like
the
switching
of
the
Run
image
we
can't
set
environment
variables
like
all
we
can
do,
is
give
it
a
an
image.
B
We
can't
do
anything
else
and
that's
where,
like
for
the
Java
one
he's,
he
figured
out
that
hey,
we're
always
going
to
have
to
have
two
and
and
for
the
the
node
one
from
the
beginning,
I
tried
to
reuse
the
existing
one
as
much
as
possible,
like
it
already
uses
the
the
common
code
in
the
detect
phase
to
set
up
the
build
plan,
and
so
that's
where,
like
the
pr
I
have
now
also
then
does
the
same
thing
to
say:
well,
we're
going
to
reuse
the
non-node
installation
part
so
just
to
say
like
from
the
note
side,
it
was
like
always
hey
yeah
having
two.
B
These
two
work
together
make
sense,
so
I
think
we
could
find
that.
That
is
the
case,
and
we
can
confirm
with
Aussie
that
he's
actually
proposed
that.
C
E
Well,
thanks
for
the
update,
you
have
a
kind
of
unique
contribution
experience
in
that
year,
contributing
to
builders,
Stacks
extensions,
build
packs.
So
it's
kind
of
interesting
to
hear
how
your
experience
is
going.
Have
you
found
the
feedback
loop
with
maintainers
and
looking
at
documentation
and
stuff
to
be
okay,
or
is
there
anything
that
we
could
be
doing
to
help
you
more.
B
I
guess,
as
always,
would
be
really
nice
if
the
next
day
after
I
submitted
a
few
art
was
reviewed.
I
understand,
that's,
not
realistic,
so
you
know
the
it
is
a
cycle
other
than
that
I
found
it
quite
interesting.
Like
there's,
you
know
you
really
get
to
appreciate
how
much
Automation
and
how
much
is
there
versus
the
you
know,
naively
you
could
say:
hey,
let's
just
build
our
own,
build
packs,
right
and,
and
the
reason
we
didn't
go.
B
That
way
is
like
there's
lots
in
there
that
we
don't
want
to
reinvent
the
wheel
and
I'm
just
learning
the
more
like
there's
more
than
even
I
would
have
imagined
in
terms
of
the
Automation
and
how
these
all
these
things
work
together,
and
so
it's
been
an
interesting
process
to
learn
those
different
things
and
and
like
the
functional
part,
it's
it's
almost
like
there's
not
a
lot
of
functionality,
but
there's
a
ton
of
this
automation
to
keep
the
whole
thing
hanged
together,
which
is
quite
interesting.
B
And-
and
some
of
those
are
like
you
know,
I
don't
know
if
you
could
go,
read
it
somewhere,
but
like
learning
that
the
scripts
are
automatically
copied
from
a
common
set
and
we'll
clobber
your
ones.
It's
like
oh
yeah,
I,
didn't
think
about
that.
So,
like
my
earlier,
PR's
probably
would
have
clobbered
themselves,
but
I
don't
know
like
I'm,
not
sure
if
you
could
write
that
down,
so
that
everybody
would
understand
that
up
front
anyway,
right
because
there's
a
lot
there.
Sometimes
it's
you
really
got
to
just
go
through
the
process
to
learn
it.
D
Yeah
that
conversation
topic
has
come
up
like
periodically
and
it's
an
interesting
one
right.
It's
like
what
do
you
define
as
the
surface
area
of
your
community
product
right
like
we,
you
know
pack
it
as
a
library
we.
We
treat
that
as
like
a
surface
area,
that
anyone
should
be
able
to
take
that
library
and
build
a
packet
style,
build
pack
same
for,
like
you
know,
a
lid
pack,
but
the
CI
I,
don't
know
we
don't
really
think
that
was
a
product
right.
D
D
I
think
just
working
on
this
one
thing
I
would
be
motivated
to
do
once
we
once
adjuster
settled
a
little
bit
on
the
structure
of
the
ebi
stuff
is
I'd
want
to
figure
out
how
much
of
the
changes
to
the
automation
we
can
like
back
upstream
and
Abstract
so
that
you
don't
have
to
maintain
your
own.
Basically
a
fork
of
your
own
of
our
automation,
right
so
like
stuff,
like
the
switching
out
usns
for
ubis
right
I.
Think
that
would
be
something
that
ultimately
should.
D
We
should
be
able
to
go
back
Upstream
so
that
you
can
get
all
the
all
the
other
benefits
of
the
changes
to
CI
right
as
we
fix
bugs
or
improve
performance
or
whatever.
It
would
be
great
to
get
those
automatically
built
out.
But
to
do
that,
we're
gonna
have
to
figure
out
the
abstraction
of
like
ubis
versus
usns,
and
the
same
is
going
to
be
true
for
like
extensions
as
a
concept
right.
We
don't
have
automations
for
extensions,
so
we
have
to
figure
out
like
how
does
that
fit
in
into
the
shared
CI.
B
B
Even
I'll.
Ask
one
question
because,
like
this
is
one
of
the
things
we're
going
to
look
at
next
is
it
looks
like
the
the
immigration
tests
for
each
of
the
build
packs
food
one
on
multiple
stocks
like
so,
for
example,
the
npm
start
build
pack
we'd
like
to
get
to
the
point
where
it
runs
on
Jammy
and
runs
on
the
Ubi
stocks
is
that
is,
that
is,
is
my
intuition
there
that
it
was
designed
at
one
point
to
do
that.
A
A
Oh,
that
might
not
be
true.
I
don't
see,
I,
don't
know
that
I
can
think
I.
Think
of
right
off
the
top
of
my
head.
Why
we
couldn't
run
something
like
gme
UPI,
but
I
also
haven't
thought
about
it
at
all.
So.
B
I
think
there'll
be
a
few
tweaks
like
just
extensions.
It
doesn't
necessarily
know
about
and
then
maybe
saying
like
only
use
this
extension
for
this
stock,
but
those
those
are
the
kind
of
things
anyway,
but
it
sounds
like
the
answer
is
like
it
was
kind
of
set
that
way,
so
we'll
be
trying
to
figure
part
of
that
out
as
we
go
forward
like
right
now,
a
lot
of
things
Costas
is
going
to
look
at
is
actually
just
running
those
all
manually.
B
You
know
with
the
current
integration
tests
in
the
extension
I
think
we've
got
it
to
the
point
where
we've
got
the
same
integration
test
that
you
have
for
the
node
engine,
because
we
used
it
as
the
inspiration
but
there's
a
whole
bunch
of
integration,
pests
which
go
much
further
than
that
in
all
the
other
build
packs.
So
our
next
step
is
to
go
through
and
make
sure
that
all
those
run
successfully
which
I'm
hoping
will,
since
they
just
use
the
same,
build
packs.
B
D
Yeah
just
put
this
in
in
the
chat,
but
just
to
kind
of,
like
add,
more
evidence
or
ammunition
to
this
topic.
The
Jericho
from
rapid7
like
submitted
a
bunch
of
PR's
to
the
python,
build
packs
just
and
I
think
to
some
of
the
go
ones
to
support
running
on
the
custom
stack
right
that
he
created,
and
so
the
abstraction
should
just
work
right
like
right
in
terms
of
like
a
build
pack
being
tested
against
a
builder,
not
a
stackable
Builder
right.
That's
that's
just
the
interface
that
they
run
on,
like
once.
D
You
have
a
builder
for
the
Ubi
build
pack
list
yeah.
You
can
just
add
it
to
the
line
in
the
yeah
LinkedIn
this
in
the
chat
to
the
example
for
C
python,
but
the
same
would
be
true
for
npm,
star
or
anything
like
any
other
build
pack
just
add
a
line,
and
the
script
will
pretty
much
just
pick
it
up
and
run
it
and
the
automation
once
it's
all.
D
D
A
A
Yeah
you
have
you'd
have
to
get
a
different
order,
dependent
on
what
Builder
you're
running,
but
you
can
also
just
like
you-
can
identify
the
build
it's
it's
it's
it's
a
string
passed
in
at
some
point,
so
you'd
be
able
to
identify
that
at
the
beginning,.
D
Yeah
and
we
have
evidence-
oh,
we
have
examples
of
doing
that
as
well,
or
at
least
we
used
to
before
we
stopped
supporting
bionic
because
we
had
like
we
wouldn't
some
of
the
tests
would
would
have
would
would
test
the
upgrade
right,
so
they
would
say
like.
Oh,
if
I'm
on
a
bionic
Builder
skip
this
test
and
then,
if
I'm
on
a
Jammy
builder,
then
I'm
going
to
go
and
run
the
the
whole
test,
like
you
know,
Deploy
on
bionic
and
then
upgrade
to
Jammy.
D
E
B
A
Great
in
that
case,
I
think
we
can
call
it.