►
From YouTube: Working Group: 2020-12-16
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
Next
up
is
introductions.
I
see
a
lot
of
familiar
faces,
so
I'm
gonna
assume
we
don't
have
any
introductions
today.
Release
planning.
B
All
right
I'll
talk
a
little
bit
about
pac,
I
think.
Since
last
week
we
talked
about
the
pack
potentially
pushing
back
to
date
for
release
till
after
the
holidays
and
therefore
probably
the
new
year.
I
think
that
is
still
going
to
be
the
path
forward.
I
think
you
know
we
just
haven't
had
enough
traction
to
really
deliver
something.
That's
you
know
I
guess
complete
in
the
sense
that
users
would
expect
it
to
be
so
it
doesn't
seem
like
there's
anything
critical
there
that
that's
really
requiring
us
to.
B
You
know
work
around
in
any
form
or
fashion.
So
that's
the
update
there.
B
Another
thing
I
guess
I
I
did
a
little
bit
of
work
on
pacorb
yesterday
and
I
did
release
a
new
version
of
that.
There
is
yet
another
fix
that
I
put
in
that.
I
wanted
to
release,
and
so
I
want
to
add
it
to
the
agenda
to
talk
about
pac
orb
ownership,
since
I
believe
travis
was
taking
care
of
that,
and
I
want
to
make
sure
that
I'm
not
stepping
on
anybody's
toes
and
stuff
like
that.
C
So
I
just
put
up
a
draft
release
for
life
cycle,
o
10
0,
which
will
implement
build
pack
api
0.5
as
well
as
platform,
api
0.5,
and
we're
just
doing
some
validation
right
now
of
that
artifact
before
declaring
it
good
and
we'll.
Hopefully,
ship
today,
borrowing
anything
unexpected.
A
A
A
I
need
to
have
fewer
windows
with
github
open
because
it's
getting
hard
to
tell
in
the
preview
if
I'm
opening
the
right
one
starting
at
the
bottom
offline
build
packages
rfc.
A
I
don't
see
these
folks
here
today,
I'm
assuming
they've
gone
out
for
the
holidays.
I
just
went
through
this
today
and
left
a
bunch
of
comments
that
are
all
just
like
small
tweets
around
names
and
usage
stuff.
I'm
really
happy
with
the
overall
idea.
At
this
point.
D
Is
your
comment
on
the
asset
I
I
was
reading
through
your
comments
this
morning
too.
The
like
multiple
asset
thing,
I
think,
was
like
one
of
the
first
things
in
your
length
of
many
things
that
you
commented
on
is.
A
C
A
C
A
Names
right,
I
have
come
to
care
a
lot
about
this,
because
some
of
the
inconsistencies
in
our
early
file
schemas
really
bother
me
now
and
sometimes
create
weirdness,
where
we
have
to
do
a
bunch
of
data
transformations
rather
than
just
you
know
like
embedding
one
object
inside
of
another.
I
love
to
push
us
towards
something
consistent,
so
that's
sort
of
the
motivation
behind
a
lot
of
these
comments.
A
We're
past
the
point
where
I
think
the
ideas
here
correct
me.
If
I'm
wrong,
everyone
else
are
up
for
the
bait,
but
it's
more
about
what
command
names
and
file
schemes
we
want
to
live
with
for
a
long
time.
D
Yeah,
I'm
just
more
curious,
not
that
I
disagree
with
any
of
your
stuff
just
for
moving.
This
forward
is
to
say,
like
you,
just
need
to
sit
down
and
talk
with
david
or
have
him
or
daniel
and
have
him,
I
guess
sorted
out
yeah
through
the
sword.
Or
do
you
want
to
move
this
into
fcp.
A
I
think
I
would
like
to
talk
with
him
and
sort
it
out.
First,
let
me
always
move
it
into
fcp,
because
I
think
there's
no
hard
requirement
that
we
have
to
keep
these
exact
strings
in
pack,
but
it's
easier
for
people
when
they
look
at
the
rfc.
If
the
rc
matches
exactly
what
got
implemented
in
pack,
so
it
might
be
worth
doing.
D
C
E
C
C
A
Okay
project
descriptor
fixability
is
in
draft.
Do
you
want
to
talk
about
that
at
all
turns.
A
A
Sorry,
I'm
gonna
talk
about
tomorrow,
I'll
get
to
it
before
tomorrow.
Just
leave
it
for
last
in
my
rfc
is
because
it's
so
long
application
makes
sense
is
same
thing.
This
one
manifest
size
report.
Tommle
is
now
complete.
Its
final
comment
period
and
we've
created
all
the
issues,
so
the
assigned
team
member
ben
is
now
free
to
merge
that
copy.
F
A
Do
we
have
any
of
these
stackify
representatives
here
now?
It
looks
like
this
still
needs
reviews
from
a
couple
folks.
So
take
a
look
at
that
one.
Everybody
registry
search
api.
A
G
Yeah
I'll
put
it
it's
the
last
thing
on
the
agenda
today.
If
we
have
time
for
it
kind
of
ties
into
the
search
api.
G
G
G
F
C
A
A
C
A
B
I
guess
we
could
make
it
an
announcement
right.
Yeah
I'll,
definitely
be
taking
more
of
a
look
at
techton
right
now.
I'm
working
through
some
other
integrations
pacorb
being
one
of
them,
which
is
also
on
the
list,
but
yeah
techton
would
be
here
relatively
soon.
B
B
Cool
so
to
add
a
little
bit
of
context
here.
So
in
the
past
I
think
pacorb
was
one
of
those
things
that
was
contributed
by
joe,
then
terence
kind
of
or
sorry
not
terence
travis
took
a
little
bit
of
ownership
in
in
adding
some
functionality
to
it
and,
ultimately,
I
believe,
taking
care
of
the
releases
for
it
and
a
lot
of
it.
You
know
kind
of
stemmed
also
from
the
idea
that
travis
was
on
the
track
to
become
a
platform
maintainer.
I
think
those
plans
have
ultimately
changed.
B
My
understanding
is
that
there's
still
a
lot
of,
I
guess
involvement
requested
from,
I
guess
the
salesforce
team
to
continue
working
or
at
least
being
a
heavy
influence
for
the
pac
orb,
but
I
do
want
to
essentially
see
if
we
could
draw
the
line
and
if
that
makes
the
most
sense
for
the
platform
team-
and
I
guess
myself
on
focusing
on
integrations
to
take
on
pac-orb,
so
that
travis
could
focus
more
on
the
distribution
team,
stuff.
G
Yeah,
that
makes
sense
it's
already
in
the
platform
team
in
the
community
repo
but
yeah
in
practice,
not
really
but
yeah.
That
sounds
fine.
I
think
it's
going
to
be
fairly
stable.
You
know
it
was.
It
was
meant
to
do
a
thing,
but
it
does
if
we
were
going
to
if
it
was
going
to
go
beyond
that,
it'd
be
like
adding
things
like
a
package
build
pack
or
stuff
like
that,
but
we
don't
have
an
immediate
need
for
it.
So.
C
B
Yeah
then
I
guess
I
can,
you
know,
continue
moving
it
forward.
I
know
travis
had
some
ideas
of
of
where
he
wanted
to
take
it.
So
maybe
we'll
we'll
discuss
that
offline
somewhere
but
yeah.
I
guess
I'll,
formulate
some
sort
of
release,
cycle
release,
plan
or
something
and
take
care
of
there's
a
couple
issues
and
feature
requests
so
I'll
take
those
on,
and
you
know,
if
there's
anything
else.
Just
let
me
know.
B
Yeah,
I
think
travis
set
it
up,
so
it's
just
tagging
it
right.
So
I
think
one
of
the
things
that
we're
missing
before
is
like
release
notes.
So
I'll
probably
do
something
very
similar
that
we
did
with
pac.
It's
like
try
to
milestone
all
the
prs
and
then
produce
release,
notes,
that'll,
publish
it
automatically
with
what
travis
already
had
awesome
thanks.
E
E
E
You
know
api
application
and
we
kind
of
left
it
in
in
the
open
and
then
joe,
and
I
we
had
some
discussion
and
based
on
feedback.
We
decided
to
go
ahead
and
proceed
doing
a
more
all-in
which
approach
encompass
a
database
and
moving
forward
with
what
we
currently
have
in
the
proposed
rfc.
E
So
nothing
here
is
planning
on
being
changed
as
far
as
the
payload
is
concerned.
So
just
wanted
to
point
that
out
that
we
are
going
to
go
ahead
and
move
forward
based
on
the
suggestions
of
everybody
from
the
last
week
working
group,
I
think
it
was
terence
and
javier
had
some
some
good
endpoint
regarding
that
topic.
E
I
know
there's
some
also
last
minute
odds
and
ends
that
I'm
just
fielding
right
now.
I
think
emily
had
a
few
things,
and
maybe
there's
a
few
typos
too-
that
I
need
to
clean
up
which
I'll
address
outside
of
this.
E
A
couple
things
to
point
out
too,
that
I
mentioned
but
probably
didn't
call
out
enough,
was
the
fact
that
we
are
going
to
have
versions
endpoints,
starting
with
this
v
and
then
the
number.
Obviously
the
first
one
will
be
v1,
and
then
it
will
just
increment
as
we
release
changes
to
the
api.
That
would
merit
breaking
changes.
E
In
addition,
pagination
will
be
supported,
we'll
be
drawing
most
of
that
inspiration
from
the
github
way
of
using
pagination.
E
G
Yeah
one
of
the
one
of
the
things
that
I
think
emily
and
xavier
had
commented
on
was
like
supporting
unofficial
registries.
So,
like
I,
I
guess
like
the
the
idea
is
like
you'd
stand
up
your
own
instance
of
the
search
api
or
implementation
of
the
search
api
for
some
other
registry
and
how
we
support
that.
But
I
think
that
is
like
explicitly
out
of
scope.
G
I
don't
know
if
it's
already
called
out
in
the
rfc,
but
I
think
we
should
like
our
goal
in
doing
this
with
both
the
api
and
then
the
front
end
is
our
goals?
Don't
include
anything
other
than
the
official
registry
so,
and
I
think
most
people
that
set
up
an
unofficial
registry
will
probably
just
use
like
a
git
repo
without
all
the
the
github
stuff.
So
I
just
want
to
like,
if
possible,
just
completely
cut
that,
not
that
we
would
never
do
that
in
the
future.
G
D
Yeah,
I
think,
probably
on
that
too,
is
just
the
point
of
potentially
specking
out.
The
api
eventually.
Is
that
if
someone
wants
to
implement
that
they
can,
but
they
don't
they're,
not
going
to
necessarily
use
our
reference
implementation,
because
a
public
registry
has
very
different
implications
than
a
private
one.
B
Yeah,
I
guess
for
me
it
was
like
resetting
the
expectation
right
because
I
think,
based
on
the
previous
conversations,
it
seemed
like
we
were
very
much
leaning
towards
this.
You
know
very
specked
out
api
that
that
was
going
to
somehow
be
tied
to
the
registries,
to
support
unofficial
registries
but
yeah.
If,
ultimately,
if
we're
trying
to
do
something
a
lot
more
experimental
in
a
sense,
right
or
very
tailored
to
our
very
specific
use
case,
then
maybe,
as
you
mentioned
joe
just
calling
it
out
more
explicitly
at
the
summary-
would
be
sufficient.
G
I
wouldn't
call
it
experimental,
though,
like
I
think
this
is
a
like
the
pattern
you
see
with
like
rubygems
and
some
other
package
servers
or
whatever
you
want
to
call
them,
because,
like
ruby,
gems
is
the
front
end
forward
and
the
api
the
the
search
api
for
it
is
just
for
ruby,
gems,
and
then
you
have
like
third
parties
like
gem
gate
and
things
like
that,
but
they're
they're
headless
or
they
have
their
own,
their
completely
own
implementation
of
a
of
a
ui
into
ui
or
api
into
that
from
like
non-uh,
automated
tool
way
like
we
like
our
goal,
is
to
spec
out
the
machine
interactions,
but
not
not
necessarily
to
spec
out
and
like
make
generic
the
user
interface
for
it
or
the
programmer
interface
like
yeah.
D
I
think
in
most
of
those
patch
ecosystems,
usually
it's
the
mirroring
and
stuff-
that's
more
important.
So
it's
like
the
index
being
able
to
replicate
the
index
easily
for
those
kind
of
use
cases.
But
I
think
if
the
api
spec
there's
no
reason
that
if
someone
wants
to
implement
it,
they
can
it
just
yeah.
We
won't
provide
a
reference
implementation,
probably.
A
D
One
of
the
comments
that
I
left-
I
was
talking
with
joe
about
this.
A
little
bit
was.
D
What
do
you
think
about?
I
left
this
comment,
the
rc,
but
what
do
you
think
about
name
spacing
with
not
just
v1
but
like
api,
so
in
theory,
like
registry.buildpax
io
could
be
where
the
front
end?
Oh,
I.
G
Saw
that
yeah,
I
think
we
should
do
that.
I
don't
think
that's
part
of
the
specification,
though
that's
just
that,
like
that's
just
an
extended,
not
host
but
like
the
prefix
yeah
like
if
somebody
else
wants
to
stand
up,
acme
co,
slash
v1
like
that.
Doesn't
I
wouldn't
say
that's
like
that.
That
would
break
right.
D
D
D
Cut
like,
if
you
want
to
do
what
joe's
saying
I
think
you
should
cut
out.
Probably
the
host
name,
kind
of
thing
like
npm
or
gems,
does
in
the
content
description
just
so
it's
clear.
G
A
G
Yeah,
I
agree
with
that.
We
can
still
do
that,
though
we
do
this
exact
thing
in
the
heroku
documentation
and
there's
there's
a
clever
thing
where
it's
I
don't
know
it's
called
out
in
a
way
we
can.
We
can
figure
out
a
way
to
do
that.
I
think.
D
I
mean,
I
think,
it's
more
important,
probably
the
documentation
more
than
the
rc
to
get
that
right,
because
I
feel
like
some
like
joe
saying
some
of
that's
implementation
detail
and
some
of
those
things
may
change
right
of
like
some
hosts
or
whatever,
like
the
url
that
we
described
may
or
may
not
work
exactly.
It
may
be
a
slightly
different
url
yeah.
D
Have
you
thought,
like
you're,
sharing
a
screen
right
of
the
remain
here?
Have
you
thought
about
accept
header
stuff?
If
that's
a
thing
you
want
to
have
as
part
of
the
api.
D
E
C
D
The
only
other
thing
for
me
was
just
the
it's
probably
not
even
super
important
was
just
the
future
works
comment.
Emily
made
about
the
matches
being
split
out
the
query
things
yeah.
E
Did
we
do
you
thinking
that
we
want
to
support
both
matches
and
the
finer
grains
fields
themselves
kind
of
like
have
a
an,
or
would
they
be
like
an
org
together
like
matches?
And
if
someone,
if
someone
uses
matches
as
a
great
parameter
and
name
space,
which
is
ns
with
basically
the
that
be
like
org
together,
like
anything
that
follows,
matches
or
name
space
would
be
part
of
the
results.
E
Okay,
it's
like
think
of
and
between
all
the
other
specific
fields
like
you
had
in
ns
and
name
that
those
would
be
handed
together.
D
What's
that
yeah,
I
think
it's
the
idea
that
if
you
do
a
field,
I
think
emily
said
it's
an
exact
match
so,
like
you
could
say,
ns
equals
like
the
heroic
or
potential.
D
E
D
E
A
E
D
Yeah,
it's
outstanding.
Do
you
like
current
rfc,
but
you
know
there's
a
comment
on
it
in
the
future
work.
So
it'd
just
be
nice
to
get
your
thoughts
on
that,
not
that
it's
like
a
blocking
thing
for
this
one.
E
C
G
This
as
part
of
the
stuff
we're
talking
about
in
the
response
payload
with
the
latest
there's
a
few
fields
that
don't
exist
in
buildback
tunnel,
so
I
just
created
an
rfc
to
add
those.
G
The
three
I
added
a
third
one,
if
you,
since
most
of
you,
looked
at
it
that
terence
recommended
our
description,
which
is
a
free
text,
field
licenses
which
has
the
same
schema
as
buildpacktoml
and
then
keywords,
which
is
an
array
of
strings
I'll,
skip
down
to
the
spec
changes.
This
is
what
it
would
look
like.
G
I
think
I
said
bill
pacquiao
earlier
licenses
and
project
tunnels,
maybe
what
I
meant
but
yeah.
This
is
what
it
would
look
like,
and
then
these
would
be
used
by
the
registry
and
then
we'd
store
them
in
the
backing
database.
That
we've
been
talking
about
and
they'd,
be
searchable.
Description
and
keywords
would
be
searchable.
D
G
Yeah
alternatives
are
worth
talking
about.
This
does
not
have
to
go
in
buildpacktomo.
G
We
can
put
it
somewhere
else,
put
it
in
packagetomo,
because
we're
only
going
to
process
this
stuff
after
it
becomes
a
build
package.
Since
the
registry
only
supports
build
packages
or
we're
going
to
just
decouple
it
completely,
we
could,
you
know,
put
like
a
puts
endpoint
on
the
search
api
that
lets
you
put
a
description
or
something
like
that
sounds
like
a
huge
pain
in
the
butt,
because
we'd
have
to
do
off,
but
it's
definitely
a
thing,
that's
possible.
G
We
can
put
it
in
the
index,
so
a
few
alternatives
like
that,
but
I'm
definitely
proposing
build
pack
tunnel
and
terence
made
a
good
point
for
what
the
licenses
should
be,
because
I
could
change
between
versions.
I.
A
Definitely
feel
like,
like
I
was
going
to
create
an
rfc
to
put
a
description
field
on
bill,
peck
tumble
for
reasons
that
had
nothing
to
do
with
the
registry
anyways
right
for
inspectors.
I
think
it
makes
a
lot
of
sense
and
it's
consistent.
I
don't
see
any
reason
why
builders
have
a
description
but
build
packs.
Don't
it's
just
as
useful
in
inspect
build
pack,
as
it
is
an
inspect
builder,.
D
Yeah,
I
think
the
big
advantage
out
from
the
alternatives,
too,
is
that
similar
to
other
package
indexes
it's
a
way
you
can
update.
You
can
just
publish
a
new
bill
pack
to
update
the
description
right
like
we
don't
have
to
have
a
separate
mechanism
for
doing.
D
G
Right
yep
emily,
were
you
suggesting
or
asking
if
this
should
be
in
metadata,
as
opposed
to
the
build
packs
table
in
this
comment.
A
G
So
so
what
I
was
calling
out
here
by
calling
it
non-machine
readable,
which
isn't
totally
accurate,
is
that
the
values
don't
change
like
nothing
in
the
machine
changes
because
of
the
value
of
these
these
keys,
whereas,
like
version,
you
know,
there's
implications
there.
The
id
even
gets
parsed
like
you
know,
there's
all
sorts
of
things
that
that
mean
something
but
like
description
and
keywords,
wouldn't
change
some
behavior.
So
I
it
may
even
be
like
irrelevant
name.
G
I
forgot
about
name
which
actually
wonder
if
we
should
deprecate
name
or
change
it
to
title
or
something
because
we've
been
using
the
second
part
of
the
id,
as
name
a
lot,
and
that
could
get
confusing
to
anybody
that
digs
into
the
implementation
of
this.
G
G
Yeah,
it's
a
subset
of
the
id
if
it's
properly
formatted
and
I
those
two
can
coexist
like
it's
strictly
a
like
at
the
end
of
the
day,
the
only
place
they
collide
is
in
a
database
table
that
isn't
even
specked
out,
but
I
think
for
anybody
that
actually
was
like
digging
into
our
spec
and
some
of
the
implementation
of
the
registry.
They'd
get
really
confused.
D
A
G
B
I
don't
know
if,
if
that's
the
like
to
me
name
and
the
build
pack
tamil
is
pretty
much
what
I
think
of
as
human
readable
name.
I
don't
in
any
way
associate
it
with
the
id
right,
and
so
I
think
the
only
conflict
comes
when
we're
talking
about
the
registry,
and
so
I
do
wonder
if
the
rename
really
makes
more
sense
to
be
there
right.
G
Yeah,
but
that's
hard,
it's
like
literally
the
only
reason
it's
hard
well,
I
kind
of
agree
with
you,
though,.
G
C
B
G
Alternatives
to
me,
the
reason
that
would
be
challenging
is
that
it
would
be
a
big
refactor,
like
you
know,
tons
of
tiny
little
changes
in
pack
and
then
the
registry,
and
it
would
just
be
a
huge
pain
in
the
butt,
but
I'm
not
ruling
it
out.
I
feel
like.
G
G
It
out
of
this
yeah,
let's
punt
it
and
it'll,
definitely
be
in
my
mind,
because
I've
been
aware
of
this.
I've
just
been
dreading
it
so.
D
C
A
D
C
D
Yeah
we'll
take
that
on.
I
guess
that's
a
core
team
to
have
a
formal.
D
C
G
That's
it
for
this
one
then
take
a
look
at
it.
I
don't
think
it's
urgent.
We
can
definitely
do
it
like
it
doesn't
block
the
search
api,
but
I
think
we'd
want
to
do
it
before
we
like
launched
it.
A
G
Well,
no,
I
so
I
kind
of
like
id.
The
thing
is
the
namespace
and
name
aren't
really
exposed
to
like
90
plus
percent
of
end
users
right
for
them.
It's
just
an
id
that's
or
like
in
the
same
way
that,
like
what
you're
talking
about
with
ref
and
all
those
all
those
like
terms
are
terms
that
people
who
use
the
go
container
registry
apis
need
to
understand,
but,
like
average
developer
who's
like
building
a
container
and
shipping
it.
G
G
I
think
we
need
to
like
name
those
in
a
way
that
is,
you
know,
super
careful
about
their
meaning,
like,
I
think,
the
the
further
out
part
of
it
where
the
id
is
and
then
where
the
name
is
and
the
and
the
bill
pack
tom
will
matter
more.
G
B
G
Food
I'll
wrap
that
one
up,
probably
in
the
early
part
next
year,.