►
From YouTube: Working Group: 2020-06-09
Description
* Green Builders
* Paketo Community Charter: https://github.com/paketo-buildpacks/rfcs/pull/11
* Project Wide Verbose Log Output
* Modularization Progress
A
A
A
A
A
A
A
A
A
A
B
B
B
I'll,
take
care
of
that
after
this
replaced,
build
PMO
with
the
build
plan,
build
pack
finally
get
in
quite
a
number
of
green
checks
on
here.
I,
don't
think,
there's
anything
outstanding
as
people
have
started.
Taking
care
of
this
I
believe
the
only
thing
we're
missing
here
is
Stephen,
actually
giving
this
a
green
check.
Is
that
correct?
Okay.
B
C
C
B
Things
onto
the
actual
agenda,
the
first
one
is
green
builders,
and
this
came
from
me
yesterday.
The
potato
builder
was
broken
and
Mark
and
Forsyth
jumped
on
that
and
got
it
green
again,
and
it
had
been
pointed
out
that
it
appears
not.
Everybody
thinks
this
things
in
production,
I'm
ready
to
go,
and
so
we
haven't
been
sort
of
applying
the
same
level
of
rigor
and
guaranteed
greenness
to
it.
B
To
be
honest,
whether
or
not
we
think
it
is,
it
definitely
is
spring.
Boot
shifts
a
feature
a
couple
of
months
ago,
based
on
top
of
cloud
made,
a
build
packs.
There
are,
we
know,
of
hundreds
of
applications
already
be
going
to
production
based
on
images
based
on
our
builder.
There
are
thousands
more
in
testing
according
to
the
boot
team,
already
starting
up,
so
the
ship
has
kind
of
sailed
and
while
individual
build
packs,
I,
don't
think,
are
necessarily
ready
for
production.
B
C
C
B
Former
the
biggest
issue
was
that
someone
had
identified
a
bug
and
wanted
a
fix
out
of
some
of
the
java
build
packs,
and
that
is
the
only
mechanism
effectively
that
we
can
get
those
out
to
user
short
of
them
building
their
own
builders,
which
no
one
really
wants
them
to
do
at
this
point.
So
it
is
the
only
delivery
mechanism
for
individual
build
pack
fixes
today.
So.
C
E
Have
been
a
couple
times
where
we've
broken
builders,
either
by
like
we're
moving
stack
a
these
are
changing
stack
IDs
in
the
soon
as
we
do
that
everyone
who
uses
these
comes
out
of
the
woodwork
riff
is
broken
and
spring
boot
is
broken
and
stuff
like
that.
So
I
think
we've
fallen
into
both
cases
here.
C
F
C
F
C
F
B
F
One
thing
we've
been
talking
about
on
the
release
engineering
side
is
you
know
that
the
team
may
reach
harder
a
bit
to
be
more
focused
on
creating
tools
like
looking
at
the
operating
system
package
to
install
all
these
cases?
Things
like
that
and
builders
were
outlined
is
one
of
the
things,
though
we're
not
sure
if
make
sense,
on
the
release
engineer
side,
because
they're
kind
of
like
really
so
engineering
sitting
in
front
of
helping
build
packs
to
a
place.
B
C
Like
I
was
saying,
I'll
just
share
my
screen
really
quickly
and
do
a
quick,
walkthrough
y'all
should
go
in
and
still
read
it.
Obviously,
if
that's
something
that
you
feel
particularly
passionate
about,
it
still
needs
some
polish
on
it,
which
is
why
it's
a
draft,
but
once
that's
sort
of
figured
out
I,
will
put
it
into
an
actual
estate
to
be
sort
of
ready.
C
So
this
is
a
Red
Hat's
like
package
offering
that's
outside
of
our
standard.
Red
Hat
distribution
at
PPA
is
obviously
a
bunty's,
and
so
that's
that's,
like
the
model
I'm
trying
to
go
for
is
a
set
of
packages
that
are
not
just
whatever
is
downloaded
on
me
off
the
internet,
but
a
set
of
packages
that
have
trusts
and
sort
of
somewhat
guarantees
around
them
as
well.
C
I
have
some
discussions
in
the
implementation
about
how
a
project
that's
in
the
community
would
be
able
to
propose
itself
to
go
into
like
that's
not
in
the
community
could
propose
itself
to
go
into
the
community
and
then
what
it
would
need
to
get
that
pulled
in,
and
then
I
also
have
some
discussion
down
here
around
potentially
hosting
sort
of
a
build
solution
to
allow
us
to
build
secured
artifacts
for
all
of
our
repos.
So
there
is
a
known,
safe
place
to
download
artifacts
yeah.
C
C
Actually
sorry,
this
is
just
the
first
half
of
a
sort
of
tandem
set
of
rfcs
that
I
want
to
get
in,
but
they
are
a
little
disjoint
from
each
other,
so
I
separated
them
so
I
would
sort
of
bottleneck.
One
with
the
other
I
also
want
to
put
in
another
RFC
to
discuss.
Moving
things
that
we
feel
are
mm
have
become
critical
components
in
the
community
into
core,
so
that
we
can,
you
know,
put
them
as
our
part
of
our
paquette
Oh
sort
of
offering
and
put
them
in
our
official
artifacts.
G
Well,
a
couple
questions
on
this
I
mean
I,
had
some
comments
as
well,
but
I
think
this
is
a
great
first
pass.
Do
we
call
out
anywhere
here
what
like
the
governance,
would
look
like
of
the
community
and
in
the
Senate?
What
I'm
thinking
of
is
like
all
this
tooling
that
we
have
I?
Think
Stephen
and
I
had
a
like
offline
chat,
a
bit
about
things
like
build
packages
and
stuff
like
that
who
actually
owns
those
artifacts,
put
publish
to
say,
like
the
Cato
community
Ruby
and
on?
C
G
The
general
question
so
imagine
like
say
Dan.
The
Cuza
has
a
Rust
Belt
pack
that
we
want
to
pull
into
potato
community
who
owns
the
tooling
around
getting
that
build
package
onto
GCR.
Are
we
giving
people
like
tenma
Cuza
access
to
that
GCRA
location?
Questions
like
that
I
think
that
would
be
good
to
address
yeah.
C
B
C
A
better
word
for
that,
but
I
can't
think
of
it
right
now
and
then,
with
that
we
would
I
think
basically
have
an
entire
build
system
to
ourselves.
That
would
you
know
if
you
become
part
of
this
community
you
to
publish
these
artifacts,
you
go
through
our
build
system
and
youth
and
our
build
system
publishes
those
things
for
you.
I
think,
is
the
general
idea
that
I
want
to
go
for,
but
that
is
something
that
I
have
not
completely
fleshed
out
in
this
party,
in
particular,.
G
B
I'd
be
careful
about
making
that
a
hard
requirement
just
what
we,
what
we've
seen
in
cloud
foundry
about
making
sure
that
you
have
to
come
into
our
build
systems
or
even
in
the
spring
team
as
well,
instead
making
it
a
compelling
offering
like
an
SRE
kind
of
thing
like
you
can
write
your
own
build
system,
but
we've
got
this
one.
That's
already
exists
out
of
the
box
for
you,
the
law
made
it
so
you
don't
spend
the
time.
I
think
is
a
better
carrot,
rather
than
the
stick
almost.
F
If
we
have
a
lower
bar
for
entry
into
potato
community
or
incubator
or
whatever,
we
call
it
the
where
we're
not
doing
extensive
vetting
right
that
would
be
required
to
enter
the
project
proper,
then
having
the
source
code
get
built
automatically
without
the
you
know
maintainer,
so
he
didn't
vet,
potentially
random
people
on
the
internet,
creating
those
artifacts
and
publishing
them
it.
It's
like
that
would
be
a
big
benefit.
It
would
be
a
carrot
for
people
to
join
because
they
get
some.
You
know
like
semblance
of
like.
F
B
I'd
be
careful,
the
problem
is
making
the
bar
too
high
right,
like
it's
pretty
clear
that
Heroku
x'
community
right
hasn't
had
this
hasn't
had
a
need
for
this.
The
people
who
choose
to
use
certain
things
you
know
aren't
necessarily
worried
about
it.
I
think
this
is
a
play
towards.
We
expect
at
some
point
in
the
future
enterprises
to
say.
Not
only
can
you
use
anything
from
potato,
but
our
our
internals
can
also
use
anything
from
Poquette,
Oh,
community
and
so
like.
That
is
what
the
actual.
F
The
her
local
community
uses
build
packs
in
git
repos,
where,
like
you,
can
you
can
review
what
you're
going
it's
gonna
run
when
you
before
you
use
it,
because
I
don't
have
artifacts,
and
so
I
was
only
that,
because
our
things
tend
to
be
a
go
and
precompiled
as
blobs
of
things
that
are
on
a
registry.
I
was
wondering
if
that
changed
it
at
all,
but
maybe.
B
F
Thinking
more
like
you
have
to
use
github
actions
right
like
not,
you
have
to
use
this
particular
system
we've
designed
to
do
packaging
or
anything
like
that.
Just
like
the
stuff
that
builds
it,
regardless
of
what
it
is,
it
can
be
whatever
you
want
has
to
be
source
code
checked
into
the
repo
that
is
processed
in
an
automated
way.
Not
there
has
to
you
know
like
just
just
I'm,
not
saying
that
that's
that
alleviates
the
problem
just
to
clarify.
B
Because
yeah
I
don't
think
that's
I,
don't
think
that
was
clear
and
force
explanation.
The
idea
of
a
here
is
a
you
know:
a
prebuilt
build
system
with,
and
admittedly
forest,
as
you
said
like
this,
is
totally
undefined.
What
it
means
I
just
want
to
call
out
the
point
that
we
actually
have
to
compel
build
pack
authors
to
come
here
and
every
time
you
put
up
a
new
barrier,
you
must
do
X
is
a
strike
against
actually
coming.
Besides.
F
C
E
Be
interesting
to
see
how
this
interacts
with
the
build
pack
registry,
like
the
centralized
one,
that's
being
planned
for
CMB,
because
people
are
gonna
want
court
in
here
to
be
publishing
under
the
picado
community,
namespace
and
I'm
sort
of
curious
how
we're
going
to
control
access
to
the
credentials
to
the
picado
key
new
namespace.
So
people
can
publish
from
here
to
that
registry.
That
would.
F
Be
reason
why
controlling
the
build
of
the
build
back
would
because
then
we
could
guarantee
that
it
it
flows
up
to
that
location.
That's
that's.
The
reason
for
the
controlling
the
build
is
that
it
would
guarantee
that
it's
coming,
like
the
artefact
wasn't
published
by
random
person,
it
was
literally
the
source
code
in
the
repo
dealt.
However,
the
repo
defines
it
to
be
build
and
published
there
when
the
source
code
is
updated,
I'm,
a
certain
branch.
F
C
B
B
There
has
to
be
some
other
value
to
it
and
like
the
easy
one
is,
if
VMware
can
commercial,
we
can
go
to
a
commercial
customer
and
say
we
will
also
support,
or
we
will
also
indemnify
the
code
in
picado
community
right,
like
that's
a
very
compelling
reason
to
want
to
get
in
for
quite
a
number
of
our
partners,
in
fact,
but
it's
not
clear
actually,
that
VMware
is
gonna.
Do
that
so
other
than
we
think
potato
is
a
good
idea.
Why
does
random
build
pack
developer?
Want
our
namespace
okay,.
B
F
G
Maybe
is
somewhat
separate
question,
but
possibly
related,
but
like
do
we
have
any
docs
for
an
RFC
around
like
the
promotion
process
like
how
do
we
get
something
and
thinking
like
Ruby
or
Python
from
Paquito
community
into
like
an
officially
supported
thing
that
we
can
watch
mark
it
on
our
website?
Another.
C
G
F
I'm
chip
reached
out
a
while
ago,
I
think
cash.
Have
you
mentioned
this
about
community
being,
maybe
not
a
great
name
for
it,
because
it
implies
that
the
rest
of
the
project
isn't
community-centric.
It's
like
well,
this
is
the
community
part.
Well,
let's
who's.
Maintaining
this
other
stock
right
now
maintained
by
a
community
of
maintained,
errs
it'd
be
hard
to
change
the
name.
You
know
in
the
short
term,
but
I
think
it's
a
good
point,
and
you
know
chip-chip
knows
his
community
building
techniques
for
open
source
projects.
C
G
Spoke
the
chip
again
after,
like
we
initially
had
that
conversation
and
like
he's
not
super,
like
particular
about
like
doing
this
immediately,
his
feedback
was
more
or
less
like.
We've
tried
this
and
Cloud
Foundry
before,
and
this
is
sort
of
the
feedback
we
received
around
that
so
just
something
to
keep
in
mind.
I,
don't
think
it
makes
sense
to
do
immediately
because
we've
done
again
a
lot
of
work
past
couple
months,
just
moving
things
over
and
stuff
like
that.
But
if
we
hear
more
feedback
around
this,
we
could
think
about
it.
I.
C
G
G
One
was
me:
I'm,
not
entirely
sure,
where
I'm
going
here
with
this,
but
like
I've,
ran
into
a
couple
instances
recently,
where
I'm
doing
things
like
a
running
with
the
bundle
install
built
back
and
my
bundle,
install,
fails
and
I
have
no
way
of
debugging
what
happened,
because
the
build
process
isn't
running
bundle
install
with
verbose.
So
so
what
I'm
wondering
is,
if
there's
like
some
standard
way
or
some
flag
or
some
environment
variable
or
something
that
we
can
like
use,
project
wide,
whether
that's
like
potato
or
like
CMB
project
as
a
whole.
G
To
do
something
like
this,
what
I
have
in
mind
is
like
the
pack
for
both
flag
on
the
build
should
set
like
some
environment,
variable
that
all
build
pack
authors
can
just
consume
and
use
and
have
verbose
logging
output,
because
it
it's
extremely
hard
to
like
debug.
What's
going
on
right
now,
unlike
and
say,
you're
an
install,
failing
or
bundle
install,
or
something
like
that.
Has
there
any
other
folks
thought
about
about
this
before,
like
because
a
C
and
B
project
ran
into
any
of
this.
Oh.
B
We've
definitely
thought
about
this.
There
is
a
long-standing,
never
actually
written
RFC
for
structured
logging,
which
would
communicate
the
same
kind
of
information
through
it
that
basically
a
bi-directional
piece
of
information
so
that
verbosity
levels
or
logging
levels
are
passed
down
in
to
build
packs
and
build
packs
generate
logging
at
different
levels
that
is
displayed.
You
know
in
various
different
ways
in
various
different
systems.
It's
a
very
hard
problem
from
the
job
aside,
the
way
we've
always
handled
this
is
we
are
already.
We
already
have
environment
variables
for
configuring.
B
The
we
want
to
define
logging
levels
either
across
C
and
B
or
or
we
want.
We
want
to
have
input
from
the
tools
into
the
build
packs
is
such
a
gigantic
undertaking
both
conceptually
and
adoption
wise,
that,
like
it,
borders
on
impossible
like
getting
packed
to
pass
that
kind
of
information
and
without
also
solving
a
broader
structured
logging
kind
of
problem
is
just
like
it
just
doesn't
happen
realistically.
I
think.
F
F
If
you
decide
that
you
don't
want
to
repeat
it
again
with
B
or
or
should
build,
packs
really
make
the
decision
as
they're
running,
and
so
you
know,
I
think
it'd
be
great
to
start
those
conversations
or
keep
kickoff
those
conversations
up
again
in
the
CNP
project
and
have
that
trickle
back
down
to
either
things
build,
packs,
can
read
and
make
decisions
on
or
things
that
built
a
scalpel
with
their
output
to
be
able
to.
You
know,
have
PAC
filter
out
the
debug
information.
G
E
G
Got
it
that
makes
sense?
No
I
just
wanted
to
stir
it,
like
general
conversation
about
this,
because
I've
just
ran
into
this
a
lot
as
someone
playing
around
with
all
the
different
build
packs.
It
does
seem
to
me,
though,
that
since
the
Java
folks
already
have
some
environment
variables
for
this,
it
wouldn't
be
crazy
for
us
to
do
something
like
this
in
all
of
the
potato
bill
packs
that
they're
no
we're
calling
his
but
the
feature
engineering
team
like
maintains
I,
guess
yeah.
B
I,
wouldn't
I
wouldn't
approach
it,
as
here
is
how
you
enable
for
most
logging
right
like
it's,
it's
a
more
general
thing.
How
do
I
send
arguments
or
how
do
I,
as
an
application,
developer
customized?
What
arguments
are
actually
passed
when
I
run
npm
install
or
when
I
run
yarn
install
things
like
that.
C
So,
let's
pretend
we
didn't
want
to
launch
a
thousand
ships
first,
should
we
just
go
ahead
and
maybe
internally
and
then
express
it
through
some
documentation,
talk
about
what
we
do
to
set
varying
degrees
of
atrocity
for
just
build
packs
in
general?
Is
that
maybe
the
best
approach
for
us
to
take,
and
then,
if
there
is
some
higher-level
decision
for
the
tooling,
then
we
can
adopt
that,
but
maybe
adoption
of
that
will
be
easier,
or
should
we
just
to
avoid
this
topic
entirely?
C
B
I'd
be
careful
phrasing;
it
in
here
is
some
documentation
for
how
we
adjust
verbosity
right.
The
documentation
is
here
is
how
you
adjust
the
arguments
that
are
passed
to
these
tools
instead
and
verbosity
is
clearly
one
of
the
most
common
ones.
You'd
ever
want
to
do
right,
but
it
is
just
a
general
purpose.
Piece
of
functionality,
I'd,
say.
F
It
does
seem
like
naively,
if
you
added
a
BP
log
level
or
CNB
log
level,
did
OPEC
supposed
to
respect
and
tune-yards
they
send
to
the
tools.
You
end
up
a
lot
less
transparency
than
having
the
developer
set
the
different
debug
variables
for
the
different
tools.
They
want
to
see
more
output
from
right,
like
like
philosophically
there's
a
little
bit
of
a
difference
in
like
do.
We
want
build
packs
to
be
a
tool
that
makes
it
easy
to
build
images
using
NPM
or
do
I
want
build
packs
to
be
a
tool
that
installs
NPM
modules.
B
F
I
don't
expect
there
to
Sara
Lee,
be
an
update
on
this,
but
last
week
we
were
talking
about
there's
like
a
chat
about
modular
eyes
in
Ruby
and,
like
you
know,
really
breaking
it
down
so
they're
different,
build
packs
for
setting
of
you
know,
start
command
the
users
providing
versus
from
one
for
different
web
servers,
and
we
talked
about
how
that
could
become
modular
as
the
other
build
packs,
even
more
like
with
you
know,
should
the
NPM
build
pack
that
runs
NPM
install
should
that
set
of
start
commands?
Probably
not
that
should
be
something
else.
F
C
F
F
F
E
F
Seems
like
a
problem,
we
should
solve
that
shouldn't
shouldn't
fight
the
modularity.
Does
that
make
sense
like
if
we
need
to
make
it
so
you
can
use
one
build
packs,
been
build
and
simply
get
to
another
pill
pack
and
provided
a
different
argument.
It
feels
like
a
problem
you
should
solve
it's
that
way
in.
E
A
I
don't
want
you
to
put
any
of
these
layers
into
the
image
at
runtime,
because
I'm
only
using
this
during
build
and
so
I
think
that,
like
what
we've
ended
up
doing
is
trying
to
separate
the
portions
of
build
packs.
That
know
for
a
fact.
Something
is
needed
during
build
versus
those
portions
of
the
build
pack.
That
know
for
a
fact.
Something
is
needed
during
launch,
with
an
eye
towards
trying
to
make
efficient,
actual
runtime
run
images
that
don't
have
extra
dependencies
that
aren't
necessarily
needed.
A
E
Does
that
get
solved
by
breaking
it
up
more
I?
Guess
it's
my
question
because
you
still
need
to
at
some
point
to
detect
whether
the
smaller
modular
pieces
are
going
to
run
or
not,
unless
you're
having
users
very
explicitly
say
which
build
packs
are
running,
which
then
requires
them
to
know
a
lot
about
how
the
different
pieces
fit
together.
A
So
by
separating
the
portion
is
like
the
install
process
of
say
NPM
like
executing
the
NPM
install
process
from
the
portion
of
the
vote
pack
that
says
set
the
start
command
for
this
app
to
be
like
NPM
start
by
separating
those
two
I
can
basically
just
say
that
I
only
for
the
NPM
install
belt
pack,
if
it's
only
running
NPM
install
during
the
build
phase,
I
can
say
to
the
node
engine.
Build
pack.
I
only
require
note
during
build
and
I
can
like.
A
So
for
us,
it's
about
like
separating
the
two
like,
if
you
separate
those
two
concerns,
that's
one
way
of
building
in
the
separation
of
configuration.
Alternatively,
you
could
go
to
all
the
built
acts
that
have
these
types
of
concerns
and
build
toggles
for
them
to
say
like.
Please,
don't
attach
a
start
command
to
this
particular
thing.
I.
C
C
Build
that
someone
wants
to
use
so
by
also
attaching
that's
the
same,
build
pack
that
we
run
something
like
a
yarn
and
so
on.
We've
kind
of
we've
kind
of
had
to
push
everything
like
we'd
have
to
make
that
entire
build
process
configurable
somehow,
as
opposed
to
just
sort
of
allowing
the
user
to
define
what
they
want
their
process
to
be
through
some
other
means,
or
some
other
build
thing.
I
think
is
another
concern
that
we
were
trying
to.
I
cannot
solve
for,
but
address.
F
Just
from
a
user
perspective,
level
of
modularity
we're
talking
about,
doesn't
feel
ad
absurdum
to
me.
It
feels
like
it's
it's
taking
individual
actions,
the
user
would
think
about
when
they're
building
an
application
and
making
them
very
high
level
right
so
that
their
composable
I'm.
You
know
it
feels
very
a
single
responsibility
principle
and
it's
designed
sort
of
which
I
like
a
lot.