►
From YouTube: Working Group: January 24, 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
First
of
all,
can
I
get
a
note
taker.
Please.
A
Thanks
for
joining
welcome
back
all
right,
thank
you
for
volunteering
notes
from
any
of
the
RFC
specific
discussion
can
just
go
right
on
the
RFC
PRS.
If
that
works.
For
you
thanks
all
right
next
up,
do
we
have
any
new
faces
today,
looking
at
everyone,
I,
don't
think
we
do
so
I
think
we
can
move
on,
welcome
back
everyone,
and
then
we
can
get
right
into
looking
into
the
outstanding
rfcs.
A
A
C
No,
not
really
we're
still
working
on
other
rfcs
and
other
discussion
that
have
to
be
resolved
first,
so
this
one's
still
blocked.
B
A
Yeah
yeah
only
if
there
is
anything
worth
pointing
out.
If
there's
no
update,
then
you
can,
you
can't
believe
it,
but
that
works
cool
yep
sounds
good.
Thank
you
all
right.
Next
up
we
have
require
a
specific
Java
version
in
the
build
plan.
Are
there
any
updates
from
last
week
that
we
would
want
to
discuss
here.
A
A
Yeah,
so
maybe
just
in
the
comments
here,
we
can
capture
Logan
asked
from
David
about
what
the
status
of
this
PR
is.
A
A
Next
up
we
have
selecting
the
next
default,
Java
version.
I
know
we
had
discussed
this
one
last
week,
but
are
there
any
other
discussion
points
to
talk
about
here?.
D
I
think
I
realized
today
that
this
is
kind
of
an
hour,
a
quarter
right
now,
some
pending
responses
that
we
got
and
we
might
want
to
react
I
think
the
main
point
is
everyone
agrees
right
that
this
should
be
done,
and
after
that
immediate
action
should
be
taken
to
make
17
the
default
Java
version
following
this
RFC
I.
Think
the
main
point
is
the
comment
here
with
the
three
thumbs
up:
that
we
should
figure
out
how
to
develop
a
communication
plan
about
that.
D
So
where
should
we
actually
send
some
prior
notifications
of
careful
anyone?
Still
relying
on
Java
11
should
Now
set
it
as
explicitly
requested
jvm
version,
because
the
default
will
change
which
will
make
this
done.
A
kind
of
like
I
mean
it's
probably
still
a
major
version,
but
following
the
somewhere
rules,
but
won't
break
anyone
who
has
read
this
prior
notification
and
followed
up
so
I
doubt
that
many
people
will
do
it
because
spring
boot
now
require
requires
Java
17,
but
some
might
still
do
so.
D
I
think
that's
maybe
on
us
or
maybe
between
us
Daniel,
to
figure
out.
What's
the
next.
E
D
I
fully
agree
that
we
should
have
something
like
three
or
six
months
prior
notice
about
these
kind
of
things
and
should
make
this
part
of
the
of
the
RFC
so
I'm.
Fine
with
that.
A
A
Perfect,
thank
you
all
right.
So
that
concludes
the
RFC
section.
We
can
continue
on
first
step.
We
have
the
CMB
updates
and
questions.
Does
anybody
have
any
CMD,
C
and
B
updates
or
anything
that
they're
wondering
about.
F
Pretty
banal
update
the
CNB
working
group
meeting
that
takes
place
on
Thursday
is
now
alternating
its
time
slot.
So
if
you
are
on
the
west
coast
of
the
United
States,
and
it
has
been
a
pain
for
you
to
get
up
at,
you
know
seven
o'clock
in
the
morning
to
attend
that
meeting.
They're
alternating
it
now.
So,
if
that's
been
something
that
has
been
keeping
you
from
going
to
the
larger
Upstream
working
group
meeting,
then
just
want
to.
Let
you
all
know
that.
B
So
I
haven't
gone
for
a
little
bit,
I'm
just
wondering
if
there's
any
like
traction
on
the
arm
at
all.
If
anyone
has
heard
anything,
I
need
to
start
joining
those
meetings
too,
but
I've
been
kind
of
on
a
Hiatus,
so
I'm
getting
back
into
it.
G
No,
not
really
there's
been
some
kind
of
back
Channel
conversations
about
some
of
the
infrastructured
needs,
like
figuring
out
where
we
can
build
rm64,
stuff
infrastructurally,
and
now
we
can
have
those
things
paid
for
other
than
that.
We're
working
on
a
2023
roadmap,
blog
post
and
arm
support
is
like
the
number
one
item
voted
for
of
all
items
in
the
roadmap.
A
Okay,
we
can
move
on
to
project
updates.
I
see
somebody
has
linked
the
2022
recap.
Would
anybody
like
to
speak
to
that
item
yeah.
G
It's
a
pretty
good
list,
I'm
pretty
happy
with
what
the
project
was
able
to
to
get
done
this
last
year,
but
yeah
moving
forward,
we'll
have
a
2023
roadmap,
and
so
I
have
a
blog
post
related
to
that
coming
out,
hopefully
very
soon,
just
a
matter
of
me
finding
time
to
write
it
up,
but
yeah
thanks
to
everyone
in
the
community,
for
all
your
contributions
for
your
feedback
support.
All
those
things
were
really
really
great
in
2022
and
we're
looking
forward
to
it.
I'm
equally
good,
if
not
better
2023.,.
D
G
I
have
one
in
a
partially
formed
draft,
but
it's
not
complete
it's.
My
goal
is
to
get
it
out
at
some
point
this
week.
That's
my
goal,
not
promising
anything
though,
but
we'll
see
about
that.
The
only
other
update,
I
think
I
can't
remember.
Did
we
announce
that
node.js121.0.
G
Yeah
no
no
JS
build
pack
is
now
at
a
1.0
release.
We
removed
some
of
the
features
that
had
existed
in
the
pre
1.0
phase,
specifically
buildpack.yaml
support
and
the
Legacy
s-bomb
support
that
was
provided
by
the
node
modules
bomb
build
pack.
Those
things
are
now
gone.
If
you
upgrade
to
the
1.0
version
of
node.
A
A
A
F
Yeah,
so
this
is
just
going
to
link
to
slack
thread
between
myself,
Rob
and
Dan
makuza,
and
it
gets
into
I
think
what
Kevin
you
were
talking
about
earlier
in
terms
of
the
morphing
idea
behind
language
specific
builders.
F
F
If
you
look
into
this,
they
talk
about
it.
It's
so
the
docker
is
compatible
with
the
widest
arranges
of
machines
operating
systems
Etc,
but
it
does
mean
that
our
full
Builder
and
in
some
cases
our
base
Builder,
is
starting
to
hit
that
limit,
even
with
just
small
additional
build
packs
being
added
at
the
time.
I
think
that
I
proposed
an
RFC
to
basically
get
rid
of
builders
in
their
current
context.
I.E
sort
of
have
them
all
be
the
build
pack
list.
F
Builders
that
we
currently
support
I
think
there
were
some
good
reasons
why
that
was
kind
of
shut
down
and
we
potentially
started
looking
for
other
Solutions,
including
going
Upstream,
but
this
is
starting
to
become,
and
we
also
did
some
things
to
mitigate
it
at
the
time
like
trying
to
make
sure
we
were
increasing
our
release
cycle
for
our
build
packs
so
that
you
know
stale
or
multiple
versions
of
Any
Given
build
password
in
one
Builder.
F
F
It's
looking
like
it
might
make
more
sense
for
us
to
go
back
to
an
older
proposal,
which
is
now
I,
guess
a
new
proposal
again,
which
is
that
each
language
should
be
its
own
builder
and
then,
on
top
of
that,
some
of
the
stuff
that's
proposed
in
that
thread
is
we
still
have
like
maybe
one
Proto
Builder,
that
is
sort
of
a
welcome
to
paquetto
Builder,
use
it
as
sort
of
a
onboarding
tool
or
as
a
sort
of
quick,
iteration
or
proof
of
concept.
F
But
I
think
we
were
talking
realistically,
as
we
sort
of
shift
the
idea
to
sort
of
larger
production.
Mindsets
less
and
less
people
actually
want
to
have
a
builder
with
every
single,
conceivable
language
that
we
support
on
it
and,
in
fact,
want
to
have
a
more
tailored
and
experience,
and
the
easiest
way
for
us
to
do
that
without
sort
of
building
out
a
bunch
of
tooling
that
does
customized
build
packs
is
to
just
sort
of
support
each
language
in
an
A,
La,
Carte
fashion,.
F
So
I
guess
I
wanted
to
sort
of
bring
that
up
as
both
the
problem
and
also
what
we're
thinking
about
as
a
solution
and
I
guess
Heaven,
it
sounds
like
you
have
modified
your
RFC
to
be
less
Java
specific
and
more
all
language,
families.
C
Well,
I
haven't
yet
but
I
think
that's
what
that
RFC
is
going
to
morph
into
yeah.
Okay.
F
So
yeah
I
guess
I
wanted
to
bring
this
up
and
see
if
there
were
like
I
guess
any
questions.
Any
concerns
about
that
right
off
the
bat
I
think
this
is
a
model
that
has
been
used
by
other
organizations.
I
think
it's
something
that
Google
is
doing
right
now,
if
I
recall
correctly,
I
think
they
do
some
pretty
language
specific
Builders,
but
yeah
I
wanted
to
bring
that
up
here,
get
feedback.
Let
people
know
about
it.
D
For
what
it's
worth,
we
are
actually
producing
the
Builder
containing
Java
and
node,
and
maybe
adding
more
languages,
but
like
actually
specific
to
our
use
cases.
So
I'm
not
sure
if
that's
a
good
model
and
we
we
reduce
the
number
of
component
attacks
right
so
as
Java
apps
are
mainly
built
with
may
even
be
only
include
made
things
we
might
add
Gradle
to
it,
but
not
at
lighting
and
spt
and
others
if
it's
not
very
specific
demand
within
sap
or
or
or
a
customer
base
to
add
those.
D
So
that's
maybe
our
way
to
limit
that
and
on
the
plus
side
it's
just
a
single
Builder.
You
don't
have
to
configure
your
cicd
or
what
language
is.
It
is,
on
the
other
hand,
side,
and
can
you
convince
a
developer,
knows
pretty
much
which
language
family
the
code
base
is
in.
If
not,
then
maybe
they
don't
need
to
build
it.
D
So
probably
that's
that's
a
possibility,
especially
with
the
with
the
limit
as
as
low
as
127,
which
is
yeah.
Nobody
will
ever
need
more
than
640k
of
my
memory
right,
never
more
than
127
layers.
It
sounds
familiar.
F
Yeah
for
sure
I.
D
F
Yeah
I
I
think
I
think
there
are
some
caveats:
I'm
not
intimately
familiar
with
those
I
think
that
it's
something
that's
being
discussed
in
the
cloud
into
buildpex,
Community,
I
I
would
be
curious,
though,
if
not
necessarily
necessarily
saying
you
would
change
Your
solution
now,
because
it
sounds
like
you
have
something
that
works
works
for
you,
but
would
you
have
gone
with
just
having
like
a
node.js
and
a
Java
Builder
and
just
be
happy
with
using
those
instead
of
having
to
build
out
a
custom
builder
or
were
you
well
or
did
you
really
want
to
Pare
down
the
number
of
sort
of
even
component
build
packs?
F
You
supported
to
the
smallest
amount
possible.
D
So
probably
we
would
build
that,
and
the
other
angle
of
that
is.
We
also
slightly
increase
the
the
tiny
set
for
example.
So
we
have
added
like
four
packages
to
it,
including
a
shell
to
support
some
note
cases
and
others.
So
I
guess
we
are
anyway
on
that
road
having
something
very
customized.
C
B
Oh
yeah
I
can
comment,
I
mean
like
I'm,
not
actually
using
the
potato
builders
for
a
lot
of
the
things
I've
been
working
on
and
I
have
found
that
I've
made
the
Builder
as
universal
as
possible,
but
because
you
know,
if
you're
running
different
language,
families
it
just
gets
bigger
and
bigger,
you
know
python
requires
a
lot
more
than
go
and
then
you
have
to
deal
with
vulnerabilities
in
one
app
that
don't
even
affect
you.
So
I
actually
really
do
like
the
idea
of
language.
B
D
In
a
limited
fashion,
I
think
we
have
that
I
wonder
if
anyone
is
using
the
full
Builder
to
create
Java
apps
because
of
the
CBE
Services.
That's
just
one
example.
It's
so
unnecessarily
filled
with
and
I
wouldn't
probably
worry,
very
much
about
the
resulting
image
sides,
but
rather
really
the
kind
of
number
of
packages
on
top.
So
I
guess
it's
like.
Maybe
you
know
everyone
would
run
it
with
tiny
because
lack
of
passion
than
some
work
around.
D
So
it's
starting
promcast,
not
with
a
as
a
Lena
script,
but
with
a
gold
re-implementation
that
might
be
partial,
so
maybe
it's
base
where
they
align
on
for
us.
It's
actually
tiny,
plus
plus
just
a
little
additions
to
to
have
it
run
that
way
so
yeah
I
agree,
I,
guess
the
full
Builder
will
be
used
to
maybe
Ruby
and
PHP
apps,
but
I
doubt
that
many
people
use
it
for
for
Java
or
go
or
whatever.
D
F
If
it
is
supported
on
base
then
and
supported
on
Tiny.
Maybe
you
have
you
know
a
tiny
base
build
or
a
tiny
base
build
or
a
tiny
base
Builder
if
it
works
on
base
and
full,
maybe
just
have
bass
and
if
it
works
on
just
how
just
unfold
and
just
have
full
but
yeah.
It's
it's
potentially
an
interesting
idea.
I
I
hadn't
really
thought
about
it,
but
I.
Don't
I
also
feel
like
that's
something
that
is
probably
prescribing
a
bit
ahead
of
time.
D
I'm
going
to
be
thinking
about
if
we
should
either
propose
or
walk
around
the
current
situation
and
add
multiple
Run
images
to
stack
like
best
would
be
in
the
Upstream
specification,
so
you
could
actually
have
a
Jammy
Builder
like
base
and
Tiny
actually
share
the
same.
The
same,
build
image,
a
Jammy,
Builder
or
dummy
stack
and
then
have
different
running
they
just
and
you
can
like.
D
You
can
choose
one
and
you
can
already
do
it
as
a
user
as
tag
and
other
platforms
support,
setting
the
wrong
image,
but
making
this
the
first
class
citizen,
the
only
thing
I'm
hesitating.
Is
it
kind
of
conflicts
a
bit
in
the
the
goals
you
can
reach
with
it
with
the
the
extensions
back,
because
you
could
reach
the
same
with
that
right,
just
having
a
run
image
that
has
been
basically
nothing
and
use
extensions
for
it,
making
bigger
Run
images
without
changing
what
a
stack
is,
but
I
interrupted,
Philip
I
think
most.
E
People
yeah
so
maybe
back
to
the
the
language
specific
builders,
so
I
I
also
see
some
some
upsides
there
is
it
only
about
the
download
says
right
if
you're
not
on
fiber
optics,
it's
quite
nice
if
it
just
downloads
like
half
a
gigabyte
instead
of
free
yeah.
So
but
maybe
we
could
see,
are
there
any
downsides
to
this
I
guess
the
one
is.
It
would
be
an
overhead
on
the
Poquito
side
right.
E
F
I
think
it
changes
existing
build
processes
as
well,
if
we're
no
longer
releasing
builders
in
our
current
state.
Anyone
who's,
you
know
like
using
the
base
Builder
to
push
a
bunch
of
apps,
now
has
to
find
I
guess
a
solution
to
either
figure
out
what
Builder
to
use
or
has
to
build
out
different
pipelines
to
use
different
Builders
and
send
different
apps
there
or.
A
All
right,
thank
you
all
for
the
discussion.
It
seems
like
there
are
a
lot
of
different
ideas
and
it
sounds
like
Kevin
is
taking
the
initiative
to
transform
the
existing
RFC
into
a
like
a
non-java,
specific
RFC,
so
that
we
can,
you
know,
talk
about
this
on
the
project
level.
Yep.