►
From YouTube: Working Group: 2022-06-21
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
Good
right
welcome
everyone
to
the
pacquiao
working
group
weekly
meeting.
We
appreciate
your
time
joining
us
today.
Let
me
share
my
screen
real
quick
here
again,
I'm
sharing
the
notes
in
case
you
don't
have
it
handy.
A
Here
it
is,
please,
consider
adding
yourself
to
the
ad
in
this
list,
including
your
affiliation.
Thank
you,
okay.
Is
there
anyone
who
would
like
to
take
notes
today.
A
Right,
I
can
do
it,
there's
no
objection
cool
new
faces.
Well,
not
exactly
tell
team
here.
Welcome!
Welcome
you
all
cool,
so
we'll
start
reviewing
outstanding
rsvs.
B
I
finally
got
around
to
digging
into
some
of
these
long
threads
that
we
have
between
dan,
and
I
I
mean
I
got
gotten
a
bit
lost
in
the
details
on
some
of
these
threads,
so
it's
too
bad
that
dan
is
out
today,
because
I
think
the
synchronous
conversation
would
help
wrap
up
what's
outstanding.
B
I
think
the
big
question
comes
down
to
like
whether
it
needs
to
be
configurable
at
runtime
and
how
I
think
the
way
things
are
proposed
with
the
arguments.
It
might
be
hard
to
change
some
of
these
things
at
runtime
like
the
port,
it's
checking
and
stuff
like
that,
but
because
you
can
change
some
of
those
elements
of
the
app
at
runtime.
I
do
think
we
need
an
answer
for
configuring,
the
health
checker
to
match
at
runtime.
In
those
cases.
A
No
yeah,
I
think
we
should
have
comments
or
questions
to
the
to
the
discussion
itself
and
see
if
we
can
have
the
synchronous
conversation
very
soon
with
daniel
all
right.
Next
up
support
for
yarn
very.
C
Okay,
yeah
so
had
some
conversation
with
ryan
today
that
I
think.
C
Provides
some
direction
going
forward.
I
think
so.
I
was
able
to
provide
some
quality
here.
For
this
first
question,
I
was
able
to
generate
s-bomb
without
leveraging
the
no
module
bomb
bill
pack
at
all.
So
I
think
that's
what
we'll
continue
to
do
going
forward.
C
As
for
the
the
other
two,
I
think
I'll
also
add
this
context
here
to
the
to
the
discussion
itself,
but
I
think
some
of
the
concerns
for
this
second
question
may
become
irrelevant
after
we
evaluate
this
new
direction
of
not
creating
more
than
one
build
pack
and
just
including
the
different
code
paths
as
packages
in
the
existing
url
installer
built
back
there
just
may
not
be
as
many.
C
It
was
interesting
to
see
the
opinion
that
it
could
be
confusing
to
see
yarn
install
when
explicit
is
driving
for
zero
installers.
I
figured
the
bill.
Pack
itself
would
be
responsible
for.
C
Deciding
whether
or
not
to
run
the
actual
yarn
install
command,
I
hadn't
considered
pushing
that
decision
upwards
to
the
detection
criteria
itself.
C
C
I
think
in
that
case,
then
I'll
forge
on
with
the
refactor
and
then
once
some
of
that
has
been
some
of
the
I
guess
threads
have
been,
the
loose
ends
have
been
tied
up.
Then
I
can
revisit
this
and
answer
it
a
little
better.
A
I
don't
see
josh
oh
yeah
george
is
here
yeah
wondering
there
is
any
additional
comment.
There
are
pretty
recent
comments
here.
D
Yeah,
that's
that's
my
bad.
I
have
been
being
a
bad,
tooling
maintainer
and
not
going
over
this
as
rigorously
as
I
should
so.
I
just
went
in
just
before
this
I'd
like
to
have
a
little
bit
of
conversation
back
and
forth
with
josh,
but,
like
I
think
the
overall,
I
personally
don't
have
any
problems
with
the
overall
idea,
just
some
of
potentially
potentially
some
of
the
interface
work.
E
Okay,
yeah.
I
was
actually
going
to
mention
that
if
there
hasn't
been
a
whole
lot
of
conversation
or
movement
to
get
this
closed,
that
could
be
a
signal.
It's
not
you
know
it's
not
generating
any
any
interest.
You
know
from
the
from
the
community,
which
is
which
is
fine,
but
if
that's
not
the
case,
if
you
feel
like
you're
gonna,
take
a
look
at
it,
then
I'll
wait
for
that
feedback.
F
F
Yet
the
status
of
these
right
now
is
that
joshua
and
I
were
working
on
some
investigation
to
solidify
the
contract
between
what
will
be
required
of
build
pack
authors
and
versus
stax
maintainers,
so
that
work
has
wrapped
up
more
or
less,
and
I'm
now
in
the
process
of
you,
know,
updating
the
rfcs
and
then
I
will
be
like
updating
things
based
on
the
new
comments
that
have
come
in.
So
unfortunately,
that's
not
ready
for
today's
working
group,
but
it
definitely
will
be
for
next
week
and
we
can
discuss.
B
Got
it?
Thank
you
something
one
of
the
things
I'd
like
to
do
here
as
we
push
this
forward
is
try
to
get
when
dan's
back,
get
him
more
involved
in
this
as
well
like
if
it's
the
plan
to
also
move
java,
build
packs
over
to
talk
about
the
trade-offs
and
migration
steps
there
as
well
and
like
whether
we
need
to
standardize
more
things.
In
order
to
accomplish
that,
like,
I
think
there
are
some
areas
where
the
metadata
format
is
actually
different
between
the
different
build
packs.
F
B
A
Thank
you
anything
else
regards
to
rcs.
A
No
okay,
next
one
cmd,
updates
and
or
questions.
I
wasn't
able
to
find
any
relevant
update
from
last
week.
B
G
G
I
think
that
conversation
is
currently
being
summarized
or
kind
of
taking
place
on
there's
a
pr
that
was
opened
by
dan.
That's
something
related
to
like
generating
a
config
object.
That
seems
totally
unrelated
to
like
the
actual
conversation,
but
it's
there
that
most
of
the
conversation
about
what
the
api
should
look
like.
It
seems
to
be
happening
at
the
moment.
A
A
A
There
just
stand
up
replied
a
response
to
this
discussion
with
the
information
that
is
there,
your
old
name
contact
info
and,
basically,
how
you
use
the
keto
build
packs
right
now,
we'll
get
you
added
to
the
public
adopters
list,
which
is
also
a
way
for
us
to
learn
about
your
use
cases
and
and
keep
improving
the
project.
So
if
you're,
using
the
kettlebell
packs
right
now
in
production
feel
free
to,
and
if
you
want
to
make
it
public
feel
free
to
add
this
info
to
the
discussion
there.
A
B
I'm
curious
to
what
extent
for
build
packs
that
you
know
the
dependencies
are
already
such
that
they
would
run
on
jamming
how
much
of
the
debt
migration
work
we
need
to
get
done
before.
We
could
actually
enable
that
like
do,
we
need
to
do
a
refactoring
of
the
metadata
and
the
whole
thing
before
we
can
turn
that
on,
or
is
it
possible
in
our
current
system
to
take
things
that
would
already
run
on
jimmy
and
just
enable
them.
I
A
F
Yeah,
I
think,
if
the
same
dependency
will
work
on
either
stack,
then
like
we're
good
and
that
we
can
kind
of
modify
the
metadata
and
the
depth
server,
that
we
have
and
have
it
start
working
just
automatically,
but
it
becomes
more
complicated
if
the
dependency
needs
to
be
compiled
on
jme
itself
in
order
to
work.
So
it's
probably
going
to
require
some
investigation
to
figure
out
which
ones
will
just
work.
F
It
would
probably
require
some
code
changes
that
I
personally
don't
wouldn't
really
be
inclined
to
make,
considering
that
we're
going
to
be
doing
work
to
move
away
from
it
anyway.
But
if
we
were
really
in
a
pinch,
we
needed
to
desperately
get
something
working
like
yeah.
We
could,
you
know,
modify
the
depth
server,
probably
and
change
some
of
those
workflows,
but
I
wouldn't
advocate
for
it.
E
Sure,
just
to
share
a
little
bit
of
context,
the
the
new
approach
will
allow
build
pack
authors
to
specify
their
their
build
targets.
You
know
bionic,
jammie
or
theoretically,
anything
right
and
then
specify
which
build
packs
are,
or
rather
sorry,
stacks.
That
will
support.
So
if
a
buildback
author
determines
that
they
can
compile
something
on
bionic
and
it
will
run
on
both
bionic
and
jammy,
they
can
specify
that
and
it'll
get
compiled.
One
time
you
know
one
one:
entry
in
the
buildback
tunnel
metadata
and
with
all
the
right
stacks
listed
out.
G
Awesome
specifically
for
tiny,
like
the
ones
that
are
running
on
tiny,
is
basically
just
java
and
go,
and
I
think
both
of
those
will
run
given
they're
currently
like
how
they're
actually
packaged.
I
know
we
don't
really
do
anything
much
to
the
go
related
stuff
where
we
we
shouldn't
be
anyway.
B
B
D
Yeah
I
added
this.
Those
are
just
some
links
to
some
pr's
because
I
don't
know
that
I
have.
I
couldn't
find
the
right
issue
in
time,
but
previously
httpd
couldn't
run
on
the
base
stack.
We
have
changed
the
modified,
the
bass
stack
slightly
to
add
a
dependency
and
so
httpd.
G
D
D
Yeah
so
hopefully
everything
should
work.
I
don't
know
frankie.
I
don't
want
to
put
you
I'm
blessed.
Is
there
documentation
of
this
written
in
like
the
readme.
H
There's
no
documentation
the
way
of
turning
it
on
is
documented
with
nginx,
but
we
could
add
it
to
our
docs.
If
you
want
to
see
an
example
of
how
to
use
this
feature,
there's
a
test
fixture
in
this
repo.
It's
actually
in
this
pull
request
that
adds
the
appropriate
line
to
your
engine
x
configuration
to
produce
debug
logging,
but
I
imagine
like,
if
you're
familiar
with
how
to
configure
nginx
it's
what
you
think.