►
From YouTube: Working Group: February 7, 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
it's
about
six
minutes
past
we
should
probably
get
started.
Do
we
have
any
new
faces
today?
Anyone
would
like
to
introduce
themselves.
C
A
If
you
could
just
and
yeah
obviously
introduce
yourself
to
your
name,
and
you
know
what
you're
using
paquetta
book
packs
for.
C
Fantastic,
so
my
name
is
Anthony
dad
and
I
have
joined
last
week,
VMware
and
in
particular
the
tanzo
team,
in
the
sense
that
I
am
I,
won't
be
responsible
for
the
Java,
build
packs
at
tanzu,
including
the
packet
of
java,
peel
packs,
as
well
as
a
vitamzu
ones,
so
I've
been
using
buildbacks
in
the
past
before
joining
VMware
for
demos
and
even
at
at
a
bank
to
actually
you
know,
streamline
building
of
images.
C
You
know
all
the
advantages
sharing
via
command
common
based
practices
as
well
common
components
across
an
organization,
a
Dutch
organization,
yeah,
that's
about
it
for
me,
I
have
also
maybe
just
one
presentation:
I
have
a
special
interest
in
arm
64
compatibility.
C
I
know
some
people
I've
already
had
investigated
a
little
bit
and
not
to
name
them
Dynamics
up
yeah.
Apart
from
that
pretty
happy
to
be
here.
A
Perfect,
thank
you.
So
much
I
realized
I
forgot
to
ask
for
a
designated
Note
Taker,
so
Anonymous
unicorn.
Thank
you
for
writing
down
our
new
face.
Could
I
get
a
note,
take
care
for
this
week.
A
Right,
I
guess
we
should
probably
just
go
ahead
and
get
into
our
agenda
so
as
it
is
the
first
meeting
of
the
month,
we
are
going
to
be
looking
taking
a
look
at
the
roadmap
And
discussing
some
updates
to
it.
I
don't
know
how
up-to-date
it
is.
It
says
it's
the
2023
roadmap
I'm,
looking
at
it
right
now,
I'm,
not
sure
that
it's.
A
Right,
oh
my
gosh,
it
is
no
I
got
I
got
absolutely
sniped
by
this.
F
We
so
we
did
do
a
bit
of
roadmap
review
last
week,
but
there
weren't
a
lot
of
folks
here
with
context
on
a
lot
of
the
items.
So
if
folks
feel
like
it's
worthwhile
to
take
the
time
to
do
that,
we
could
do
that
today,
like
a
revisiting.
But
if
not,
then
that's
also
fine.
A
There's
only
a
couple
of
items
on
the
list
right
now,
so
if
we
wanted
to
just
take
a
quick
look,
how
does
that
sound,
then
everyone
that.
A
Let
me
fix
fix
my
camera,
so
I
can
see
everything
all
right
all
right.
Let's
start
off
with
things
that
are
in
progress.
First
up
we
have
node.js
Roc
14
support,
yarn,
Berry.
F
A
Let's
talk
about
the
other
one
that
is
currently
in
progress
which
is
default
behavior
for
build
Pack
set
language,
Eco
system,
environment
variables-
oh
my
goodness,
I
think
that
there
is
probably
we
needs
to
be
a
little
bit
of
updating
to
this.
I
know
for
a
fact
that
the
situation
in.net
core
has
changed
quite
a
bit.
So
I
might
move
this
back
to
needs
investigation
and
go
through
and
we
gotta
do
another
re-audit
of
how
things
are
looking.
A
A
G
Yeah
I'm
here
and
we
have
this
prioritized
to
look
into-
we
just
have
not
gotten
to
it
yet,
but
it's
definitely
on
our
radar
and
we
will
certainly
be
taking
a
look
very
soon
and
hopefully,
by
the
time
next
time
we
do
this
meeting.
Hopefully
we
will
have
done
this.
A
Next
up
well
I,
just
we
just
looked
at
this.
One
distribute
build
packs
via
Docker
hub
I
saw
that
there
was
a
pipeline
Builder
update
the
other
day
that
added
optional
stuff
to
do
Docker
Hub
things,
which
is
maybe
the
most
non-specific
sentence.
I
could
have
said
about
that.
But
I
haven't
verified
this
with
divider
Sullivan
or
Dan,
and
I
know
that
on
the
rust
end,
there
is
still
some
pipeline
changes
that
we
are
trying
to
get
through.
A
So
I
will
leave
this
open
for
the
time
being
and
point
David,
O'sullivan
and
Dan
acouza
at
this
as
well.
Take
a
look.
A
A
A
And
second,
we
have
Implement
rfc-006
reduced,
build
time,
complexity
for
net
runtimes.
A
We
added
some
backwards
compatibility
into
the
new
build
pack
that
was
proposed,
so
this.net
core
asp.net
runtime
build
pack
that
would
allow
build
packs
that
required
the
old
build
plan
API
to
continue
to
function
until
we
1.0.net
core
which
allowed
us
to
remove
or
to
Archive
the
old,
build,
packs
and
kind
of
effectively
get
rid
of
their
provision
API.
A
So
with
that,
basically
the
we
have,
we
have
succeeded.
We've
been
able
we've
removed
basically
as
much
surface
area
as
we
can
until
we
completely
deprecate
the
old
build
plan
API.
So
we're
calling
this
closed
out
and.
B
A
And
then
we
have
stuff
that
is
planned.
We
typically
go
over
the
plan
stuff
as
well,
and
give
an
update
on
that
correct.
A
Okay,
starting
from
the
top.
We
have
remote
debug
work,
and
this
looks
about
as
sparse
as
I
normally
think.
It
looks.
H
I
think
the
thing
we
were
planning
to
look
at
targeting
next
was
node.js,
this
one's
relatively
straightforward.
As
far
as
implementation
goes,
node.js
has
like
a
flag
or
a
couple
of
flags
that
you
can
set
when
you
actually
start
the
node
runtime.
That
just
say,
like
spin
up
a
second
are
like
attached
to
a
port
so
that
you
can
have
this
kind
of
like
debug
server,
be
able
to
like
connect
to
the
process
and
manage
it
and
I
think
we
just
need
to
like
specify
those
flags
when
the
environment
variable
is
set.
H
So
there's
a
type
of
thing
that,
like
if
folks
in
the
open
source
Community,
were
interested
in
like
the
barrier
to
implementation.
It's
pretty
low.
It's
not
like
a
lot
of
work
to
get
remote,
debugging
type
functionality
working
in
a
node
thing,
but
otherwise
I
know
the
maintainers
for
node
at
some
point
were
planning
to
get
around
to
it.
Probably
sometime
in
the
next
couple
of
months,
foreign.
A
That's
fair,
all
right,
that's
good!
It's
a
great
update,
at
least
here
in
one
of
these
is
potentially
in
progress.
A
A
I,
don't
have
any
updates
on
this
as
a
Content
maintainer
or
anything
like
that.
It's
just
been
kind
of
placed
on
the
back
burner
as
we've
been
trying
to
pick
up.
Other
maintainers
should
work
and
that
sort
of
thing.
H
What's
the
default
setting
some
text
that
says
what
it
does,
I
think
we
wanted
to
do
the
same
thing
on
the
packet
side
before
we
got
to
a
point
where
we
could
then
have
some
automation
that
basically
just
scrapes
all
of
that
configuration
information
and
presents
it
in
a
like
a
more
easily
digestible
format
on
the
documentation
pages.
H
So
I
don't
know
as
far
as
like
progress
goes.
I
don't
think
anyone
has
looked
into
this.
But
if,
if
someone
was
interested
in
implementing
such
a
thing,
I
think
the
next
step
would
be
like
some
sort
of
support
for
that
type
of
configuration
to
be
read
in
by
a
packet
based
Bill
pack,
so
so
modifications
to
pack.
It
would
probably
be
the
next
step.
A
We've
also
some
something
to
think
about,
as
well
as
we've
been
trying.
We've
been
shifting,
at
least
on
the
packet
side.
Our
approach
to
how
we
load
in
environment
as
well
in
particular,
I,
think
a
good
example
of
that
would
be
like
nginx
or
httpd,
where
we
try
and
not
query
Os
or
environment
variables,
all
the
time,
and
we
try
and
sort
of
load
them
all
up
in
to
an
object
that
can
be
passed
around
just
because
that's
kind
of
easier
to
Intuit
over
and
it
does.
A
You
know,
fancy
things
like
parses
for
you
and
that
sort
of
thing
could
be
potentially
something
for
us
to
look
into
as
well.
But
I
don't
want
to
actually
add
more
to
the
size
of
the
story.
H
A
A
All
right,
I
think
that
that
brings
us
up
to
data
on
our
roadmap.
Are
there
any
questions.
H
The
only
other
thing
is,
we
have
items
that
were
basically
brought
up
as
like
kind
of
the
larger
2023
roadmap
that
were
outlined
in
this
blog
post
and
I
just
wanted
to
make
sure
that
like,
even
though
we
don't
have
issues
yet
for
them
and
they're
they're
not
yet
appearing
in
the
the
roadmap
that
you
see
here.
H
H
So
like
introducing
new
Stacks
kind
of
figuring
out
what
our
Builder
story
is
going
to
be
I
know,
there's
already
an
open
RFC
about
language,
specific
Builders,
but
like
really
trying
to
figure
out
what
that
looks
like
going
forward
how
we
can
scale
out
that
kind
of
thing
when
we
have
more
build
packs
and
more
languages
and
more
Stacks.
You
know
it's
just
going
to
be
a
lot
more
kind
of
combinatoric
permutations
of
things,
and
how
do
we
make
that
reasonable
support
and
easy
for
users
to
understand?
H
So
those
are
kind
of
like
the
high
level
things
we'll
be
mapping
out
some
more
kind
of
specifics,
of
what
we're
planning
to
do
in
those
areas.
But
yeah.
If
you
haven't
already
feel
free
to
read
the
blog
post
and
then
there
are
some
discussion
topics
that
are
attached
to
each
one
of
the
sections
where,
like
I'd
like
to
see
that
kind
of
further
discussion
of
what
we're
planning
to
do
start
to
happen.
A
All
right,
I
think
that
we
oh
excuse
me
I,
think
that
we
can
launch
into
the
next
segment
of
our
meeting.
Let
me
check
that
I
actually
know
what
that
is.
It
is
outstanding
rfcs.
A
In
that
case,
should
I
guess
it
is,
is
it
Mark
status
block
yeah
all
right?
It's
great.
B
A
Are
there
any
updates
on
this?
It
looks
like
there
was
a
post
four
days
ago.
A
Anthony,
it
looks
like
you.
I've
been
diving
into
this
a
little
bit.
C
Yeah
yeah
just
a
bit,
so
there
are
two
things:
they
are
not
exactly
the
same
issue
but
right
now
we
the
default
version
for
the
Java
beer
packs,
is
11.
and
medium
Frameworks
such
as
require
Java
17.
So
you
can
imagine
that
sometimes
that
can
it
can
cause
a
trouble
because
of
that.
So
so
there
is
the
the
matter
of
the
of
the
default
Java
version.
C
So
it's
a
different,
RC
and
I
think
it
was
approved
this
morning,
so
yeah
the
default
version
is
going
to
move
to
Java
17
in
a
month
or
so,
and
then
I
think
the
this
over
issue
that
you're
looking
at
is
probably
something
that
is
related
to
to
being
able
to
to
let
the
user
choose
the
the
Java
version
and
there
were
suggestions
to
actually
be
smart
about
it
and
try
and
detect
what
is
the
Java
version
that
is
required
by
the
project
so
having
yeah
go
ahead.
C
E
I
can
add
on
to
that.
So
it's
a
colleague
of
of
mine
and
then
actually
who
wrote
that
RC
so
so.
The
idea
here
was
that
kind
of
the
detection
logic
for
the
Java
version.
It's
all
part
of
lip
jvm
currently,
so
that
feels
kind
of
wrong
that
that
the
lip
jvm
looks
at
files
that
are
actually
in
the
area
of
other
build
packs
right.
E
So,
for
example,
the
executable
jar
is
actually
responsible
for
executable
charts
right,
but
the
lip
jvm
does
look
at
the
meta
information
of
the
executable
jar
build
pack,
and
we
had
this
idea
that
actually,
the
the
Java
pack
as
a
whole
could
look
at
the
poem
and
detect
that
the
Palm
requires
a
certain
Java
version
and
therefore
make
sure
that
this
Java
version
gets
installed
automatically
similar
to
how
it
does
it
for
for
the
executable
char,
based
on
the
meta
info
that
is
available
there.
E
I
From
my
point
of
view,
what
this
RFC
would
need
is
more
people
jumping
in
and
discussing
because
it's
a
little
bit
about
back
and
forth
between
complexity
of
using
the
build
plan
for
orchestrating
this.
So
you
could
delegate
the
responsibilities
right.
The
maven
build
pack
could
know
how
to
read
upon
the
Apache
Tomcat,
build
packs
could
know
the
minimum
versions
of
different
Tomcat
versions
and
other
things
and
the
potential
complexity.
This
brings
to
the
built
packs
is
more
like
the
side.
I
Daniel
is
currently
choosing
here
in
particular,
hinting
at
the
current
problem
with
Java,
17
and
spring
is
going
to
be
solved
by
bumping
the
version
so
I
guess
that's
the
back
and
forth,
and
a
bit
stall
and
stallmate
there.
I
So
I
think
Daniel
went
on
and
started
to
kind
of
try
to
collect
some
use
cases
and
figuring
out
if
there
are
use
cases
that
can't
be
supported
by
the
current
model,
where,
where
lib
jvm
decides
a
lot
of
things
and
users
have
to
in
in,
if
in
doubt,
present
the
version.
From
my
point
of
view,
it's
showing
quite
a
lot
right.
E
Maybe
one
thing
to
add
here:
I
guess:
that's
actually,
the
the
mechanism
that
this
RFC
proposes
is
exactly
what
node
detect
does
to
like
decide
on
the
Node
version
right,
so
it
uses
the
build
plan
there
and
to
negotiate
which
node
version
should
be
used
yeah.
It
shouldn't
be
too
complex
right,
it's
already
done
in
the
notebook
or.
I
What
it's
worth
I
think
there
should
be
something
done
to
make
the
build
plan
more
transparent
to
the
user.
So
if
something
goes
wrong
with
the
build
plan,
it's
really
hard
to
figure
out,
but
I
think
this
can
be
solved
by
logging
output
by
or
like
either
by
providing
debug
logs
or
even
provide
some
proper
output.
Right
I
mean
it's.
You
can
tell
the
user
why
you
chose
a
particular
version
of
java
that
you
used
or
node,
but
it
does
require
effort.
Otherwise
it's
like
undebuggable.
A
And
then
we,
you
know
say
we
elected
this
one
and
then
the
way
that
we
end
up
electing
a
version
is
based
on
like
a
handmade
priority
graph
of
sort,
known
sources
where
we
say
you
know
if
it
comes
from
I
I,
wouldn't
know
them
off
the
top
of
my
head
right
now
but,
like
you
know,
if
it
comes
from
your
package,
Json,
that's
a
higher
thing
than
something
else,
such
as
a
higher
thing
than
something
else,
but
yeah.
No,
the
build
plan
is
unfortunately
opaque.
I
I
think
this
could
be
changed
by
either
like
logging,
something
in
detect
or
by
actually
approaching
upstream
and
making
sure
that
the
life
cycle
actually
informs
better
about
this
and
I
think
you
can
choose
how
how
complicated
you
make
it
I
mean
you
can
always
opt
out
and
go
back
to
the
current
default,
which
is
the
user
has
to
pick
the
version
right.
So
you
could
say:
oh
there's
a
conflict.
I
can't
solve
it,
I'm
not
going
to
set
up
this
graph
of
Precedence
order.
Instead,
I'm
telling
the
user
that
I
can't
right.
I
There's
I,
don't
know
what
your
your
palm
requests
Java
eight,
but
your
framework
once
Java
17,
there's
no
way
I
can
decide
this
point.
You
figure
it
out,
so
I
I
think
you
can
provide
a
good
User.
It's
the
main
point,
I'm
I'm,
seeing
there
is
I
I
think
this
is
exactly
what
build
packs
promise
right.
You
don't
have
to
figure
this
out.
I
That
spring
requires
a
newer
Java
version,
and
these
kind
of
things
so
I
would
really
like
to
see
some
support
of
that
and
I
can
see
these
use
cases,
but
I
do
understand
the
the
complexity
that
this
brings
and
that,
in
particular,
the
complexity
that
might
leak
to
the
user.
In
terms
of
do
I
understand,
the
selection
process
needs
to
be
well
orchestrated.
D
B
I
Oh
yeah
user
Choice
has
to
be
on
the
top
of
the
of
the
list.
Of
course,
if
you
request
a
certain
Java
version,
if
it's
Tom,
if
if
it's
Java
8
and
you
want
to
run
it
with
spring
boot
3,
then
that's
your
problem,
but
we
should
pick
that
version
and
it
won't
work,
of
course,
but
that's
the
same
on
your
machine
right.
If
you
install
Java,
8
and
start
spring,
it
won't
work
so
yeah
yeah.
C
I
just
wanted
to
add
something
we
forgot
to
to
the
comparison
with
with
node.js
I.
Think
you
know,
GS
you
you
specify
it
I
mean
in
package.json.
You
can
specify
the
version.
You
know
you
can
yeah.
You
can
definitely
specify
version
in
a
in
a
single
way
right
in
a
singular
way.
I
think
the
difficulty
with
Java
is
that
there
is
no
there's,
not
one
single
way
of
specifying
the
version
of
java
that
you
want
from
your
perm
or
from
your
build.gradle
in
Spring
boot.
By
default.
C
E
B
I
I
think
the
particularly
odd
thing
is
if
there
is
a
single
source
for
a
particular
version
like
you
use
spring
boot
3
or
you
use
a
tomcat.
That
requires
a
certain
minimum
version.
Even
this
is
not
considered
we.
We
could
even
implement
it
in
a
way
where,
as
soon
as
there's
a
conflict,
we
just
opt
out
and
say,
yeah.
Sorry,
here's
why
we
don't
know
which
version
to
pick.
Please
select
it.
What
currently
happens
is
the
default
version.
11
is
picked
and
that's
the
wrong
one
for
the
most
recent
spring
framework.
I
I
think
that's
that's
particularly
bad.
This
will
be
solved
by
bumping
the
version,
but
I
don't
know
when
the
next
time
we'll
discover
a
problem
like
this
again,
hopefully
we'll
Define
also
a
regular
update
process.
So
it's
like
Java
21
is
around
the
corner,
I
think
and
I
think
we
aligned
on
let's
say
after
one
year
one
year
after
release,
we'll
just
bump
the
version.
So
maybe
we'll
run
into
these
problems
less
frequently
by
being
more
on
the
modern
side
of
versions,
but
I
don't
know.
J
You
actually
have
to
bring
the
whole
of
Maven
into
being
so
that
it
can,
you
know,
basically
evaluate
all
of
its
stack
variables
and
then
you
can
ask
that
what
you
want,
and
the
current
preferred
way
for
doing
that
with
Maven
is
to
invoke
the
command
line
and
ask
it
what
the
property
is.
So
there's
no
actual
way
to
invoke
Maven
to
obtain
the
version
that
Java
would
be
using
for
a
given
Maven
project
via
a
direct
API
call.
J
You
have
to
go
results
using
like
system
exact
to
invoke
Maven
as
a
command,
which
is
crazy,
but
I
can
kind
of
see
why
they
went
that
way.
It's
not
easy.
I
can
believe.
Sbt
would
be
somewhere
as
well
online
again
and
all
the
other
various
ones
I've
messed
with
a
lot
of
them
to
try
and
resolve
this.
It's.
C
That,
even
worse
than
that,
that
would
actually
mean
that
you
would
need
to
you.
You
would
I
mean
if
you
were
to
actually
try
and
find
you
know
the
the
right
version
you
know
going
through
the
going
for
the
hierarchy,
then
you
would
need
to
have
Maryland,
so
you
would
need
to
have
Java
as
well.
So
unfortunately,
I
think
at
the
point
where
we're
doing
the
detection
we're
not
there
yet
I
mean
we,
don't
we
don't
have
a
Java
runtime
yet
so
yeah.
E
Yeah
I
was
thinking
like
kind
of
supporting
the
90
case
there.
Maybe
where
I
guess
most
people
don't
go
crazy
with
their
Java
version
and
do
this
with
some
templating
that
is
fetched
from
some
other
source
right.
It.
J
Becomes
more
common,
the
larger
the
organization
is
that's
doing
the
development
and
the
more
structured
their
Dev
teams
become.
You
start
having
things
where
the
parent
Palm
will
be
supplied
via,
like
the
architecture
team
that
includes
all
the
dependencies
that
these
projects
are
allowed
to
use
or
should
be
using
that
kind
of
stuff,
and
that
will
also
lock
down
the
Java
version.
J
As
for
the
chicken
and
egg
problem
about
needing
Java
to
run
Maven
but
needing
Maven
to
find
out
what
version
of
java
you
need
to
run,
Maven
with
you
can
cheat
if
you
pre-compile
something
that
has
the
maven
jars
as
a
native
executable,
and
then
you
can
drive
that
directly
and
it
won't
need
a
jvm.
So
that
was
my
get
out
when
I
hit
the
end
of
that
at
the
end
of
the
day,
was
to
write
a
small
program
and
compile
it
as
a
native
Java.
App
that
then
ran
didn't
need.
I
There's
even
like
Tomcat
has
like
documented
minimum
Java
versions.
I
mean
they
are
far
lower
than
17,
but
I
think
that's
like
the
newest
might
be
now
on
17.
I'm,
not
sure
about
that.
So
maybe
that
runs
out
of
the
problem
space.
Once
we
are
on
more
recent
versions
of
java
as
the
default
but
yeah
these
sources
would
be
more
clear
in
terms
of
what
they
want,
but
anyway.
H
Yeah,
even
for
the
node.js
build
pack,
it's
not
that
during
the
build
phase,
the
build
pack
goes
out
and
figures
out
what
version
the
user
specified
say
through
like
an
environment
variable
like
that
flattening
of
everything
all
the
sources
of
where
a
version
could
be
specified.
It
all
happens
in
detect
such
that
when
you
get
to
the
build
phase
you're.
H
Just
looking
at
the
build
plan
like
the
build
pin
is
no
matter
what
is
the
source
of
Truth
at
that
point
in
time
to
say
how
do
I
figure
out
what
version
should
be
installed
so,
like
you
could
even
just
say
like
the
only
thing
that's
expected
here
is
that
during
detect,
Java
is
just
going
to
take
turn
that
environment
variable.
That's
the
toggle!
H
That's
currently
the
way
you
specify
the
version,
and
it's
just
going
to
inject
that
into
the
build
plan
so
that
by
the
time
you
get
to
the
build
phase
you're
only
looking
at
the
build
plan
and
you're
not
looking
at
environment
variables.
So
then,
at
that
point
further
on
other
things,
can
inject
versions
in
through
the
build
plan
from
other
sources.
H
A
I
think
in
an
effort
to
try
and
keep
us
moving,
I
would
like
to
move
on
to
the
next
RFC
sounds
like
there's
a.
B
A
Interesting
discussion
to
continue
to
happen
on
this,
though.
A
Seems
like
there
was
an
update
five
days
ago,
looks
like
commenting
the
cell
down
I'd
like
to
make
a
final
call
in
comments
for
both
with
February
7
2023
being
the
final
day
for
comments.
Slash
vote
thanks
all
right,
you
guys
better
get
on
it.
I
guess,
though,.
A
February
today,
February
7th
okay,
today.
A
All
right,
if
no
one
has
any
other
comments
on
this.
Let's
move
to
RSC
selecting
the
next
default
Java
version.
A
This
looks
like
it
has
approvals
any
comments
on
this.
It
sounds
like
and,
and
it's.
I
Something
that's
the
other
one.
We've
we've
spoken
about.
It
will
increase
the
default
Java
version
to
17
trigger
that
will
like
provide
some
documentation
about
about
the
future
of
how
this
will
be
done
and
announce
that
we'll
bump
the
default
and
these
kind
of
things
so
I
think
it's
going
to
be
merged.
I
guess
today
now
with
the
approval
and
the
end
of
the
final
voting
period,.
A
A
Let's
see
here,
we
have
a
cherry
across
node.js,
Bill
pack,
slash
extensions,
I
am
have
not
seen
this
one
I'm
going
familiar
with
it.
I
assume
that
you
all
talked
about
this
last
week.
D
H
D
Can
give
some
context
I
opened
this
one,
because
you
know
we're
working
on
an
extension
to
support
ubi8
in
that
extension,
we
need
to
do
in
the
some
of
the
similar
detection
in
particular
for
like?
Is
this
a
node
build
pack
or
not
want
to
make
that
match
exactly?
D
What's
in
the
rest
of
the
build
box,
because
we
really
just
want
to
you
know
we
really
want
to
just
replace
some
parts
of
the
of
the
node.j
node
engine
sub
build
pack,
and
so
ideally,
I
want
to
reuse
that
logic
and
I
I
can
do
a
little
bit
of
that
today
by
you
know,
using
things
from
the
existing
build
packs,
I'm,
not
sure
that
they're
necessarily
public,
though
I
also
noticed
that,
like
there's,
say
three
three
copies
of
the
same
code
and
a
couple
of
the
different
build
packs.
D
D
What's
the
name
of
node,
what's
the
name
of
npm
and
and
so
I'm
proposing
to
to
do
that
refactoring
to
let
those
pieces
I,
don't
think
it's
going
to
be
a
ton
of
code,
you
know
it's
probably
100
lines
of
code
or
less,
but
it
will
avoid
drift
and
and
make
it
so
that
we
can
reuse
it
more
easily.
I
D
Yeah,
there's
there's
and
it's
not
strictly
about
well.
Some
of
the
common
things
are
like
find
me
the
like
a
path.
So
it's
not
it's
not
solely
like
hey.
Is
there
a
package
Jason
and
is
there
a
version
so,
but
that
in
the
end,
most
of
them
who
support
that
so
I
think
you're
right
that?
That's
that's
a
good
analog.
A
All
right,
it
sounds
like
there
probably
needs
to
be
some
more
discussion
about
this
from
node.js
maintainers.
H
Yeah
the
reason
we
had
it
brought
up
originally,
this
was
open
just
as
an
issue
in
the
node.js
repo
and
I.
Think
the
node.js
maintainers
from
speaking
on
their
behalf,
are
inclined
to
accept
this
type
of
change
like
it's.
Something
we
think
would
make
the
build
packs
better.
It
would
be
better
to
reduce
the
shared
code
across
all
the
good
packs,
and
you
know
generally.
We
just
think
that
it's
probably
the
right
direction
as
civil
packs
kind
of
grow
in
scope
and
complexity.
H
The
thing
we
wanted
to
bring
up
and
why
I
had
Michael
open
it
as
an
RFC
and
propose
in
front
of
other
language.
Family
maintainers
is
just
that.
This
is
the
type
of
pattern
we're
starting
to
see
emerge
across
a
number
of
different
things
and
I
just
wanted
to
get
feedback
generally.
I
know
the
Java
folks
have
been
dealing
with
this
concept
through
live
jbm
for
a.
H
Their
feedback,
I
think
Dan
at
some
point,
had
some
comments
on
the
open
issue
and
then
I
just
wanted
to
get
feedback
from
other
maintainers
about
their
thoughts.
Generally
speaking,
I
think
in
the
long
run,
what
we're
probably
likely
to
do
is
open
up
a
separate
repository,
one
that
can
be
versioned
and
released
independently
from
any
one
of
the
build
packs.
I
know
that
at
some
point
we
had
discussed,
like
maybe
we'll
just
put
a
package
in
one
of
the
build
packs.
H
The
issue
becomes
like:
how
do
you
version
that
outside
of
the
versioning
cycle
of
the
build
pack
itself
just
introduces
a
bunch
of
complexities?
This
is
probably
going
to
have
to
be
its
own
repo
that
lives
separately.
Do
we
want
to
think
about
how
we
name
those
types
of
things
that
they're
like
easily
identifiable
across
the
organization?
So
there
are
some
kind
of
like
general
questions
and
just
some
feedback
that
we're
soliciting
outside
of
specifically
the
node
folks
I.
Think
conceptually
the
node
folks
are,
you
know,
would
approve
this
kind
of
change.
A
H
H
Are
there
other
language,
families
that
could
benefit
from
this,
and
if
they
do,
are
there
just
some
things
that
they
should
follow
that
are
kind
of
like
generally
agreed
upon,
so
that
this
doesn't
just
become
a
chaotic,
every
single
language
families
doing
something
slightly
different
granted
I
understand,
there's
going
to
be
differences
between
these
things.
H
A
I
I
I
I'd
be
curious
as
well.
If,
like,
we
also
found
some
commonality
like
I,
guess
amongst
a
larger
set
of
build
packs,
I
guess
most
of
the
time
when
we
see
that
we
would
move
it
into
the
larger
sort
of
Library
have
either
packet
or
lip
pack.
We
see
I,
guess
a
big
enough
swath,
but
this
is
just
sort
of
meant
to
be
100
language,
specific.
A
I
I
think
the
the
the
really
interesting
idea
in
around
like
detecting
whether
or
not
something
is
node
or
requires
node
is
highly
applicable,
like
for,
like,
like
dot
net
and
I,
assume
rupee
as
well
all
the
build
packs
who
themselves
have
node
requirements,
because
you
know
everything
uses
npm
and
makes
JavaScript
files.
So
I
like
that
idea,
that's
cool.
H
I
just
know
that,
like,
for
example,
like
dot
net
core,
has
these
like
project
files
and
I,
assume
that
the
project
file
is
probably
parsed
and
read
for
all
sorts
of
reasons,
across
a
number
of
the
build
packs
in
that
ecosystem
so,
like
it,
may
make
sense
for
there
to
be
some
type
of
like
common
library
for
doing
that
type
of
functionality.
Yeah.
H
Anyway,
yeah
just
saying
this
is
their
the
folks
who
are
you
know
other
language
maintainers
and
have
some
interest
in
that
concept
of
this,
like
shared
Library,
feel
free
to
comment.
A
I
think
that
personally
I
would
like
to
see
it
proved
out
one
in
one
method,
and
if
we
decide
how
this
is
not
working,
we
can
try
it
a
different
way
going
forward
with
another
like
like
having
an
RFC
that
binds
how
we
do
libraries
for
individual
Bill
pack,
families
right
off
the
bat
might
not
be
exactly
what
we
want.
A
If
we
do
find
that
this
works,
and
then
we
do
another
one
and
it
works
for
that
one
and
we
do
another
one
and
it
works
for
that
one
or
two
or
however
many
we
can.
We
could
codify
it
and
say
like
hey
if
you
have
shared
libraries
you'd
like
to
share
across
a
language
family.
This
is
what
you
need
to
do.
This
is
what
you
need
to
name
it,
that
sort
of
thing
but
I.
A
Think,
while
we're
developing
the
structure,
it
makes
more
sense
to
not
try
and
make
it
a
a
top
level
mandate.
E
Just
for
the
title
of
this
RFC
right
that
that
kind
of
reflects
that
we
want
to
discuss
the
general
direction
we
want
to
go
in
and
like
more
on
optional
thing,
of
course,
if
it
doesn't
make
sense
for
that
language,
family,
of
course,
we
don't
don't
need
it,
but
yeah.
If,
if
you
want
to
have
something
for
your
language
family,
you
should
follow
like
this
common
kind
of
pattern.
A
E
A
I,
don't
want
to
like
there's
just
magic
up
a
title
here,
but
is
that
more
in
the
vein
of
what
you
would
be
looking
for.
I
There's
just
one
thing
to
to
keep
in
mind
there:
if
I
have
seen
it
correctly,
it's
an
RFC
and
the
node.js
folder.
So
if
it
is
an
RFC
for
a
note,
then
we
don't
need
to
make
the
title
more
General.
If
it
is
not,
then
we
should
also
move
it
out,
but
I
have
the
feeling
that
right
now,
it's
very
specific
for
node
and
might
be
a
blueprint
for
discussing
that
project
white.
So
maybe
there's
other
channels
other
chances
to
make
sure
everyone
reads
this:
it's
still
an
RFC
for
node
I
believe.
I
What
is
in
the
RFC
right
deriving
a
pattern
is
maybe
something
to
to
trigger
a
discussion
with
different
means
than
the
the
title
of
the
of
the
RFC
in.
A
That
case
then,
do
we
maybe
think
it's
sufficient
to
talk
about
it
in
this
working
group
and
maybe
put
it
in
something
like
the
general
slack
Channel
as
like
a
hey.
This
is
a
potentially
interesting
precedent
for
how
we
would
do
shared
libraries
between
build
packs.
A
Getting
a
little
bit
too
much
case
law
for
my
liking
anyway.
Are
there
any
other
discussions
that
we
would
like
to
have
on
these
rses.
A
Nope
all
right
hold
on.
Let's
see,
CNB
updates
meeting
for
arm
support
work
on
Thursday
at
1500,
UTC
yeah
like
Thursday
so
two
days
from
now.
Could
someone
speak
to
this
real,
quick.
K
This
is
you
know,
we're
just
kind
of
like
getting
people
who
are
going
to
start
working
on
the
project
together
and
feel
free
to
join
the
meeting
just
chime
in
in
the
in
this
thread.
If
you
want
to
get
included,
I,
don't
think
that
the
probably
end
up
posting
a
zoom
Link
at
the
time
that
we're
gonna
meet.
So
you
know
if
you
want
to
join
just
chime
in
on
the
thread.
G
Yeah
I
think
I
sent
this
in
our
slack
channels,
but
we
are
removing
the
dependency
server
like
I
mentioned
earlier,
so
the
dependency
server
is
where
the
non-java
build
packs
got
their
dependencies
from.
We
had
a
bunch
of
GitHub
actions,
workflows
that
retrieve
new
versions.
You
know
generated
metadata
and
then
stored
them
on
an
API
endpoint
for
us
and
uploaded
the
artifacts
to
a
bucket.
G
So
we
have
kind
of
deprecated
that
in
favor
of
our
new
dependency
management
system,
which
we
had
been
working
on
for
the
last
few
months,
which
we
just
closed
out
so
on
March
3rd.
In
about
a
month's
time,
we
will
be
fully
removing
the
depth
server.
So
the
API
endpoints,
if
anybody
was
using
them,
won't
be
available
anymore,
but
the
dependencies
that
were
stored
there
before
will
still
be
available.
G
So
let
us
know
if
you
have
any
concerns
about
that,
but
it
shouldn't
affect
anybody
who's
using
the
build
packs,
because
we've
already
transitioned
to
our
new
system.
A
If
you
had
set
up
a
custom,
API
server
using
the
same
API,
it
would
be.
That
would
be
who
you
were
who
was
affected
so.
A
And
I
I
believe
actually
that
that
may
continue
to
work
for
some
time,
because
we
allow
you
to
change
your
API
endpoint,
but
then
I
believe
that
will
be
removed
at
the
March
3rd
deadline.
Correct.
A
All
right,
I
know
that
we
are
getting
pretty
close
to
the
allotted
time
for
this
meeting.
Are
there
any
open
questions
we
want
to
discuss
further.
A
All
right,
thank
you
all
for
coming.
It
was
a
GM
packed
meeting,
feel
really
good
about
how
productive
it
was.