►
From YouTube: Working Group: 2022-05-10
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).
B
A
Are
good
to
go!
Welcome
everyone
to
the
pacquiao
working
group
weekly
meeting.
I'm
really
glad
to
see
you
all
here
coming
to
you
from
a
nice
co-working
side,
because
I'm
dealing
with
a
5-day
internet
outage
in
my
area,
the
joys
of
rural
life.
A
So
this
is
my
second
home
for
rawa,
all
right
and
yeah,
I'm
doing
my
best
to
cancel
outside
noise
right.
So
let
me
share
my
screen.
A
Real
quick.
All
right
for
this
session
would
like
to
take
notes.
A
C
Sure
I'm
the
product
manager
for
my
name
is
brett
maglevsky
pronouncer.
He
and
him.
I
live
on
the
west
coast
of
the
us.
C
I
am
the
product
lead
for
cloud.gov,
which
is
a
government
tailored
deployment
of
cloud
foundry,
I'm
starting
to
get
interested
in
the
kubernetes-based
deployments
and
therefore
starting
to
look
at
cnbs,
particularly
because
it
looks
like
cnbs
are
never
coming
back
to
cf
for
bosh.
So
just
thought.
I'd
start
attending
some
of
these
meetings
and
seeing
what's
happening
with
cnp's.
A
D
A
All
right
next
up,
extend.net
sdk.
E
Yeah,
I
don't
expect
to
have
any
discussions
about
this.
I
just
put
in
a
new
I
just
put
in
another
little
paragraph
discussing
about
how
this
is
an
effort
to
try
and
move
us
towards
the
artifact
that
microsoft
released
in
terms
of
its.net
sdk,
as
opposed
to
one
that
we
are
trying
to
sort
of
crop
and
prune.
E
So
I
added
that
clarification
drc
itself
and
then
I
wrote
up
a
small
response
to
andrew
stakov's
exploration
into
potentially
extending
the
extended
sdk
even
more
to
allow
for
like
to
allow
for
us
to
only
have
one
sdk
version.
I
responded
with
that.
My
biggest
sort
of
fear
or
hang
up
with
it
is
that
kind
of
the
whole
reason
we
have.
This
rfc
is
to
move
us
towards
the
artifacts
that
are
coming
from
microsoft
directly
and
move
us
away
from
having
a
custom
artifact
that
we're
building.
E
So
it's
all
fine
and
good,
but
I
feel
like
that
would
swing
the
pendulum
in
the
wrong
direction
entirely.
So
I
think
that
unless
he
can
come
back
with
an
incredibly
compelling
argument
about
how
it's
super
easy
to
add,
x,
y
or
z,
or
something
to
that
effect,
we'll
probably
just
be
moving
forward
with
the
rfc
as
it
is,
stands.
F
Oh
yeah,
this
one
was
me
so
for
those
of
you
who
aren't
familiar
yarn,
yarnberry
is
kind
of
the
new
direction
that
the
project
is
is
going
in,
which
attempts
to
forego
no
modules
being
included
in
the
project
directory
or
indeed
like
the
need
to
run
yarn
install
at
all
in
some
cases
and
the
yarn
install
build
pack
currently
doesn't
support
any
of
those
workflows
for
yarnberry.
So
this
is
just
proposing
the
creation
of
a
new
build
pack
that
supports
the
berry
workflows.
F
I
guess
some
of
the
things
that
are
that
might
catch
the
eye
on
first
read
are
the
the
fact
that
yarn
the
yarn
bill
pack
as
it
stands
probably
won't
need
to
be
required
explicitly
by
this
new
build
pack,
since
the
yarn
has
switched
to
a
per
project
based.
F
The
other
thing
here
that
may
be
of
note
is
the
bearing
style
order.
Group
would
be
placed
before
the
yarn
install
order
group,
since
it
relies
on
this
extra
bit
of
configuration.
F
That's
intended
to
be
the
differentiator
between
berry
and
classic
yarn
other
than
that
more
generally,
the
the
yarn
bearing
style
buildback
will
attempt
to
avoid
running
yarn,
install
wherever
possible
to
try
and
conform
with
the
philosophy
of
yarnberry,
which
is
to
get
to
a
quote-unquote
zero
install
state
where
one
doesn't
have
to
run
your
installing
free
portal.
F
Other
than
that
there
are
a
few
cli
changes
that
we'll
need
to
account
for
in
the
new
build
pack,
most
of
which,
if
not
all,
are
listed
here
lower
in
the
in
the
file.
Here,
there's
some
small
changes
to
flags
and
such
but
yeah
just
looking
for
any
feedback
from
anyone
on
this,
I
am
one
of
I
think
two
maintainers
for
this
sub
team,
so
I
guess,
ran
your
feedback,
would
be
appreciated
other
than
that
yeah.
Just
any
any
comments,
questions
would
be
welcome.
A
All
right,
yeah
feel
free
to
add
your
comments,
observations
to
the
rfc
itself,
okay,
cool
things
like
that
in
terms
of
rfcs,
okay,
cmv,
updates
and
questions.
A
Maybe
I
don't
know
if
the
team
has
anything
else
to
share
about
these,
but
but
I
found
this
announcement
in
the
cmb
channel
around
the
new
pack
beta
release.
That
probably
has
some
breaking
changes.
A
B
I
think
the
only
thing
worth
noting
is,
I'm
pretty
sure.
Every
release
of
pack,
like
all
the
way
back
through
history,
is
marked
as
a
beta
release.
So
I'm
not
even
sure
that
that
information
is
like
useful
in
the
context
of
like
what
rob
saw,
but
it's
worth
noting
that
as
it
stands
today,
they're,
basically
all
beta
releases.
G
And
then
just
to
answer
your
question
david,
the
main
issue
that
I
saw
was
within
the
intercollection
tests
of
a
variety
of
piquette
build
packs
which
were
relying
on
the
the
old
building
materials
being
located
in
one
file
and
then
with
pack
26
and
the
underlying
life
cycle:
zero
014
that
changed
to
a
different
file
which
broke
a
lot
of
integration
tests.
It's
fairly
straightforward
to
fix,
and
I
don't
think
this
really
affects
many
people
outside
of
the
picato
core
team,
because
I
don't
think
many
other
people
actually
run
integration
tests.
G
The
way
that
before
team
does.
But
if
there
are
any
questions
you
know
feel
free
to
raise
them
and
I'm
happy
to
share
context.
A
A
Got
it
all
right
in
terms
of
project
update,
we
have
a
new
blog
post
live.
Thank
you
all
for
making
it
happen.
It's
a
recap
remember.
In
the
last
week,
in
the
first
roadmap
session,
we
were
discussing
also
the
the
status
of
the
2021
roadmap.
The
achievements
of
last
year
here
are
the
highlights
and
again,
thank
you
all
thanks
to
our
community
of
contributors,
maintainers
users,
for
making
it
happen.
A
Some
of
these
initiatives
are
still
in
progress
because
they
are
big
enough,
but
yeah
feel
free
to
check
it
out,
and
what
I
know
is
that
the
2022
post
is
coming
soon,
so
yeah
keep
an
eye
on
that
cool
and
all
right.
I
saw
this
also
from
brahav
a
project
you
know
like
summarizing.
A
All
the
issues
and
vrs
in
the
like
python
build
packs
ecosystem,
and
I
thought
it
was
really
cool,
because
if
a
new
contributor
is
a
quick
way
to
see
where
I
could
start,
I
mean
I
see
all
the
good
first
issues
here
and
our
experience
with
this
is
that
issues
labeled
this
way,
opening
a
big
opportunity
for
for
new
contributors
to
come
up
and
at
least
casual
contributors,
which
is
the
majority
of
the
contributor
base
of
open
source
projects
these
days.
A
So
I
thought
it
was
it's
cool,
I'm
not
sure
if
the
other
ripples
have
this,
and
I'm
not
sure
if
you
want
to
do
this,
but
I
thought
it
was
really
cool.
I'm
a
big
fan
of
the
of
the
github
project
boards
and
yeah.
Thank
you
rob
for
doing
this
and
will
be
interesting
to
explore
this
for
other
peoples.
G
Sure
I
can't
really
take
too
much
credit
because
they
already
these
product
boards
already
exist
for
essentially
all
of
the
other
language
families.
It
was
really
in
a
mission
that
python
didn't
exist
if
you
click
on
the
projects,
tab
you'll
see
that
all
of
your
language
families
have
these
project
boards
already.
So
these
are
already
exist
for
any
contributors
looking
to
see
what's
going
on
in
different
language,
families.
E
Yeah,
I
just
added
this
because
I
was
just
scrolling
through
our
updates
previously
and
noticed
that
this
wasn't
an
update
that
was
given.
We
have
released
php
version.
1.1.0
is
a
full
rewrite
of
php,
build
pack
based
on
the
rfc
and
so
yeah.
There
is
a
blog
post
coming
soon
on
that
as
well.
E
It's
written
up
and
we're
just
doing
the
last
refinements
and
trying
to
space
out
our
blog
post
release
a
little
bit
so
it'll
be
out
in
the
next
next
day
or
two
yeah,
and
I
just
figured
that
people
ought
to
be
aware
that
there's
shiny
new
php.
A
H
I
wanted
to
ask
a
question
about
doing
dependency
updates,
so
we
we
have
a
series
of
our
own
pipelines
that
do
dependency
updates
of
various
things
inside
the
packs
and
we're
using
the.
I
think
it's
the
update,
dependency
and
update
package
dependency
commands
inside
lib
pack
to
do
that.
H
We
noticed
with
the
release
of
jam
that
came
out
this
week,
that
there's
also
the
ability
to
to
perform
dependency
updates
and
what
would
be
the
recommended
approach
to
do
that.
E
So
gm
dependency
update
the
command
relies
on
depth
server
or
something
that
conforms
to
the
depth
server
api,
so
you
can
point
it
at
either
of
those
basic
apis.
If
that's
not
what
you're
doing
you
might
struggle
to
integrate,
it
super.
Well,
I
think
that
it's
something
that
we're
potentially
looking
at
changing
with
our
explorations
into
how
we
do
update
dependencies
and
what
we
should
be
expecting,
but
I
don't
I'm
not
working
on
any
of
that
exploration
work,
so
I
don't
want
to
speak
unturned.
H
D
Yeah,
I
was
just
gonna
say
that
force
and
I
were
talking
not
too
long
ago
about
trying
to
kind
of
unify
some
of
those
tools
and
there's
a
good
amount
of
work.
I
think
on
the
roadmap
for
2022,
in
terms
of
like
making
the
dev
experience
easier,
which
would
be
like
unifying
some
of
these
tools
and
and
also
just
the
way
that
we
handle
dependencies
too.
So
you're
probably
fine
the
way
you're
doing
it
now,
but
you
know
things
will
likely
be
evolving
and
hopefully
getting
better.
H
Actually,
the
depth
server
thing
is
really
interesting
for
us,
because
we
have
a
scenario
where
we're
trying
to
update
some
internal
build
packs
and
we
don't
actually
have
network
access
to
them
at
the
from
the
tools
that
are
doing
things
so
we're.
We
currently
have
like
a
very
much
a
split
system
in
terms
of
ci
and
cd
to
try
to
do
this,
but
having
something
like
this
actually
was
what
we
were
thinking
of
building.
H
That's
that's
really
interesting.
Thanks.