►
From YouTube: Working Group: May 2, 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
A
Nope:
okay:
let's
hop
right
into
the
large
agenda
item
for
today,
which
is
of
course
going
over
the
roadmap
with
the
two
rfcs
that
are
currently
open
right
now
we
kind
of
have
some
Quantum
roadmap
items
because
the
issues
for
them
haven't
been
generated.
Yet,
but
let's
talk
about
what
we
have
right
now
and
then
I
guess
we
can
talk
about
those
when
we
get
into
outstanding
RCs.
A
First
things:
first,
let's
start
with
status,
needs
investigation,
create
static,
Jamie,
build
pack,
build
pack
list
Builders.
If
I
recall
correctly.
Last
month,
we
were
waffling
about
whether
or
not
this
was
even
important
anymore
and
then
48
hours
after
we
had
that
meeting.
We
had
someone
contact
us
saying
that
it
was
very
important
to
them
and
that
we
should
create
this
Builder.
So
we
spun
all
of
that
up
and
it
exists.
A
Now
you
can
create
static
images
using
rust,
I
believe
reliably,
I
think
that
there's
probably
ways
to
do
it
with
go,
although
we
have
not
done
a
full
deep
dive
investigation
with
it.
Yet
so
I
want
to
put
this
in
the
done
column,
because
I
think
it's
done.
A
Next
up,
we
have
default
behavior
for
build
Pack
set
language
Enviro-
oh
my
goodness,
sorry
behavior
for
build
Pack
set
language
ecosystem
environment
variables
as
a
mouthful.
I
apologize
I
think
that
this
is
just
a
case
of
us
needing
to
go
back
through
I
honestly
just
need
to
put
a
message
on
here:
pinging,
basically,
every
maintainer
group,
or
probably
more
accurately.net,
yarn,
dot,
net
and
node.js
and
Ruby,
and
ask
for
these
to
be
checked.
I
think
that
some
of
these
have
changed.
A
I
know
that
dot
net
has
and
I
should
probably
go
through
and
just
investigate
this,
but
I
think
this
is
just
a
case
of
us
trying
to
close
the
last
two
out
and
then
this
will
be
done.
I'll
take
that
on
as
an
action
item
right
after
this
meeting
to
go
through
and
paying
relevant
parties.
A
Next
up,
we
have
distribute
Bill
packs
via
Docker
hub,
oh
okay.
Once
again,
this
is
done.
It's
a
matter
of
documentation.
At
this
point.
C
A
That's
pretty
much
it
I
guess
this
is
a
call
out
for
all
maintainers
that
are
currently
in
this
meeting.
I
would
love
if
you
could
go
and
check
this
out,
although
it
might
make
more
sense
to
open
some
high
level
issues
in
the
various
Bill
pack.
Language
families,
as
well
as
the
website,
so
I
can
take
that
on
to
do
as
well.
A
Okay,
we
have
support
for
yarn
Berry.
A
D
Yeah
I've
pushed
up
some
comments
in
recently.
Folks
want
to
try
that
out
or
there's
not
much
more
than
that
to
report.
A
We
can
just
go
for
each
one
of
these
quickly
and
talk
about
them,
I
assume
if
they're
planned
and
anyone
works
on
them,
we'll
move
them
to
in
progress.
So
I'll
just
see.
If
anyone
has
done
any
more
work
on
these
and
if
not,
then
we
can
move
on
reliable
process
types
looks
like
Ruby.
Is
the
last
outstanding
one
to
get
done?
Is
there
any
progress
on
that.
A
A
A
On
that
auto-generated
reference,
documentation,
I
think
Ryan
before
going
on
right
to
leave
sort
of
laid
out.
The
first
example
for
what
adding
configurations
like
excuse
me
hold
on
environment,
variable
configurations
in
I
think
npm
install
Tim.
If
that
yeah
that's
correct,
what
that
would
look
like
for
a
packet
supported
or
packet
build
packs,
so
I
would
encourage
people
to
go.
Take
a
look
at
the
structures
set
up
there
and
see
what
could
be
done.
A
Define,
an
image
dependency
retention
policy,
I
pinged
Dan
about
this
last
time,
I'll
ping
him
again
about
it.
This
is
waiting
on
an
actual
sort
of
comprehensive.
A
I
guess
assay
of
our
image
repositories
to
be
done.
A
A
Oh
wait
and
I
think
that
we
have
wrapped
around
and
we
are
at
the
end
of
the
road
map.
Is
there
anything
that
people
want
to
talk
about
or
call
out
here.
A
A
B
E
A
This
is
a
proposal
to
remove
YJ
from
the
binary
stack
or
binary
from
the
stacks.
Excuse
me
I
see
that
there
was
a
comment
from
you
Rob
yesterday.
F
Was
responding
to
you
virus,
so
I
think
this
I
think
so
people
put
a
question
to
a
community
member
just
at
the
top
of
your
screen.
Someone
did.
D
F
They
were
using,
or
they
mentioned
in
passing
they
were
using
YJ
because
it
wasn't
working
for
them.
So
it
might
be
pretty
a
little
bit
of
time
just
to
give
that
Community
member
an
opportunity
to
respond,
but
hopefully
down
I,
think
we
can
just
move
forward
with
the
RFC
assuming
there's
no
other
objections.
I
think
we
are
still
collectively
coming
to
your
consensus
on
whether
it
makes
sense
to.
F
Or
just
like,
do
the
extra
work
to
support
it
and
all
Stacks,
but
I
think
all
architectures,
sorry
I
should
say,
but
I
think
I
think
it
makes
sense
to
remove
it
like
none
of
the
potato,
Bill
packs
use
it.
Maybe
a
community
build
pack
like
a
girl
plan
or
something
might
use
it,
but
like
I,
think
we
should
just
put
it
where
it's
used
rather
than
build
it
in
the
stacks.
A
F
Awesome,
it's
easy!
It's
easy
for
me
to
say
yes,
because
I'm,
not
the
one
that
has
to
maintain
such
a
build
pack
right,
like
yeah
I,
think
maybe
less
facetiously,
if
you,
if
you
want
to
propose
that
show,
but
it
probably
would
be
worth
like
spinning
into
a
separate
Roc,
because
the
utilities
maintainers
would
likely
be
the
ones
that
would
maintain
that
and
they
are
not
the
same
as
the
Snapchat
maintainers.
A
I
think
that
that's
fair
I
also
don't
know
how
hard
it
would
be
to
maintain
that
in
a
sane
way.
I
might
take
a
look
at
proposing
that,
just
at
that,
at
that
point
it
it
kind
of
covers
all
of
our
bases,
because
we
have
something
that's
compatible
going
forward.
E
A
Oh
yeah,
that's
actually
I
hadn't,
even
thought
about
doing
an
extension.
I
think
I
I
think
that
I
don't
know
that
it's
an
apt
YJ
is
an
apt,
getable
binary,
but
I
mean
I
assume
we
can
install
any
binaries
or
an
extension
as
long
as
it
can
be
built
out
through
a
dock
file.
That's
a
good
call.
I
hadn't
even
thought
about
that.
A
In
that
case,
then,
if,
if
we
do
want
some
feedback
from
that
Community
member
I
I,
don't
actually
know
the
best
I,
don't
know
the
best
GitHub
courtesy
if
it
is
just
to
at
them
and
say
hey,
we
saw
that
you
had
a
problem
with
this.
Could
you
take
a
look.
A
A
All
right
in
that
case,
then
I'll
move
on
from
this.
Next
up,
we
have
D
couple
dependencies
from
build
packs.
This
is
my
Behemoth
RFC.
A
It's
kind
of
hard
I
have
to
cycle
through
here
a
lot
and
try
and
pick
things
up
so
I'm
trying
to
stay
on
top
of
it
and
if
I
have
not
gotten
back
to
your
discussion
question
yet
I'm
trying
to
I
promise.
B
I
had
a
quick
question.
Apologies
if
you
said
this
before
is
the
I
saw
that
you
also
put
up
an
exploration
in
a
separate
repository.
I
was
wondering
if
that
exploration
is
like
functional,
something
that
we
could
play
around
with,
because
this
rfc's,
like
really
it,
has
a
lot
of
information.
It's
kind
of
hard
for
me
to
conceptualize,
so
I'd
love
to
be
able
to
like
play
around
something
and
I
was
just
wondering
like
what
the
state
of
that
exploration
is.
A
Yeah,
so
this
exploration
or
the
exploration
that
I
did
was
mainly
to
prove
out
the
actual
functionality
of
each
of
these
proposed
methods
is
dependency,
assets.
A
This
one
to
prove
out
at
least
these
three
methods
of
actually
sort
of
like
injecting
the
metadata
and
making
sure
that
it
could
practically
be
done,
and
so
yeah
there's
some
variations
of
showing,
like
externally
mounting
this
data,
doing
it
via
build
pack
and
doing
it
during
us
via
a
stack
extension
in
a
builder.
A
That's
really
the
the
section
that
it
tackles
it's
just
sort
of
trying
to
ensure
that
the
actual
practical
application
of
this
is
sound
but
yeah.
All
of
these
are
they
work.
The
only
one
that
I
would
call
out
is,
if
you
do
want
to
play
with
the
stack
extension
via
Builder,
it
uses
a
build
environment
spec
that
is
only
in
platform,
API
only
available
platform,
API
versions,
0.11
and
up
and
the
pack
as
of
when
I
was
doing
this
pack.
A
A
G
A
For
you,
it's
not
going
anywhere
right
away,
so
I
think
you'll
have
plenty
of
time.
A
This
was
this:
is
the
multi-tech
a
multi-architectural
build
pack
builds
RFC
that
you
mentioned,
that
you
were
going
to
be
opening.
This
is
a
good
read.
C
Yeah
I
had
a
question
actually
about
this,
so
there's
a
lot
of
good
discussion
and
then
I
assume
at
some
point
once
all
the
discussion
is
over
we'll
kind
of
take
the
key
okay
takeaways
and
like
put
them
into
this
text.
So
it's
like
official
before
it
gets
committed,
okay,
cool
and
is
that
something
that
I'm
going
to
be
doing
or
will
other
people
commit
to
this
Branch
like?
How
does
that
usually
work.
C
Okay
sounds
good.
The
other
thing
is
I
have
a
repo
that
I
created
to
kind
of
like
play
around
with
multi-arch
Builders
I
plan
to
do
some
of
this
with
the
build
pack.
So
we
can
kind
of
like
have
some
concrete
examples,
rather
than
kind
of
like
live
in
the
world
of
theory.
C
A
D
H
Yeah
I
don't
know
if
if
it
has
been
mentioned
but
I
remember
that
you
had
some
questions
about
how
to
build
for
arm64
and
actually
for
us.
You,
you
told
us
recently
that
we
had
some.
H
We
had
some
usage
of
a
beerjet
already
authorized
in
the
packet
to
build
pack
organization.
Actually,
I
already
tried
that
out
and
yes,
we
do
provide
the
m64
builders,
so
maybe
we
see
something
Worth
Main
training.
H
H
Yeah
I
have
a
good
question:
it's
just
some
kind
of
well,
no
just
to
make
sure,
because
I
can't
remember
so.
Basically,
the
idea
of
this
RFC
is
to
publish
build
packs
into
into
different
Arch.
To
do
that.
There
are
some
tools
that
exist,
such
as
Docker,
manifest
and
I.
H
Think
it's
mentioned
in
this
RFC
I
was
just
wondering
if
if
people
could
still
just
opt
out
and
just
still
only
download
the
arch
that
we
that
we
require
okay,
yeah
I'm
I'm,
just
thinking
out
loud,
because
I
think
I,
remember
that
normally,
if
any
Docker
CLI
well
I
need
Academy
anyways,
any
Docker
compatible
demon
will
will
actually
just
fetch
the
layers
for
the
arch.
H
But
but
it
wants
right
if
it's
available
so
I
think
it's
a
it's,
not
a
concern,
but
I
just
wanted
to
validate
with
you
that
it's
not
going
to
put
on
a
burden
or
on
performance
with
regard
to
huge
downloads.
Is
it
going
to
double
the
download
sizes
or
are
all
or
is
all
the
tooling
smart
enough
to
just
download
the
things?
I
mean
just
the
layers
that
that
matches
its
art
I,
don't
know
if
I'm,
clear,
yeah,
sorry
I
was
thinking
out
loud
I
didn't
prepare
that
question.
H
C
I
can't
hear
you,
oh
yeah,
sorry
I,
thought
I
clicked
the
button.
It
does
just
download
the
layers
for
your
specific
architecture,
so
it
shouldn't
I
mean
you're.
Gonna
have
two
copies
of
everything
in
the
registry.
Yes,
but
you
won't
necessarily
have
tags
to
pull
both
versions.
You'll,
just
pull
from
the
one
tagged
version.
C
Unless
you
guys
decide
to
publish
the
tag,
the
arch
specific
version
as
a
tag
too,
but
yeah
there
shouldn't
it
should
be
completely
transparent
to
users
and
they
shouldn't
put
any
really
shouldn't
change.
Anything
except
for
you're.
Gonna
have
two
copies
one
for
whatever
architecture.
F
Add
one
of
a
comment
which
I
didn't
really
put
any
hours
to
because
I
don't
think
it's
on
scope
for
this,
but
it's
kind
of
wanted
to
mention
it,
which
is
that
we've
here
in
in
this
RFC,
we
talk
about
using
the
docker,
build
X,
like
extension,
to
basically
create
a
multi-arch
manifest.
F
So
another
thing
that
you
may
consider
Jericho
or
anyone
right
may
consider
opinion.
Obviously
on
the
pack
tool
to
extend
its
publish
this
package
will
interval
for
publishing
directly,
like
you
know
like
when
you
create
a
little
pack,
you
can
publisher,
so
it
may
be
worth
considering
like
making
like
rolling
up
the
like
multi-arch,
manifest
tooling
into
pack
itself.
So
you
don't
need
to
like,
like
rely
on
blockline
its
extensions,
but.
C
I
can
comment
on
that.
So
there
is
a
project
to
add
this.
Some
some
version
of
support
for
multi-arch,
but
it's
not
making
it
quite.
It's
not
making
it
into
the
pack
build
build.
Sorry
pack
build
pack
creator,
Builder,
create
versions
of
the
commands
yet
and
I
think
it's
because
they
don't
quite
understand
what
the
community
is
going
to
want.
C
You
know
like
what
what
flags
do
they
want
to
pass
in
so
right
now,
they're
just
going
to
do
a
general
I
want
to
have
some
manifest
support
and
that's
the
approach
and
then
I
I
have
a
feeling
that,
once
this
gets
implemented,
I
think
Picanto
will
probably
have
a
lot
of
feedback
to
give.
It
will
help
drive
that
but
yeah
it's
it's
kind
of
like
on
the
horizon,
but
I'm
not
sure,
there's
anything
concrete.
Yet.
F
C
I
put
it
in
the
RFC
about
kind
of
not
necessarily
fully
relying
on
the
platform
13
like
the
sorry,
the
the
new
platform,
API
changes
and
kind
of,
and
having
backward
compatibility,
because,
let's,
let's
just
say,
somebody
like
set
up
CI
and
pin
their
version
of
pack
to
a
certain
version
and
the
life
cycle
and
then
they're
just
pulling
new
versions
of
back
out
to
build
packs.
If
those
like
Picanto
build
packs
are
relying
on
new
Builders
and
new
platforms.
C
C
C
So
when,
in
my
experience
when
I
was
working
with
build
packs,
I
had
to
use
a
different
operating
system,
so
I
created
my
own
Builders
and
you
know:
I
just
went
to
the
buildbacks.io
site
and
their
example
said:
use
this
lifecycle
flag,
so
I
pin
the
lifecycle
into
a
certain
version
and
then
I
believe
also
like
in
my
CI
I,
just
downloaded
a
version
of
pack
and
just
walked
away
so
like.
C
If
someone
were
to
do
that
and
then
these
build
packs
are
changed,
they
won't
be
backwards
compatible
to
an
old
Builder
that
was
built
on
an
old
version
of
pack.
So
it's
just
something
to
keep
in
mind
like
sure
not
everybody's,
going
to
keep
up
with
packed
the
way
you
know
I
think
I
have,
but
they
may
be
using
them.
And
then
you
know
things
stop
working
and
they
don't
know
why?
Just
something
to
keep
in
mind.
G
What
one
other
comment
that
just
came
to
my
mind
just
because
the
question
of
duplicating
downloads
came
up.
That's
maybe
one
thing
to
at
least
keep
in
mind:
there's
like
there's
some
facility
to
actually
create
offline,
build
packs,
I,
I,
guess
that
would
then
actually
double
the
download
size.
People
would
do
offline,
build
packs
with
that
support.
I
guess
than
both
versions
would
be
packaged
just
to
keep
in
mind.
G
I,
don't
think
it's
even
worth
mentioning
in
that
RFC,
but
there
are
facilities
to
create
offline
building
packs
that
package,
the
dependencies
that
will
be
shipped
build
tax
and
those
would
then
probably
just
package
all
the
beta
data
dependencies
that
are
listed
and
those
are
then
for
multiple
architectures
right,
probably
that's
actually
what
you
would
want
right
for
an
air-capped
environment.
You
need
both
if
you
want
to
support
both
architectures.
H
There
would
be
nothing
preventing
the
offer
of
an
offline
build
pack
to
actually
filter.
Just
you
know
the
arch
that
it
wants
to
support.
F
Yeah,
we
may
want
to
create
a
separate
in
the
future,
a
separate
like
RFC
for
Jam
pack
to
gain
a
feature
to
filter
by
some
some
architecture,
operating
system
combination
which
doesn't
exist
currently.
However,
I
also
think
this
is
gonna
like
look
different
based
on
the
previous
RFC
about
spilling
out
dependencies
anyway.
So
I
kind
of
feel
like
there
might
be
many
ways
to
solve
this,
but
some
of
them
are
going
to
be
invalidated
if
that,
otherwise,
first.
A
E
A
We
can
go
into
CND,
CMP
updates
and
questions
I'm,
not
sure
that
I
have
any
updates,
Beyond
ones
that
we've
had
effectively
for
the
last
couple
weeks
stack
removals
coming
down
the
pipeline
shortly
and
I.
Don't
know
if
I've
called
it
out
in
this
meeting
before,
but
currently
there
is
work
being
done
on
a
pack
create
build
pack
flatten
flag.
A
That
would
allow
us
to
basically
flatten
I,
believe
it's
meta,
build
packs
or
language
family
build
packs
all
into
one
layer,
as
opposed
to
the
multi-layers
that
they
currently
are.
H
G
I
think
that
request
was
opened
by
Daniel
in
the
discussions
around
now.
We
need
language,
family
Builders,
which
would
be
a
question
like
if
that
has
landed
or
is
close
to
Landing,
do
we
still
need
yeah.
A
I
I
think
that
I
think
that
the
idea
when
we
were
merging
that
RFC
is
that
this
will
have
to
land
eventually,
just
based
on
you
know,
just
like
practical
usage,
I
I
think
that
what
we
would
encourage
for
language,
family
Builders
is
maybe
like
very
specific
and
tailored
ideas.
A
At
that
point
you
know,
like
did
we,
we
see
a
lot
of
people
that
spend
time
in
the
Java
ecosystem
spend
basically
all
of
their
time
in
the
Java
ecosystem
or
large
swaths
of
their
time
in
the
Chavo
ecosystem
and
so
having
to
waste
a
lot
of
time
trying
to
update
Builders
with
you
know
a
bunch
of
other
languages,
not
necessarily
what
we
want
to
do,
I
think
as
well.
A
There
was
some
talk
about
like
trying
to
find
ways
to
make
completely
building
out
custom
Builders
more
user
friendly
because,
like
in
a
production
environment,
that's
probably
more
realistically,
what
you
would
want
to
do
is
have
a
builder
with
just
like
you
know
the
the
three
build
packs
that
you're
actually
using
over
your
entire
system,
and
you
don't
need
everything
else,
and
that
would
make
things
easier
to
update
as
well.
A
G
H
A
I
think
the
only
major
thing
to
update
is
that
there's
been
a
bit
of
an
initiative
to
try
and
go
through
and
improve
error
handling
throughout
the
sort
of
build
packs.
That
first
part
was
the
first
part
of
that
was
a
series
of
issues
that
updated
all
of
the
commands
that
are
run
so
like
language
specific
commands,
like
npm
install,
builds
Etc.
All
of
those
now
have
streaming
logs
as
opposed
to
capturing
all
those
logs
and
only
outputting
them
on
fail.
A
A
So
hopefully,
when
you
are
looking
at
your
verbose,
detect
logs,
you
will
see
not
just
that.
X
build
pack
failed,
but
X
Bill
pack
failed
because
it
couldn't
find
wide
dependency
or
Wi-Fi
on
the
file
system
or
whatever
so
yeah.
A
A
Okay,
in
that
case,
I
think
that
that's
the
the
end
of
this
meeting.
Thank
you
all
for
stopping
by.