►
From YouTube: Working Group: 2021-01-19
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
B
A
C
Sure
it's
on
the
agenda
for
later
on.
So
I'm
happy
to
like
just
do
a
quick
thing
later,
yeah.
A
All
right
we'll
talk
about
that
more
later,
dependency,
library,
rfc.
B
Yeah,
so
we
got
a
lot
of
feedback
on
this
that
maybe
it
would
make
sense
as
a
standalone
thing,
we're
thinking
about
maybe
closing
out
this
rfc
and
just
doing
what
was
suggested
and
adding
it
side
by
side
with
the
server,
but
maybe
renaming
that
renaming
that
repo
to
something
else
potentially
and
also
like
using
that,
basically
using
that
having
one
repo
for
like
the
server
and
the
library-
and
you
know
eventually
we're
going
to
add
actual
dependency
building
to
like
the
actions
in
that,
like
the
github
workflows
in
that
repo.
B
A
I
don't
know
if
you're
at
the
meeting
last
week,
but
I
think
there
was
also
some
confusion,
sort
of
about
the
intended
audience
and
the
workflows
that
would
be
enabled
by
this
edition.
D
A
A
All
right
go
http
function,
build
pack,
I
don't
know
if
there's
any
updates
here.
I
know
matt's
not
here.
A
Okay,
moving
on
to
language
specific
rfcs,
let
me
drag
a
tab
over
here.
A
Did
that
work
you
guys
can
see
the
language
specific
ones
great
seems
like
the
only
one
is
restructure
rfc
for
php
same.
I
want
to
talk
about
this
rfc.
A
Approvals,
okay,
so
everyone
take
a
look
at
this
and
I
will
stop
sharing
because
I
think
we're
done
with
the
review
part
of
this.
So
the
next
item
is
upstream
rfcs
to
take
a
look
at
the
person
who
added
this
like
to
talk
about
it.
F
Oh
yeah,
that's
that's
me.
No!
I
just
figured
that
it
would
be
helpful.
There
is
an
upstream
rfc
that
is
getting
close
to,
I
guess
being
merged.
It
has
approval
and
I
believe
that
it's
an
fcp.
I
could
be
wrong
about
that.
Actually
it
is
an
fcp
and
it's
not
like.
I
think
that
it's
currently
marked
as
a
distribution
spec,
because
it
does
affect
that,
but
it
will
affect
build
packs
on
a
pretty
significant
level,
not
right
away.
F
I
think
it'll
be
a
little
while
before
this
gets
rolled
in
to
the
life
cycle
and
whatnot,
but
you
know
we're
all
specifically
built
pack
container
maintainers
here
so
or
built
pack
maintainer
adjacent.
So
taking
a
look
at
that
might
behoove
you.
F
In
particular,
it
might
be
interesting
for
us
to
take
a
look
at
it
with
the
chord
eps
team
here,
because
it
was,
it
is
sort
of
has
a
a
loadout
of
what
a
more
standardized
dependency
layout
would
look
like
inside
of
buildpack
toml
and
so
making
sure
that
we
have
all
of
that
information
present
for
us
on
the
depth.
Server
would
be
really.
A
F
Yeah,
this
is
also
me
so
as
per
an
rfc,
it
would
have
been
a
couple
of
months
ago,
bill
pam
build
pack
was
adopted
into
picado
community.
I
am
currently
I
am
the
maintainer
of
that
bill
pack,
which
is
fine
for
now.
G
I
think
if
it's
an
existing
team
that
adopts
it,
I
think
it's
just
really
up
to
that
team
to
designate
that
they'll
adopt
it
and
we
can
handle
transferring
like
ownership
control
or
any
other
kind
of
permission,
settings
that
need
to
take
place
to
make
that
happen.
If
it's
about
establishing
a
new
team
around
that,
then
I
think
that
would
require
an
rrc.
F
F
Cool
you
guys
can
have
it.
I
don't
want
it
anymore.
F
C
C
So
I'm
just
going
to
read
what
this
says:
picado
build
packs,
sometimes
use
language
ecosystem
environment
variables
to
configure,
build
and
launch
time
behavior.
An
example
of
this
would
be
the
node
and
environment
variable
and
then
node
build
packs,
which
does
things
like
determine
which
dependencies
get
installed.
C
If
that
was
kind
of
confusing
and
abstract,
there
are
a
few
different
examples
in
the
body
of
the
rfc
that
outline
what
exactly
that
would
mean
in
sort
of
like
different
cases,
and
I
invite
you
to
take
a
look
at
the
rfc
and
evaluate
whether
you
think
this
is
a
good
idea
to
actually
implement
the
way
that
I've
written
it.
Given
the
examples,
I
appreciate
your
comments
already
emily.
I
think
the
goal
here
is
to
try
and
align
all
the
build
packs
on
a
similar
approach.
C
A
Yeah,
it
concerns
me
a
bit
from
the
java
perspective,
because
we
have
some
examples
like
java
tool
options,
I
think
we
just
like
I
the
downsides
of
that
making
that
change
for
the
job
of
build
packs
would
outweigh
the
upsides
of
consistency,
and
it's
probably
not
something
we'd
be
able
to
do
so.
In
my
mind,
I
feel
like
the
question
becomes:
do
we
want
this
to
be
the
like
default
way
of
doing
things?
A
A
A
Okay
seems
like
the
action
item.
There
is
for
everyone
else
to
take
a
read
through
and
then
next
up
on,
our
agenda
is
2021
roadmap.
Synthesis.
G
Yeah
I
took
some
time
in
the
last
week
to
read
through
all
the
comments
and
comments
on
comments
on
the
discussion
thread
for
the
2021
roadmap
and
I've
kind
of
synthesized.
What
I
saw
out
into
these
three
kind
of
top
line
themes
generally
being
a
maturation
of
the
existing
build
pack
feature
set,
there's
a
bunch
of
stuff
that
falls
under
that
category:
expansion
of
the
buildpack
ecosystem.
G
That
one
seems
pretty
clear.
There's
you
know
more
than
probably
about
two
dozen
different
new
build
packs,
so
you
could
arguably
start
building
in
addition
to
like
a
bunch
of
new
kind
of
integrations
and
features,
and
then
the
last
one
that
is
still
this
kind
of
nastened
category,
but
like
ultimately,
pretty
interesting
is
the
non-production
use
cases
area.
G
That's
kind
of
what
I
saw
if
folks
want
to
give
that
a
look
point
out.
Anything
that
you
think
seems
wrong
or
that
I
may
have
missed,
feel
free
to
just
add
comments
and
we
can
kind
of
move
from
there.
I
hope
that
by
this
point
next
week
we
will
be
able
to
be
in
a
position
to
write
up
a
blog
post
that
we
can
share
much
more.
G
So,
like
generally,
the
roadmap
is
not
going
to
be
a
prioritized
list
of
we're
going
to
do
a
and
then
we're
going
to
do
b
and
then
we're
going
to
do
c.
So
I
don't
really
feel
a
need
to
filter
it.
G
We're
basically
going
to
say,
like
these
are
the
themes
for
things
that
are
going
to
be
important
to
us
things
that
we're
going
to
be
focused
on
and,
like
maybe
can
kind
of
organize
that
list
to
be
prioritized.
Sorry,
I
have
a
very
excited
dog
here.
We
can
kind
of
prioritize
the
things
that
we
think
are
gonna
be
much
more
likely
to
be
worked
on.
We
can
kind
of
move
towards
the
top
of
those
lists
and
kind
of
prioritize
other
stuff.
G
That's
like
been
that
long
tale
of
like
interesting,
but
we'll
probably
won't
get
to
it
kind
of
stuff.
Towards
the
end,
I
think
the
point
of
enumerating
everything
is
really
to
kind
of
give
people
a
sense
of
what
that
particular
category
means,
but
yeah.
I
don't
think
we're
going
to
have
like
a
highly
prioritized
list
of
things
that
we're
going
to
work
on.
A
A
I
I
think
it
would
be
cool
if
we
also
have
like
a
github
style
roadmap
like
what
the
cmd
project
already
does.
That
might
be
a
good
way
just
to
like
link
a
lot
of
stuff.
You
know
more
granular
things
like
build
pack
requests
and
stuff
like
that.
Maybe
we
could
tie
it
into
issues
as
well,
but
this
is
pretty
awesome.
Thanks
friend,.
A
Okay-
next
up,
I
put
this
on
here,
I
was
wondering
I
wasn't
seeing
all
of
all
the
java
build
packs
still
explicitly
declare
support
for
cf
linux
fs3
stack
both
at
the
bill
pack
level
and
we're
talking
about
what
stacks
a
given
dependency
runs
on,
and
I
was
thinking
about
just
cleaning
that
up,
because
I
don't
think
we're
actively
using
the
cf
linux.
Fs3
stack
with
the
cognitive
paketto
build
packs
anymore.
G
G
G
H
Before
we
do
this
as
well,
would
it
be
possible
to
spend
out
some
kind
of
deprecation
notice,
or
I
guess
to
enable
to
do
that-
we
have
to
know
who's
using
it
right
first,
but
a
good
idea
if
it's.
A
Yeah,
I
think
that
makes
sense.
We
have
a
paquetto
mailing
list.
I
A
quick
question
on
this
note:
do
we
still
publish
the
cf
linux,
fs3
builder,
image,
somewhere
marty
or
mark?
I
I
want
to
say
we
talked
about
something
last
year,
just
publishing
the
full
builder
and
place
of
it.
I
forget
if
we
actually
did
that
or
not.
B
D
C
B
A
All
its
pr's
are
being
rejected.
I
know
there
was
a
conversation
in
one
of
the
slacks,
but
I
was
wondering
if
someone
knew
who
I
could
follow
up
with
or
what
the
next
step
was
to
try
to
fix
the
cla
issue.
C
Yeah,
so
actually
I
just
before
this
meeting,
I
messaged
in
the
general
channel
of
the
paquetto
slack
tagging
chris
clark
who's
the
person
I
reached
out
to
directly
to
try
and
get
this
sorted
out,
so
he
I
asked
him
to
update
on
that
more
visible
thread
when
he
has
an
update.
As
far
as
I
understand
the
next
step
that
he's
planning
on
taking
is
getting
the
picato
build
packs
or
get
into
vmware's
list
of
approved
orgs,
which
should
sort
of
make
this
problem
go
away.
C
E
A
It
depends
what
approved
orgs
mean,
I
guess.
If
vmware
says
we
can
take
contributions
from
here,
it
doesn't
necessarily
mean
that
they
own
it
and,
like
maybe
that's
okay,.
C
Fair,
in
which
case,
I
guess
an
answer
to
your
question,
emily
asking
chris
would
be
what
I
would
do.
A
Okay,
that
makes
sense
yeah.
This
confused
me
for
similar
reasons
right.
This
is
the
cloud
foundry
cla.
This
isn't
a
yeah
vmrcla
like
does
vm,
I'm
not
quite
sure
why
vmware
approved
orgs
would
need
to
be
involved.
It's
like
can
cloud
foundry
org,
except
the
keto
org,
as
a
contributor
I
feel
like,
is
what
I
would
have
imagined
happening,
but
also
as
a
very
practical
person,
I'm
happy
to
do
just
whatever
we
need
to
to
make
things
merge.
A
That's
it
for
our
agenda
today.
Does
anybody
have
any
late
breaking
things
they
want
to
talk
about.
C
I
had
a
question.
I
noticed
that
under
a
week
ago
the
stack
packs
rfc
finally
landed
in
cnb,
and
I
was
curious
if
that's
going
to
be
implemented
anytime
soon
or
like.
What's
the
what's
the
vibe
there,
should
we
care
yet.
A
It's
going
to
take
a
while
because
it's
impressively
complicated
piece
of
work.
It's
going
to
need
to
roll
out
in
stages.
A
A
In
the
next
month,
I
would
say,
because
the
release
of
life
cycle
that
would
support
stackpacks
is
going
to
be
implementing
the
07
apis
and
there's
going
to
be
a
06
release
first
and
the
06
release
probably
isn't
for
at
least
a
month,
so
we're
looking
at
a
medium
term
time
horizon
not
a
right
now.