►
From YouTube: Working Group: 2020-12-02
Description
* New Platform Maintainer
* User Research
* Registry API: https://github.com/buildpacks/rfcs/pull/125
* Stack Buildpacks: https://github.com/buildpacks/rfcs/pull/111
B
B
C
B
E
B
E
G
A
Is
it
ready
for
votes,
looks
like
it
is,
I
think
so.
It
looks
like
me.
Terence
and
steven
are
outstanding,
so
yeah
unless
there's
anything
to
discuss.
Oh
yeah,
it
looks
like
I
had
some
comments
that
got
resolved
so
yeah.
Unless
there's
anything
that
needs
to
be
discussed,
I
think
that's
just
ready
to
vote
on.
D
A
B
Yeah
he
did
and
there
was
an
update
from
someone
else
that
said
that
they
were
gonna.
Take
a
look
at
this
and
update
it.
I
haven't
seen
any
commits-
and
they
haven't
reached
out
to
me
since
mentioning
that
they
were
going
to
take
over
so
maybe
I'll
ping
that
person
this
week
and
see
if
they're
going
to.
D
Joe
before
we
move
on
from
this,
so
the
build
pack
registry
search
api.
When
we
do
the
review,
we
can
make
sure
that
we
assign
it
to
a
team,
but
the
application,
mix-ins
and
layer
origin
metadata
haven't
been
assigned
to
a
team.
Therefore
they
don't
have
us
a
sherpa.
Yet
can
we
do
that
before
we
yep
leave.
B
B
H
E
D
D
A
F
B
B
B
C
Cool,
so
for
those
of
you
who
don't
know
me
my
name's,
sam
I'm
a
product
designer
and
user
researcher
at
vmware,
formerly
pivotal,
been
focused
on
engineering
tools.
I've
been
working
on
build
packs
for
about
two
and
a
half
years
now
originally
focused
on
net
framework
and
then
worked
with
ben
on
azure
spring
cloud
and
now
working
with
steven
there's
on
tangent,
build
service,
k-pac
and
paquetto.
C
But
I
want
to
make
sure
this
is
really
serving
everybody
in
the
community.
So
I
want
to
learn
from
you
all
about
what
you
think
is
most
important
to
take
this
product
to
the
next
level.
So
to
that
end
tomorrow,
I'm
going
to
use
part
of
the
time
during
working
group
to
do
a
brainstorming
exercise
around
some
of
the
key
assumptions
we
want
to
test
and
some
of
the
key
questions
we
want
to
answer.
C
So
that's
just
intro
to
why
I'm
joining
and
what
I'll
be
doing
with
the
project
over
the
next
couple
months,
sort
of
hoping
to
wrap
this
up
in
time
for
build
pack
summit
in
the
spring
so
that
it
can
help
bring
some
data
to
those
conversations
yeah
and
then
I
just
wanted
to
open
it
up
for
questions.
If
anybody
is
is
curious
to
know
more
about
this.
A
C
Yeah,
that
would
be
awesome,
so
the
wonderful
part
about
the
budget
is
that
we
are
paying
some
people
to
do
this.
Who
do
this
kind
of
busy
work
professionally
and
they
like
scour,
linkedin
and
like
put
out
like
requests
on
twitter,
and
they
also
like
have
a
database
of
like
engineers
and
devops
folks
that
they've
recruited
from
in
the
past?
So
that's
partly
what
we're
paying
them
to
do,
but
I
think
for
some
of
the
things
like
in
discussions
with
them.
C
They
don't
really
feel
confident
to
be
able
to
recruit
like
build
pack
users
or
build
pack.
Authors
they'd
certainly
be
fine
like
recruiting
like
potential
users
in
the
demographics
that
we
want
to
see
like
docker
file
users,
for
example,
or
or
something
like
that,
but
in
terms
of
like,
if
we
want
to
really
dig
into
people,
who've
actually
built
build
packs
with
the
v3
spec
or
folks
who
have
have
converted
over
to
using
build
packs.
V3.
Those
channels
would
be
super
helpful,
so
I'll
definitely
definitely
reach
out
more.
C
I
think
the
next
step
sort
of
from,
as
I
see
it,
is
to
write
the
the
screener
for
recruitment
and
like
what
are
the
key
like
what
would
be
a
qualified
candidate
for
us
to
interview
and
that's
a
process.
I
want
to
work
closely
with
you
all
on
and
then
based
on
that,
we
can
decide
what
channels
we
might
need
to
add.
C
G
We've
introduced
a
bill
pack
registry
right
now.
We
have
a
lot
of
bill
pack
metadata,
that's
starting
to
populate
this
in
a
couple
of
weeks,
or
actually
it's
been
a
while
now,
but
I
did
a
quick
demo
on
just
adding
more
support
for
our
customers
to
have
access
and
the
ability
to
discover
these
different
build
packs.
G
And
as
a
result
of
that,
I
was
thinking
more
about
what
would
a
service
look
like
an
api
service.
Specifically
that
would
allow
the
capability
for
a
user
or
any
client
for
that
matter,
to
perform
searches
against
this
growing
vastness
of
bill
packs
inside
of
our
registry,
and
that's
the
the
main
motivation
of
this
right
now.
G
G
Currently,
as
I
mentioned,
there's
really
no
ability
to
easily
search
this
unless
you
go
directly
into
the
get
repo
and
do
manual
traversal
of
the
actual
file
system,
which
is
very
cumbersome
and
as
we
want
to
increase
adoption
and
just
reduce
that
friction
to
all
the
different
vendors
out
there.
You
know
we
have
google,
we
have
roku,
pocato
and
xyz,
whatever
anyone
that
wants
to
publish
and
expose
bill
packs
to
be
consumed
by
the
broader
community.
G
So
you
can
see
these
three,
which
is
one,
is
to
retrieve
all
the
bill
packs
in
the
registry,
so
just
a
simple
endpoint
to
gather
all
these
bill
packs
in
a
normalized
fashion,
because
right
now
we
have
a
different
schema
kind
of
a
method
for
indexing.
All
of
these
build
packs
into
the
github
repo
which
is
based
on.
If
you
just
go
and
look
at
it,
it's
pretty
it's
it's
not
very
straightforward,
but
this
will
allow
to
to
normalize
it
and
just
make
it
more
readable
and
user-friendly.
G
G
Just
things
like
that,
and
maybe
even
there's
still
going
to
be
some
investigative
work
that
needs
to
be
done
to
just
see
what
is
available
with
these
different
registry.
Vendors,
like
you,
know,
gcr
ecr
github,
so
it's
not
exactly
clear
how
this
additional
data
might
even
be
calculated,
but
I
just
envisioned
down
the
road.
It
would
be
really
beneficial
to
provide
more
than
what's
currently
being
offered
in
the
existing
bill
pack
registry.
D
Yeah
and
the
registry
itself
doesn't
actually
need
to
gain
any
more
information
right.
The
search
can
actually
maintain
an
index
of
all
of
this
one
of
the
things
one
of
the
things
that
we've
started
working
on
is
the
metadata
for
the
images
themselves
actually
contains
a
bunch
of
information
already.
Basically,
everything
in
the
build
packs
block,
I
think-
and
so
so
that's
like
id
name
version
home
page
and
that's
about
it,
but
we
should
endeavor
to
say:
okay,
anything
that
we
want
the
index
to
be
able
to
return
should
actually
move
up.
D
Should
there
be
a
description
up
there?
Should
there
be
a
license
as
a
first-class
construct
when
we
start
attaching
assets
to
it,
for
example,
that
stuff
should
absolutely
be
added
to
that
external
metadata,
because
what
I
want
is
the
index
to
basically
stay
the
way.
It
is
with
a
series
of
pointers
and
for
both
this
search
thing
or
any
other
tool
to
be
able
to
get
all
of
the
metadata
you
might
be
interested
in
without
actually
downloading
and
cracking
open
the
build
package
we
have
to
do
today.
G
Nice
yeah
yeah.
I
agree.
I
don't
want
to
have
to
to
mess
with
the
metadata
and
and
change
it
as
it
stands.
It
would
just
be
nice
to
have
the
ability
to
further
extract
those
those
details
by
other
means
yeah,
so
currently
how
it
works
is
right.
Now
I
am
basically
looking
at
the
existing
repo
that
has
all
the
metadata
in
there
and
if,
for
those
of
you
haven't
seen
it.
G
This
is
the
repo
that
I'm
referring
to
so
in
here
we
have
indexed
in
a
very
non-normalized
fashion,
all
the
the
bill
packs
in
the
registry
from
different
people,
different
vendors.
You
can
see
we
have
a
lot
of
the
cato
ones.
We
have
some
riff
ones.
Joe
has
a
minecraft
one
in
here
somewhere
and
it's
not
normalized.
So
what
I'm
currently
doing
and
what
I'm
currently
proposing
is
just
trying
to
leverage
as
much
of
what
we
currently
have
in
this
case,
taking
the
existing
repo
that
I
just
showed
you
and
normalizing
it
pulling
it
down.
G
So
the
current
solution
I
have
is
to
have
a
separate
thread
that
periodically
will
pull
the
repo
normalize
all
of
these
bill
pack
metadatas
into
it,
one
single
json
object,
which
then
will
become
indexed
and
I'm
using
a
third-party
library
right
now
to
simply
specify
which
keys
on
these
json
objects
that
I
want
to
be
indexed
in
searchable
fields
and
those
are
the
fields
that
are
compared
against
the
query
string.
So,
as
that
query
comes
into
the
the
request
with
you
know:
node,
for
example,
user
wants
to
search
for
node,
build
packs.
G
So,
as
I
mentioned,
there's
there's
two
components
as
it
currently
stands.
One
is
to
pull
data
from
the
github
registry
to
normalize
it
and
re-index
it
because
you
know
outside
of
that
new
build
packs
are
being
uploaded
and
merged
into
the
repos.
So
it
has
right
now
just
some
pre-defined
pulling
interval
that
will
constantly
grab
that
re-update
it.
And
then
we
have
the
three
endpoints
that
I
mentioned
earlier.
G
The
three
get
endpoints
one
to
retrieve
all
of
the
bill:
packs
that
are
currently
in
there
bill
packs
that
match
a
specific
query,
string
value
and
then
one
that
hasn't
been
implemented.
Yet
is
then
the
ability
to
drill
down
specifically
into
a
particular
build
pack
to
get
more
detailed
information
on
that
build
pack.
G
Also
just
worth
mentioning
that
it's
kind
of
unknown
territory
right
now,
because
it's
the
first
time
as
a
community
we're
looking
at
potentially
supporting
a
service,
and
what
does
that
look
like?
What
does
the
burden?
Look
like
I
mentioned
here
that
the
distribution
team
maintainers
will
be
responsible
for
this.
So
that's
a
burden
that
we
are
looking
at
in
all
seriousness
of
taking
on
ourselves
and
we're
aware
of
it.
E
So
I
have,
I
don't
know
if
it's
a
question,
maybe
more
a
comment,
so
it
seems
like
this.
Rfc
is
maybe
twofold
right.
It's
talking
about
a
search
api,
what
the
parameters
and
what
the
output
or
results
are.
But
then
I
think
one
of
the
things
that
it
doesn't
detail,
maybe
too
much
in
depth,
is
that
this
is
a
new
server
right
like
a
new
service
and
so
where
it's
going
to
be
hosted
where
source
code
is
going
to
live
and
and
all
that
stuff
I
feel
like.
G
Yeah,
I'm
happy
to
add
some
details
there.
My
initial
thought
was
potentially
heroku.
We
could
just
serve.
We
could
post
this
on
our
service.
I
need
to
verify
some
of
that
stuff,
but
I'll
be
happy
to
add
more
details
around
that.
The
code
itself
is
in
my
personal
repo,
but
I
plan
on
just
donating
it
to
the
cmb
community
project.
So
that's.
D
Right
yeah,
another
repo
under
the
the
build
packs
umbrella,
exactly
the
distribution
team,
managing
it
yeah
precisely
yep,
yeah
and
xavier,
like
I
sort
of
take
a
slightly
different
view
on
this,
the
things
that
you're
primarily
concerned
about,
like
I
think
it's
important
to
spell
out
that
this
is
a
service
that
we
are
going
to
keep
alive,
but
it's
kind
of
up
to
the
distribution
team,
in
my
opinion,
like
whether
it
where
it's
hosted
right,
I
don't
think
it's.
You
know
a
core
team
responsibility
to
know
those
things.
D
I
think
it's
important
that
we
define
like
here's,
what
the
actual
domain
is
going
to
be,
and
it's
going
to
be
something
something.buildpacks.io
right,
registry.buildpax.io
or
something
like
that
to
make
sure
that
it
is
portable
and
we
want
to
sort
of
note
like
if
it
runs
on
heroku
or
if
it
runs
on
digitalocean
or
it
runs
on.
You
know,
name
your
other
place,
whatever,
whatever
works
well
for
the
distribution
team
to
give
us
a
reliable,
effective
registry
search,
engine
or
api,
I
should
say.
G
D
A
E
Yeah,
that
makes
sense-
and
I
guess
that's
why
the
it's
the
note-
and
I
guess
maybe
that's
what
threw
me
off
right-
it's
that
there's
a
small
note
that
says
that
this
is
a
service
and
that
this
thing
is
going
to
live
somewhere,
but
it
doesn't
go
into
detail
about
that
so
yeah
I.
I
could
totally
agree
with
that
everything
you
you
all
said.
F
I
was
curious
if
we
considered
sort
of
the
more
client-side
version
of
this
that
doesn't
have
a
service
right
like
if
we
augmented
the
registry,
with
a
little
bit
more
of
the
metadata.
Someone
might
want
to
search
which
could
be
useful,
anyways
and
then,
since
pack
already
has
a
copy
of
a
registry,
you
could
basically
do
its
own
search
for
you
without
needing
an
extra
server
component.
A
So
I
think
we
should
do
that
in
pack.
However,
I
don't
think
that's
gonna
solve
the
or
address
the
biggest
problem
we're
trying
to
solve,
which
is
discoverability
and
growth
of
the
ecosystem
like
searching
from
the
cli
functions,
but
it's
not
going
to
be
a
pleasant
experience
and
it's
almost
like
having
this
api
and
the
like
the
web
page
that
goes
with
it
is
part
of
this
is
marketing
right.
A
D
Pushing
it
out
to
platforms
that
would
it's
like
as
convenient
as
that
is
like
it's
got
problems
right
like
do
you
think
that
all
searching
has
to
be
done
with
pack?
Do
you
think
that
kpac
has
to
implement
a
search
function
and
heroku
would
have
to
implement
a
search
function
like
I
don't
think
we
can
actually
distribute
it
completely.
F
Yeah
imagine
if
you're
going
to
distribute
it
that
way,
it
would
be
essentially
a
library
that
pat
could
consume,
but
another
thing
could
which
then
of
course,
you're
limiting
yourself
to
go,
but
I
guess
the
reason
I
think
was
thinking.
That
is
because
the
data
already
exists
in
the
index.
The
data
you
would
want
so
like
if
we
didn't
have
a
way
to
serve
this
data
to
someone,
then
it
would
or
like
a
way
for
people
to
consume
it,
we're
not
serving
it.
People
are
get
pulling
it.
F
That
would
make
more
sense
to
me
that
we
definitely
need
this,
so
people
could
write
their
own
integrations,
but
because
we
already
have
a
way
of
providing
this
data
like.
Could
we
just
use
that
as
the
distribution
for
this
and
then,
if
the
way
we've
organized
this
data
makes
it
hard
to
do
the
kinds
of
things
people
want
to
do
with
it.
F
D
D
H
The
service
is
probably
kind
of
the
big
advantage
that
you're
also
pulling
from
right,
like
you
can
imagine
when
someone
publishes-
and
we
do
some
of
that
stuff
when
we
index
it
in
this
thing
like
we
can
fetch
like
that
label
data
that
isn't
going
to
be
in
the
index
right
or
the
the
offline
asset
cache
right
like,
and
that
now
is
a
searchable
entity.
A
little
bit
worried
about
the.
H
D
B
D
Like
there
is
an
opportunity
to
instead
say
actually
what
we're
going
to
do
is
we're
going
to
write
all
of
that
metadata,
like
you,
give
us
the
sort
of
small
bit
today,
that's
like
namespace
version
and
address,
and
we
will
go
build
all
that
and
the
line
that
we
actually
put
into
the
index
is.
This
is
all
of
the
additional
information.
D
H
Yeah,
I
think
we
I
had
some
extensive
work
working
on
bundler
for
rubygems
and
there
was
a
huge
part
where,
as
the
thing
got
bigger
like
you,
we
you
had
a
separate
kind
of
store
for
stuff.
Like
description
like
we
ripped
that
stuff
out
index
like
you,
don't
need
it,
you
don't
need
it
to
basically
do
like
depends.
Your
resolution
and
other
stuff
right,
like
you
kind
of
just
want
to
have
an
index
that
is
as
small
as
possible.
D
B
F
Yeah
I
buy
that
I
feel
like
the
model
I
was
searching
for
is
more
of
the
brew
model,
but
I
feel
like
to
do
the
brew
model
successfully.
We
would
have
had
to
make
sort
of
different
decisions,
be
more
like
a
like
brew
and
that
there
aren't
many
things
in
the
canonical
index
or
like.
Maybe
there
isn't
one
it's
like
taps.
You
point
at
a
bunch
of
places
that
are
hosting
and
decide
what
to
do,
and
then
you
can
sort
of
do
the
stuff
on
the
client
side.
E
B
E
H
B
E
E
E
Index
right,
but
now
I
want
to
search
that
registry,
because
that's
the
one
that
I've
set
as
my
default.
How
do
I
do
that
right
and
it
sounds
like
we
want
to
essentially
keep
the
same
interface
right
and
so
el
bandito
has
to
have
that
interface
for
searching,
hosted
somewhere
right,
at
least
as
an
optional
feature.
D
F
H
H
B
H
If
you
notice
an
npm,
they
actually
used
to
have
an
all
endpoint,
but
they
removed
it.
I
think
part
of
it
is
just
like
that's
just
a
huge
hit
on
any
server
as
you
grow
is
like.
You
cannot
feasibly
return
all
the
packages
in
a
json
format
that
is
super
scalable,
and
so
I
don't
know
if
we
actually
want
that
endpoint.
B
H
H
Yeah,
I
think
npm
solves
this
problem
by
basically
having
a
max
on
like
the
size
and
stuff.
It
will
return
back.
So
like
they
hard
code,
you
can
never
have
more
than
250
npm
packages
that
will
ever
return.
You
can't
override
that,
but
you
can
adjust
from
1
to
250.,
and
so
I
think
you
can
basically
scope.
E
G
D
A
Yeah,
that's
when
terence
is
gonna,
rub
it
in
I'm
sure
I
I
think.
Even
if
we
go
that
route,
we
want
some
kind
of
hybrid
like
it
can
still
fall
back
to
github,
so
that
even
you
know,
if
it's,
if
there's
some
kind
of
service,
that's
on
the
critical
path
and
it
goes
down,
people
can
still
pull
they
just
or
you
know
people
can
still
build
and
get
their
bill
back
from
somewhere.
They
just
can't
do
other
things.
F
A
As,
like
your
entry
point
to
like,
I
need
a
tool
that
will,
you
know,
generate
a
gpg
key
or
whatever
like
no,
you
go.
You
go
to
gpg
and
you
look
at
the
install
instructions
right.
It's
probably
a
terrible
example.
I'm
trying
to
think
of
a
good
one
that
I've
done
recently
like
you
know
some
of
these
kubernetes
tools
like
like
canines
or
customized,
or
whatever,
like
I'm,
not
finding
those
through
groove,
I'm
finding
those
through
their
website
and
their
mark.
A
G
Yeah,
so
the
drawbacks
that
I've
mentioned,
we
kind
of
discussed
already
actually
with
just
performance,
and
you
know,
decoupling
some
of
the
the
existing
data
inside
of
the
the
current
github
repo
with
what
might
be
presented
or
how
we
might
augment
it
it's
like
do.
We
want
to
change
it
at
once
in
one
place
or
keep
the
the
repo
clean
and
simple
and
augment
augmented
somewhere
else
and
persisted
somewhere
else.
G
G
G
G
And,
of
course,
as
mentioned,
this
is
a
service.
This
is
the
new
ground
for
us
as
far
as
maintaining
a
service
and
what
that
looks
like
so
just
things
to
consider,
and
of
course,
we
are
depending
on
github
at
heroku,
we've
had
instances
where
there
have
been
outrages
on
the
github
side
which
have
degraded
some
of
our
services
doesn't
happen
often,
but
it's
just
you
know
something
that
can
happen
worth
mentioning.
G
Getting
down
to
the
alternatives,
there's
two
that
just
kind
of
stuck
out
to
me.
One
was
just
you
know
we
do
nothing.
We
already
have
this
information
more
or
less
inside
of
the
github
repo
that
I
that
I
showed
earlier
a
user
could
navigate
that
repository
and
find
this
information
on
their
own
or
maybe
even
using
github
search
to
some
extent.
G
So
one
of
the
other
things
I
mentioned-
and
this
might
be
more
of
an
implementation
detail-
is
actually
kind
of
separating
out
a
separate
service,
that's
responsible
for
because
right
now,
it's
all
part
of
the
actual
api
itself.
Well,
maybe
I
break
out
this
background
process
into
a
separate
service
like
a
worker
process
that
will
be
solely
responsible
for
interfacing,
with
the
github
repo
taking
the
metadata
from
there
massaging
it
going
out
to
these
various.
G
My
goal,
as
I
mentioned
again
at
the
beginning,
is
I
really
am
trying
to
figure
out
an
mdp
approach
to
this
something
really
simple,
because
we
are
figuring
out
and
trying
to
figure
out
how
a
customer
might
want
to
use
this
stuff.
What
you
know
there
might
be
things
we
don't
know
yet,
and
I
don't
want
to
commit
to
such
a
huge
solution
as
we
are
going
through
this
experimentation
phase
and
discovering
things
as
we
go,
so
my
attempt
is
just
to
keep
it
really
simple
and
right
now.
G
G
It'll
be
really
hard,
I
believe,
for
the
adoption
and
discovery
of
all
these
third-party
build
pack
vendors
out
there
and
just
exactly
what
the
community
can
offer
in
the
form
of
bill.
Packs
it'll
be
really
beneficial.
I
think,
for
customers
to
have
that
ability
to
quickly
and
easily
find
information
that
they're
interested
in,
which
is
you
know,
building
their
applications
using
build
packs.
G
G
G
I
think
it
would
be
nice
to
have
other
clients
pack.
I
totally
agree
that
pac
would
be
something
that
we
should
also
implement,
search
capability
on
and
then
also
having
a
web-based
client
kind
of
like.
As
the
first
introduction.
You
know,
like
rubygems
npm
those
kinds
of
places,
something
similar
to
that.
G
E
One
of
the
other
things
that
I
just
thought
about
was
to
make
this
a
little
bit
more
accessible
instead
of
having
to
re-implement
the
spec
right,
I'm
wondering
if
producing
the
the
service
right,
the
api
rest
service
as
an
image
like
being
an
output
that
then
similar
to
like
a
registry
2
for
docker
right
like
where
you
could
now
essentially
set
it
up
and
just
point
it
to
the
registry
that
you
wanted
to
look
at.
I
think,
would
be
like
a
five-minute
setup
for
anybody
and
would
make
it
a
lot
more
accessible
as
well.
D
G
A
For
your
time,
yeah
thanks,
travis
yeah.
I
think
I
guess
he's
gonna
address
the
feedback,
but
take
a
look.
If
you
haven't
already,
we
have
five
minutes
left,
but
I
wanted
to
bring
up
stack
packs.
I
was
looking
over
it
and
I
don't
see
any
outstanding
questions.
Comments,
concerns
that
haven't
been
replied
to
or
something
like
that.
So
it's
waiting
on
votes
from
stephen
and
emily
so.
A
F
F
A
Yeah,
actually
I
you
know,
I
started
drafting
up
the
spec
pr
and
in
part,
for
the
same
reason
I
wanted
to
kind
of
validate
what
did
I
miss
or
whatever,
but
it
was
actually
kind
of
the
opposite,
like
as
I
was
doing,
the
spec
pr.
It's
like.
Oh,
I
could
just
gotta
cut
all
this
stuff
out.
That's
in
the
rfc,
because
it's
like
examples
and
like
implementation,
details
and
writing
the
spec
pr
actually
felt
a
lot
easier
in
that.