►
From YouTube: Working Group: 2022-10-11
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
A
I
will
volunteer
to
take
notes
unless
you
have
any
objections.
Otherwise,
I
I
can't
help
with
that
all
right
see
a
couple
of
news
faces:
kind
of
kind
of
near
faces
to
these
meetings.
I'd
like
to
start
welcoming
dual
Pimentel.
We
like
to
briefly
introduce
yourself
Joel.
B
A
C
Yep
sure
hi
I
haven't
been.
D
C
To
join
this
one,
usually
because
it
was
in
my
evening
time
so
I'm
glad
we
moved
this
but
I,
look
after
the
the
Java
Bell
packs
side
of
the
kettle.
A
A
D
Hey
I
guess
I
just
came
in
just
in
time:
I
updated
this
RC
With
The
Changes
mentioned
was
adjusted,
including
adding
the
Cyclone
DX
for
Noble
node
module
bomb.
So
this
this
is
ready
to
get
mentioned
in.
E
E
So
I
know
that
Forest
opened
a
draft
PR
to
kind
of
like
investigate.
This
I
was
just
wondering
if
there's
any
like
plan
to
move
this
forward
or
if
it's
still
on
hold.
F
So
this
should
be
being
picked
up
soon.
We
have
been
experimenting
with
the
best
ways
of
implementing
the
dependency
RFC
and
we've
just
gone
through
a
couple
of
iterations.
This
is
one
of
the
ones
where
some
experimentation
has
happened,
but
I
think
that
that
branch
is
going
to
be
solidified
as
soon
as
Ryan
gets
back.
F
A
A
No
cool
all
right
so
I
guess
time
to
move
to
the
next
section
in
what
I'd
like
to
think
of
a
regular
thing
that
we
could
start
doing
this
meeting
like
once
in
a
month
or
something
like
that.
We're
opening
the
floor
today
for
one
of
our
adopters
one
of
the
potato
users
to
share
with
us
their
use
case,
how
they're
leveraging
potato
Bill
packs,
especially
what
we
can
do
to
better
support
their
use
cases
with
that
I'd
like
to
welcome
again
to
help
him
until
from
Ron
Dolly.
Thank
you
for
joining.
A
B
C
B
B
With
over
the
past
few
years,
we've
worked
with
our
customers
to
help
the
modernize
and
migrate
over
206
applications
to
kubernetes
both
playing
kubernetes
and
also
using
whiteheads
openshift
platform
and
the
plan
for
today's.
A
very
very
brief
presentation
average
spoke
about
randomly.
Let's
see
how
we
use
bid,
packs
practically
packet
boost
packs
in
our
products
that
is
app
character
and
I'll
feedback
from
it
and.
D
B
B
B
B
So,
basically,
when
you
choose
that,
so
it
says
here:
I
chosenport.net,
core
I've
chosen
paquero,
so
many
developers
are
going
to
specify
the
application
when
they
choose.net
core.
It's
going
to
use
paquero
with
packs,
as
it
was
set
up
by
the
administrators
and
of
course
we
need
to
set
up
the
environment,
the
cluster,
the
git
repository
the
brains
and
so
on
and
so
forth.
B
But
for
this
example,
let's
view
the
simple.net
app
and
we
can
also
customize
the
good
process
using
paquero
Flags
in
this
example,
I'm
setting
up
a
specific
version
of
the.net
framework
using
this
packet
of
value
whenever
the
user,
the
developer,
wants
to
actually
build
their
image,
be
it
from
the
user
interface
or
be
it
from
a
git
web
hook.
It's
going
to
trigger
our
detecton
Pipeline
and
one
of
the
steps
there
is
going
to
use
the
cloud
native
build
pack
life
cycle.
So
in
this
example,
we
can
see
here
in
the
logs
of
the
task.
B
It
is
showing
okay
different
steps,
the
targeting
restoring
included
and
so
on,
and
what
is
our
feedback
from
usage?
So
the
first
thing
I
want
to
say
is
that
it's
just
very
convenient.
I,
remember
I
was
talking
to
a
friend
of
mine
a
few
weeks
ago
and
he
asks
for
some
help
with
a
Docker
file
and
it
was
like,
like
sure,
yeah
I
can
help,
but
did
you
try
good
packs
and
he
tried
and
he
switched
to
it
and
it's
just
fun
to
get
go.
It's
worked,
so
it
was
perfect
perfect
for
us
and.
A
B
Transparents
in
multiple
ways
in
particular,
in
the
way
it
shows
the
tail
logs
of
the
boot
process,
with
all
the
dependencies
that
are
being
loaded
and
builds
the
different,
build
packs
and
with
back
versions
that
are
being
used
since
that's
very
important
for
us
another
thing
we
like
it's
how
we
can
use
the
packet
of
Flex
for
customized,
pretty
remote
I
mean
almost
everything,
so
it's
very
handy
so
I
don't
have
to
change
the
Ripple
right.
Just
go
set
up
a
flag
and
it's
there
for
us
and.
C
B
I
just
wanted
to
show
a
token
of
appreciation
for
the
ongoing
work,
my
uniformisation
to
make
the
difference
great
effects
more
uniform.
That's
definitely
very
helpful.
It's
going
to
make
it
easier
to
use
different,
build
packs
and,
of
course,
we
still
have
a
lot
to
learn
about
good
packs,
and
we
are.
We
are
still
in
the
beginning
of
the
journey
issues
we
are
having
right
now,
which
is
not
up
necessarily
a
packet
of
respect
issue,
because
we
still
have
a
lot
to
learn
right,
so
probably
something
that
we
still
don't
know
about.
B
So
the
first
thing
is
about
Verizon,
because
recently
we
experiences
some
issues
when
you
said
the
last
versions
of
the
particular
build
pack
I
think
it
was
the
dot
in
that
one
and
because
of
course,
we
always
wanted
to
use
the
most
recent
put
back
available,
but
it
dropped
one
of
the.net
framework
versions
that
we
had
specified
in
a
flag,
so
we
would
simply
stopped
working.
So
we
are
trying
to
understand
how
we
can
define
a
specific
version
and
also
all
right.
It's
right
now.
B
We
think
it's
a
little
bit
difficult
to
look
and
see
what
are
the
different
and
versions
of
a
two
of
the
languages
that
are
being
supported
in
a
specific
version
of
the
good
text.
So
that's
our
feedback
related
to
Verizon.
Also,
it
would
be
great
for
us
if
we
had
the
ability
to.
We
have
more
options
to
choose
for
these
images.
B
A
B
Just
a
little
bit
nitpick
because,
as
I
was
said
before,
we
can
use
reflex
to
customize
almost
everything,
but
not
the
process.
Styles.
For
that
we
have
to
add
a
file.
As
far
as
I
know,
we
have
to
add
a
file
to
Adobe
per
story
and
you
have
access.
We
just
think
it
would
have
been
nice
and
more
uniform
if
you
could
also
set
that
up
through
the
packet
of
flex
and
that's
it
as
a
promises.
B
Presentation,
I
didn't
want
to
take
too
much
of
your
time,
but
before
opening
for
questions,
I
just
wanted
to
give
a
brief
shout
out
for
our
team.
That
is
right
now
today
and
tomorrow
presents
yet
God
exploit
Asia.
So
if
you
happen
to
go
there,
or
maybe
someone
of
your
friends
or
colleagues
is
there,
you
could
please
invite
them
to
visit
us
at
stand.
Number
j86.
B
If
you
want
more,
if
you
want
to
get
in
touch
to
learn
more
about
our
experiences,
our
services
and
our
products,
it
normally
charge
to
receive
our
CTO
in
this
email.
D
B
E
Great
presentation
so
I
was
going
to
ask:
have
you?
Are
you
only
using.net
or
using
like
I
know,
you
mentioned
other
build
packs,
but
are
you
primarily
using.net?
Is
that
one
of
the
because
you
mentioned
it
a
couple
of
times.
B
B
E
So
the
reason
I
was
saying
it
is
like
the
python
build
pack.
I
recently
made
some
changes
with
a
lot
of
help.
So
if
you
saw
that
that's
has
red
hat
support,
so
I
don't
know
if
there's
something
similar
for
net,
but
maybe
there's
some
kind
of
project
to
do
something
similar.
B
Yeah
and
by
the
way,
thank
you
very
much
for
your
work.
There
I've
been
following
the
meetings
who
do
you
record
this,
but
yeah
so
you'll
be
great
if
you
can
have
a
customized
building
from
Source
right
instead
of
having
the
paintings
in
the
air
that
was
from
source
so
that
you
make
it
easier
to
support
different
images.
B
So
it
would
be
great
if
you
have
that
for
your
other
build
packs
as
well
and
and
in
this
next
two
weeks,
I'm-
probably
going
to
investigate
that,
if
you
can,
as
I
said,
use
red
hats
for
python,
the
python
with
the
pack
as
well
I
haven't
tried
so
I'm
glad
you'll
mentioned
it
because
now
I
know,
I
can
look
at
it.
But
of
course,
for
the
other
images
for
the
other
application
types
would
be
great
to
have
that
as
well.
E
Cool
and
then
another
thing
is
you
mentioned,
you
have
to
use
proc
files
and
I
agree.
I
ran
into
this,
but
have
you
ever
used
inline
build
packs?
Have
you
ever
tried
those.
E
Yeah,
you
can
specify
it
in
the
toml
file,
the
project,
comma
file,
but
long
story
short.
You
can
actually
create
the
process
type
by
appending
to
a
launch.com,
a
file.
I
think
it
is
there's
actually
an
example
on
the
buildpacks.io
website.
So
that's
another
way
to
create
your
process.
Types
like
you
can
basically
embed
another
build
pack
at
the
end
of
your
whole
workflow.
If
you
know
you
want
to
have
a
specific
process
type
and
you
can
have
multiple.
So
that's
another
option.
A
G
I
had
one
around
the
the
process,
types
configuration
thing,
I'm
curious.
If
there's
any
way
that
you
could
provide
like
an
example,
proc
file
that
you
know
had
to
be
put
in
place
just
so,
we
have
a
better
sense
of
kind
of
the
level
of
complexity
of
things
that
your
users
are
trying
to
express,
to
figure
out
a
good
alternative
for
the
configuration.
B
Okay.
Okay,
thank
you.
Thank
you
for
your
question
and
suggestion
yeah,
it's
not
practically
complex,
but
you
just
have
to
have
to
have
the
file
there
and
we
think
that
would
not
have
to
change
the
repo.
You
can
do
everything
from
Flat.
It
would
be
easier
for
the
customers,
but
I
would
I
will
can
I,
send
it
to
you
and
please,
like
maybe.
G
You
could
honestly
my
suggestion
on
that
specific
front
would
be
if
you
could
file
an
issue
on
either
on
the
proc
file,
build
pack
or
on
one
of
the
language
family
build
packs
where
it
comes
up.
The
most
I
know
in
Python.
That's
probably
the
one
that
guesses,
the
least
about
how
to
start
your
app.
So
maybe
that
one
is
relevant
if
you
file
an
issue
and
sort
of
include
an
example
proc
file
on
the
issue,
that
would
probably
be
the
best
way,
so
everyone
can
see
it.
B
Awesome
awesome.
Thank
you.
C
A
Yeah
sorry
still
learning
how
to
use
this
stuff.
Any
other
question
for
Joel.
A
No
well
I
I
have
one
I
saw
in
the
in
your
in
the
rendoli
website
and
nice
comparison
table.
Let
me
put
in
the
chat
I'm
able
to
find
the
chat
there.
You
go.
You
know.
By
reading
the
table
there,
I
will
say
that
one
of
the
reasons
to
prefer
paquero
build
packs
is
that
it's
the
only
option
there
with
a.net
core
Bill
pack
or
implementation
available
compared
to
Roku
or
Source
image.
B
C
B
D
B
Different,
we
like
to
have
different
options
right
to
provide
different
options
to
our
customer,
and
so,
for
instance,
we
know
it
said
that
sometimes
the
email
is
generated
by
patero
is
a
smaller
than
the
image
generated
by
heroico,
Bridge
packs,
which
is
one
thing
we
appreciate
there
on
paquero
and
also
the
customization,
because
for
Heroku
we
also
use
sometimes,
for
instance,
for
Java.
We
have
to
have
the
application.vmo
file
that
we
don't
need
much
for
paquero,
because
you
can
have
that
setup
on
the
flags.
A
E
Thank
you,
I.
Have
one
more
question.
Sorry,
do
you
have
any
like
metrics
on
you
know
when
a
user
goes
through
this
app
director
thing
and
they
choose
paquetto
versus
Docker
file?
Do
you
have
any
metrics
on
like
the
choices
that
are
made.
B
E
B
Yeah,
if
they
have
it
and
it's
working,
why
change
right
so,
but
what
we
promote
is
that
the
demonstrators
of
the
company
can
decide
beforehand,
so
they
can
when
they
can
simply
disable
Docker
file
usage
and,
in
this
case,
they're
going
to
need
to
investigate,
put
their
research
and
choose
paquero
or
hero
or
Red
Hats.
That's
why
cool.
A
C
B
A
F
Me
sorry,
that's
me:
I
got
lost
in
my
windows
yeah,
so
this
comes
from
a
discussion
that
I
was
having
with
Ryan
last
week.
It's
a
little
unfortunate
that
he's
not
here
today.
So
maybe
we
can
talk
about
this
again
in
the
future,
but
essentially,
over
the
past
couple
of
months,
we've
made
a
couple
of
changes
that
have
required
us
to
modify
the
sort
of
build
pack
order
in
either
subtractive
or
ways
that,
like
change,
the
underlying
API,
so
great
example.
F
This
would
be
the
removal
of
support
for
Depp
in
the
go,
build
packs
and
an
example
that
we're
currently
working
on
is
the
move
in.net
core
from
having
two
separate
build
packs
for
asp.net
and
runtime
and
converging
on
one
build
pack
for
an
asp.net
core
runtime
dependency.
F
What
this
means
is
that
we
have
build
packs
that
we
essentially
need
to
say
these
are
EOS
or
like
end
of
support.
We
are
no
longer
planning
on
supporting
these
in
the
same
way,
and
in
fact
we
are
changing
the
underlying
API
for
the
build
pack
itself.
F
The
internal
API
I
guess
I
should
I
should
make
that
clear
for
the
fill
pack
itself,
where
you
know
like
in
the
go
case,
all
apps
that
were
supported
except
for
depth.
Apps
will
continue
to
be
supported
in
identical
ways
and
for
the
network.
It
is
more
of
a
case
of
no
outward
functionality.
Change
should
occur,
so
you
should
be
continue
to
be
able
to
build
the
same
apps,
but
the
layer
structure
and
the
build
structure
is
changing
and
I.
F
Sanctioned
way
to
do
this,
so
that
you
know
like
like
just
like
a
process
to
actually
deprecate
these
build
packs
or
make
these
deprecating
moves,
and
we've
kind
of
done.
It
ad
hoc
for
a
couple,
Bill
packs,
but
is
becoming
ever
more
apparent
to
me
that
we
probably
should
have.
F
Like
a
set
of
protocols
in
terms
of
what
needs
to
be
done
for
a
build
pack
to
be
okay,
deprecated
for
lack
of
a
better
word,
so
I
wanted
to
like
raise
this
in
a
working
group
and
potentially
open
up
a
discussion
post
around
this
and
I
mean
I
have
a
couple
of
ideas
of
things
that
I
feel
should
be
the
bare
minimum
which
sort
of
includes
you
know
like
trying
to
identify
in
as
many
places
as
possible
that
this
change
is
happening
at
the
you
know,
it
is
going
into
end
of
support,
but
I
would
be
curious
if
anyone
here
had
anything
that
they
would
like
to
bring
up
for
the
original
or
sort
of
like
for
the
initial
post
of
this,
and
if
not,
this
is
sort
of
more
of
an
announcement
that
I'm
trying
to
start
a
larger
discussion.
F
I
will
try
and
Lead
everyone
to
that
larger
discussion
when
I
have
a
better
forum
for
it,
but
yeah
it's
more
of
a
I'd
love
people
to
start
thinking
about
this
issue
and
be
ready
to
talk
about
it.
D
H
I,
don't
have
any
intelligent
additions
to
propose
at
the
moment,
but
definitely
think
that
this
is
a
good
thing
to
talk
about.
I
had
the
same
problem
when
I
was
introducing
the
dependency
management
changes,
and
it
was
just
kind
of
difficult
to
know
exactly
how
to
announce
that
in
a
a
good
way
for
everybody
in
the
project
to
understand
and
for
it
to
be
organized
so
definitely
interested
to
see
the
discussion
there.
G
One
I
guess,
like
related
question,
I
find
myself
asking
is
sort
of
which
are
the
most
common
ways
that
users
consume
the
build
packs
because
there's
several
sort
of
you
know,
layers
of
integration
or
layers
of
abstraction
implementation,
build
packs,
composite,
build
packs
like
the.net
language,
family,
build
pack
and
then
Builders
right
and,
as
Forrest
said
before,
we
think
about
some
of
those
apis
as
sort
of
more
internal
like
apis
between
component
build
packs.
G
But
it's
hard
to
tell
which
ones
are
the
internal
apis
and
which
ones
are
users
care
about
changing
without
a
clear
sense
of
how
people
are
consuming
them.
So
in
particular,
joao
I
was
wondering:
are
you
all
consuming
the
paquetto
Builder
images?
Are
you
consuming
the
language
family
build
packs,
how's
that
working.
B
G
C
A
Thank
you.
So,
as
far
as
would
you
create
a
discussion.
F
A
C
G
I,
don't
know
if
we've
in
terms
of
the
core
team,
if
we've
said
out
loud,
that
we're
gonna
have
a
presence
at
kubecon,
that's
kind
of
been
implicit
I,
don't
know
if
we've
said
that
in
one
of
these
meetings,
Sophie
and
I
are
going
to
be
talking
at
kubecon,
Sophie
and
Ryan
are
going
to
be
talking
at
CF
day.
Both
of
those
I
think
you
can
like
attend
them.
G
Virtually
Tim's
going
to
be
doing
a
demo,
also
a
cloud
boundary
day,
and
then
we're
also
going
to
be
Staffing
physical
and
virtual
booths.
So
if
you
want
to
learn
more
about
the
ghetto,
there
will.
D
A
Thank
you,
Frankie
yeah,
we'll
have
links
for
everything
everything
yeah
follow-up
message
from
this
meeting
and
it's
also
there
in
the
newsletter.
Thank
you
for
the
reminder.