►
From YouTube: Working Group: 2022-05-03
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
Meeting
today
is
a
special
session,
we'll
touch
a
little
bit
on
that,
but
I'm
really
happy
to
see
full
house
today
and
some
really
good
friends
from
this
community
joining
welcome
ron
ram,
really
glad
to
see
you
here
also
jan,
is
the
first
time.
At
least
I
see
you
in
this
session
so
welcome
you
all
yeah,
welcome
all
team
welcome
aussie,
again
we're
glad
to
have
you
here
awesome.
B
I'll
go
first,
hi
everyone.
This
is
ram,
I'm
part
of
the
cloud
foundry
foundation
team.
My
big
motivation
to
come
today
and
join
was
because
chris
is
away
for
a
week,
so
I
just
had
to
make
sure
that
the
recording
was
fine
but
otherwise
really
happy
to
see
everybody
here.
We've
obviously
all
met
on
different
forums
but
appreciate
all
the
new
energy
that
you're
bringing
in
david.
Thank
you
for
that
happy
to
be
part
of
the
group.
A
B
C
I'm
jan
I'm
I'm
a
product
owner
with
a
with
the
team
at
sap.
We
are
looking
at
vacato,
build
packs
cloud,
foundry
cloud
native
buildbacks
in
general,
and
I'm
also
happened
to
sit
in
the
doc
of
the
cff.
A
Sounds
great
jen!
Thank
you
for
joining
yeah
yeah.
The
big
thing
I
want
to
share
with
you
all
today
is
its
proposal
from
the
team
was
to
turn
the
first
working
group
meeting
of
every
month.
Make
it
an
open
roadmap
discussion,
which
is
awesome.
I
was
feeling
ryan
I
mean
I
just
wish
some
other
projects
will
follow
this
example,
because
one
thing
is
to
build
a
road
map
and
play
in
the
public
and
put
it
in
a
repo.
A
A
different
thing
is
to
consistently
you
know
every
month
make
sure
that
we
are
aligning
with
the
roadmap.
We
are
communicating
the
progress
or
the
lack
of
progress
on
some
stuff
in
the
roadmap.
This
is
great
and
we
hope
this.
A
This
is
useful
for
the
existing
and
new
contributors
to
the
pacquiao
wheel,
packs
project,
and
I
really
appreciate
that
the
team
had
this
condition
so
because
it's
the
first
time
today,
we
do
this,
at
least
that
I'm
aware
of
ryan
proposed
to
facilitate
this
particular
session,
and
I
will
be
a
notetaker
and
unless
there's
any
objection,
so
yeah
I'll.
Let
ryan
lead
from
this
point
on.
D
Yeah
I
can,
I
can
provide
some
more
background
on
the
the
kind
of
general
thinking
behind
this
particular
version
of
the
working
group
meeting,
the
steering
committee,
which
consists
of
myself
and
dan
makuza
and
emily
who's.
D
Also,
here,
we've
been
talking
for
a
bit
about
things
that
picado
could
be
doing
to
try
to
bring
in
more
contributors
to
get
more
involvement
earlier
on
to
get
better
user
feedback
about
particular
things
that
we
want
to
produce
as
features
and
one
of
the
things
that
became
pretty
evident
was
it
wasn't
always
clear
to
end
users
or
people
who
could
become
contributors?
D
What
it
is
we
were
working
on,
even
though
these
things
were
there.
If
you
looked,
it
wasn't
in
one
place
and
it
wasn't
clearly
communicated,
and
so
this
is
one
part
of
that
effort
in
you
know
the
coming
year
for
us
to
try
to
be
a
little
bit
better
at
as
stewards
of
that
kind
of
road
map
and
and
making
that
discussion
a
little
bit
more
open
and
gathering
feedback
from
folks.
D
So
yeah,
I
think
today,
we're
going
to
start
with,
is
a
little
bit
of
a
review
of
what
happened
in
2021,
because
we
did
in
2021
a
lot
of
stuff
and
it's
worth
taking
a
look
back
and
seeing
what
we
achieved
and
then
we're
going
to
talk
about.
What's
upcoming
for
2022.,
both
of
these
things
are
going
to
be
discussed
in
a
couple
very
shortly
to
be
published,
blog
posts
and
then
from
there.
D
We
can
actually
take
a
look
at
the
current
roadmap,
the
items
we
have
that
are
kind
of
top
of
mind
there,
and
we
can
kick
off
some
discussion
if
that
takes
place.
So
to
start
a
little
bit
with
the
review
stuff,
I'm
gonna
hand
it
over
to
emily
who's.
Gonna.
Give
us
a
little
background
on
what
happened
last
year.
F
F
So
I
know
we're
a
little
late
into
the
year
to
be
doing
our
2021
recap
and
the
launch
of
2022
roadmap.
But
you
know
it's
been
a
strange
year,
so
we're
getting
off
to
a
little
bit
late
start,
but
hopefully
that
won't
impact
us
too
much.
F
So
our
themes
from
last
year's
roadmap
were
solidifying,
existing
build
packs,
expanding
the
bill
pack
ecosystem
and
supporting
non-production
use
cases.
So,
just
to
summarize
some
of
the
work
we
got
done
on
that
front,
we
put
a
lot
of
effort
into
defining
via
rfcs
and
standardizing
a
bunch
of
options
and
practices
across
all
of
our
build
packs.
So
we
move
from
having
a
variety
of
types
of
configuration
options
to
standardizing
on
environment
variables
wherever
possible.
F
We
also
defined
options
that
exist
in
all
build
packs
for
things
like
log
levels.
You
know
we
define
common
interfaces
to
make
sure
that,
when
anyone's
picking
up
a
paquetto
build
pack
they're
getting
a
predictable
experience
whenever
that's
possible,
we
standardized
our
handling
of
versioning,
some
of
the
details
of
how
we
handle
specific
environment
variables,
like
ones
that
are
meant
to
configure
tools
that
are
orchestrated
by
the
build
pack,
and
we
also
included
a
set
of
utility,
build
packs
that
provide
common
configuration
options
in
all
of
our
major
language
families.
F
So
we
have
these
features
that
are
reproducible
across
all
the
different
languages.
Another
thing
we
did
was
you
know
over
the
course
of
the
previous
year.
We
learned
a
lot
about
how
to
architect
build
packs
in
a
way
that
makes
them
modular
and
composable
and
more
useful.
So
we
went
back
and
did
some
work
to
restructure
our
python
and
php
build
packs
to
take
those
learnings
into
account,
obviously,
to
anyone.
F
Who's
interacted
with
the
kettle
build
packs
we're
not
at
perfect
standardization,
yet
like
there's
gonna,
be
more
work
to
do
there
to
make
sure
all
the
build
packs
are
using
similar,
tooling
and
the
same
metadata
schema.
So,
even
though
this
isn't
a
theme
on
the
22
roadmap,
we're
going
to
be
continuing
work
in
this
thing.
F
Next
up
in
expanding
the
build
pack
ecosystem
just
want
to
call
out,
you
know,
support
for
additional
types
of
applications
that
we've
added
over
the
last
year,
including
you
know.
Whole
language.
Ecosystems,
like
python,
now
has
a
top-level
build
pack
that
we're
supporting
and
recommend
as
being
production
grade,
we've
introduced
into
the
paquetto
community
project,
support
for
rust
and
also
support
for
javascript
front-end
applications.
F
We've
done
a
lot
of
work
with
a
lot
of
help
from
the
community
and
some
folks
on
this
call
to
expand
into
supporting
new
new
use
cases.
New
java
application
servers,
new
jvm
implementations,
new,
build
tools,
new
apms,
including
data
dogs,
stuff,
like
that,
so
we're
pretty
excited
about
all
these
new
features.
F
We
definitely
want
to
hear
from
folks
who
are
using
the
build
packs,
but
what
top
priorities
should
be
for
upcoming
expansion
work?
Another
one
of
our
major
themes
was
supporting
non-production
use
cases,
so
we
added
a
watch
exec
build
pack
that
can
be
used.
F
F
I
feel
like
secure
supply
chains
have
been
a
big
theme
in
the
industry
over
the
last
year
and
the
upstream
cmb
project
launched
a
new
feature
to
allow
build
packs
to
contribute
bills
of
materials
and
standardized
formats
like
sift
and
cyclone,
and
once
that
feature
launched,
you
know
we
took
that
and
ran
with
it
and
are
trying
to
ensure
that
all
of
our
build
packs
generate
thorough,
accurate
builds
of
material
in
predictable
formats
and
we've
rolled
that
out
in
java
node.js
and
go.
F
This
is
not
everything
we've
done
in
21,
but
in
2021,
but
these
are
some
of
the
major
highlights,
and
I
just
want
to
thank
everyone
for
their
hard
work.
I
feel
like
it's
when
you
step
back
it's
exciting,
to
see
how
much
we
accomplished
over
the
last
year.
D
D
Yeah,
emily,
you
can
are
all
I
guess,
I'll
share
hold
on.
D
All
right,
yeah,
so
scrolling
down
here
we
get
into
the
2022
roadmap,
so
this
is
based
on
effectively
the
feedback
we
got
from
the
discussion
thread
that
was
in
our
feedback
repository
there's
a
lot
of
really
great
feedback.
I
think
we
ended
up
seeing,
like
you
know,
a
huge
number
of
votes
for
a
lot
of
things
that
you're
going
to
see
here
at
the
the
top
that
are
kind
of
the
most
important
priorities
for
the
year
so
like.
D
Why
don't
we
start
with
the
first
one
here,
I
think
probably
the
most
voted
for
and
the
most
requested
sets
of
features
had
to
do
mostly
with
improving
and
updating,
and
you
know
enabling
more
base
images,
stacks
and
builders.
We
saw
requests
from
folks
asking
for
arm
64
support
for
more
support.
D
In
particular
os's,
like
you
know,
more
variant
versions
of
ubuntu,
we
saw
requests
for
things
like
ubi,
red
hat's,
universal
base,
image
os
as
well,
and
we're
going
to
be
planning
to
do
a
bunch
of
things
on
the
road
map
in
the
next
few
months,
even
to
start
to
move
the
ball
on
this
front.
You
you've
been
coming
to
the
working
group
meetings.
D
Recently,
you
probably
have
noticed,
there's
a
jammy,
jellyfish
rc,
that's
already
been
approved
and
merged,
that
work
is
definitely
going
to
be
starting
soon,
in
addition
to
some
rfcs
related
to
improving
our
tooling
around
how
we
build
and
maintain
stacks
going
forward,
hopefully
in
such
a
way
that
it'll
be
much
easier
for,
for
you
know,
people
joining
the
community
to
contribute
stacks
as
a
thing,
instead
of
it
being
something,
that's
very
much
a
dark
art
of
the
folks
who
are
familiar
with
the
project,
so
yeah,
that's
probably
the
number
one
thing
we
care
about
for
2022
is-
is
trying
to
make
our
our
stacks
something
that's
a
little
bit
more
representative
of,
what's
going
on
in
the
general
ecosystem
and
embracing
a
bunch,
more
kind
of
like
target
os's
as
well
as
architectures.
D
What
we've
noticed
is
that
there's
quite
a
lot
of
there's
quite
a
big
gap
between
that
being
entirely
self-service,
where
folks
can
go
ahead
and
just
build
a
build
pack
and
contribute
it
versus
what
we're
seeing
is
that
we're
we're
having
to
do
a
lot
more
explaining
than
what's
written
in
our
documentation
or
what's
visible,
in
example,
repositories.
D
So
we're
going
to
want
to
do
a
lot
in
the
next
year
to
try
to
improve
that
experience.
We
want
paquetto
to
be
a
place
where
folks
can
come
in
figure
out
how
to
build
a
build
pack
and
contribute
it
and
be
able
to
do
that
in
a
way
that
doesn't
require
a
lot
of
support
from
the
core
team
that
will
be
kind
of
a
really
big
win.
D
If
we
can
get
to
a
place
where
you
know,
someone
comes
in
with
a
fully
fledged
build
pack
that
we
didn't
have
any
real
hand
in,
because
they
were
able
to
build
the
entire
thing
themselves,
and
so
that's
gonna
require
quite
a
lot
of
stuff
improvements
to
the
actual
tooling
around
how
we
build
build
packs,
improving
improvements
to
our
documentation
and
we're
really
interested
in
hearing
from
the
folks
who've
built,
build
packs
in
the
past
or
contributed
major
features.
Where
are
the
places
that
were
deficient?
D
D
D
We
also
want
to
make
it
really
really
clear
to
outside
contributors
what
the
dependencies
are
where
they
came
from
how
they're
built
all
of
those
things
should
be
very
transparent
and
clear
to
users
again
to
double
down
on
what
emily
mentioned
earlier
about.
You
know:
supply
chain,
vulnerabilities
and
understanding
where
things
come
from
making
sure
that
the
dependencies
that
appear
in
our
build
pack
that
those
are
clearly
defined
where
they
came
from
and
how
they
are
built.
I
think
that's
a
major
goal
for
the
keto
build
packs
in
the
next
year.
D
In
addition
to
that,
we
want
to
make
a
bunch
of
improvements,
and
this
is
going
to
be
just
you
know:
lots
of
small
improvements
across
all
of
the
build
packs.
We
have
existing
to
try
to
reduce
overhead
in
downloading
and
re-downloading
and
enable
better
caching
mechanisms
so
that
we're
making
sure
that
the
actual
building
process,
when
you
go
to
build
a
build
pack
or
to
build
up
an
app
based
on
build
packs
that
if
that
goes
as
quickly
as
possible,
and
that
our
users
have
a
really
great
experience.
D
So
that
wasn't
everything
that
was
in
the
discussion.
Those
were
just
the
kind
of
three
top
big
areas
that
were
that
had
a
lot
of
votes
that
people
were
really
interested
in,
seeing
some
progress
being
made
on,
and
so
there
definitely
will
be
items
that
show
up
on
our
roadmap
that
are
outside
of
these
three
themes
and
we'll
continue
to
push
forward
on
those
things.
But
these
are
the
main
things
we're
focusing
on
starting
this
year.
D
Right,
I
think
from
there
we're
going
to
transition
into
actually
looking
at
what
is
going
on
right
now
in
the
roadmap
and
how
it
relates
to
those
particular
themes.
D
So
the
document
I'm
looking
at
right
now
is
in
the
paketto
buildpex
community
repository
it's
roadmap.md,
and
our
goal
with
this
meeting
is
to
kind
of
review
this
document
and
make
sure
that
it
stays
up
to
date
and
representative
of
what's
actually
happening
and
how
those
things
are
kind
of
like
addressing
the
overall
topics
that
we
think
are
priorities
for
the
year.
D
D
The
way
that
these
tracking
issues
are
structured
is
that
they
should
have
a
short
summary
of
what
exactly
it
is
we're
trying
to
achieve,
and
then
some
explanation
of
where
the
particulars
of
the
implementation
are
taking
place,
and
so
you
should
be
able
to
from
any
one
of
these
particular
roadmap
items.
Click
through
and
see
a
say,
a
top
level
summary
of
what's
supposed
to
happen,
and
then
some
details
about
progress,
that's
being
made.
D
All
right,
that
being
said,
I
kind
of
wanted
to
open
the
floor
at
this
point
to
ask
about
these
particular
items.
D
I
think
that
these
are
the
highest
priority
items
that
we
have
currently
in
flight,
but
I
wanted
to
basically
open
up
conversation
if
folks
were
interested
in
having
the
discussion
about
what's
in
here
or
questions
about
what
they're,
seeing
at
the
moment.
D
Doesn't
sound
like
there
are
questions
here,
I
think
in
the
long
run,
the
hope
is
that
this
will
continue
to
like
evolve.
None
of
these
excuse
me
one.
One
of
these
is
currently
in
flight,
which
is
this
particular
issue
here.
We're
gonna
be
landing.
Hopefully
this
particular
thing
soon
at
a
future.
D
Okay,
not
hearing
anything
about
these
particular
items.
I
was
going
to
move
on
to
the
next
section,
which
is
improving
the
bill
pack
authority
experience,
so
the
one
rsc
that's
on
here
is
actually
a
relatively
old
one.
That's
been
outstanding,
it
just
has
kind
of
fallen
off
the
priority
list,
but
with
it
being
a
renewed
theme,
something
that
we
want
to
try
to
achieve
or
do
a
better
job
on
in
2022.
D
I
brought
it
back
up
here
to
the
top.
This
was
to
auto
generate
reference
documentation.
So
today,
if
you
look
at
any
of
the
reference
documentation
on
the
piketto
website,
all
of
that
is
written
by
humans.
So
when
new
flags
are
added,
new
environment
variables
are
added,
new
features
are
added.
D
It
doesn't
sound
like
it.
The
last
topic
we
had
was
improvements
to
dependency
management
and
caching,
and
so
the
thing
here
is
not
actually
an
rc,
it's
a
little
bit
earlier
than
that,
which
is
it's
an
exploration
or
really
an
issue
outlining
what
next
an
exploration
could
look
like,
and
this
is
basically
an
exploration
around
what
I
was
talking
about
earlier
about
the
coupling
between
the
cloud
foundry
dependency
management
system
and
the
pochetto
dependency
management
system.
D
So
this
is
really
for
the
team
to
spend
some
time
looking
at
what
the
coupling
between
those
things
looked
like
and
how
we
could
actually
break
that
in
a
way
that
would
allow
paquetto
to
add
a
bunch
of
new
support
for
new
stacks
and
architectures
and
then
also
make
it
more
transparent
and
more
easy
for
folks
to
contribute
to
so.
If
you're
interested
in
that
particular
thing,
please
check
out
the
issue
related
to
the
exploration.
D
The
folks
who
pick
this
up
will
definitely
keep
this
issue
up
to
date,
with
what
they're,
finding
and
ideas
on
what
direction
that
might
move
in.
So
if
this
is
a
topic
of
interest
for
you
feel
free
to
chime
in
there.
C
Just
just
a
quick
comment
from
my
side
as
a
member
of
the
of
the
tfc,
the
the
cftoc
has
some
budget
for
ci
related
things
that
paquetto
might
be
able
to
request,
or
at
least
ask
for
I'm
not
sure
about
the
numbers.
But
if
there's
any
need
like
that,
I'd,
like
I'd,
say
broly,
you
best
join
the
toc
meeting
on
on
tuesdays
and
come
up
with
something.
C
So
if,
if
it's
about
that,
there
is
some
some
budget
and
some
of
the
other
working
groups
are
already
like
setting
up
concourses
or
some
other
infrastructure
thinking
about
how
to
share
it
and
within
what,
and
I
think
that
the
limit
seems
currently
to
be
somewhat
within
a
working
group.
So
I
guess
it
would
be
okay
for
a
potato
to
have
some
some
own
infrastructure.
There.
D
So
yeah,
that's
a
great
call
out
all
right,
so
that
covers
the
things
we
talked
about
as
kind
of
top
level
items,
but
there's
also
stuff.
We've
already
approved
that
we
accepted
as
rrcs
in
the
last
year,
and
some
of
these
have
some
ongoing
work.
Others
were
accepted
and
mostly
us
sat
there
and
we
haven't
made
forward
progress
on
them,
and
some
of
these
are
actually
done,
but
we
just
haven't
done
the
work
to
say.
Oh
yes,
this
is
crossed
off
the
list.
D
We're
completely
finished
with
this
thing,
so
all
I
really
wanted
to
say
about
this
section
is
that
the
folks
who
are
involved
in
doing
a
lot
of
the
work?
I
think
you
should
feel
free
to
look
through
this
list
figure
out.
What's
actually
getting
work
done,
what's
complete
what
you
maybe
can
make
progress
on
going
forward,
and
we
should
look
about
trying
to
close
out
some
of
these
particular
issues
or
making
sure
that
their
tracking
issue
is
kept
up
to
date
with
what
the
current
progress
is.
D
Other
than
that,
I
think
that
the
if
you're
in
the
community
and
you're
looking
for
things
to
work
on
these
are
perfectly
reasonable
issues
to
try
to
help
push
the
ball
forward
on
and
so,
for
example,
there
is
this
rfc
about
remote
debugging.
D
If
you
are
interested
in
contributing
remote
debugging
to
any
one
of
the
language
families
that
is
not
currently
checked
off
in
this
list
like
there
is
a
lot
of
space
for
contributions
for
what
that
could
look
like.
So,
if
you're
looking
to
contribute
something
more
substantial
to
the
project,
take
a
look
at
the
roadmap,
especially
stuff
in
this
kind
of,
like
older,
other
open
rsc's
list.
These
are
definitely
things
that
are
worth
trying
to
push
the
ball
forward
on.
C
All
right,
there's
two
things
from
the
very
broad
topics
from
the
from
the
very
top
that
that
we
might
want
to
to
talk
about
with
in
in
that
regard,
which
is
like,
maybe
the
the
the
jammy
jellyfish
things
like,
because
we
are
already
looking
into
building
that
stack.
So
at
least
partially.
C
We
could
try
to
do
that
just
just
upstream
because,
like
we,
we've
run
actually
like
a
a
stack
as
it
comes
from
pocato,
a
version
that
uses
2004
and
a
version
that
uses
2204
through
some
of
the
vulnerability
scanners
and
are
like
actually
up
for
looking
forward
to
consume
the
one
that
has
zero
known
vulnerabilities,
which
is
temmie
jellyfish.
C
So
if
we
we
could
just
instead
do
that
upstream,
it
could
be.
It
could
be
a
thing,
and
the
other
is
that
for
some
of
the
build
packs
we've
written,
we
we
have
like
kind
of
created
our
own.
I
guess,
like
gareth,
could
say
more
to
that.
Our
own
integration
testing
framework,
I'm
not
currently
considering
moving
over
to
arkham,
while
doing
that
writing
some
readme,
maybe
for
it
by
understanding
how
it
works
documenting
it
for
others.
So
that
could
be
some
things
that
would
be
great.
D
Would
definitely
fall
in
this
improving
the
buildback
authoring
experience
category
for
sure,
yeah
yeah.
So,
if
you
are
interested,
I
would
encourage
you
to
like
comment
on
this
particular
issue,
saying
you
know:
here's
what
we're
looking
into
we're
interested.
How
can
we
get
started?
That
would
be
great.
D
All
right,
that's
all
I
had
planned
as
far
as
like
our
review
of
the
current
roadmap,
I
wanted
to,
I
guess,
open
up
the
floor
for
any
other
conversation
about
road
map
items
that
seem
like
we
entirely
missed
or
things
that
folks
are
interested
in
on
this
kind
of
the
remainder
of
this
meeting
can
just
be
an
open
forum
for
us
to
discuss
things
that
folks
might
be
interested
in
that
just
weren't,
represented
necessarily
on
the
roadmap,
is
today.
G
All
right
well
I'll
jump
in
there.
I'm
particularly
interested
in
the
the
bullet
point
that
you
had,
that
doesn't
have
the
stuff
after
it,
but
that
was
the
publish
a
full
set
of
paquito
stack
images
compatible
with
ibm
red
hat
universal
base,
image
stuff,
that's
something!
I'm
I'm
really
interested
in
on
a
number
of
levels
as
well.
G
I'm
also
interested
in
it
because
I'm
following
the
build
packs
work
to
add
extensions
to
allow
you
to
install
dependencies
using
the
operating
system
stuff
because
I'd
like
to
be
able
to
install
like
the
runtime
that
I'm
using
like
java,
install
that
using
equivalent
of
like
rpm
install
java
rather
than
having
a
tarball
that
comes
down
instead.
So
I
can
get
it
from
the
upstream
vendor
for
the
os
that
I'm
using.
G
So
that's
that's
kind
of
my
real
interest
and
why
I'm
kind
of
here,
as
part
of
this
working
group,
is
because
I
want
to
kind
of
like
see
what's
going
on
with
that
and
if
there's
so.
If
there's
people
who
are
already
looking
at
or
already
interested
in
stack
images
on
ubi,
then
yes,
I
would
love
to
talk
with
you
and
lend
a
hand
and
see
what
we
can
achieve
with
that
part
of
it.
D
Yes,
this
reminds
me
of
something
that
I
didn't
clearly
articulate
that
I
wanted
to
make
sure
that
I
covered,
which
is:
how
do
we
get
things
to
show
up
on
the
roadmap
here?
There
are
things
that
aren't
there
that
you're
interested
in
working
on.
How
do
we,
you
know
collaborate
around
making
sure
that
they
appear
somewhere
in
the
roadmap
and
get
those
things
moving
forward?
D
I
would
say
to
me
the
things
that
make
logical
sense
as
far
as
steps
go
is
to
start
with
a
discussion
in
the
the
feedback
repository.
So
if
you
don't
know
where
that
is,
that
is
the
the
keto
build
pack
feedback,
repo
and
there's
a
discussion
forum.
That's
underneath
there.
I
can
drop
a
link
here
in
the
chat.
D
The
discussion
from
there
like,
I
think
the
next
obvious
step,
is
to
open
an
rc
to
basically
outline
what
your
plans
are
clearly
between
those
two
points,
there's
probably
quite
a
bit
of
exploration,
to
try
to
figure
out
what
exactly
that
rfc
should
look
like,
and
hopefully
that
thing
can
happen
both
in
the
discussions
actual
threat
itself,
but
then
also,
if
you're
interested
in
just
publicly
putting
information
about
an
exploration
somewhere,
so
that
it's
actually
addressable
in
some
way
that
folks
within
the
community
can
see.
D
We
have
this
piketto
community
explorations
repository,
whose
purpose
is
entirely
just
to
hold
kind
of
exploratory
documentation
of
you
know.
You
looked
into
a
particular
thing:
here's
what
we
kind
of
found
out-
and
you
know
there
are
a
couple
of
examples
in
there
of
previous
explorations
that
have
been
done.
D
So,
if
that's
useful
to
you
as
far
as
the
kind
of
next
step,
then
feel
free
to
contribute
an
exploration
there,
but
once
you
do
get
to
a
state
where
the
rfc
happens,
I
think
things
start
to
fall
into
a
much
more
regular
order.
That
folks
should
be
familiar
with.
D
The
rfc
will
go
through
its
standard
process
of
approval
and
then
acceptance
at
which
point
we're
going
to
make
sure
that
that
rfc
appears
somewhere
on
this
roadmap
document
and
that
we
start
up
a
tracking
issue
that
will
then
let
people
figure
out
where
the
work
needs
to
get
done
and
keep
track
of
the
progress
that's
being
made.
As
that
happens,.
D
I
am
going
to
write
up
a
bunch
of
thoughts
on
this
and
kind
of
directions
for
how
stuff
gets
on
the
roadmap
and
make
that
thing
a
little
bit
more
clear
for
people.
So
we
can
point
them
at
something
that's
written
rather
than
having
to
maybe
review
the
recording
of
this
particular
meeting,
but
basically
to
outline
a
little
bit
about
what
I
just
said.
D
But
yeah
so
ozzy
for
you,
particularly,
I
would
say
if
you
haven't
already
gone
to
the
discussion
forum
on
the
feedback
repository,
feel
free
to
open
an
issue
there
and,
like
start
a
conversation,
I
know
there's
like
some
other
stack
related
stuff
there.
So
it's
entirely
possible
that
this
conversation
is
already
happening.
I
just
don't
know
about
it.
G
Yeah,
it
looks
like
there's
a
comment
from
it's
kevin
who's
put
one
on
to
the
interesting
feedback
on
broader
stack,
support,
topic
and
there's
a
that's
coming
from
there
in
there
talking
about
ubi
stack
support.
So
I
wonder
if
that's
where,
because
I'm
I'm
talking
referencing
the
bullet
point
that
you
had
in
the
presentation
thing
that
you
put
a
minute
ago
or
the
document
you
had
a
video
at
the
overview.
G
F
I
wonder
if
one
of
the
things
we
could
do
is
on
the
rfc
repo,
like
we
have
tracking
issues.
Do
we
want
another
type
of
issue,
that's
sort
of
like
a
pre-rfc
placeholder,
it's
like
something
that
we
have
as
a
community
agreed
to
do,
or
maybe
we've
mentioned
it
in
one
of
these
themes,
just
to
say
that,
yes,
we
want
to
create
an
rfc
for
this,
and
then
you
know
if
we.
F
D
I
think
that's
an
entirely
reasonable
thing
to
do.
You
should
not
feel
that
you
can't
open
an
issue
on
the
rfc's
repo
doing
exactly
that.
So
that's
another
place
for
sure
that
you've,
you
can
feel
like
you
should
be
able
to
at
least
stake
a
claim
or
describe
a
level
of
interest
in
maybe
working
on
a
particular
area
for
an
rc.
D
I
would
a
hundred
percent
agree
with
you.
I
think
we've
hopefully
will
as
soon
as
they'll
kind
of
work
in
refactoring
our
stack
infrastructure
to
support
something
like
jammy
goes
forward.
It
will
be
considerably
easier
for
us
to
build
out
and
support
many
different
kinds
of
stacks,
and
so
I
don't
think
there
would
be
hardly
any
opposition
to
such
an
idea
for
us
to
basically
support
every
ubuntu
lts
release
that
comes
out.
D
Okay
well
hearing
yet
more
silence.
I
think
that
that
basically
concludes
the
discussion
of
the
roadmap
for
this
month
next
month.
We're
gonna
again
take
a
look
at
the
items
in
the
roadmap
and
from
there
figure
out
kind
of
what
next
directions
could
look
like.
What
are
the
new
major
pieces
of
work
that
we
think
the
project
should
focus
on?
D
We
have
about
20-ish
minutes
left
in
the
meeting,
and
I
know
that
we
had
at
least
last
week-
and
maybe
this
week,
some
remaining
rfcs
that
we
might
have
wanted
to
look
at.
So
I
think
I'm
gonna
hand
the
medium
back
to
david
and
we
maybe
can
at
least
discuss
a
couple
of
those
with
the
remaining
few
minutes.
We
have
in
the
meeting.
F
Dan's,
not
here
today
to
dive
in
my
general
thought
was.
This
seems
like
a
good
idea,
but
I'd
like
a
little
bit
more
detail
in
the
rfc
around,
like
I
think,
it'd
be
nice
to
have
an
example
of
how
folks
would
be
using
this
with
docker
run
or
docker
compose
and
then
sort
of
also
going
into
what
kind
of
configuration
options
we
need
in
order
to
be
able
to
set
the
end
point
that
the
health
checker
is
reaching
out
to.
H
Yeah,
I
just
saw
the
feedback
from
you
emily
and
some
of
the
feedback
from
andrew.
I
haven't
had
time
to
respond
to
either
of
those.
I
think
that
your
request
of
me
laying
out
a
little
bit
more
on
what
it
means
to
be
a
net
installation
is
fair.
H
It's
a
bit
hard
to
quantify
because
it
is
a
bit
of
a
moving
target
depending
on
the
version,
but
I
can
give
a
maybe
a
bit
more
of
a
rough
estimation
of
what
it
looks
like
and
then
I
haven't
had
time
to
fully
digest
andrew's
proposal
and
either
decide
that
it
should
be
included
in
the
rfc
or
come
back
with
a
counter
argument.
H
So
yeah
this
is
almost
effectively
a
stop
gap
to
do
that
in
so
far
as
we
are
currently
stripping
out
certain
dependencies
that
we
didn't
that
were
like
overlapped
in
how
we
were
doing
the
build.
This
is
effectively.
If
you
go
look
at
my
spike,
it
is
to
change
the
change
it
to
we're
now
consuming
the
release
from
microsoft
directly.
That's
the
thing!
That's
changing.
E
I
think
that's
probably
worth
spelling
out
in
the
rfc
itself.
I
didn't
really
notice
whether
or
not
that
was
clear
because
we've
like
had
so
many
synchronous
discussions
about
this
idea.
But
if
that's
not
obvious
from
rfc,
I
think
it
should
be
because
that's
like
really
the
core
of
the
idea
is
just
ship.
What
microsoft
ships.
F
H
I
This
is
a
fairly
short
rfc.
It
spun
out
of
the
jimmy
jellyfish
rfc
that
ryan
put
up
last
week
and
essentially
that
rfc
like
laid
out
some
different
naming
structures
for
the
repos
and
how
we
tagged
the
images
for
jimmy
jellyfish
going
forward.
So
an
effort
to
you
know
just
be
consistent
and
across
like
the
two
stacks
or
sets
of
stacks
that
we
will
be
supporting.
I
I
I
think
the
only
one
is
that
we
plan
to
stop
shipping
like
this
intermediate
image,
which
is
the
stack
images
that
don't
contain
cnb
metadata
and
instead
we
will
be
essentially
publishing
the
same
image
that
contains
the
cnb
metadata
to
both
the
tags
with
the
cnb
suffix
on
the
end
and
without-
and
I
think
that's
the
only
like
major
major
change
here
so
check
it
out.
I
But
then
I
also
saw
a
comment
today
that
brought
up
the
idea
of
like
what
we're
going
to
do
for
builders,
and
that
was
an
open
question
that
we
hadn't
answered
on
the
jimmy
jellyfish
rfc
as
well,
just
like
what
all
these
changes
are
going
to
mean
for
the
builders
and
I'm
just
hoping
that
I
know
some
of
the
builders
maintainers
are
here
that
we
could
start
thinking
about
that.
H
A
All
right,
thank
you.
Okay,
next
up
move
web
server,
promotion
to
top
level.
H
Yeah,
so
this
is
on
request
from
ryan,
based
on
the
fact
that
this
is
an
rfc
to
introduce
a
new
language
family.
It's
a
bit.
The
protocol
was
a
bit
unclear
I
initially
opened
and
had
this
merged
in
the
web.
Servers
sub
team
rfcs,
however,
ryan,
requested
that
I
actually
basically
reopen
it
and
move
it
into
the
top
level
rfc,
as
it's
proposing
the
introduction
of
a
new
meta,
build
pack
or
language
family,
so
I've
complied
with
that
moved
it
up.
I
don't
think,
there's
anything
that
needs
to
be
done.
H
The
only
maybe
slightly
tricky
bit
is
that
it
is
replacing
some
of
the
logic
that
we
have
in
the
full
builder
as
it
exists.
Currently,
so
we
will
be
removing
like
standalone,
http
and
nginx
and
replacing
it
with
web
server
who,
as
part
of
their
order
grouping,
have
standalone,
nginx
and
httpd,
see
only
gotcha
really
but
yeah,
pretty
straightforward.
F
F
I'm
just
wondering
if
we
could
leave
the
old
file
in
place
and
link
to
the
new
one
instead
of
removing
it.
A
All
right
great
seems
like
that's
it
in
terms
of
rfcs
there's
a
pretty
new
one,
but
it's
a
trap
state
from
team.
Okay,
anything
else
you
would
like
to
share
here
discuss.
C
D
D
It
appears
it's
moving
more
towards
using
cosine
and
having
a
cosine
integration
in
order
to
basically
assert
that
an
s
bomb
belongs
to
a
particular
image,
and
so
we're
basically,
you
know
we
have
the
outlines
of
what
we
think
we
would
want
for
this
particular
thing,
but
we're
kind
of
waiting
for
the
the
cnb
folks
to
figure
out
what
direction
they're
going
to
be
heading
in
before
we
implement
anything.
D
This
was
mostly
written
because
we
thought
it
was
very
close
or
eminent
to
land
in
the
cmb
space
and
then
that
ended
up
not
happening.
Okay,
understood.
F
I
think
some
of
the
motivation
behind
why
this
was
changing
on
the
cmb
side
is
that
it
can
be
hard
to
get
the
right
s
like
the
original
specification
required
you
to
bake
the
s-bomb
into
the
image
which
requires
special
tooling.
You
can't
you
know,
build
the
image
and
then
generate
it
afterwards
and
also
there's
some
concern
about
how
it
plays
into
like
the
dockerfile
extension
features.
That
ozzy
was
talking
about
where,
if
you're
running
those
extensions,
it
could
be
incorrect.
I
Might
also
just
be
worth
pointing
out
that
we
have
like
a
version
of
what's
in
this
blocked
rfc
implemented.
It's
just
turned
off,
so
all
of
our
stacks
that
we
publish
don't
have
this
bomb,
but
there
is
a
flag
that
you
can
turn
on
in
the
not
easy
to
turn
on.
But
there
is
a
flag
you
can
turn
on
to
add
an
s-bomb
of
the
type
that's
like
described
in
this
blocked
rfc.
I
If
you
wanted
to
see
what
that
would
look
like
in
practice,
but
actually
will
be
much
easier
once
the
new
stack,
descriptor
pull
request
lands
and
we
have
like
a
nice
tool
to
create
stacks.
You
can
set
that
environment
variable
for
the
experimental
s
palm
and
see
what
that
looks
like,
but
I
don't
think
that
this
one,
this
rfc
specifically,
will
ever
actually
get
merged
at
this
point.
So
it
might
just
make
more
sense
for
me
to
close
it
out.