►
From YouTube: Working Group: 2022-11-01
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
Awesome
welcome
to
the
paquero
working
group
meeting,
I'm,
glad
to
see
you
all
here,
a
friendly
reminder
that
I
I
don't
do
quite
often,
but
makes
sense.
This
meeting
falls
into
the
falls
under
the
cloud
Foundry
Foundation
code
of
conduct,
which,
in
summary,
it's
be
excellent
to
each
other,
like
you
always
do,
Awesome
song
sharing
again
here
link
to
the
notes
there
you
go
and
the
agenda
feel
free
to
add
yourself
to
attend
these
listings,
including
your
affiliation,
would
be
great
okay.
If
this
particular
session
does
anyone
would
like
to
take
notes.
A
Great
anyone
joining
for
the
first
time,
not
much
I'm,
glad
to
see
Ram
here
but
I'm
sure
I,
believe
everyone
here
announce
Ram
right.
A
In
case
you
don't
will
run
explore
the
cloud
Foundry
Foundation
ESR,
developer,
Advocate
there
and
and
a
big
supporter
of
the
project.
So
thank
you
for
joining
right.
So
normally
we
will
review
outstanding,
rfcs
but
I
believe
yeah.
There
are
no
non-draft
or
ready
to
be
reviewed
rfcs
as
of
now.
So
we
will
skip
this
section
unless
there
is
any
comment
or
question
regarding
rfcs.
A
Nope
all
right
next
up
in
terms
of
Upstream,
you
know
Cloud
native,
build
packs,
updates
or
questions
wondering
if
there's
anything
I
saw
that
Natalie
Arellano
was
looking
for
feedback,
or
this
particular
RNC
feedback
or
I,
don't
know
there.
You
go
all
right,
yeah
this
proposal
that
deals
with
the
deprecation
of
older
apis,
specifically
platform
API
less
than
0.7,
and
also
build
pack
API.
So
if
you
have
any
comment
regarding
that
proposal
feel
free
to
drop
it
there
right
any
other
update
from
Upstream.
A
C
A
B
I'm
pretty
sure
at
least
one
chunk
of
outstanding
work
on
this
will
be
resolved
quite
soon,
with
the
like
re-architecture
of
the.net
build
pack,
that's
in
progress
once
that's
fully
released,
which
we're
hoping
for
this
week
will
have
ticked
off.
The.Net
portion
of
this
I
see
that
there's
still
some
outstanding
stuff
related
to
node
and
Ruby
I
was
wondering
if
any
of
those
maintainers
could
comment.
A
D
E
A
Believe
to
confirm
the
status
on
that
one.
E
D
A
B
Cool
yeah,
as
of
last
week,
I
think
we
have
jme
support
for
the
web
servers
build
pack.
A
F
Made
it
just
in
time,
I
guess
sorry,
welcome,
yeah
I'm
still
at
work
on
this
on
the
yarn
installer
piece,
not
much
in
the
way
of
updates.
Just
now.
F
No
I
wouldn't
say
so,
I
think
there's
just
there's
a
lot
of
permutations
to
consider
and
it's
just
been
going
through
that
that's
the
challenge,
I
would
say,
but
nothing
blocking
per
se.
A
D
Yep
we
are
still
actively
working
on
this.
We
have
completed
a
number
of
language,
families,
I
believe
right.
Now.Net
core
is
almost
done,
Ruby
is
about
halfway
done
and
PHP
is
in
progress.
So
I
think
there
are
a
few
on
here
that
aren't
quite
up
to
date.
So
if
anyone
who's
working
on
these
could
just
make
sure
their
issues
are.
You
know
accurate,
really
reflected
here.
That
would
be
good
foreign.
A
A
All
right
seems
like
that's
it.
Okay,
it
is
new
relatable
process
types
yeah.
It's
investigation,
also
yeah.
Thank
you
to
whoever
did
this
I
think
I
need
to
move
this
one
out
all
right,
great
anything
else
in
regards
to
roadmap.
A
Good,
thank
you
all
right.
Okay,
next
one
project
updates.
Well,
it
seems
like
this
week
is
cubecon
recovery
weeks
for
for
many
people
it
was
great
to
see
potato.
It
was
great
to
see
the
Clan
Foundry
Day,
so
I,
don't
know
if
from
the
team
members
or
whoever
else
attended
the
event
in
person
there
is
any
highlight.
You
would
like
to
share
briefly
here.
The
conference.
G
So
I
know
there
are
real
human
beings
behind
the
prophet
now,
but
I
think
I
think
there
was
a
lot
of
there's
a
lot
of
value
in
the
talks,
both
the
one
at
the
CFA
and
the
one
at
the
kubecon
floor
on
Friday,
Also
and
then
I
guess
the
biggest
takeaways
for
me
from
working
the
booth
and
attending
these
conferences,
and
things
like
that
are
a
lot
of
folks
from
different
companies-
have
actually
tried
paqueto.
G
G
So
it's
really
fantastic
to
see
that
kind
of
feedback
from
the
community
and
the
other
thing,
obviously,
is
you
know,
learning
from
all
the
conversations
that
Frankie
and
Ryan
and
Sophie
were
having
with
the
different
people
about
Billy
packs
and
realizing
how
little
I
know,
but
also
like
learning
a
lot
and
taking
some
notes
back
and
in
particular.
E
G
The
big
lesson
was
also
that
paqueto
is
Way
Beyond,
just
the
cloud
Foundry
ecosystem
I
mean,
although
the
foundation
technically
has
some
part
to
play
in
the
in
the
governance
for
the
project.
But
the
reality
is
a
lot
of
people
who
had
never
heard
of
cloud
Foundry
never
used
it
before
are
all
making
use
of
paqueto
and
they
had
questions.
They
had
some
feedback.
They
had
some
ideas
about
how
to
use
it
and
things
like
that,
and
that
was
that
was
generally
great
to
see.
For
me.
D
I,
don't
have
a
huge
amount
to
add,
besides
what
Ram
just
said,
but
in
general
this
year,
compared
to
last
year,
it
just
seemed
like
a
lot
more
people,
I
talked
to
had
heard
of
build
packs.
Paquetto
just
had
a
general
understanding
of
the
technology
I
feel
like
last
year
when
I
spoke
to
people,
not
that
many
people
had
heard
of
them
or
ever
considered
them
as
a
solution.
D
So
it
was
good
to
see
you
know
just
build
packs
as
a
technology,
picking
up
a
little
bit
more
interest
this
time
around
the
cloud
native,
build
packs
talk
about
multi-architecture
builds,
was
also
pretty
heavily
attended
and
had
some
really
good
questions
about
build
pack
specific
stuff,
so
just
good
to
see
in
general.
B
I
was
just
gonna,
say:
I
was
definitely
surprised
that,
first
of
all
surprised
at
how
emphatically
some
of
the
Keynotes
kukon
were
talking
about
like
the
importance
of
securing
a
container
and
hardening
a
container,
which
obviously
we
know
matters,
but
just
to
sort
of
hear
it
said
again
and
again
on
large
stages
was
cool,
but
then,
on
the
flip
side,
I
had
to
see
how
relatively
few
like
Solutions
seem
to
be
available
for
solving
that
problem,
other
than
build
packs.
B
It's
like
us,
and
then
people
who
are
providing
secure
sort
of
Base
images
and
Tool
chains
like
chain
guard,
and
then
people
who
are
hardening
Docker
file
based
builds,
like
slim
AI,
but
I
didn't
really
see.
Is
we're
not
really
in
a
big
ecosystem?
Solving
this
specific
problem,
which
kind
of
surprised
me
given
that
everyone
seems
to
agree.
It's
very
important.
A
Yeah
absolutely
I
believe
one
of
the
big
themes
this
year
with
supply
chain
security,
so
yeah
more
more
on
that
later,
on
yeah
I'll
say
thank
you
again
for
everyone
in
the
team
who
did
boot
duties
who
prepare
content
left
home
to
be
there.
Thank
you.
We
will
have
a
more
complete
recap
in
the
upcoming
newsletter,
with
links
to
the
recordings
recordings
once
they're
available
and
a
copy
of
the
slides
for
each
session
yeah.
Thank
you
right.
Anything
else
in
terms
of
project
updates.
A
All
right
next
up
just
wanted
to
surface
here
a
discussion
created
by
a
Community
member
last
week
and
thank
you
Jan
for
adding
to
the
conversation
it
was
created
during
cubiccon.
So
I'm
not
sure
if
this
person
attended
and
had
a
this
conversation
and
then
created
the
discussion
here
but
refers
to
campus
of
the
kitten
offline
environment
so
feel
free
to
have
your
thoughts
there
or,
if
there's
anything
that
you
would
like
to
discuss
in
that
regard
here,
it's
also
good.
A
All
right,
yeah,
okay,
next
up
non-tokiro
stacks
for
integration
tests.
H
Hi
everyone
yeah.
That's
me
so
I'm,
while
looking
at
doing
some
changes
for
the
node.js
build
pack
to
support.
Non-Pechetto
Stacks
I
noticed
that
the
stack
that
I'm
using
to
test
python
is
not
gonna
work
for
all
versions
of
node
because
of
a
dependency
with
G
libsy.
That's
how
it's
too
old,
so
I'm
gonna
have
to
create
another
stack
to
do.
Testing
and
I
just
wanted
to
kind
of
like
raise
this
on
just
to
get
some
input
on.
H
You
know
like
right
now
for
non-pequeto
stacks
for
python
I'm,
just
using
something
in
my
own
Docker
hub,
which
is
fine,
but
do
do
you
want
to
have
some
kind
of
place
where
we
have
like
a
non.
You
know,
like
a
test
stack
sandbox,
that
you
guys
want
to
publish
specific
images.
To
that
you
have
some
control
over
or
you
know,
is
there?
Is
there
any
kind
of
strategy
on
that?
I
mean
I'm
happy
to
continue
to
do
it
myself
and
try
to
be.
H
You
know
aware
of
not
making
things
break,
but
if,
if
there's
any
desire
to
put
that
in
a
specific
Docker
Hub,
you
know
repo
or
something
I'm
happy
to
do
that.
Just
I
want
to
make
sure
I'm
working
with
you
guys
on
that.
D
As
far
as
I
know,
I
don't
think
we
have
a
strategy.
Somebody
please
tell
me
if
I'm
wrong,
but
I
would
be
interested
to
know
if
we
could
set
up
just
like
a
Pequeno
community
Stacks
situation.
So
we
could,
you
know,
have
an
official
paquetto,
slightly
supported
stack
that
we
use
for
testing,
but
I'm
not
entirely
sure
what
that
would
look
like
I
know.
It
would
be
kind
of
a
maintenance
burden
for
the
stacks
maintainers,
but
and
also
use
more
resources,
but
it'd
probably
be
good
to
have
something
in
the
project.
I
H
Yeah,
it's
really
like
I'm
testing
things
on
red
hat.
You
know.
Images
versus
Ubuntu
images
so
like
the
idea
would
be
like
I
was
thinking
about
that.
We
could
just
have
an
Ubuntu
with
a
different
stack
name
and
test
it.
But
like
really,
if
it's
going
to
break
the
integration
test,
it
would
be
nice
to
know
on
something
legit.
H
But
I
mean
like
as
a
short
term
I'm
happy
to
you
know,
keep
doing
what
I'm
doing,
but
I
just
think
it
would
be
good
to
just
to
have
you
guys
think
about
it,
and
you
know
if
there's,
if
there's
a
some
kind
of
plan
or
consensus.
That
would
be
good
for
me
to
know
so
that
I
can
work
with
you
on
that.
J
I
One
thing
just
coming
to
my
mind,
is
like
in
in
one
of
the
like
I
think
in
conversations
on.
Where
was
that
it
was
in
the
Java
sub
team
working
group.
I
There
seemed
to
be
someone
interested
from
the
red
hat
side,
so
maybe
they
even
have
a
stack,
they
could
provide
I,
don't
recall
the
name,
but
there
was
someone
attending
attending
the
Java
working
group
meeting
that
was
working
on
that
which
will
be
pretty
special
I
think
because
they
plan
to
use
the
Java
environment
that
is
coming
from
redhead,
so
somehow
different
in
in
how
it
works.
But
there
might
be
something
there
to
even
get
something
right
out
of
the
box.
C
Yeah,
you
should
hate
me
now
right,
yeah,
I,.
H
Yeah
I
guess
the
one
thing
I
want
to
be
careful
is
I.
Don't
want
to
have
this
be
interpreted
as
paquetto
supporting
these
images.
It's
just
really
for
testing,
and
you
know
the
thing
I
created
was
just
a
simple
stack,
not
doing
very
much.
It
was
just
basically
based
on
the
base,
one
so
I
just
you
know.
If
there's
a
integration
test,
stack
repo
or
something
something,
that's
very
clearly
labeled.
H
So
people
don't
go
and
use
it,
but
it
could
be
as
a
sort
of
an
example
I'm
happy
to
use
whatever,
but
I
just
want
to
make
sure
it's
not
misinterpreted
as
production.
H
J
Yeah
I
was
going
to
just
sort
of
plus
one
last
hope
he
said
I,
don't
certainly
we
haven't
talked
about
this
before
so
I'm
kind
of
like
spitballing,
but
I.
Think,
first
of
all,
as
a
python,
maintainer
I
don't
really
mind
what
stacks
of
integration
tests
I
don't
have
any
like
opinions
about
whether
they're,
like
you
know
in
your
repo
or
a
community
repo
or
something
it
it
could
be
a
relabeled
bionic,
Ubuntu
bionic
stack.
It
doesn't
really
matter
for
the
purposes
of
like
the
build
pack
integration.
J
Then
there's
like
a
separate
conversation
about
like.
Should
we
have
a
community
like
I,
said
Community
Stacks,
which
are
like
slightly
more
supported
than
some
random
persons
like
stack
they
built
up
to
on
top
of
like
six
months
ago?
Maybe
we
should
probably
have
that
conversation,
maybe
with
the
stacks
maintainers
and
other
folks
who
are
interested,
can
have
that
like
asynchronously
I
didn't
as
far
as
like
your
specific
situation
of
like
what
to
do
with
node.
At
the
moment,
it's
probably
a
node
maintenance
question.
J
Hopefully
it
becomes
more
of
a
as
you
want
like
a
solution.
That's
like
constant
or
consistent
for
all
of
the
build
language.
Families
like
some
sort
of
like
clearly
not
fully
supported,
stack
that
you
can
use
on
any
like
build
pack
for
testing.
H
Cool
all
right,
yeah
I
mean
like
the
thing
I
Envision
is
to
just
have
some
stack
that
we
use
to
test
non-pequeto
stack
for
Python
and
use
the
same
one
for
node
like
when
we
get
there.
You
know
we
could
just
have
the
same
one
be
used
everywhere
and
if
it's
ID,
if
it
was,
you
know,
Ubuntu
I'm,
sorry,
if
it
was
a
you
know,
Red
Hat,
based
that
would
be
nice,
because
a
lot
of
you
know
users
can
check
that
off
the
list.
H
But
it's
really
just
to
make
my
life
easier
when
looking
at
how
to
do
this
so
anyways.
This
is
helpful.
So
thank
you
for
hearing
me
out.
I
That's
coming
from
me:
it's
actually
kind
of
rhetorical,
because
I
asked
that
on
on
Sac
already
the
answer
was
like.
Apparently,
there
are
no
plans
yet
so
I
just
wanted
to
bring
it
up
like.
I
Should
we
should
there
be
plans
for
a
1.0
of
note,
like
it
would
change
like
rules
of
what
kind
of
changes
we'll
see
what
kind
of
bumps
like,
for
example,
we
just
realized
that,
with
one
of
the
recent
node
releases,
the
note
bill
pack
starts
to
by
default
call
the
build
script
instead
of
not
calling
anything
and
as
we've
integrated
that
in
a
CI
pipeline,
where
we
have
a
separate
job,
doing
the
build
and
then
actually
just
want
to
package
it.
I
I
So
for
us
that
was
easy
to
fix,
but
it
was
not
that
easy
to
spot,
because
it
was
just
a
minor
bump
of
those,
because
it's
pre
1.0,
this
I
guess
would
change
right,
like
changing
the
behavior
of
environment
variables
would
need
to
be
at
least
somehow
be
introduced.
Maybe
people
need
to
get
warned
and
we
want
to
probably
have
a
major
month
for
this
kind
of
changes
and
that
would
be
easier
to
spot.
So
that's
just
a
thought.
D
I,
don't
have
any
input
specifically
on
node,
because
I'm,
not
a
maintainer,
but
something
I've
been
thinking
about
for
net
core
is
I,
would
love
to
set
up
a
milestone
in
GitHub
for
all
the
things
that
we
want
to
see
done
for
a
1.0
release
and
I
think
that
would
be
really
helpful
to
do
a
node,
slash
or
other
non
1.0,
bold
pack
releases
in
general.
Just
so
people
can
track
that,
and
also
as
a
maintainer,
it's
hard
for
me
to
know
how
much
stuff
we
have
left
on
that
effort.
F
F
Regardless
of
pre
or
post
one,
oh
based
on
the
RFC
for
SIM,
for
that
we've
laid
out
like
that,
would
to
me
be
as
far
as
major
versions.
Right
now
we
have
a
change
in
the
buildback
API
version,
the
build
plan
API
the
remove
all
of
our
stack
or
removal
of
configuration,
options
which
I
don't
think
any
of
I.
Don't
think
any
of
those
represent
the
thing
you're
describing
that
being
said,
I
mean
yeah.
I,
don't
know
it
was
that
the
chief
reason
for
the
1.0
or
the
desire
for
1.0.
I
Is
it
it's
interesting
that
that
you
bring
bring
that
up,
because
I
I
would
consider
this
kind
of
change
of
breaking
change?
So
maybe
I
have
to
reread
the
somewhere
RFC
and
maybe
make
a
proposal
to
get
some
stricter
rules,
because
it's
a
it's
a
breaking
change
kind
of
right
I
mean
you,
you
have
relied
on
no
scripts
being
executed
and
then
by
a
change
that
is
a
minor
bump.
Some
scripts
get
executed.
F
F
F
Noticed
there's
also
like
an
incompatible
change,
but
I
think
there
was
also
I
think
there
that
specific.
In
that
specific
instance,
there
was
a
later
edition
added
to
for
for
folks
to
opt
out
of
that.
F
But
I
suppose
your
points
to
the
stance
so.
I
Yeah
yeah,
you
can
easily
opt
out
that
it
was
easy
to
fix
once
we've
spotted
it
right.
We
can
just
now
it's
kind
of
the
other
way
around.
If
you
don't
like,
you
could,
in
the
past,
specify
that
some
scripts
should
be
run
by
setting
an
environment
variable
now
you
can
set
it
to
an
empty
string
and
restore
the
behavior
of
not
executing
any
script
so
yeah.
That
was
a
measure
to
actually
keep
this
kind
of
well,
not
really
compatible
like
the
it.
There
is
a
escape
hatch
in
there,
so
to
say.
I
Yeah
I
guess
my
wish,
with
with
a
1.0,
is
just
for
a
more
like,
more
stable
and
like
considered
approach
than
to
these
kind
of
bright
breaking
changes
in
terms
of
announcing
them
making
sure
people
are
aware
making
sure
we
as
a
Poquito
project,
are
aware
of
providing
mitigations
for
these
and
like
providing
some
release,
notes
for
what
users
can
do
if,
if
they
would
be
broken
by
a
behavior
of
change,
sure.
F
I
In
more
general
terms,
right,
this
was
one
specific
instance
of
what,
where
I
would
have
said,
that
this
is
a
breaking
change
and
that
it
wasn't
a
major
version,
but
because
of
the
pre-1.0
situation
anyway,.
F
Yeah,
the
I
definitely
hear
you
and
that's
that's
reasonable
for
sure.
A
There
were
two
conversations
or
interactions
that
I
had
last
week
in
the
context
of
cubecon
I
wasn't
attending
person,
but
even
as
a
virtual
attendee,
I
I
try
to
be
everywhere,
and
it
was
interesting
because,
for
example,
in
the
office
hours
and
Josh
was
there
and
deemed
the
one
of
the
first
questions
that
an
attendee
asked
was
what's
the
difference
between
the
spaghetto
thing,
these
paquero
build
packs
and
Cloud
native
buildbacks,
and
and
it's
a
question
that
I've
heard
several
times
and
also
I,
had
an
interaction
with
a
machine
learning
startup
she's
interesting,
because
it's
a
kind
of
workload
that
requires
you
know
speed
at
every
step,
especially
in
on
build
time,
and
they
are
using
Docker
files
and
also
it
requires
a
high
level
security
and
they're
using
Docker
files
and-
and
they
asked
me
yeah,
the
keto
build
pack
seems
interesting,
but
how
mature
they
are.
A
So
I
believe
we
have
a
work
to
do
in
terms
of
how
we
communicate
out
their
little
relationship
between
potato
buildbacks
and
and
the
cloud
native
buildbacks
and
how
potatoes
it's
an
implementation
of
the
Upstream
API
spec
and
yeah
all
the
added
value
that
the
project
provides.
But
there
is
a
huge
effort
we
need
to
in
terms
of
Education
awareness
out
there.
A
You
know
a
lot
of
people
already
heard
about
build
packs,
but
there's
this
confusion
out
there
with
what
are
these
new
kind
of
bucket
of
build
packs
so
yeah
how
mature
they
are.
It's
a
different
conversation.
The
the
topic
here
is
in
in
our
positioning
or
messaging
yeah
just
surfacing.
This
probably
I
will
put
this
into
a
discussion
with
some
ideas
Etc
but
yeah.
A
E
D
D
E
We
can
publish
some
information
like
this.
I
can
offer
obviously
space
on,
like
the
PF
blog
as
well.
Do
some
cross
posting
and
just
put
it
out
there,
there's
probably
some
information
that
we
could
send
out
to.
G
Like
the
world
right,
but
also
there's
a
there's,
a
few
key
Publications
that
the
cff
obviously
has
a
continuous
sort
of
relationship
with,
like
think
of
container
Journal.
Think
of
the
new
stack
think
of
pfir
videos.
There's
always
something
that
we're
looking
for
to
publish
to
these
Avenues
and
we
could
do
it
at
a
regular
frequency
as
well
so
like.
If
you
want
to
publish
something
now
and
then
publish
something
at
the
start
of
next
year.
G
That
kind
of
sort
of
clarifies
this
in
slightly
different
ways
than
we're
more
than
welcome
to
do
so,
and
we
can
make
that
happen.
So
yes,
on
blog
posts,
yes
on
Key
by
lines,
yes,
and
maybe
a
couple
of
videos
on
the
CF
YouTube
channel
or
the
packetto
YouTube
channel
or
both
I
guess,
foreign.
A
I
will
put
a
placeholder
placeholder
PR,
so
we
can
start
working
collaboratively
to
draft
what
will
be
blog
post
and
probably
we
could
extract
by
lines
Etc
from
from
there.
I
I've
just
quickly
skimmed
over
the
GitHub
org
page
and
potato
I
o
and
like
you,
can
find
the
CNB
logo
way
down
on
the
page.
As
a
reference
to
you
can
use
the
pack
CLI
to
build
using
these
build
packs,
but
there's
no
clear
reference
to
pecado
being
in
the
implementation
of
the
cloud
native
build
pack
API,
another
inwarding
nor
as
an
icon.
So
maybe
that's
another
Avenue
to
actually
make
that
very
clear
on
the
main
entrance
points
to
documentation
for
replicator,
build
packs.
E
B
You
I
also
just
took
a
look
at
the
build
packs.io,
because
I'll
also
say
that
this
is
a
question
that
I
answered
several
times
at
the
booth.
B
If
you
just
look
at
the
website
by
itself,
you
get
the
impression
that
buildpacks.io
offers
build
packs
that
are
actually
capable
of
doing
things
which
it
doesn't
so
I
think
that
there's
potentially
also
work.
We
could
do
to
say
Upstream
like
hey.
Can
you
make
it
more
clear
that
you're
a
specification
like
because
I
see
a
similar
kind
of
confusion
talking
to
developers
like
oci
images
versus
Docker
images,
and
sometimes
people
have
never
heard
of
an
oci
image
and
want
to
know
whether
the
Kettlebell
packs
produce
Docker
images?
B
So
I
think
that
you
know
it's
helpful
that
the
oci
specification
like
if
you
Google
oci,
you
immediately
find
out
that
it's
a
specification,
whereas
if
you
Google
Cloud
native,
build
packs,
you
kind
of
also
have
to
dig
to
understand
that.
That's
a
specification
so
I
think
like
with
the
power
of
improving
the
paquetto
site
and
the
build
packs
I,
guess
that
that
relation
could
probably
be
clarified.