►
From YouTube: Working Group: 2020-12-09
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
Okay,
if
you
have
not
please
sign
in
to
the
document.
B
Sure
yeah
I
just
I
was
on
a
different
team
in
in
heroku.
I
was
in
the
web
services
team
working
on
api
and
related
components,
and
just
last.
B
So
just
new
and
trying
to
make
sense
of
everything.
C
Jason's
working
with
jesse
and
travis
those
folks.
D
D
A
Cool-
I
don't
see
david
here
so
I'll
speak
on
behalf
of
pack.
I
know
we
had
during
our
sub
team
sync.
We
talked
about
potentially
pushing
back
the
release
date
based
on
the
holidays
and
a
lot
of
vacations
going
on.
We
are
going
to
aim
for
having
a
rc
candidate
beforehand,
just
in
case
there
is
any
sort
of
testing
that
we'd
like
to
do
before
the
holidays,
but
yeah
more
to
come
on
those
specific
dates
most
likely
next
week.
A
A
E
Yeah,
I
do
request
that,
since
it
was
a
lot
of
usual
suspects,
commenting
on
that,
if
you
are
satisfied
making
sure
that
you
resolve
the
conversations,
so
it
clears
things
out
a
little
bit
makes
it
a
little
easier
to
figure
out
what's
outstanding.
A
Okay,
moving
on
create
stackify
repo
is
this.
A
A
C
E
B
C
B
A
All
right,
let's
see
application
mix-ins
what
is
happening
with
this
one.
A
Parked
right
now:
okay,
so
this
one's
on
hold,
do
we
have
a
label
for
that,
or
should
we
should.
B
B
H
Reached
out
okay,
this
week
to
I
believe
his
name
is
yeah,
it's
josh
josh
and
he
said
he
was
gonna
circle
back
with
his
team
and
figure
out
whether
they
want
to
keep
it
open
or
updated.
So
maybe
later
this
week,
they'll
have
an
update,
but
I
think
we
just
leave
it
parked
for
now
and
it's
there
next
week
we
can
put
it
back
in
draft
or
something.
H
Paul,
okay,
he
reached
out
on
the
slack
after
paul.
You
know
left
his
current
or
his
other
place.
B
Yeah,
so
I'm
hoping
that
people
feel
like
they
can
vote
on
this.
I
think
that
there's
been
some
consensus.
That's
been
established
about
how
this
should
work.
D
A
Great
looks
like
we'll
get
that
in
soon
all
right,
let's
see
now
that
we're
done
with
all
our
outstanding
rfcs,
we
can
move
on
to
calendar
updates.
Who
wants
to
take
that
one
on.
E
Oh
sorry
yeah,
I
forgot
I
just
typed
in
didn't
put
my
name
in
so
I
wanted
to
let
everyone
know
you
may
have
if
you
are
actually
subscribed
directly
to
the
calendar,
invite
we
have
cancelled
all
of
the
meetings,
leadership,
meetings
and
working
group
meetings,
and
I
think
javier
is
also
going
to
do
the
sub
team
meetings
for
the
weeks
of
december
21st
and
december
28th.
So
we
expect
next
week
to
be
the
last
set
and
then
we'll
take
two
weeks
off
and
then
reconvene
at
the
beginning
of
january.
E
Is
given
the
leadership
meeting
we
just
completed
in
the
hour
before
this
one?
I
am
pleased
to
announce
that
we
have
a
new
implementation.
Maintainer,
congratulations!
Natalie
on
your.
D
I'm
excited
natalie
has
been
a
invaluable
contributor
to
the
lifecycle
for
some
time
now,
driving
forward
a
lot
of
our
new
work
and
being
heavily
involved
in
giving
feedback
on
all
the
work
coming
in
and
also
writing
rfcs
to
help
us
improve
it
in
the
future.
So
well.
Well,.
F
Ready,
I
can
share
my
screen.
There
are
a
lot
of
outstanding
comments
that
took
me
a
while
to
get
to,
but
I
think
I
addressed
all
of
them.
I
probably
should
not
have
clicked
the
resolve
button.
That
was
my
bed,
but
there
most.
There
are
a
couple
of
comments
that
I
got
since
then
seemed
more
about
semantics.
C
Yeah
mine
are
super
bike
sheddy,
but-
and
I
wouldn't
probably
block
on
that,
but
I
did
want
to
bring
them
up.
Yeah.
F
I
definitely
think
they
were
good
comments,
but
I
added
I
guess.
The
biggest
thing
is
adding
this
proposed
interface,
so
this
was
and
then
also
adding
the
pack
create
stack
command.
B
F
So
the
interface
for
a
stack
by
itself,
it's
just
a
bunch
of
command
line
inputs
that
you
could
pass
in,
but
then
the
pack
creates
that
command
following
convention
was.
That
would
have
this
tamil
file
where
you
could
set
all
the
mixins.
You
want
to
put
on
your
images,
the
ca
certs
packages,
user
group,
all
that
stuff
yeah.
I
don't
know
if
there's
any
more
comments.
People
have
on
this.
C
I
thought
it
looked
good
in
general,
I
the
camel
case
just
sort
of
caught
my
eye,
but
I
couldn't
actually
find
any
other
case
of
where
we
have
more
than
one
word
in
a
tamil
file.
So
there
was
no
prior
art
happy
to
change.
D
B
C
I
guess
it's,
oh,
I
guess
it's
in
the
file
and
in
the
flag
right,
but
yeah,
the
all
it
won't
actually
install
the
mix
and
it'll
only
like
add
the
label
like
these
are
like
pre-existing,
mix-ins
right
yeah.
I.
F
A
I
am
curious
why
we
need
the
key
the
the
phase
key
like.
Is
that
not
part
of
the
pre-known
notation
of
the
prefix.
B
A
F
Yeah,
so
this
is
for,
for
the
pack
creates
that
command.
This
is
assuming
that
you
would
that
under
the
hood
pack
would
call
stackify
once
for
each
image
and
so
in
the
tunnel
file.
We
need
to
know
which
image
to
put
which
package
on
or
which
makes
it
on
so
this
would
say,
tell
pack
to
run
stackify
on
the
build
image
with
this
mix
in,
whereas
on
the
run
image
run
with
fix,
miss
this
mix.
In
in
case,
you
wanted
to
differentiate
between
mix-ins
and
packages
based
on
your
image,
based
on
which
image.
D
But
couldn't
that
javier
is
calling
sorry
go
ahead.
Sorry,
it's
okay!
I
didn't
mean
to
jump
in.
I
think
you're
probably
about
to
say
the
same
thing
I
think
in
the
mix
and
name
if
it
starts
with
run
colon.
That
would
mean
just
do
it
on
the
wrong
image
already.
So
we
might
not
need
a
a
separate
field
for
phase
here.
F
G
F
A
F
From
nixon's
mixins,
which,
as
joe
pointed
out,
we
should
change
that
to
mix
and
labels.
The
mixed
in
labels
would
just
be
metadata
to
add,
whereas
packages
would
be
new
packages
to
actually
install
on
the
images.
D
F
A
Yet
another
option
is
like
I
see
the
ca.
Certs
have
like
a
ca
search
that
build
right
instead
of
having
this
additional
key
for
each
package.
What
if
you
kind
of
group
them
together
in
that
array
right
so
packages.build
and
you
know
fortune
would
be
there
and
whatever
other
else
and
then
packages.run
yeah.
H
B
F
H
Just
a
suggestion,
I
don't
have
a
hard
I
already
approve
on
it.
From
my
perspective,.
H
H
A
I
mean
I
am
curious,
like
to
maybe
lean
on
to
joe's
point
what,
if
everything
was
either
packages
or
mix-ins
and
then
because,
like
we,
have
that
notation
right
and
all
these
packages,
if
I'm
not
mistaken,
we'll
also
end
up
creating
in
labels
from
them
right
so
you'll
have
a
cow
say,
mix
in
applied
to
the.
F
F
F
A
C
I
I
had
a
lot
of
good
feedback
from
everybody,
so
thank
you
for
that.
I
really
appreciate
it.
I
did
make
some
changes
that
I
just
wanted
to
quickly
highlight,
and
hopefully
I
you
know
get
this
into
a
state
where
it's
ready
for
voting,
which
I
think
it's
pretty
close,
but
the
things
I
wanted
to
mention
were
that
I
did
make
some
adjustments
and
changes
to
the
endpoint
first,
of
which
I
simplified
the
actual
search
endpoint
to
just
be
search
with
a
query
parameter.
I
In
addition
to
that,
I
also
simplified
the
high
level
metadata
that
gets
returned
from
such
a
query
to
just
include
namespace
name
version
and
then
the
address-
and
I
also
introduced
this
object
called
versions,
and
I
made
it
an
object
just
because
I
wanted
to
make
it
more
flexible
too.
In
case
I
ever
wanted
to
add
any
higher
level
metadata
to
this
data
structure,
but
as
you
can
see,
it's
keyed
off
of
the
actual
version
and
then
there's
a
helper
link
that
will
take
you
to
that
specific.
I
I
This
endpoint,
as
it
shows,
will
be
a
namespace
and
name-
and
I
know
joe
had
mentioned
escaping
this
and
just
making
it
the
whole
escape
thing.
The
actual
idea
itself
yeah.
C
I
C
Yeah
the
reason
I
suggested
that
is,
we
did
it
in
the
v2
build
pack
registry
for
heroku.
We
did
that
so
that
you
could
specify
either
a
uuid
or
the
namespace
name,
and
if
you
use
a
real
slash
that
that's
really
difficult,
if
not
impossible,
to
figure
out
which,
like
is
your
uuid
a
namespace
or
you
know
like
right
now.
This
api
is
simple
enough
that
we
could
do
that,
but
yeah
you
know
in
the
future.
Do
we
do
we
want
to
future
proof
it?
C
I
I
don't
know
I'm
a
big
fan
of
using
a
real
slash
because
it
kind
of
feels
very
natural,
but
I
just
have
a
small
concern
about
that.
B
I
I
C
B
C
A
I
mean
I
thought
the
whole
reason
why
we
had
the
id
contain
a
slash
is
because
we
were
thinking
about
how
they
would
be
structured
in
an
org
fashion
right,
and
so
I
feel
like
by
now
making
it
into
this
like
encoded
version.
It's
like
might
as
well
have
not
done
that
and
done
something
different
with
the
ids.
Well,.
C
It's
still
so
no,
it
still
is
valuable,
for
example,
in
the
build
pack
uris
right
like
we
would
not
encode
it
there
if
you're
using
like
cmb
colon,
slash,
slash
or
urn
colon
registry
or
whatever,
so
it's
still,
I
think
it's
still
is
good
there.
It's
just
in
this
particular
case
we're
trying
to
create
a
restful,
get
post
api
where
it
gets
a
little.
It
gets
a
little
challenging.
A
I
G
For
the
search
api
for
inputs,
are
there
other
params?
Besides
query
like?
Can
you
say
I
just
want
namespace
equal
to
picato
like
like
you
can
imagine.
Maybe
someone
like
I
know
for
the
road
case.
You
won't.
I
E
G
I
So
right
now
you
just
use
query
because
the
current
implementation
is
indexing.
Basically,
all
these
metadata
fields,
namespace
name
and
address,
I
believe,
are
the
three.
So
it
would
just
search
whatever
that
query
is
set
to
against
those
three.
But
if
we
wanted
to
expose
like
some
of
these,
you
know
metadata
fields
in
the
form
of
additional
queries.
We
could
do
that,
like
I
don't
have
a
strong
opinion
at
this
point.
B
I
Yeah,
so
there's
definitely
some
flexibility
here
but
yeah
for
now,
I'm
just
making
it
just
pretty
simple.
C
Yeah
I
mean
it's,
I
I'm
not
a
I'm,
not
I
don't
feel
too
strongly
one
way
or
the
other.
I
just
want
to
be
really
explicit
about
what
the
implications
are,
and
the
implication
is
that
we
can
never
have
a
uuid
unless
we
have
a
different
path,
completely
different
path.
Maybe
that's!
Okay.
I
like
this
is
not
a
critical
part
of
the
spec
or
anything
like
that.
C
G
Are
you
going
to
do
versioning
at
all?
I
think
I
asked
that
in
a
question
on
the
api.
C
I
I
So
my
thought
behind
this
is
have
a
more
generalized
view
into
a
particular
build
pack.
And
then,
if
you
wanted
to
look
at
a
specific
version,
you
can
use
the
version
endpoint
right
here
and
then
we
would
add,
you
know,
provide
those
additional
metadata
fields
like
the
license.
I
The
description,
I
think
it
was
emily
that
mentioned
that
these
two
things
could
theoretically
change
between
different
versions
of
the
build
pack.
So
to
me
it
seemed
like
it
made
more
sense
to
tie
these
to
a
particular
version
like
in
this
case.
You
know
zero.
Four
one
has
this
license.
That
has
this
description
and
then
zero.
Four
two
could
be
something
different,
instead
of
assuming
that
it
will
never
change
and
lock
that
data
at
the
higher
level.
A
A
A
And,
and
if
you
look
at
my
comment,
I
just
like
put
it
under
like
a
latest
key
just
so
that
it's
like
nicely.
I
don't
know.
I
A
B
A
G
A
C
But
I
is
it.
C
E
C
You
mean,
including
in
the
version
yeah
route,
okay,.
E
C
E
We
we
are
trying
to
protect
this,
like
even
in
a
cold
cash
situation
like
assume
for
a
moment
that
we
don't
put
a
database
behind
it.
We
want
to
do
true.
Caching,
like
the
goal
is
to
put
all
of
anything
that
needs
to
be
returned
here,
needs
to
be
in
the
metadata
for
the
like
in
the
the
manifest
right
of
the
image
itself,
not
as
data
inside
of
the
image,
so
I
think
it
will
perform
anyway.
E
But
hey
you
know,
network
problems
are
network
problems,
so
maybe
we
don't
you
know
we
do
want
to
keep
a
cache
to
to
sort
of
sort
that
out,
but
I
think
we
should
return
it
at
all
times
and
it's
on
the
services
level
of
responsibility
to
make
sure
it
can
respond
in
a
timely
manner.
C
Yeah
that
that
makes
sense,
I
guess,
what
about
cold
cold
cash
case,
where
we're
hitting
like
api
limits
on
docker
hub.
Are
we
assuming
that,
whatever
back
end,
we
need
whatever
back
ends?
We
need
to
hit
to
get
that
information.
We
can
have
unlimited
access
to.
D
D
D
E
I
argue
that
we
absolutely
do
for
like
we're
talking
about
the
search
api
here,
but
imagine
the
gui
that
sits
in
front
of
it
and
then
think
about
what
the
gui
for
npm
looks
like
right
nobody's
skipping
listing
what
the
license
is
of
a
particular
module.
Like
that's
got
to
be
a
thing.
G
G
G
I
mean
I,
I
guess,
there's
like
there's
lots
of
material
out
there
about
api
design.
Like
I
mean
that's,
why
I
think
like
graphql
and
json
api
and
things
exist,
because
I
think
sometimes
you
want
to
leave
it
to
the
end
user
if
they
actually
want
to
include
that
data.
G
G
A
I
We
can-
and
I
know
you
had
some
comments
in
the
rfc
that
I
have
had
a
chance
to
look
at
today.
Obviously
so
sorry,
if
I
don't
have.
I
A
Definitely
didn't
put
that
comment
about
the
search
field
or
yeah.
So
if
you
go
down,
there's
some
search
fields
and
it
mentions
that
it'll
search
through
license
and
yanked,
and
I
was
confused
about
that
like
how
does
why
would
the
query
search
for
yanked?
Am
I
typing
in
true
or
false
into
the
query.
I
Yeah,
it's
kind
of
weird
right
now,
because
I
I
kind
of
don't
think
yank
is
I
don't.
I
don't
really
know
if
it
is,
as
it
is.
Primitively
like
right
now
like
a
very
user-friendly
field,
but
my
intention
is
to
have
the
ability
just
to
search
via
the
search
query
like
if
you
know
for
all
the
yanked
files
or
non
yank
files.
I
I
don't
know
if
I
go
back
and
forth
and
I
honestly
don't
know
if
it's
going
to
be
useful
or
not
to
have
the
ability
to
search
for
yanked
and
non-yanked
or
supported
unsupported
bill
packs.
So
I
could.
I
could
go
either
way,
but
that's
kind
of
where
I
was
going
down
with
that
going
down
the
road
with
that.
A
A
I
I
Yeah
but,
like
I
feel
like
yank,
is
kind
of
weird,
because
I
personally
didn't
I've
never
referred
to
things
as
yanked
or
unyanked
until
I
started
working
on
this
stuff,
I
always
think
of
supported
and
unsupported,
and
I
don't
know
if
it's
just
my
lack
of
exposure
to
the
yanked
term.
I
E
E
I
Exactly
that's
kind
of
what
I
was
wondering
like
say:
I'm
using
a
build
pack
and
I
suspect
there
might
be
something
wrong
with
it.
Well,
let
me
check
if
something
is
wrong
with
it.
After
the
fact
and
oh
I
shouldn't
be
using
this
one,
it's
been
yanked,
I'm
going
to
upgrade
to
a
newer
version.
Now
you
know.
A
So
I
do
wonder
for
the
search
fields
for
the
purpose
of
querying
right.
If
yeah
from
the
get
go,
namespace
and
name
are
sufficient.
A
I
I
A
I
mean
just
to
solve
it
for
now
and
get
it
through
right,
like
I
feel
like.
Maybe
we
might
want
to
have
more
discussion,
but
I
just
feel
like
yeah,
true
or
false,
as
a
query
parameter
to
go
to
this
very
specific
field
is
just
awkward
like
you
know.
This
is
the
true
php
build
pack
right,
all
of
a
sudden,
it's
yanked,
but
it
comes
back.
As
you
know,
in
the
search
field,
it
just
doesn't
seem
intuitive.
A
Maybe
we
should
call
it
text
instead
of
queries
to
make
it
or
unless
we're
going
to
do
a
query
language
right,
like
github,
where
they
have
like
it,
would
be
like
yanked,
colon,
true
or.
I
I
Sounds
good,
in
addition,
really,
the
only
thing
I
just
wanted
to
shout
out
about
was
that
I
did
remove
metrics
related
items.
Just
I
feel,
like
that's
a
whole,
separate
discussion
that
I
wanted
it
to
be
outside
of
this
rfc.
I
And
yeah:
that's
that's,
probably
the
big
one
that
I've
removed
those
out.
So
I
will
fold
into
this
the
discussions
that
we've
just
had
and
throw
it
out
there
again,
it's
maybe
tomorrow
or
some
other
time.
A
C
D
D
About
these
the
word
user
space,
I
wonder
if
we
before
we
merge
this
rfc.
We
want
to
come
up
with
a
different
word
for
that,
because
I
think
it
has
yeah.
D
Like
I
have
like
a
great
other
selection,
I
feel
like
it
just
this
thing.
I
thought
about
the
first
time,
but
then
sort
of
put
it
back
in
my
mind,
because
it
wasn't
material
to
like
the
actual
design
discussions
we
were
having,
but
I
think
it
does
have
a
pretty
concrete
technical,
meaning
that
might
be
misleading.
C
Yeah,
I
think,
that's
fair.
I
think
I
was
when
I
used
the
term.
I
was
thinking
of
it
in
the
sense
of
like
customer
space,
but
I
don't
think
that
works
either.
I
C
D
The
thing
we
used
to
call
build
pack
in
this
rfc.
It
introduces
a
more
specific
term.
That's
like
user
space
build
pack,
but
I
feel
like
user
space
is
generally
used
to
distinguish
from
kernel
space
and
the
place
they
run
is
rude
or
still
running
in
user
space.
Right
like
where
it's
a
user.
So
I
worry
that
it's
like
a
little
bit.
B
D
I
don't
have
another
great
word
for
it.
I've
had
to
think
of
one
like
in
the
past,
thinking
about
the
distinction
between
what
we
just
called
build
packs
and
order
build
packs
or
metabolic
packs.
I
wanted
to
do
component
and
composite
build
packs,
but
stack
build
packs
are
still
component
build
packs,
but
maybe
like
maybe
that's.
Okay
like
we
can
just
decide
that
component
build
packs.
Just
refers
to
regular,
build
packs.
I
kind
of
like
that
one.
C
C
Yeah
there's
a
lot
of
language
in
the
spec
that
needed
like
actually
more
that
I
realized
that
needed
to
be
qualified
with.
At
the
time
I
was
using
user
space.
B
D
C
All
right
I'll
think
on
it
a
bit
probably
just
to
just
think
about
it
after
this
meeting
and
then
I'll
make
an
update
and
I'll.
Let
you
know
when
it's
when
it's
there
yeah
my
hope
is
to
spend
some
time
working
on
both
the
spec
and
then
potentially
get
started,
bringing
that
poc
back
into
implementation
over
the
break.
So
it'd
be
great.
If
we
can
wrap
some
of
this
up
before
the
end
of
the
year.