►
From YouTube: Working Group: April 19, 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
C
B
D
A
Awesome
I
mean
so
I
think
we
can
jump
right
into
outstanding
rses
there's
two
this
week.
The
first
one
up
is
from
Dan
makuza,
and
this
one
is
proposing
to
remove
YJ
from
the
stack.
A
I
believe
this
is
in
the
stack
sub
team,
so
I
don't
think,
there's
much
more
to
elaborate
on
that
other
than
the
proposals
to
move
YJ
from
the
stack
there's
a
little
bit
of
conversation,
Happening
Here.
A
This
goes
in
line
with
one
of
our
roadmap
items,
and
I
can
already
see
that
Rob
has
had
a
crack
at
this
so
lesson,
but
one
of
our
roadmap
items
this
year
was
to
decouple
the
dependencies
from
the
Bell
pack
and
that's
what
this
proposal
is.
It's
based
very
heavily
on
Dan
mccusa's
sort
of
proposal
that
sort
of
kicked
off
this
being
on
the
road
map.
A
It
is
a
very
long
RSC
and
it
will
need
a
lot
of
revisions
and
a
lot
of
discussion,
but
I'd
love
to
go
over
some
of
the
quick
overview
points
for
this.
So
as
this
might
entail,
the
idea
is
to
sort
of
separate
the
build
packs
dependency
metadata
from
the
bill
pack
themselves.
A
Currently,
if
you're
unaware
the
bill,
packs
have
Bill
packed
hommels
in
them,
and
the
bill
pack
tamils
contain
all
of
the
metadata
that
is
needed
to
actually
fetch
the
dependencies,
so
Uris
shot
sums
to
ensure
that
we're
getting
the
correct
thing
from
the
URI
Etc.
A
This
has
worked,
and
you
know
we'll
continue
to
work,
but
one
of
the
problems
that
we
have
with
that
is
that
we
don't
maintain
sort
of
specific
version
lines
of
build
packs,
so
feature
editions
and
updates
to
the
dependencies
in
the
build
packs
are
treated
as
sort
of
equivalent
actions
when
in
reality
that's
just
sort
of
not
the
case.
So
it
means
that
users
that
don't
want
new
feature
work
but
want
new
versions
of
dependencies
are
kind
of
out
of
luck.
If
that's
something
that
they're
looking
for.
A
A
Now,
there's
a
couple
of
sort
of
proposed
ways
of
doing
this,
and
so
you
should
definitely
read
the
RFC
if
you're
interested
in
the
mechanics.
But
essentially
what
would
happen
is
we
would
set
up
some
structure
that
would
allow
a
format
to
be
set
up.
A
A
This
would
then
extend
further
into
sort
of
the
quote-unquote
offline
experience
for
the
pill
pack,
where
we
would
also
have
a
dedicated
area
for
dependency
assets,
which
is
this
section
here
where
it
would
be
a
series
of
files
that
are
just
sort
of
the
pre-downloaded
dependencies
themselves,
and
you
would
be
indicate
where
those
are
on
the
file
system
and
the
names,
and
then
you
could
attach
both
files
and
you
would
have
sort
of
separated
offline
dependencies
as
well.
A
That's
a
really
high
level
of
this
I'd
like
to
just
call
out
I,
did
a
little
bit
of
sort
of
a
proof
of
concept.
Investigation
I'll
have
to
update
this
link
in
a
little
bit
when
the
branch
gets
merged,
but
effectively
that
was
proving
out
sort
of
the
individual
interface
methods,
so
sort
of
an
external
attachment,
a
build
pack
attachment
and
a
builder
attachment
did
not
do
a
platform
attachment.
A
This
would
sort
of
I
think
have
to
come
later
for
us
like,
we
would
have
to
prove
out
the
whole
separated
dependencies
concept
and
really
have
it
fleshed
out
and
then
probably
go
upstream
and
say:
Hey
pack,
AK
pack,
hey,
you
know
X,
Y
or
Z.
Is
there
a
way
for
us
to
have
it
so
that
we
can
specify
files
for
you
to
load
during
build
essentially
into
the
container
yeah?
That's
like
the
incredibly
high
level
of
this.
E
I
have
a
question
so
I
haven't
read
through
this.
Yet
first
of
all
is
this
already
approved.
A
Oh
not
not
even
a
little
bit
okay,
this
is
gonna,
probably
I'm.
Gonna
want
to.
This
is
obviously
a
top
level
RFC,
so
the
steering
committee
is
going
to
have
to
approve
it,
but
I'm
going
to
want
approvals
from
basically
every
maintainer
that
I
can
get
on
this
project
before
we
merge
this
and
I.
Think.
A
So
it'll,
it's
it's
more
akin
to
like,
like
I,
think,
a
good
way
of
like
describing
how
this
works
is
like
in
in
one
of
the
use
cases
externally.
What
what
we
do
is
sort
of
like
what
I
do
in
the
proof
of
concept
is
basically
just
attach
a
directory
with
the
correct
file
structure
and
then
it
goes
and
finds
this
toml
file,
which
is
the
metadata.
So
this
is
effectively.
This
is
the
metadata
section
of
the
billpack
tomml,
as
it
currently
exists
in,
like
the
dependency
metadata
section
of
the
bill
pack
tunnel.
A
Is
it
currently
exists
in
the
billpack
tommel?
We're
just
trying
to
separate
the
two
entities
now
and
the
way
that
this
is
sort
of
gonna,
I,
I
guess
work
in
the
going
forward
is
that
we
would
modify
our
libraries
to
go
and
look
for
these
metadata
files,
as
opposed
to
looking
in
the
pill
pack
novel.
F
And
then
art
and
Os
I
see
there
are
those
new
things
that
are
being
added
yeah.
A
So
I
think
the
new
fields
that
are
being
proposed
are
this.
This
license
field
I
think
that
Java
currently
formats
their
license
field
licenses
field
in
this
manner,
but
I
don't
know
that
other
potato
Bill
packs
do
so
I
think
that's
part
of
this
and
then
distro,
OS
and
Arch
are
all
the
new
proposed.
Fields
I
think
that.
E
A
Yeah
and
we
we
may
need
to
actually
make
these
changes
sooner
than
this
RFC
like
we
might
have
to
do
an
intermediate
step,
because
I
think
stack
removal,
May
land
and
become
more
pertinent
before
we
are
able
to
sort
of
fully
implement
this
RSC.
E
E
The
another
reason
I'm
kind
of
talking
about
this
is
yeah
I'm
I'm
in
the
process
of
writing
an
RFC
for
creating
multi-arch,
build
packs,
and
if
this
is
going
to
be
kind
of
like
a
component
of
that
I'm
just
wondering
if
I
should
be
trying
to
factor
in
this
RFC
into
what
I'm
proposing,
because
right
now
kind
of
proposes
doing
something
similar.
But
it
doesn't
talk
about.
You
know
not
the
dependency.
So
you
know
anything.
D
A
I
think
I
think
fundamentally
the
the
the
only
thing
that
this
would
change
in
in
my
head.
The
only
thing
this
would
change
for,
like
supporting
multiple
architectures
is
just
the
the
expression
of
like
the
metadata
that
we
need
when
actually
like
searching
for
files
that
are
compatible,
and
so,
if
it
looks
similar
to
this,
that's
great.
That
means
that
we're
going
to
implement
this
even
sooner
through
multi-architecture
support.
E
Okay,
cool
all
right,
I
mean
I,
think
that's
it.
This
looks.
This
looks
great
I
agree
with
this
big
time.
E
A
A
so
I
think,
that's
something
that
we
are
I
I,
think
that's
something
that
still
needs
to
be
100
figured
out
I.
There
are
a
couple
of
proposed
things,
but
it
was
getting
to
the
point
where
Dan
and
I
were
talking
about
this,
and
we
could
talk
in
circles
about
each
of
them,
in
terms
of
which
one
might
be
more
effective
or
not,
and
so
I
was
like.
A
It
would
make
more
sense
for
us
to
just
put
this
in
front
of
everyone
and
have
it
ripped
apart
and
then
write
it
back
up
and
have
it
ripped
apart
and
have
it
written
up.
I
just
wanted
to
get
it
in
front
of
eyes
as
soon
as
possible.
A
I
think
there's
a
couple
of
sort
of
delivery
mechanisms
that
we
could
go
by
yeah.
We
here's
the
but
yeah
I
think
this
is
here's.
The
metadata
distribution,
section,
I
I,
think
that
you
know
it
could
be
that
yeah.
We
have
like
a
sort
of
I
like
a
language
family
level,
a
language
family
level
repository
that
does
this.
We
have
one
repository
that
does
this,
for
everything.
I,
probably
won't
do
that,
but
you
know
it
could
be
the
case.
A
I
think
it
depends
on
the
granularity
of
the
how
we
want
to
distribute
these
sort
of
packages
and
then
I
think
on
top
of
that,
the
tooling
that
we
produce
as
well,
because
you
know
maybe
we
might
pick
one
great
level
of
granularity,
but
we,
you
know,
offer
tooling
that
allows
you
know,
users
to
you,
know
easily
customize
the
actual
metadata
dependency
packages
they
have
or
whatever
it
might
be.
Okay,.
E
A
And
if
you
obviously,
if
you
don't
find
those
questions
addressed,
please
leave
a
comment.
D
I'm,
looking
very
much
forward
to
this
RFC,
it's
like
it's,
the
successor
of
the
Google
Doc
that
Daniel
had
written
up
right,
yeah.
A
It
is
almost
one-to-one
with
that
yeah
as
it
stands
right
now.
Yeah
I
think
I've
only
added
one
or
two
things
and
I
removed
one
of
the
proposals,
but
it's
almost
identical.
A
A
I
think
that
I
think
that
we
might
find
that
we
want
to
implement
it
through
one
means
as
a
way
of
sort
of
proving
out
the
concept
and
then,
as
we
prove
out
the
concept
we
say
this
is
actually
you
know
as
as
this
project
we
feel
this
is
you
know
this
separation
is
actually
the
best
way
for
us
to
serve,
build
packs
and
maybe
finding
a
way
to
talk
to
the
CNB
and
say
hey.
So
we've
discovered
this
pattern.
We
feel
that
it's
a
really
powerful
pattern.
A
We
would
like
you
know,
to
propose
an
RFC
to
enable
ease
of
use
with
this
pattern,
which
is
something
that
we've
done.
Obviously,
in
the
past.
D
F
F
A
So
I
think
that
I
think
that
the
maybe
the
best
that
we
could
probably
get
Upstream
is
like
the
method
of
delivery
that
we
have
for
this
particular
set
of
metadata
is
important
and
you
know
we
could
potentially
even
like.
If
it's
generic
enough
like
you,
could
you
could
even
do
things
like
set
build
pack
configurations
with
it
right
like
the
metadata
file,
you
actually
upload
that
gets
referenced,
has
default
environment
variable
settings.
If
you
wanted
to
even
go
that
far,
but
it.
D
It
it's
like
I
I
ask
because
that
that
basically
means
we
can
just
do
whatever
in
kind
of
could
consider
Poquito
a
Sandbox
for
this.
Yes,
and
if
it
is
actually
a
good
thing
than
others
like
Heroku
and
Google
might
want
to
adopt
it.
If
not,
then
they
don't
have
to,
and
we
are
not
actually
required
to
change
to
to
do
many
changes
or
anything
like
it's
not
hindering
us
right
that,
if,
if
we
don't
do
anything
in
the
Upstream
Upstream.
A
Well,
yeah
for
sure,
I
think
that
there's
a
couple
of
the
sort
of
dependency
metadata
interfaces
that
wouldn't
work
so
well
like
I,
don't
think
that
we
could
very
effectively
serve
this
metadata
via
the
platform
without
going
upstream
and
asking
for
a
larger
platform
or
even
life
cycle
changes.
But
I
think
that
you
know
obviously
externally
you
know,
I
I
threw
together
a
build
pack
with
a
library
that
did
this
in,
like
you
know,
20
minutes.
So
it's
not
a
particularly
difficult
problem
to
solve.
Beyond
that.
D
True,
even
like
a
folder
structure
like
platform,
depths
metadata
might
at
least
need
some
acknowledgment
from
us
from
Upstream
that
this
is
okay
to
use
this
file
system
path,
and
it's
not
going
to
be
used
for
anything
else
in
the
stack
in
the
future.
Yeah
some
kind
of
assurance
in
that
direction
might
make
sense.
Yeah.
A
Like
like,
even
just
getting
a
reservation
from
Upstream
might
be
what
we
would
want
to
do,
but
I
I,
I
I'm,
not
I,
don't
think
that
would
that
would
need
to
happen
before
you
know
this
would
even
be
implemented.
A
I
would
appreciate
any
feedback
that
I
can
get
about
that
get
on
this
I
will
leave
it
open
for
a
couple
of
days
and
then,
hopefully
before
next
week,
I
will
be
able
to
go
through
and
address
as
much
of
the
feedback
as
possible
and
we'll
rinse
and
repeat:
do
this
for
the
next.
You
know,
four
months
until
we're
able
to
finally
decide
that
this
is
the
decide,
the
path
that
we
want
to
go
on.
D
I
mean
it
might
actually
be
worth
it
to
keep
some
some
things
big
and
just
accept
that
we
will
change
them
during
implementation,
instead
of
figuring
out
every
little
detail.
A
Yeah
I
want
I
think
that
that's
the
hope
with
this,
in
particular,.
A
All
right,
I
think
that
that
means
that
we
have
hit
the
the
top
of
our
rfcs
for
today.
So
we
can
move
on
to
CMB
updates,
I,
don't
know
if
there's
any
major
CMB
updates
other
than
the
fact
that
they
were
at
qcom
as
far
as
I
understand
and
so
they've
been
a
little
quiet.
A
I
think
the
only
project
update
that
I
can
think
of
is
that
rust
has
been
updated
to
support
I,
think
both
Jamie
and
the
static
stack
I
think
it
was
a
maybe
a
tiny
Jamie
tiny
I'll
have
to
double
check
that
just
just
a
release
today,
hopefully-
and
so
if
y'all
are,
what
do
they
say?
Restations
is
that
is
that
the
the
term
that
anyway
and
are
looking
to
play
with
the
static
stack
by
all
means.
B
Another
update,
I,
don't
know
if
we
ever
announced
this,
but
the
one
of
the
outstanding
build
packs
we
had
for
reproducible,
builds,
is
Ruby
and
we
recently
just
shipped
like
reproducible,
build
support
for
all
those
build
packs,
except
for
the
rails.
Assets
build
pack
because
there
was
no
native
way
that
our
team
could
discover
to
actually
achieve
reproducible
builds.
So
that
would
be
more
of
a
like
issue
to
take
up
with,
like
the
rails
project
itself,
but
for
all
the
other
use
cases
in
the
Ruby
build
pack.
F
A
And
finally,
open
mic:
are
there
any
questions
or
discussion
topics
or
anything
that
people
want
to
talk
about,
I,
believe
I,
guess
I
actually
have
something
I
believe
that
election
season
is
coming
up
in
the
next
couple
of
weeks
it's
supposed
to
be
mid-may
to
mid-june
Dan
and
I
are
trying
to
reach
out
and
discover
the
exact
process
of
the
cff
would
like
us
to
use,
and
we
will
try
and
keep
you
as
updated
as
we
are
on
that
process.
E
I'm
not
sure
what
that
means.
Elections
for
what.
A
So
we
recently
passed
a
new
RFC
for
governance
to
for
governance
in
the
steering
committee,
so
to
more
accurately
reflect
the
processes
that
the
cff
uses,
which
is
our
I've,
got
one
parent
body,
I,
don't
I,
don't
actually
know
what
the
technical
or
legal
term
for
that
is.
But
and
so
we
will
be
running
a
round
of
Elections
to
elect
steering
committee
members.
A
D
There's,
like
one
interesting
question,
might
actually
be
I.
Think
the
the
POC
elections
for
the
cff
are
actually
it's.
It's
a
yearly
election,
but
only
for
half
the
chairs.
So
it's
one
year
it's
for
two
of
the
TLC
members
the
other
year.
It's
for
three
also
to
have
some
continuity,
so
that
would
be
a
question
probably
for
the
steering
comedy
as
well.
D
If
that's
I
think
it's
three
members,
if
I'm
correct,
with
only
two
seats,
actually
seated
right
now,
if
we
do
such
a
thing
as
well,
I,
don't
know,
I
haven't
really
read
the.
A
Yeah
I
I
think
that
if
it
were
to
be
the
case
that
all
Spirit
current
steering
committee
members
were
not
part
of
the
next
set
of
steering
committee
members,
then
we
would,
you
know
I,
think
ad
hoc
probably
holds
some
form
of
you
know
like
like
I,
don't
want
to
say
orientation
but
like
we
would,
we
would
probably
do
a
slower
sort
of
transfer
of
full
powers
and
responsibilities
over
just
to
ensure
that
everything
was
kept
running
smoothly.
A
E
I
did
have
a
question
related
to
the
RCM
drafting,
which
I
was
hoping
to
have
done
before
this
meeting,
but
I'll
just
get
it
done
afterwards.
So
when
I
post
it
I
would
appreciate
some
eyes
on
it.
The
question
I
had
was
like
one
of
the
things
that
Forest
you
mentioned
was
gitlab.
Github
actions
are
only
supported
on
x86
Runners,
so
would
paqueto
or
cff
or
somebody
consider
using
different
Runners
I,
mean
I,
understand,
everything's
written
in
get
up
action,
so
I
think.
A
That's
a
good
question:
I
would
have
to
ask
someone
from
the
cff,
because
I
think
there's
two
options
that
we
could
do.
We
could
either
host
our
own
Runners
somewhere
and
I
have
no
idea
how
expensive
that
is,
but
I
we
could
potentially
do
it
or
I
have
seen
services
that
host
arm
Runners
that
you
can
be
used.
I
would
have
to
ask
the
cff
what
they
would
be
more
willing
to
do.
D
I
would
be
my
my
advice
as
well
to
ask
but
like
from
the
time
like
I
did
serve
in
the
in
the
cfftoc
that
was
like
back.
Then
there
was
budget
for
something
like
Ci
and
I.
Think
one
of
the
decisions
was
that
it
would
be
okay
if
every
working
group
runs
their
own
Concourse,
which
was
the
preferred
CI
solution
for
the
CF
project,
so
I
suppose
we
would
have
a
share
of
a
budget
for
saying
the
potato
working
group
would
like
to
host
some
some
kid
of
action.
A
I
would
expect
so
to
I
think
that
they
have
they've
been
allowed
us
to
like
host
both
like
files
like
buckets
as
well
as
VMS
in
the
past,
but
I
would
have
to
still
get
approval.
I
and
I
think
that
as
well,
GitHub
is
probably
hopefully
going
to
be
moving
towards
getting
their
own
arm
workers
in
the
not
too
too
distant
future.
One
of
the
reasons
that
they
were
lacks
on
doing
it
previously
is
because
they
run
everything
on
Azure
and
Azure.
A
Didn't
have
a
set
of
arm
compatible
workers,
I
think
they're
trying
to
work
on
getting
allocation
for
that.
But
in
the
meantime
definitely
I
will
reach
out
to
Dan
once
once
the
RFC
is
there
I'll
reach
out
to
Dan
and
talk
about
it
getting
workers
and
look
into
the
process
more.