►
From YouTube: Working Group: March 1, 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
Hello-
everyone
not
too
many
people
here
today,
but
I'm
still
gonna
put
in
the
link
to
the
sign-in
sheet.
A
Please
go
ahead
and
sign
in
we'll
give
it
a
couple
more
minutes,
but
if
no
one
else
is
here,
I
guess
it'll
probably
be
a
quick
meeting.
We
might
push
off
the
roadmap
update
if
it's
only
the
four
of
us
until
next
week,
so
that
we
can
hopefully
maximize
the
people
that
see
our
roadmap
update.
B
A
All
right
six
minutes
past,
let's
go
ahead
and
get
started,
could
I
get
a
note
taker
for
today.
A
I
can
take
notes.
Awesome.
Thank
you
so
much.
Let's
start
out,
let's
see
or
I'll
I'll
mark
you,
this
they're
taking
Ryan.
A
New
faces,
I
I,
don't
think
we
have
any
new
faces.
So
let
me
share
my
screen
and
hop
right
into
this
road
map.
A
Alrighty
perfect,
so
just
taking
a
quick
look
at
the
roadmap
here,
let's
start
with
the
stuff,
that's
in
progress
and
then
go
to
the
stuff
that
needs
investigation.
Then
we
can
go
to
the
stuff.
That's
planned,
I
think
that
probably
makes
the
most
sense
order.
Wise
Implement,
node.js,
RFC
14
support
yarn
Berry.
Is
there
any
updates
on
this.
A
A
C
A
A
All
right,
perfect.
A
Let
me
open
these
up
real
quick,
so
we
have
reloadable
process
types.
It
looks
like
the
only
outstanding
reloadable
process
type
is
Ruby.
I
assume
that
this
is
once
again
a
prioritization
thing.
Just
no
review
maintainers
haven't
had
the
time
to
work
on
this.
A
Cool
and
then
yeah,
obviously
you
can
track
it
through
the
this
issue.
Here
next
up
we
have
distributed
build
packs
via
Docker
hub.
This
might
be
done.
B
I,
don't
think
it
is
I
think
the
last
thing
is
like
purely
documentation,
thing
I
think
someone
needs
to
go
and
like
clone
all
the
repos
and
the
organ
like
grip
for
GCR,
dot,
IO
and
I.
Think
you'll
be
surprised.
It's
mostly
readme
files
that
have
like
references
to
images
that
that's
no
longer
the
canonical
location.
B
A
In
that
case,
then,
I
guess
that's
the
next
thing
that
needs
to
be
done.
So
we
kind
of
know
the
status
so
I'm
gonna
should
I
plop
this
back
into
in
progress.
A
And
then,
finally,
we
have
default
behavior
for
build
Pack
set
language
ecosystem
environment
variables.
There
was
a
big
push
for
this
a
little
while
ago,
and
then
it
kind
of
petered
out
a
little
bit
I
assume
that
we
probably
need
to
go
over
and
just
like
look
at
some
of
these
again.
Like
I,
don't
know,
that.net
root
is
going
to
have
the
same
problem
anymore,
just
because
we
kind
of
completely
restructured
how
the
build
pack
works.
A
I
know
that
we
still
set
it
in
like
one
scenario,
but
I'm
not
I'm,
not
entirely
sure
that
it's
a
a
big
deal.
I'd
have
to
go
back
and
look
at
the
like
npm
stuff
and
then
MRI
would
also
probably
need
to
take
a
look
at
as
well
so
I
guess.
We
probably
just
need
to
go
through
and
sanitize
this
issue
and
just
make
sure
that
all
the
things
that
we
have
open
are
still
relevant
and
just
check
everything.
A
I
will
keep
this
here
then
next
up
we
have
the
three
planned
ones:
I
can't
imagine,
there's
going
to
be
big
stuff
for
any
of
these
remote
debug
I
assume,
basically
nothing
about.
This
has
changed.
B
B
A
A
A
This
is
a
a
bit
of
a
white
whale
I
I,
don't
know,
I
feel
like
it's
been
here
for
a
while,
and
we
haven't
really
talked
about
or
made
any
progress
towards
it
just
because
it
keeps
getting
bumped
down
the
priority
list.
B
I
mean
I
think
that's.
The
main
thing
here
is
environment
variables
and
I.
Just
think
that
it's
like
a
huge
amount
of
work
for
build
packs
to
actually
shift
to
like,
what's
proposed
in
this,
like
every
time,
I
go
in
and
make
some
sort
of
change
like
most
recently,
it
was
like
I'm
pulling
code
out
of
npm
install
in
order
to
implement
this
like
lib,
node.js,
shared
library
and
like
one
of
the
types
that's
in
there.
B
Just
has
like
references
to
like
OS
get
M
right,
and
so
you
just
have
that,
like
string
across
every
repo,
where
it's
like
there
isn't
a
canonical
place
where
we
like
read
in
the
environment,
it's
like
riddled
throughout
the
code.
At
any
point,
the
process
might
reach
out
and
grab
environment
variables,
and
so
so,
like
Step
One,
is
like
all
build.
Packs
need
to
like
have
a
plan
for
how
they
read
in
environment
variables
and
do
that
in
a
uniform
way.
B
A
I
think
I
might
have
mentioned
this
last
time,
but
we
made
strides
in
trying
to
sort
of
standardize
when
we
pull
in
environment
variables
with
httpd
and
nginx,
because
they
had
just
a
very
large
number
of
environment
variables.
They
had
to
pull
in
this
had
a
pretty
actually
cool
side
benefit
of
making
our
tests
way
more
thread
safe
and
robust,
because
we
could
just
do
things
like
pass
objects
in
instead
of
having
to
pass
the
actual
environment
variables.
A
So
maybe
we
should
write
up
some
tracks
of
work
for,
like
all
the
language,
families
that
are
basically
like
hey.
You
should
find
a
way
to
basically
like
preload
environment
configuration
and
put
like
the
configuration
in
one
place
in
code
and
then
reflect
that,
probably
somewhere
in
like
Bill
pack,
Tamil
right,
because
that's
like
what's
proposed
in
the
RFC
but
yeah.
B
A
Fair
all
right,
I
might
have
some
ideas
on
that,
but
yeah
I
don't
know
that
I
necessarily
want
to
sign
up
for
that
right
now.
Are
there
any
other
comments
on
this
auto-generate
reference
documentation.
A
B
I
think
this
mostly
was
waiting
on
some
work
from
Dan
makuza,
mostly
to
like
I,
think
write
up
that
definition,
the
retention
policy
definition
somewhere
and
then
there's
some
work
to
like
figure
out
how
to
automate
that
retention
policy.
It's
basically
like
purging
images
from
locations
where
it
is
no
longer
under
the
like
retention
policy,
I
think
the
retention
policy
is
so
generous
that,
like
I'm
pretty
sure
there
are
no
images
that
are
in
violation
at
this
point.
B
I
think
it's
like
three
years
or
something
like
that.
If
I
remember
correctly,
it's
pretty
generous
like
the
time.
B
A
A
I
I
think,
like
I,
said
at
the
beginning
this
meeting
it
might
make
sense
for
us
to
potentially
just
put
this
in
topics
for
next
week
as
well
and
hopefully
grab
a
couple
more
people.
D
B
B
Now,
there's
no
net
new
things.
We
haven't
added
anything
this
year
so
far,
I
think
we're
waiting.
There's
like
the
red
hat
folks
I
know
are
working
on
like
a
Ubi,
RFC
and
so
like
that
would
be
added,
that's
new,
but
it
hasn't
landed
yet
and
then
we're
probably
going
to
start
thinking
or
looking
into
what
it
means
to
do
better,
arm64
support,
and
so
that
will
probably
land.
Those
are
probably
like.
The
major
things
I
can
think
of
that
would
land
they
just
they're,
not
there.
Yet.
A
A
We
have
two
Java
specific
ones,
but
I
don't
necessarily
see
anyone
here
representing
Java,
so
it
might
not
make
sense
to
talk
about
these.
Unless
someone
here
wants
to
talk
about
them.
A
All
right
cool:
let's
talk
about
the
next
two
up
here.
First
off
we
have
proposal
create
language.
Family
Builders
I
just
saw
that
Dan
mccusa
put
a
comment
on
here
asking
for
Builder
maintainer
comments.
A
I
didn't
have
a
chance
to
read
this.
It
was
two
hours
ago,
but
I
will
take
a
look
at
this.
Hopefully
this
afternoon,.
A
Although
I
say,
although
Upstream
as
well,
there
was
there's
an
upstream
issue
to
squash
Builder
images,
and
that
also
has
been
getting
non-zero
amounts
of
comments
in
the
past
couple
weeks.
A
Asking
for
clarifications
and
whatnot
I
still
probably
wouldn't
hold
my
breath.
It
would
probably
take
a
while
for
them
to
get
anything
into
say
pack
or
something
like
that.
So
it
probably
still
makes
sense
for
us
to
do
this
and,
like
part
of
me,
thinks
that
it's
probably
this
right
thing
to
do
in
terms
of
like
actually
running
builders
in
production.
B
Yeah
I
think
this
is:
has
all
the
approvals
needed,
I'm
kind
of
wary
to
go
ahead
and
just
merge
it.
No
one
other
than
me
and
Dan
makuza
have
talked
about
this
I
put
it
in
front
of
the
cloud
Foundry
Foundation
technical
oversight
committee.
Their
feedback
was
this
looks
great
and
Chris
Clark
who's,
our
liaison
with
the
foundation,
is
showing
it
to
apparently
the
cloud
Foundry
Foundation
has
lawyers
that
can
read
over
stuff
like
this,
so
This
RFC
is
getting
read
by
some
lawyers.
B
I,
don't
know
what
feedback
they'll
have,
but
maybe
they'll
Point,
some
legalese
out
at
me
that
could
be
worded
better
or
is
unclear
or
yeah
anyway.
I
think
we're
basically
in
a
state
that
this
looks
good.
My
plan
is
to
leave
it
open
to
hear
this
feedback,
possibly
from
the
foundation's
lawyers
and
hopefully
have
this
work
by
Friday,
at
which
point
we
can
start
to
plan
for
how
we're
going
to
hold
an
election.
When
that's
going
to
happen.
B
Yeah
I
gave
one
last
week.
The
summary
is
that
we're
going
to
hold
elections
there's
basically
the
way
that
it's
going
to
work
is
that
we're
going
to
have
a
three-person
steering
committee
each
seat
on
the
steering
committee
is
going
to
be
for
a
two-year
term,
although
for
the
very
first
election
that
we
hold,
it's
going
to
be,
two
of
those
seats
are
for
a
two-year
term,
and
one
of
those
seats
is
for
you
one
year
term.
B
This
is
to
make
sure
that
we
have
like
context
that
can
be
handed
off
every
year
instead
of
a
situation
where,
like
maybe
the
entirety
of
the
steering
committee
change,
is
over
and
then
there's
some
rules
about
candidates
and
their
eligibility
and
voters
and
their
eligibility.
How
voting
Works,
which
is
basically
a
ranked
Choice
algorithm?
B
So
you
kind
of
you
vote
for
everyone
in
order
of
your
preference
and
there's
also
some
rules
about
the
number
of
people
from
any
given
company
and
then
also
a
specific
rule
about
the
addition
of
a
candidate
from
the
community.
So
this
is
likely
to
be
someone
who's
like
a
major
user,
but
isn't
necessarily
A
contributor
and
so
yeah.
B
It's
worth
a
read
through
just
to
understand
the
elections
Concepts
in
general,
but
it's
pretty
much
based
off
of
the
existing
Cloud
Foundry
Foundation
talk
election
process
with
some
modifications
that
are
tailored
to
better
support
the
keto
project,
mostly
because
it's
just
like
a
much
smaller
project.
Generally
speaking,.
E
Hey
this
is
Ram
I,
just
pinged
Chris,
to
find
out
if
he
has
any
updates
for
the
potato
working
group
from
LF
legal.
So
hopefully
there's
some
news
from
that
end.
A
A
A
Don't
think
there's
anything
big.
The
only
thing
that
might
be
worth
calling
out
is
I
believe
that
Java
now
has
some
form
of
internal
node
support.
I.
Think
that
just
got
released
this
week.
I
don't
actually
know
what
that
entails,
because
I
am
on
a
Java
developer
or
a
Java,
buildpax
maintainer,
but
I
believe
that
they
have
now
some
support
for
if
you're
running
a
Java
app
with
node
front
end
material.
A
And
then,
finally,
any
open
mic
any
questions.
Anything
like
that.
E
I
am
again
I
love
to
get
an
idea
of
what
it
takes
to
be
able
to
provide
arm
support
across
build
packs,
and
the
reason
I'd
like
to
know
that
is
I
see
good
potential
for
sprinkling
sort
of
potato
road
map,
slash
updates
on
the
cloud
Foundry
blog.
We
could
of
course
publish
to
the
packetto
blog
as
well
and
cross
post
it.
But
you
know
that's
just
a
technicality,
but
the
idea
is
I.
E
Think
the
cloud
Foundry
community
in
general
will
benefit
from,
or
rather
the
paqueto
community
will
benefit
from,
like
something
of
some
information
about
text
Okay.
So.
B
Yeah
there's
an
ongoing
discussion
feel
free
to
post
further
questions,
Sophie
wrote
it
up
and
Dan
has
provided
some
feedback.
There's
some
like
history
of
things,
we've
done
in
the
past
things
that
are
needing
to
be
done,
but
it's
worth
maybe
another
look
in
kind
of
refining
at
this
point
to
figure
out
what
the
next
step
is.
E
A
D
D
We
also
have
the
arm
slack
channel
in
the
potato.
Slack
haven't
looked
the
latest,
but
I
know
that
there
are
a
few
people
in
our
community
who
have
been
working
on
different,
tooling
and
things
related
to
arm
support,
which
could
also
be
a
helpful
place
to
check
out
I.
Think
also
we
were
talking
earlier
about.
You
know
adding
the
roadmap
items
around
arm
64
and
that
would
also
potentially
have
some
like
helpful
context
about
like
what
we
actually
need
to
do
to
support
that
I.
Just
don't
think.
We've
gone
around
to
fleshing
that
out.
A
A
Jericho
from
rapid7
he's,
he
has
been
talking
a
lot
to
us
about
potentially
like
how
could
we
support
arm
64
as
well.
E
Yeah,
if
I
remember
correctly,
I
think
he
was
coming
at
it
from
like
running
Gravitron
instances
and
things
like
that,
and
he
was
worried
about
like
compliance
and
stuff
for
some
os's
that
he
had
I
think
maybe
like
a
year
ago
or
something
but
I'll
definitely
reach
out
to
him
and
thanks
everyone
for
the
inputs.
I
think
I
have
a
few
good
starting
points
that
I
can
make
use
of
to
write.