►
From YouTube: Working Group: May 16, 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
All
right,
let's
get
started
please
if
y'all
can
sign
into
the
notes
document
appreciate
that
could
I
start
by
getting
a
designated
Note
Taker
for
today.
A
All
right,
thank
you.
Next
up,
we
have
go
into
outstanding
rfcs.
Oh
sorry,
go
on
one
vacation,
I'm
a
little
rusty
forget
how
to
do
everything
all
right.
Let's
start
from
the
bottom
work.
Our
way
up
propose
that
we
remove
YJ
from
the
binary
stack.
A
I
believe
that
we
wanted
to
keep
it
open,
maybe
one
more
week,
and
then,
if
we
don't
get
a
response
from
this
concerned,
Community
member,
then
we
just
go
forward
with
it.
If
the
stacks
Team
approves
it.
A
Awesome
next
up,
we
have
decoupled
dependencies
from
build
packs.
I
was
out
last
week.
I
did
not
have
a
lot
of
time
to
go
over
developments
on
this.
A
My
plan
is
to
get
into
this
this
afternoon,
hopefully,
and
make
some
edits
and
update
update
some
stuff,
but
it
doesn't
look
like
really
much
new
conversation,
as
of
last
week
has
happened,
seems
like
things
are
slowing
down,
so
I
will
go
over
and
try
and
answer
as
many
of
these
as
I
can
and
then
I
might
open
it
up
and
start
asking
for
reviews
from.
A
C
A
A
All
right
next
up,
we
have
proposal
to
publish
multi-arch,
build
packs.
Don't
think
that
Jericho
is
here,
I'm
not
super
familiar
on
any
of
the.
A
A
Okay:
next
up,
we
have
ADD
bionic
end
of
support,
RFC.
A
A
The
end
of
service
date
for
bionic
is
coming
up
at
the
end
of
this
month.
I
think
it
is
the
31st
of
May.
So
if
we
can
get
people
to
start
taking
a
look
at
this
and
put
approvals
on,
it
would
appreciate
that.
A
Awesome
Moving
on
in
a
clip
and
then
the
final
one
is
RFC
for
tramad,
build
pack,
Anthony
I
think
that
you
are
here.
You
have
any
comments
on
this
yeah.
D
So
there
are
a
few
comments
you
know
so
following
the
well,
that's
the
walking
group,
meaning
there
were
a
few
comments.
Eight
comments,
I
still
think
that
from
the
look
of
it,
we
could
make
it
work.
So
I
need
to
address
all
comments.
There
are
some
suggestions,
so
rephrase
few
things
and
make
it
I
I
believe
that
was
the
main
issue
make
it
super
clear
that
it's
optional.
D
E
E
My
one
request
would
be
to
make
sure
that
the
RFC
itself
actually
contains
a
warning
about
the
damage
that
could
be
done
with
it,
because
the
RFC
is
going
to
stand
as
the
documentation
moving
forwards
for
this
yeah,
the
evidence
of
where
it
was
so
providing
there's
like
a
big
box
in
there
that
says:
Please,
Don't,
Judge
mod
everything
with
plus
X,
because
it
fixed
your
problem.
Then
then
that
will
be.
D
So
yeah,
hopefully
last
week,
then
should
be
ready
to
to
go.
I
mean
less
meaning.
Next
meeting
sorry.
A
A
In
that
case,
then,
I
will
not
belabor
the
point.
Cnb
updates
and
questions
I
have
been
out,
so
it
did
not
have
any
CNB
updates.
Personally.
Are
there
any
in
The
Ether
that
should
be
brought
here.
E
I
have
a
minor
one-
that's
probably
not
important
to
most
people.
The
extension
Tamil
schema
didn't
mention
the
fact
of
whether
we
could
include
metadata
on
the
end.
I've
discussed
that
with
Natalie
and
she's
agreed
that
that's
probably
an
oversight
and
we'll
just
PR
that
in
so
that
that
will
make
I
think
at
least
me
and
Michael
breathe
a
little
easier.
Yes,
yes,
for.
B
E
Yeah
and
in
a
similar
note,
I've
been
chatting
with
Daniel
about
lib
CMB
and
updating
that
to
include
support
for
extensions
which
is
needed
because
I'm
blocked
on
the
Java
extension
to
be
able
to
be
built
because
the
Java
Poquito
Bill
packs
use
octo,
also
known
as
pipeline
Builder,
to
generate
all
the
pipelines
and
octo
is
based
on
lib
CMB.
So
at
the
moment,
I
can't
run
that
against
a
project.
E
That's
based
around
extensions,
because
the
very
first
thing
it
does
is
looks
for
build
a
buildpack.tommel
to
read
all
the
information
it
needs
where
I
could
Hack
That
and
tell
it
to
go,
look
for
extension
tunnels
as
a
backup.
Then
you
very
quickly
start
running
into
problems
that
you've
got
the
wrong
data
or
in
the
wrong
struct
being
passed
to
the
right
methods
and
that's
not
fun
either.
E
So
you
know
long
story
short
we're
going
to
try
and
address
that
upstream
and
get
lip
CMD
to
have
some
support
in
it
and
Spike
octo
to
run
against
the
newer
version
of
Liv
CNB.
A
A
The
only
other
thing
I
can
think
of-
and
it
may
have
been
brought
up
last
week-
is
that
the
extensions
work
has
actually
landed
as
well.
I
think
that
that
was
something
they
were
pushing
for
for
kubecon
and
they
got
it
out
like
the
day
they
were
giving
the
presentation
on
it.
A
So
yeah
I
think
that
that's
out
project
updates
the
only
project
that
is
I
believe
that
we
have
some
of
the
election
stuff
for
paquetto
through
the
cff
finalized.
I
need
to
have
a
conversation
with
Dan,
because
a
lot
of
that
happened
like
Thursday
of
last
week,
I
think
so.
I
need
to
have
conversation
with
Dan
about
the
actual
process.
I
think
it
will
I
think
it
will
be
announced
later
this
week
and
the
nomination
process
will
begin.
Some
of
it.
A
I
think
has
been
laid
out
in
the
cff
community
or
Cloud
Foundry
Community
already,
but
I
will
get
actual
links
with
actual
wording
from
people
that
know
what
they're
actually
talking
about
and
I
will
post
those,
probably
in
just
like
General,
for
the
piccato
slack
and
I'll,
probably
also
duplicate
that
post
into
core
Dev
as
well
I'm.
Trying
to
get
some
time
with
the
end,
to
figure
that
out.
A
Any
other
project
updates
that
people
would
like
to
talk
about.
A
All
right,
finally,
we
have
open
mic
question,
slash
discussion
topics,
and
the
first
one
in
here
is:
where
are
the
paquetto
P
URLs
coming
from
pearls?
Purls
I
never
actually
figured
out
what
you're
supposed
to
call
them.
C
C
Like
the
the
entries
for
from
from
my
side,
we've
realized
lately
with
the
with
the
tool
that
was
integrating
with
s-bombs
that
some
of
the
things
like
some
of
vulnerabilities
weren't
detected
based
on
these
Xbox,
and
then
we
looked
a
little
closer
and
it
would
turned
out
like
the
P
URLs
that
were
only
used
like
they
were
not
used
using
the
cpes
for
detecting
things,
because
osv
def
was
used
for
finding
them
and
with
the
p
URLs
nothing
was
detected
which,
like
I,
don't
really
wonder
about
like
it's
really
just.
C
It
looks
like
invented
by
paquero
just
to
provide
a
value
there
and
if
it
wouldn't
be
required,
like
it's
just
a
question,
if
it
would
be
better
to
provide
Xbox
only
containing
cpes
and
no
made
up
P
URLs
yeah.
It's
like
nobody
like
just
one
example.
There's
a
package
generic
sub
machine,
something
nobody
will
report
vulnerabilities
for
that
yeah.
So
like
you,
won't
find
anything
with
it.
Yeah
and.
C
For
Tomcat
for
node,
for
others,
I'm
pretty
sure
you
just
won't
find
any
vulnerabilities
with
it,
and
then
the
information
is
kind
of
it's
useless
and
it's
even
dangerous,
because
you
might
believe
that
something
is
good
right.
I
mean
whatever
tooling
we
use
I,
don't
know
if
it
would
have,
but
it
might
have
actually
indicated
that
it
can't
find
anything
because
we
don't
provide
P
urls
right.
That
would
be
the
better
message
that.
A
Is
that's
good
feedback
I
think
that
currently
we
we
try
and
generate
the
best
prls
that
we
can
by
hand,
because
when
we
were
first
looking
to
implement
this,
there
was
no
tooling
for
just
like
or
even
database
for
like
given
a
package.
How
would
you
actually
prescribe
that
package
in
any
meaningful
way
like
like
a
CPE
right,
and
so
we
kind
of
reached
out
at
some
points
to
the
to
the
PE
URL
Consortium
and
asked
them
like
like
explained
our
thing
and
asked
like
hey
like
these?
A
Are
the
these
are
the
kind
of
packages
that
we're
doing?
This
is
how
we're
installing
these
things,
and
they
gave
us
some
advice
on
how
we
might
want
to
do
that
and
then
I
haven't
really
done
any
further
investigation
on
whether
or
not
they've
built
out
a
database
or
not
I
think
that
go
ahead.
I.
C
I
hadn't
looked
too
deeply
into
it,
but
it's
like
maybe
there's
no
real
good
answer
right
like,
for
example,
you
can
find
vulnerabilities
for
a
tomcat
in
osv
death.
If
you
accept
the
fact
that
this
is
handled
as
a
maven
package,
but
like
it's
not
right,
it's
not
some
even
dependency
either
so
I,
don't
know
if
there's
really
good
P
URLs
or
if
that's
just
a
project
in
its
infancy
or
like
maybe
mature
infancy,
I
think
it's
older
I,
don't
know,
but
I
think
yeah.
It
might
be
worth
a
thought.
A
I
think
it's
something
that
we
could
definitely
talk
about
and
look
back
at
I
think
it
would
be
a
difficult
thing
for
us
to
I.
Think
we'd
have
to
come
up
with
a
full
RFC
ruling
on
it.
We'd
have
to
basically
say
like,
and
in
the
case
where,
like
with
Tomcat,
we
could
we
could
theoretically
construct
some
seemingly
meaningful
in
the
same
way
that
we
do
with
cpes
right,
like
you
have
to
construct
the
CPE
by
like
going
to
nist
and
being
like
Oh
every
time
they
report
a
golang.
It
has
this.
You
know.
B
A
String
right
and
then
getting
more
or
less
specific,
so
maybe
looking
like,
unless
we
can
discover
that
there
is
a
certified
query
string
for
prls
like
through
Maven
talking
about
Tomcat,
then
maybe
we
don't
add
it
and
therefore
the
only
ones
that
we
can
do
are
the
validly
buildable
ones.
C
C
D
And
what
about
Apache?
So
since
you
were,
since
you
were
talking
about
Apache
Tomcat
as
an
example,
so
I
can
see
that
we're
downloading
it
from
we're,
not
downloading
the
archive
dependency.
D
D
C
It's
like
I
think
that
would
be
best
right
if
the
package
providers
would
actually
tell
what
they
should
be
called,
because
they
will
hopefully
have
a
security
response
process
that
will
funnel
whatever
comes
up
into
already,
also
making
sure
that
these
assignments
are
set
correctly,
but
I
think
that's
the
ideal
World
we're
talking
about
and
not
the
one
we
live
in.
A
Yeah
I
think
that
that's
the
idea
around
prls
and
to
be
fair,
I,
think
when,
like
Sophie
and
I,
were
originally
doing
a
large
chunk
of
sort
of
initializing,
the
s-bomb
work
we
kind
of
tried
to
cover
as
many
of
our
bases
as
possible
and
said.
Well,
we'll
wait
until
users
come
back
and
say
anything
about
any
of
these
and
you're.
You
are
currently
the
first
person
to
bring
up
a
problem
with
us
hand
making
PRL.
So
maybe
that
is
an
indication
that
we
should
take.
Take
it
seriously
foreign.