►
From YouTube: Working Group: January 18, 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).
B
A
Just
in
the
in
the
same
Dock
at
the
very
bottom
there's
a
node
section
at
the
very
bottom
of
the
like
agenda
for
the
day
yeah,
so
just
Whatever
Gets
talked
about
that.
Isn't
that
isn't
already
clear
from
the
context
of
the
agenda
Maybe
thank
you,
I
appreciate
it
yeah
all
right
and
then
any
other
new
phases
I
haven't
been
able
to
attend
this
meeting
for
a
week
or
so
so
I'm
not
entirely
sure
whether
or
not
the
folks
here
are
all
new
faces
or
not.
A
A
C
C
Costas
I,
don't
know
if
you
can
hear
me:
okay
and
I'm
I'm.
D
This
one
specifically
to
support
the
energy
is.
B
Thanks
I
guess:
I
might
as
well
go
next
time
on
Michael
Dawson
from
Red
Hat
been
working
with
Ozzy
on
the
Node
aspect
of
doing
some
proof
of
concepts
with
the
keto
build
packs,
and
some
of
the
extensions
he's
been
working
on-
and
you
know
here,
along
with
costness,
just
to
hear
a
little
bit
more
about.
What's
going
on
and
maybe
have
some
questions
as
well.
A
Awesome
well
welcome.
Hey
we've
seen
Aussie
for
a
while,
it's
cool
to
see
some
more
Red
Hat
boots,
all
right.
Let's
see
moving
on
with
the
next
bits
of
the
agenda,
let
me
go
ahead
and
share
my
screen.
A
Okay,
so
let's
see,
we've
got
outstanding.
Rsc's
I
have
these
open
over
here
we'll
skip
over
this
really
old
draft
that
I
need
to
figure
out
what
to
do
with
and
we'll
jump
into.
The
first
RFC
here,
which
is
propose
additional
jvms
in
job,
build
pack.
C
Yeah
that
one's
still
under
discussion
and
we're
still
trying
to
to
get
by
the
the
technical
challenge
that
we
have
with
the
layer
limit.
So
this
one's
on
on
hold
for
for
or
blocked
for
the
moment
until
we
have
a
solution
to
the
lighter
limit.
A
Okay,
I
see,
we've
got
a
block
tag
on
there
already
all
right,
okay,
cool,
then
moving
on
require
a
specific
Java
version
in
the
build
plan.
A
Excuse
my
ignorance
here
I
haven't
been
following
much
of
the
Java
stuff
recently,
but
does
anyone
maybe
know
what
the
status
is.
E
I
think
last
week
there
was
just
more
like
requests
for
comments
and
opinions
from
java
users.
I
think
that
was
it
like.
They
just
want
to
have
more
conversation,
an
iron
out
some
of
the
details,
stuff.
A
A
It's
gonna
be
an
all
Java
all
day
meeting
today.
Let's
see
it's
selecting
the
next
default
Java
version
and.
C
Yeah
this
one
I
I
opened
this
morning.
This
is
to
one
option:
to
get
by
the
layer
limit
that
we
need
to
resolve
before
we
can
add
additional
jvms
providers
to
the
Java
build
pack.
C
So
this
is
basically
just
to
create
a
new
set
of
builders
that
will
include
only
include
the
the
build
packs
needed
for
the
composite
Java,
build
pack
and
and
not
include
any
of
the
other
families
and
do
that'll
that'll
drop.
The
number
of
layers
from
103
to
I
think
44
is
what
I
counted
and
then
we
can
also
add
the
APM
build
packs,
and
you
know
whatever
else,
to
have
them
all
built
built
into
the
composite.
Build
pack.
C
So
that
hasn't
been
there's
no
discussion
in
in
this
PR.
Yet.
But
there's
been
some
discussion
on
the
side
with
Daniel
and
other.
A
This
makes
sense,
I
mean
all
language
specific
one
makes
a
lot
of
sense.
We've
talked
about
this
on
and
off
at
different
points.
I
know
that,
for
me,
I
tend
to
just
use
like
a
build
pack
with
Builder
and
a
build
pack
and
Stitch
them
together
and
just
bite
the
bullet
on
the
performance
impact
that
has
there
probably
are
a
bunch
of
uses
out
there
who
do
something
similar
so
combining
that
pattern
into
something
that's
like
formally
supported
by
the
project,
which
would
probably
be
a
good
idea.
A
I
know
that
there
are
some
concerns
on
the
Builder
maintainer
team
about
this
particular
thing,
but
maybe
that
could
be
mitigated
if
we
I
don't
know
if
this
outlines
like
something
like
who
actually
owns
these
Builder.
This
is
the
Java
team
that
owns
the
builders.
C
A
If
Java,
then,
why
not
all
the
other
build
packs,
and
then
you
end
up
with
this
kind
of
like
very
large
explosion
in
the
number
of
Builders
Builders
every
time
a
new
stack
thing
comes
out,
you're
like
talking
about
you,
know
many
many
builders
that
need
to
then
get
shipped
out
the
door
and
stuff
that
just
runs
the
risk
of
like
you
know
if
automation
is
broken
or
that
kind
of
thing
also
just
like
it,
putting
a
slight
amount
of
pressure
on
our
relatively
fragile
GitHub
action,
CI
system,
so
yeah
just
talking
that
through
would
be
great,
I'm
sure
the
Builder
folks
will
chime
in
and
give
their
thoughts
great
anything
else
to
say
on
this.
A
Well,
everyone
else
feel
free
to
check
this
out
that
covers
outstanding
rfcs
from
the
day
and
then
jumping
down.
We've
got
cnd's,
CNB
updates
and
questions
I,
don't
know
of
anything
that
I've
seen
in
the
CNB
project
that
merits
an
update.
D
A
Yeah
we
have
an
ongoing
conversation
in
an
open
PR
against
package
to
add
stack
extension.
Support
to
the
library
should
help
for
folks
using
packet
to
develop
stack
extensions,
I,
don't
know
if
lib
CNB
is
added
anything
like
that
or
if
everyone's
just
doing
custom,
stuff
or
just
bash
stuff,
I
I,
don't
know.
D
A
C
D
B
Yeah
Costas
took
the
bash
script
that
that
you
know
we'd
work
together,
converted
it
to
go,
and
we've
been
working
on
that
just
the
last
few
days
to
try
and
reuse
some
of
the
the
bits
and
pieces
from
the
existing
build
pack.
So,
like
you
know,
figuring
out
which
version
of
node
to
to
you
so
we're
sort
of
at
that
transition.
Point
of
like
we
did
the
proof
concept
now
we're
starting
to
build
something
move
it
over
to
go
because
I
think
that's
what
we
need
to
do
to
reuse.
A
That
makes
sense
it's
worth
opening
up
a
conversation
about
the
use
of
anything
from
like
say
the
node
engine
build
pack.
If
it's
like,
because
I
know
that
those
maintainers
have
not
necessarily
thought
about
what
you
can
grab
as
like
a
political
public
package
API
in
there
as
like
a
supported,
public,
API,
right
and
so
I,
don't
know
they
think
about
it
as
like.
Oh
I
should
make
sure
to
like
provide
a
backwards
compatible
API.
A
It's
mostly
considered
like
an
internal
implementation,
but
like
that
all
that
being
said,
like
I'm,
not
sure
that
that,
like
that
opinion
or
that
perspective,
isn't
negotiable
right
so
like
if
you
did
come
to
them
and
say
like
Hey,
we're
relying
on
this
or
you
want
to
create
some
compatibility
between
these
two
things
by
reusing
code.
I'm
sure
that
that's
something
that
the
team
would
be
open
to
it
just
we'd
have
to
be
aware
of
that.
The
fact
that
that
other
folks
are
relying
on
that
specifically.
B
Yeah,
that's
actually
one
of
the
the
questions
I
had
in
mind
is
like
how
how
open
is
the
team
to
that
and
like
there's,
some
very
specific
things
that
we've
come
across,
that
we
would
want
that
we
would
need
to
sort
of
be
like
you
said,
public
API
that
we
could
reuse
to
minimize
code
that
we
we
can
reuse.
B
You
know
we
through
the
experiments
so
far.
You
know
what
we
want
to
try
and
get
the
ideal
case
would
be.
We
just
reuse,
those
build
packs
and
we
just
provide
node
and
that's
it
right
because
of
the
way
the
extensions
fit
in
I.
Think
today
it
looks
like
we're.
Gonna
have
to
like
figure
out
whether
it's
node
or
not
in
the
in
the
extension
versus
in
the
build
box,
because
we
don't
get
the
you
know,
we
can't
participate
in
the
in
that
sort
of
detect
phase.
B
B
We
figured
out
like
in
our
go
generate
that
we
can
actually
reuse
the
information.
That's
put
into
the
build
plan,
to
figure
to
say
what
version
but
I
think
we're
going
to
have
to
re
like
have
another
copy
of
the
stuff
that
says
hey
like.
Is
there
a
package
Jason?
Is
there
an
mvmrc
and
it
would
be
nice
to
be
able
to
call
that
from
those
build
packs,
rather
than
duplicating
that
part.
B
B
The
the
build
packs
was
to
say
that,
like
in
addition
to
the
Ubi
stocks,
that
the
red
hat
stack
was
also
supported,
and
you
know
all
I
did
in
our
proof
of
concept-
is
I
added
it
in
the
sub,
build
pack
to
say:
hey
I
support
another
stock,
but
my
question
is:
what
would
it
take
for
the
build
packs
to
say?
Yes,
you
can
add
that
as
a
supportive
stack
like
what
kind
of
testing-
or
you
know
it's
easy
to
add
the
tag
but
I
know
there's
going
to
be
a
lot
more.
A
I
mean
truthfully
at
the
end
of
the
day,
what
seems
to
be
happening
across
quite
a
lot
of
the
build
packs
is
like
we
have
this
really
rigid
compatibility
contract,
which
is
just
like
that
stack
IDE
identifier
and
like
every
time
someone
comes
along
with
a
new
stack
we
have
to
like
at
it
and
yeah.
The
question
is
like:
do
we
Mark
that,
as
like
you
know,
paquetto
supports
this
thing
explicitly
and
if,
if
you
did,
what
would
be
the?
A
What
would
we
have
to
do
to
feel
comfortable
doing
that,
and
mostly
for
us,
it's
like
we'd
want
to
have
some
integration
tests
to
test
the
fact
that
that
thing
actually
works
in
a
way
that
a
user
would
use
the
bill
pack
and
for
those
things
we
just
have
tests
currently
for
the
bionic
and
Jammy
Ubuntu
Stacks
that
we
officially
support
and
what's
been
happening
when
other
folks
have
stacks
they
want
to
bring
in
and
for
the
most
part,
is
we've
just
been
green
lighting,
a
wild
card
stack
and
the
projects
kind
of
perspective
on
that
is
like
yes,
this
means
now
you
can
use
other
stacks
and,
like
your
functionality,
with
this
other
stack,
may
not
work.
A
100
right,
like
the
project,
isn't
making
like
a
really
strong
guarantee
that
isn't
to
say
that,
like
if
you
show
up
with
a
bug,
we're
not
going
to
fix
it,
but
it
just
says
like
we
don't
guarantee
that
this
works
with
every
stack,
because
that's
just
kind
of
impossible
for
us
to
do
now
in
the
long
run.
I
think
the
thing
that's
going
to
save
us
from
this
really
brittle
stack,
ID
compatibility
contract
is
the
CNB
project
and
I
think
this
is
like
coming
up
very
soon
on
their
list
of
priorities.
A
They're
working
on
this
thing,
that's
going
to
basically
remove
stack
IDs
entirely
from
the
definition
of
how
build
packs
interact
with
stacks
and
so
we'll
be
able
to
say
as
a
build
pack
like
we
just
work
on
like
flavors
of
Linux,
on
x8664
or
arm
64
or
whatever
right.
We
just
kind
of
just
say:
there's
this,
like
very
generalized
level
of
compatibility.
D
A
Can
lock
that
down
a
lot
more,
you
can
say
like
specifically
Ubuntu
distribution,
specifically
these
versions
of
Ubuntu
distributions,
but
for
us
on
the
Canada
will
probably
be
pretty
permissive
and
just
say
something
like
you
know:
Linux
x8664
and
then
probably
arm
64
very
shortly
after
but
like
we'll
try
to
be
as
permissive
as
possible,
which
means
that
you
know
folks,
like
yourself
who
are
bringing
a
different
sack,
should
be
able
to
just
use
the
build
packs,
as
is
but
yeah
that
kind
of
describes
the
state
of
the
world
as
it
exists
today.
B
A
B
A
Yeah,
it
would
be
accepted
with,
like
kind
of
that,
that
caveat
of
like
we're
not
making
the
statement
that
this
now
means
the
build
pack
absolutely
works
on
every
stack.
We're
just
saying
you
can
use
it
on
a
stack
and
like
if
you
find
issues
like
file
bugs
we'll
fix
them,
but
like
we're,
just
not
we're
not
able
to
make
that
like
ahead
of
time,
guarantee
versus
like
for
the
two
stacks.
We
do
support.
It's
like
those
are
tested
ahead
of
time,
and-
and
you
know,
we
we
fully
back
them.
D
I
was
gonna,
say
well,
I,
think
that
brings
into
the
the
next
point,
which
is
we're
really
not
under
CNB
updates
and
questions
so
much
as
Poquito
ecosystem
updates
and
questions
at
this
stage.
But
it's
you've
got
your
two
supported
stacks
of
the
Ubuntu
flavors
at
the
moment
and
last
year
on
the
roadmap,
there
was
an
item
to
Ubi
eight
Stacks
we've
been
working
on
that
and
working
towards
that
now,
I'm
I'm,
assuming
that
carries
over
to
this
year's
roadmap.
I
missed
all
that
stuff
because
you
know
I'll
start
the
year.
D
I
was
still
on
vacation,
but
it
would
be
kind
of
my
expectation
that
if
we
do
manage
to
get
Ubi
8
Stacks
as
a
supported
Thing
by
Poquito
that
then
it
would
become
a
third
option
to
those
two.
So
for
as
long
as
Stacks
exist,
then,
if
we
were
going
that
way,
we
would
hypothetically
have
ubia
as
a
third
option
as
a
sported
stack
against
those
Bill
packs.
D
I
think
I'd
make
the
suggestion
that
it's
probably
not
worth
going
to
the
effort
of
having
adding
that
in
in
this
case
and
adding
the
Wild
Card
makes
more
sense,
because
we
know
that
CMB
is
going
to
be
removing
the
concepts
of
stacks
long
term
anyway,
but
it
does
bring
around
the
the
larger
discussion.
That
again
is
not
really
CNB
related.
It's
more
pecula
related,
which
is
look.
D
We've
got
is
that
we
want
to
write
an
RFC
up
for
the
ubi8
stack
stuff
and
we're
kind
of
wondering
about
how
do
we
get
the
information
for
what
we
need
to
put
in
that
RFC?
Regarding
how
do
we
make
this
a
supported
stack,
you
know:
do
we
have
to
have
a
test
Suite
that
runs
against
the
bill
tax,
that
we
include
for
Builder
images
for
that
stack?
How
do
we
get
that
stack
built,
or
how
do
we
get
Builder
images
for
that
stack
built?
D
How
do
we
decide
which
build
packs
go
into
it?
Is
this
an
opt-in?
Do
we
just
run
things
and
test
it
manually?
Do
we
Port
existing
test
cases
and
if
they
work,
everything's,
good
or
yeah?
D
There's
a
lot
of
questions
in
there
that
we're
a
little
bit
wary
about
as
to
how
how
do
we
get
this
started
because
we
could
write
an
RFC
but
I
think
we
need
to
kind
of
know
roughly
what
we
should
be
suggesting,
because
you
know
this:
the
introduction
of
a
whole
new
thing
that
will
run
parallel
to
the
existing
Ubuntu
Stacks,
but
there's
some
questions
in
there
and
I.
Think
I'd
like
to
get
some
discussions
going
around
that
and
I.
Don't
think,
there's
really
enough
people
here
to
do
that.
A
Yeah
I
think
that
the
place
for
this
is
probably
like
the
paquero
build
packs
discussion
forum.
I
would
start
like
a
discussion
there,
just
to
kind
of
like
sketch
out
what
we
think
of
as
the
set
of
requirements
for
like
what
an
RFC
would
outline,
but
I
think
like
the
best
example
of
this
is
probably
like.
A
If
you
just
looked
at
the
the
existing
Jammy
RFC,
which
is
like
the
most
recent
example
of
like
we're
gonna,
add
a
new
stack
and
I'm
trying
to
jog
my
memory
on
this,
but,
like
I,
think
that
there's,
like
you
know
a
handful
of
things
that
are
outlined
like
you,
have
to
specify
the
actual
stack
identifier
for
it
and
I
think
the
way
practically
that
we
went
about
going
to
support
it
was
we
kind
of
just
went
build
pack
by
build
pack
and
how
you
choose?
A
You
know
which
build
packs
are
going
to
be
your
kind
of
you
know.
Initial
targets
for
support
is
probably
up
to
you.
What
are
the
ones
that
you
know
are
the
highest
use
for
end
users,
that
kind
of
thing?
What's
the
easiest
to
get
to
a
working
state,
but
basically,
at
the
end
of
the
day,
like
I,
think
the
expectation
would
be
you
have
Stacks
for
whatever,
like
the
reasonable
use
cases.
Are
that
you
care
about
so
for
like
on
the
Ubuntu
side,
it
meant
like
full
base
and
Tiny
stack.
A
So
like
some
sort
of
expectation
of
that
and
then
build
packs
that
support
it
so
like
the
build
packs
have
to
have
whatever
it
is
that
they're,
providing
as
their
functionality
modified
in
such
a
way
that
they
are
capable
of
supporting
the
new
stack
and
then
finally,
I
think
there
would
be
an
expectation
that
there
are
builders
that
the
stack
has
and
for
those
builders
we
really
would
only
just
have
at
least
initially
those
build
packs
that
do
actually
support
the
stacking
right.
A
You
would,
you
would
add,
more
build
packs
onto
that
Builder
over
time,
as
you
kind
of
rolled
out
support
across
the
set
of
build
packs.
That's
how
we
did
Jammy
I
think
it's
makes
the
most
sense
for
how
we
would
do
Ubi
support
as
well,
but
yeah
I
would
start
a
discussion.
You
can
kind
of
like
work
out
the
details
there
and
then
from
there
I
think.
The
next
step
is
definitely
an
RFC.
A
Absolutely
so,
if
there's
like
any
sort
of
other
new
things
that
are
needed,
do
you
need
stacked
extensions
repositories?
You
have
new,
build
packs
or
whatever
that
need
to
get
added.
I
would
expect
if
you
knew
ahead
of
time.
A
The
RFC
would
include
those
things,
but
also
like
an
RC
is
kind
of
like
a
proposal
of
an
idea
so
like
it's
expected
that
you're
not
going
to
know
everything
ahead
of
time,
and
so,
like
you
know,
if
things
come
up
along
the
way
we
can
do
new
RCS,
we
can
do
an
addendum
to
the
existing
RFC,
so
the
workflow
is
kind
of
flexible
there,
but
like
if
you're
thinking
already
ahead
of
time,
I
know
I'm
going
to
need
this
and
like
I,
would
expect
to
see
it
in
the
RC
foreign.
A
All
right,
I
think
we're
we're
deep
into
the
open
mic
question
discussion,
topic
section
so
I'll
just
ask
again:
if
there
are
other
questions
or
topics,
folks
wanted
to
bring
up.
A
A
All
right,
then,
I
think
we've
reached
the
end
of
the
meeting
here.
Thank
you
all
folks.
This
is
a
great
discussion.
I
think
we'll
see
you
all
next
week.