►
From YouTube: Working Group: 2020-09-29
Description
* Paketo Java Docs
* Procfile tiny support
* Paketo Utility Buildpack
A
B
B
B
B
D
Yeah,
I
was
actually
in
the
process
of
pinging
emily.
In
the
background
to
tell
her
that
I
I
was
told
that
I
have
to
pick
maintainers,
so
I
I
was
able
to
talk
to
frankie
ahead
of
time.
We
wanted
to
add
frankie
as
a
maintainer,
but
I
also
put
emily's
name
down
emily.
If
you
object,
we
could
pick
someone
else
from
the
java
team.
C
B
Think
there
was
an
open
question
about
whether
for
when
we
were
forming
a
new
sub
team,
should
we
put
the
maintainers
in
the
rfc,
so
they
go
through
the
approval
process
with
the
rfc,
or
should
we
do
an
rfc,
creating
a
team
and
then
do
a
vote
afterwards?
I
think
that's
where
that
pick.
The
maintainers
thing
came
from
is
like
probably
makes
sense
to
just
do
one
thing
when
we
establish
the
sub
team,
but
I
don't
know
if
anybody
has
an
opinion.
B
C
B
B
Look
at
the
thing,
but
if
we're
making
a
new
sub
team
and
the
steering
committee
votes
on
rfc's
at
the
top
level
repo,
it
seems
silly
to
vote
twice
over,
creating
the
sub
team
and
the
maintainers
and
something
can't
really
exist
without
maintainers
anyways.
So
I
figured
might
as
well
just
go
down
in
one
thing.
D
B
B
E
Yeah
this
is
in
process.
It's
like
very
bare
bones
right
now,
as
I
work
on
it
it'll
all
like
keep
adding
more
to
this
draft.
So
if
you're
curious
about
how
this
is
coming
together,
you
feel
free
to
take
a
look
at
it,
but
until
it's
in
a
sort
of
more
existent
date,
I'll
refrain
from
actually
going
through
it
here.
B
E
B
A
Yeah,
I
was
just
looking
at
that
emily
and,
if
you
all
haven't
seen
emily
put
a
pr
with
the
javadocs
java
native
image,
I
think
it's
really
cool
to
use
sections
around
like
configuring,
the
build
packs
and
stuff
like
that.
I
had
a
couple
comments
on
there,
but
just
wondering
if,
like
we're
finding
merge,
just
once
that's
approved,
or
do
you
want
like
ben
to
take
a
look
at
it
or
not,
because
we're
also
trying
to
just
make
one
final
pass-through
of
the
content
on
our
end
and
just
get
the
stuff
merged.
C
C
If
we
find
small
inaccuracies,
there
were
a
couple
things
that
I
had
threatened
to
put
in
the
common
docs.
I
was
talking
to
forrest,
including
some
concepts
like
process
types
and
stuff
like
that
that
didn't
end
up
in
there
for
two
reasons:
number
one,
because
it
was
taking
me
way
too
long
to
finish
and
number
two,
because
I
think
some
of
those
things
could
be
in
the
cmb
docs
and
we
can
link
out.
So
I
just
wanted
to
give
everyone
a
heads
up
on
that
as
well.
B
Good
all
right-
and
that
is
the
end
of
our
agenda
this
week
anything
else.
Anybody
want
to
chat
about
any
of
the
rfcs
in
the
language,
individual
language
repos
that
are
worth
bringing
up
with
the
larger
group
for
feedback.
Anything
like
that.
Should
we
be
listing
all
the
rfcs
and
all
the
languages
during
this
meeting
too,
probably
not,
but
maybe
just
by
request.
C
They
can
only
be
used
to
set
batch
processes.
So
the
fact
that
that
build
pack
says
it
can
run
on
tiny
in
some
ways
is
a
lie
which
brought
up
an
interesting
question
like
what
do
we
do
about
sort
of
components
in
larger,
build
packs
that
have
a
run
on
a
smaller
set
of
stacks
than
the
rest
of
the
group
in
this
case
is
optional,
but
I
think
we
can't
if
we
wanted
to
update
that
to
truly
reflect
the
set
of
stacks.
It
could
run
on.
D
Can
I
ask
maybe
a
naive
question,
which
is
what
about
the
proc
file
build
pack
makes
it
so
that
it
cannot
run
on
a
stack
that
doesn't
have
bash
like
what
about
it
is
like
enforcing
its
like
process
needing
to
run
on
bash.
Like?
Could
you
not
just
like
detect
that
you're
on
tiny,
and
in
that
case,
that
said
direct
true,
I
think
the.
C
Format
of
a
proc
file
right
now
doesn't
provide
a
way
to
tokenize
things
and
if
you're
setting
a
direct
process,
you
want
to
be
very
clear
about
like
what
the
exact
arcs
and
like
the
anarchs
you're
exact,
are
and
there's
no
way
to
express
that
in
the
format.
So
right
now,
in
some
ways,
proc
files
are
pretty
limited.
Now
that
we
have
args
for
bath
bash
processes
as
well,
you
can
only
only
use
it
in
the
mode
to
pay
where
you
have
a
single
script.
That
can't
have
arguments.
C
C
B
C
I
feel
like
that's,
you
know,
there's
a
couple
different
workarounds
here,
I'm
not
bringing
this
to
up
because
there's
no
workaround.
It
feels
like
an
interesting
problem,
though,
where
you
want
to
express
like
I
want
to
say
I
use
pochetto's
java
opinions
and
I
don't
want
to
have
to
build
like
the
name
of
the
stack
into
the
name
of
the
build
pack,
so
that
people
use
different
ones
in
different
situations.
B
I
could
see
two
two
different
upstream
rfcs
in
cnv
to
get
around
this
one
is
like
optional,
build
packs
if
the
stack
id
doesn't
match
just
are
removed,
but
the
build
package
is
still
allowed,
but
they
have
to
be
optional
or
because
optional
is
just
a
shorthand
for
listing
multiple
groups
right.
If
there's
any
group
combination
that's
possible
for
a
stack,
then
we
allow
the
stack
and
remove
all
the
other
group
combinations
that
aren't.
B
B
C
That's
basically
just
a
grab
bag
of
paquetto
common
configuration,
but
then
would
make
it
easy
for
non-java
sub
teams.
If
you
wanted
to
consume
these,
you
could
just
put
that
meta
build
pack
in
your
group
and
then,
if
we
wanted
to,
you,
know,
add
something
else
that
is
very
generic.
You
could
just
get
it
for
free
as
you
consume,
updates.
D
C
D
B
B
C
It'd
be
slightly
more
work
and
we'd
have
to
release
it
before
like
right
now,
we
at
least
to
release
a
java
build
pack.
We
release
each
component
and
then
release
the
meta
build
pack.
This
we
would
release
some
components
and
release
a
metabolt
pack
then
release
another
meta,
build
pack.
So
for
us,
that's
an
extra
step,
but
might
be
worth
it
for
downstream.
F
C
B
Maybe
someday
without
it
sometimes
we
support
the
whole
world
yeah.
Then
it's
just
one
apn
built
back.
You
can
put
on
there
if
they
were
to.
If
we
got
pretty
close
to
that
and
the
ones
that
didn't
work
didn't
and
just
opted
out
right,
then
that
could
be
a
later
architectural
optimization,
especially
if
the
apms
are
maintained
like
if
the
integration
point
is
closer
to
the
java
side
right.
You
can
just
provide
a
here.
This
works
ship
it.
The
tanzania
version
thing.
B
B
I'm
worried
that
if
we
don't
do
that
kind
of
optimization
that
later,
when
we
want
to
do
it,
it's
going
to
be
a
big
change
for
people,
but
I'm
I'm
pretty
tempted
to
just
say
like
it
doesn't
seem
like.
We
have
a
big
use
case
for
it
now.
So
just
proceed
without
it,
but
I
wanted
to
bring
it
up
to
this
group
just
to
see.
B
If
you
know
people
felt
like
that
change
would
be
a
large
change
later
and
to
kind
of
go
into
more
detail,
because
I
don't
think
that's
a
very
good
explanation.
It's
like
we
could
have
a
dependency
layer
like
the
ups.
You
know
ruby
coming
that
way.
You
know
build
from
the
on
the
you
know:
depth
sub
team
could
be
literally
an
image
layer
that
we
put
into
the
build
package
or
or
you
could
build
an
artifact.
B
It
gets
turned
into
an
image
layer
that,
in
the
build
package,
looks
exactly
like
the
layer
that
would
end
up
in
the
application
right
and
then
that
could
that
layer
could,
without
any
changes,
just
follow
through
into
the
final
app
image.
You
know
without
the
path
changing
in
a
very
fast
build,
but
it
it's
kind
of
complicated
to
make
that
work,
and
some
of
the
benefits,
as
emily
has
pointed
out,
are,
like
you
know,
once
it's
built
once
for
the
application
on
a
rebuild,
it's
not
going
to
change
anyways
right.
B
B
Seems
like
not
too
many
thoughts
on
it.
Well,
it's
something
we'll
probably
talk
about
in
the
cnb
working
group
meetings
quite
a
bit
in
the
next
week
or
so
so.
If
people
have
thoughts,
it's
a
good
place
to
to
chat
about
it.
Just
wanted
to
make
people
aware
here
that
it's
gonna
it'll
have
a
pretty
big
effect
on
how
you
make
and
put
dependencies
in
build
packs
in
the
end
in
the
offline
case.
So
I
want
to
make
sure
we
have
good
consensus
for
everybody's
going
to
use
it.