►
From YouTube: Working Group: 2021-01-28
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
So
everybody
signed
in
no
we're
missing
one
person.
Still
I
already
sign
and
sign
in,
and
I
don't
think
we
have
any
new
faces
anything
anybody
want
to
talk
about
today.
A
A
We're
talking
a
little
bit
about
you
know:
how
could
we
add
more
flexibility
there
and
one
idea
I
had
was:
could
we
use
domain
make?
Could
we
make
project
tamil,
like
like
docker
labels,
where
you
can
have
any
fields
you
want
on
it
nothing's
reserved,
except
if
they're
they
match
domains
and
then
configuration
you
know
could
go
into
each
of
those
things.
So
if
there's
an
idea
there,
we
could
expand
out
on
like
reserve
format
as
opposed
to
reserved
you
know,
individually
reserved
keys
and
let
the
the
top
level
vary.
C
Yeah
terence
had
showed
me
that
I
think
it
makes
a
lot
of
sense.
The
aesthetics
could
be
better,
but
I'm
you
know
once
it
was
in
use.
I
wonder
if
that
would
if
it
would
feel
that
way.
You
know
like
I
don't
like
like
when
I
use
maven
artifacts.
I
don't
really
think
about
the
aesthetics
of
the
group
id.
You
know
it's
just
what
it's
just
what
it
is,
so
that
I
I
wonder
if
it's
just
me
being
picky.
B
I
do
think
the
aesthetics
are
better
too,
if
it's
generated,
like
you
care
less
about
it
being
ugly.
If
you
don't
have
to
write
it.
C
A
I
think
we
either
have
to
do
that
right,
reverse
domain
and
then
exactly
like
have
a
comm
table
and
then,
but
you
don't
have
to
specify
the
com
table,
it'll
automatically
get
created,
so
you
could
still
do
quote:
com,
dot,
heroku
or
whatever
you
know
on
or
bracket
on
bracket
right
or
if
we
did
domains.
We
could
still
just
do
full
domains,
but
you
have
to
quote
the
key
in
the
table
so
be
like
bracket
quote:
buildpacks.io
quote
bracket
and
that
seems
pretty
gross.
A
D
C
Yeah
yeah,
that
makes
sense.
I
mean
I'm
fine
with
reverse
again.
Don't
I
don't
know
if
that's
my
lineage,
you
know
with
maven
and
everything.
C
B
Well,
I
think
like.
Basically,
if
you
have
like
a
sub
a
sub
domain,
like
you
imagine
com.heroku.some
right,
it
means
that
if
we
didn't
quote
it
right
like
you
would
have
com
as
a
group,
I
guess
which
whatever
then
you
could
have
multiple
different
other
companies
or
things
under
tom.
That
would
make
sense,
but
then
roku
would
be
in
its
own
table,
but
then,
like
you,
had,
then
another
sub
thing
like
whatever
like
that,
would
still
be
under
the
heroku
table
there,
whereas
if
you
inversed
it
like
it,
wouldn't
work
that
way.
Yeah.
C
E
Is
there
a
reason
to
be,
I
guess,
subjective,
to
domains
versus
just
namespaces
arbitrary
namespaces,
like
heroku
or
salesforce,
and
then
being
able
to
have
nested
namespaces
spaces
domains.
E
C
There
is
some
amount
of
validation
like
I
don't
know
if
they
actually
like
check
who
owns
that
domain,
but
like,
for
example,
if
you,
if
you
have
a
github
account,
you
can
register
com.gethubs.yourname
your
username
and
they
do.
They
actually
verify
that.
That's
your
user
on
github.
A
A
So
if
I,
if
I
say
I
I
define
com.docker.you,
know
whatever
key
to
be
this,
but
I'm
I'm
not
actually
docker
right
nobody's
going
to
agree
to
interoperate
with
that
key,
because
they're
going
to
say
that
they
broke
the
rule,
they're
not
supposed
to
declare
keys
under
com.docker
right,
but
but
if
I,
if,
if
as
a
project,
we
say
io.bilpex.whatever
means
this
right
and
that's
published
on
buildpacks.io
that
everybody
knows
yes,
that
is
something
I
can
rely
on
for
interoperability
and
it's
nice
because
generally
contracts
are
published
on
the
domains
that
match
their
key
names.
B
I
think
it
also
makes
it
so.
The
one
thing
I
dislike
is
just
how
verbose
it
is.
I
think
that's
just
it's
just
extra
reviews,
but
the
benefit
is
that
it
also
means
that,
because
it's
verbose
like
conflict
like
name
space
conflict,
will
be
sniffing
less
common
or
almost
non-inconsistent
right,
like
no
one's
going
to
reserve
a
key
that
is
calmed
at
heroku
like
under
their
global
namespace,
unless
they,
but
like
someone,
you
can
imagine
someone
potentially
think
that
they
might
like
do
a
thing
that
maybe.
A
B
Okay,
sorry,
could
you
hear
me,
have
you
does
that
make
sense.
E
D
I
think
I'm
trying
to
understand
like
what
this
gets
us
that's
different
from
having
like
a
platforms
table
that
people
can
reserve
keys
underlying
platform.heroku
because
it
just
seems
like
that.
Semantically
is
less,
I
mean
aesthetically,
not
semantically,
it's
just
more
pleasing
and
it
makes
sense.
Semantically.
C
I'm
not
sure
it's
aesthetically
more
pleasing,
but
it
definitely
demotes
those
like
vendor-specific
keys
to
sort
of
a
second
class
thing,
and
I
think
what
terence
is
really
after
is
that
first
class
feel
to
the
com.heroku
or
whatever.
It
is
because.
D
A
B
B
A
A
That's
not
a
domain
is,
is
valid
to
define
right,
and
so
you
know
you
you
could
define
it,
you
get
less
strong
guarantees
and
less
interoperability,
but
you
could
throw
whatever
you
want
at
the
top
level
right
and
it
would
be
okay,
just
like
you,
you
know
people
regularly
throw
labels
on
docker
images
that
don't
follow
the
reverse
domain.
Name
notation.
You
know
when
when
they
want
to
it's
only
bad,
if
you
do
that
with
docker.
C
The
other
thing
I
like
about
this
that
it's
especially
as
compared
to
like
the
platform
table,
is
that
it
really
lets
it
sit
outside
of
the
build
packs
concept
like
I
could
totally
imagine
a
project
tommel
with
a.
C
I
don't
know
some
terraform
key
that
just
has
a
bunch
of
stuff
that
has
nothing
to
do
with
build
packs,
and
maybe
you
don't
even
have
build
pack
stuff
in
there,
but
it
seems
like
the
original
idea
was
that
it
could
do
that.
I
don't
know.
Maybe
that
ship
sailed.
Maybe
that's
not
realistic,
but
it
definitely
aligns
with
that.
A
The
advantage
of
the
reverse
domain
notation
is
that
the
underlying
keys
under
a
domain
could,
at
your
discretion,
be
subdomains
or
just
properties
right,
and
so,
as
terence
was
saying,
with
the
versioning
right,
you
could
define
a
subversion
of
any
you
know
kind
of
at
any
table
along
the
lines.
So,
if
you
had
two
large
business
units
within
a
large
company,
they
could
you
know,
do
com.example
dot
business
unit
one
and
have
a
schema
there,
that's
separate
from
com.example.businessunit2
right,
so
it
feels
extensible
in
a
very
generic
way.
A
B
B
D
D
It's
like
a
little
bit
cumbersome
and
ugly
right
to
put,
I
hope,
built
back
in
front
of
everything,
but
I'm
sure
once
I
started
doing
it,
I
would
get
used
to
it
my
mind
if,
like
the
big
decision
is
like,
are
we
trying
to
make
it
the
tunnel
file
to
end
all
tamil
files,
where
everyone
puts
everything
in
there
or
we
like
at
one
point,
we're
talking
going
the
absolute
opposite
direction
and
making
more
like
docker
files?
D
So
it's
very
obvious
that
it
was
like
a
a
marker
when
someone
landed
in
a
repo
like
yes,
this
is
a
build
pack
build.
D
A
I
definitely
agree
that
we
should
move
in
one
of
those
two
directions
right
either
if
we're
going
to
have
platform-specific
stuff
make
this
a
very
generic
thing
right.
I
like
I,
like
the
you
know,
taking
what
docker
did
with
labels
right
in
that
situation
and
like
learning
from
how
other
people
have
done.
Similarly,
generic
things
in
the
past,
but
then,
if
we
go
the
other
other
direction
like
I'd,
really
like
to
not
call
it
project,
tumble
right,
like
build
pack
file,
put
build
pack
specific
stuff
in
it.
Keep
the
schema
very
fixed
one.
A
Fixed
version
of
the
top
right
would
be
my
preference,
but
I
don't
have
a
strong
preference
between
which
way
we
go
actually.
D
Like
if
we
want
to
go
the
generic
way,
I
think
this
makes
sense.
I
do
think
we
leave
something
behind
it's
a
trade-off
right
like
people,
don't
even
know
it's
cool.
If
people
can
know
that
something
is
a
build
pack,
build
sort
of
from
a
marketing
perspective
right.
C
Those
like
named
files
like
dockerfile,
can
they
end
up
littering
the
repository?
It's
like
here's,
your
you
know,
here's
your
file
for
that
technology
and
here's
your
file
for
this
technology,
like
I
kind
of
feel
like
if
we
need
that
to
market
ourselves,
we
should
probably
doing
a
better
job
at
marketing,
but
I
don't.
I
definitely
lean
towards
the
the
generic
side,
but
I
100
agree
with
you
stephen,
I
think
like
we
need
to
sort
of
pick
one.
B
Can
you
do
I
wonder
if,
like
they're
even
like,
I
think
you
can
even
imagine
a
world
where
potentially
it
you
can
support
both
where,
if
there
is
a
bill
pack
file
like
like
we
get
rid
of
project
tamil,
but
project
home
becomes
the
generic
thing,
and
so
you
can
have
a
built
pack
file.
B
That
does
that
and
then,
if
you
don't,
have
a
buildpack
file
in
your
project
tom
and
you
want
all
in
one
file,
you
can
have
like
the
I
o
bill-
packs
kind
of
define
that
schema
or
even
point
to
like
the
bullpec
file
or
something
right
where
it's
like
in
each
of
one
of
these
things.
It
points
to
that
thing.
If
that's
what
you
want.
D
I
think
in
a
lot
of
cases
that
might
be
all
someone
would
need,
but
a
project
tamil
file
could
allow
you
to
specify
that
in
the
same
file
as
other
things,
if
you
wanted,
I.
D
C
Like
you'd
want
that
to
support
other
things
too,
like
docker
file
or
whatever
like
to
me,
that's
just
like
a
strong
indication
that
we
do
want
the
generic
path,
because,
if,
if
we
think
we're
going
to
have
that
pattern
with
some
kind
of
build
pack
file,
then
we
should
design
it
in
a
way
that
it
doesn't
only
work
with
the
build
pack
file
and
also
works
with
whatever
else
you
know.
B
I
guess
that's
kind
of
what
I
was
suggesting
that
I,
I
think
they're
not
necessarily
like
one
or
the
other
like.
I
think
you
could
try
to
do
both
things,
but
not
what
project
tama
looks
like
today.
Right,
like
I
think,
you'd
have
a
version
thing,
and
then
you
could
have
a
project
tamil.
That
is
larger
than
scope.
B
That
could
allow
you
to
either
import
something
like
a
buildpack
file
where,
like
you're
saying
the
schema
is
mostly
the
same
or
if
you
want
to
just
have
one
file,
you
could
just
have
a
thing
that
allows
us
to
do
the
domain
thing.
E
But
then
you
have
a
whole
bunch
of
other
ones
as
well,
and
I
don't
know
it
seems
like
a
very
specific
task
to
try
to
unify
as
many
as
possible
configuration
files
into
one.
C
E
E
Sorry,
I
I
don't
know
if
this
helps
or
makes
it
worse,
but
one
of
the
things
at
least
I
I
believe
I've
brought
up
a
few
times-
is
the
idea
that,
like
right
now,
the
project
tamil
file
is
an
extension
of
the
spec.
But
to
really
like,
I
don't
know,
reap
what
it's
it's
trying
to
provide.
E
That
may
be
right
and
it
could
be
heroku,
it
could
be
the
google
platform
or
any
other
platform,
and
if
they
don't
take
into
consideration
the
project
tamil
found
and
the
things
that
they're
configured
there,
then
you
have
to
like
manually,
go
and
tweak.
So
it's
not
essentially
portable
in
the
same
way
that
we'd
probably
want
it
to
be.
B
Obviously,
I
think
we
put
it
in
extension,
spec,
remember
saying,
because
we
stuff
in
there
like
we
don't
want
to
require
platforms
to
support
it
to
be
basically
cmb
out
of
compliance
right
word
but
like
to
say
you
basically
follow
you.
You
are
a
fully
supported
like
platform
that
follows
cmb,
so
you
want
I
I
remember
we
wanted
to
make
project
tamil
like
optional
at
the
time
when
we
put
it
there.
D
C
I
don't
think
it
has
to,
I
think
I
think
it
may
be
if
it
moves
into
the
life
cycle.
It
needs
to
be
more
than
an
extension,
but
it
could
also
be
its
own.
I
think
it
could
be
its
own
project
right,
like
we
support
many
specifications
life
cycle,
including
like
the
container
registry
spec
right,
so
I
think
ext
like
if
it
goes
into
life.
Life
cycle
extension
is
probably
the
wrong
place
for
it,
but
I
think
there's
more
than
one
option.
D
C
C
Definitely
yeah,
I
think,
there's
desire
from
the
folks
at
google.
I
was
talking
well.
At
least
I
mean
when
you're
talking
to
their
dev
advocacy
folks
a
little
bit
different
from
talking
to
the
engineering
side,
but
you
know
they're
the
ones
that
pushed
their
use
of
app
json,
which
I
was
disappointed
to
find
out.
They
were
keeping
alive,
but
they've
been
using
project
tomml
with
pac
to
do
some
interesting
things,
so
they
may
have
an
appetite.
C
C
I
may
be
happy,
I
don't
know,
I
don't
know
why.
I
I
don't
know
why
I
cared
about
this
thing
in
the
first
place,.
C
I
think
we
can
make
the
decision
about
extension
and
some
things
like
that
later,
the
the
sort
of
best
of
both
worlds
approach
sounds
sounds
like
there's
a
lot
of
appetite
for
that
and
certainly
gives
us
the
option
to
kick
project
onto
the
curb
at
some
point.
If
we
just
don't
use
it
or
or
if
like
heroku
is
using
it
heroku
can
make
it
a
roku
thing.
E
C
B
If
they
actually
have
an
appetite
for
it,
I
think
that
definitely
changes
the
game.
Yeah.
C
I
think
the
thing
is
they're
stuck
on
a
few
things
they
need
like
they
just
peed
me
yesterday
about
the
group
editions
rfc,
which
they
didn't
know.
The
group
editions
rfc
existed,
but
they
wanted
pre
and
post
or
they
didn't
call
it
pre
and
post,
but
they
wanted
that
in
the
project
tamil
because
they
need
like
having
it
on
the
cli
didn't
work.
C
So
I
think,
like
it's
it's
one
of
those
things
where,
until
it
has
until
it's
like
really
fully
featured
that
they'll,
never
like
sink
their
teeth
into
it,
and
I
think
I
suspect
inline
build
packs-
is
a
big
part
of
that
too,
which
I've
just
been
waiting
for
like
to
get
through
prepare
before
implementing
that.
That
thing,
that's
already
been
rfc.
B
Okay,
I
can
take
a
stab
at
I'll,
probably
close,
my
other
rc
and
then
take
a
stab
at
writing
something
up.
I
probably
need
to
also
talk
to
product
people
on
our
end
to
see
how
open
they
are
to
steven's
idea,
because
that
was
not
in
the
original
thing
I
talked
to
them
about.
B
B
E
Cool,
if
we're
done
with
that,
I
did
add
something
else
to
the
agenda.
Maybe
somewhat
related
go
for
it,
so
this
came
up
via
one
of
the
issues
in
pac.
I
believe
where
somebody
was
looking
to
be
able
to
provide
environment
variables
at
runtime
and
to
me
I
feel
like
this
would
there's
an
added
complexity
with
process
types,
but
I
think
it
would
be
reasonable
to
expect
that
you
could
provide
runtime
environment
variables
per
process
type,
and
so
this
seems
very
reasonable.
E
D
I
was
gonna
say
I
definitely
think
I
feel
like
we've
wanted
that
for
some
time
on
the
kettle
side,
we
wrote
a
build
pack
that
does
this,
but
this
in,
like
labels,
are
things
that
we've
written
build
packs
to
support.
I
think
it
makes
sense
to
natively
support
in
the
project.
C
The
tricky
part
about
this
is
that
I
don't
think
we
have
any
concept
of
the
process
types
in
project
tamil,
yet
so
like
well,
I
totally
agree
this
makes
sense
to
have.
I
think,
there's
like
a
tougher
question
about
like
how
do
process
types
fit
in,
and
we've
run
into
this
with
other
things
too,
where
it's
like.
C
Oh,
what
like
should
prostrate
tamil,
be
able
to
support
multiple
images
like
sort
of
like
different
build
configurations
like
I
have
build
packs
for
this
image
and
then
different
set
of
build
packs
for
this
image,
because
it's
a
mono
repo
I
should
like,
should
you
just
simply
be
able
to
define
process
types
in
project
tamil?
Like
that's,
I
feel
like
that's
what
this
sort
of
begs
that
question.
C
D
B
One
thing
I
was
talking
to
david
about
from
this
because
there
was
this
issue
and
then
I
think
there
was
another
one
from
slack
about
wanting
to
do.
I
don't
remember
exactly,
but
something
else
and
almost
wonder
like
essentially,
I
think
what
people
want,
because
of
both
that's
useful,
but
also,
I
think,
a
lot
of
people
also
just
have
potentially
a
background
of
writing
stuff
in
docker
file.
We're
able
to
kind
of
do
all
these
things
that
a
bill
pack
can
that,
I
almost
wonder,
is
inline
bill
pack.
B
The
right
answer
for
salt,
like
we
have
an
api
for
build
packs,
may
not
be
exactly
what
we
want
the
user
experience
to
be,
but
it
seems
like
if
I
just
wrote
an
inline
build
pack
to
do
all
these
things
it
would.
I
can
do
all
the
things
people
are
asking
right.
B
It's
like
define,
process
types,
define
environment
variables,
define
all
these
things
not
saying
we
shouldn't
have
a
separate
mechanism
for,
but
I
do
think
that
there's
a
lot
there's
once
we
open
this
can
of
worms
too,
like
I
think,
there's
probably
more
and
more
functionality.
We
probably
would
want.
C
No
yeah,
I
totally
agree
but,
like
I
feel
like
we
had
this
discussion
when
we
did
the
inline
build
pack
thing
and
it
was
like
the
magic
stuff
or,
like
the
you
know,
little
things
that
make
it
easier
to
do.
The
common
stuff
is
a
real
slippery
slope
like
right
now,
inline
build
packs,
have
no
magic.
It's
like
here's,
your
bin
script
or
your
your
build
script
or
whatever,
and
that's
really
cumbersome
to
just
add
you
know
just
append
an
mvr
or
whatever,
but
as
soon
as
you
just
have
like
a
special
key.
C
B
C
Say
I
think
like
as
soon
as
you
introduce
the
the
very
basic
like
set
in
mvar
people
are
gonna
want
more
powerful
capabilities
like
maybe
I
want
to
set
this
dynamically
based
on
some
other
file.
In
my
repository
that
I
read
in
and
then
that's
when
it's
like
well,
it's
nice
that
this
is
an
inline
build
pack,
because
I
can
do
that.
F
D
You
can
always
fall
back
to
the
inline
build
pack,
but
I
do
think
it's
a
lot
easier
for
someone
just
to
say:
label
key
equals
value,
rather
than
have
to
write
an
inline
build
pack
script.
That
knows
to
write
a
launch
toml
that
has
the
key
in
value
and
also
like
you
don't
have
to
think
of
build
pack
order
as
much
if
it's
just
the
app
brings
the
config
right.
E
All
the
way
down,
I
think
the
problem,
though,
is
we
got
to
think
about
the
different
personas
right
in
like
an
app
developer
or
anybody.
That's
configuring.
Something
like
doesn't
want
to
learn
how
to
write
a
build
pack
right,
whether
it's
inline
or
not,
like
that's
a
whole
different
contract
versus
me,
passing
an
environment
variable
it
via
cli
or
putting
it
in
a
project
configuration
file.
C
E
I
think
like
right
now,
right
like
we
will
have
that
capability
with
inline
build
packs.
I
mean
even
right
now
we
have
relative
based
build
packs,
so
you
could
have
a
build
pack
built
in
and
just
point
to
it
relatively
via
project
tumble.
So
technically
we
have
a
quote:
unquote,
workaround,
but
it's
definitely
not
ideal
right
for
that
app
developer
to
be
like
okay,
create
these
files
and
then
like
copy
and
paste
this
snippet
that
I'm
going
to
give
you
real
quick.
So
you
could
put
environment
variables
in
here.
B
D
C
B
B
I
I
do
think
if
we
going
down
the
case
of
just
defining
it
in
practical
and
not
the
inline
bill
pack
thing
I
do
you
think
we
should
scope
it
to
be
not
trying
to
do
everything
for
everyone,
because
I
like,
I
think
you
should
fall
back
to
inline
bill
pack.
If
you
want
to
because
I
I
feel
like
the
more
complex
you
make
it,
the
more.
The
heart
is
because.
B
Yeah,
if
I'm
an
app
developer-
and
I
want
to
be
able
to
just
set
an
environment
variable
or
do
these
things
like,
I
think
we
should
aim
for
probably
a
little
bit
on
the
simpler
side
of
like.
I
just
want
to
do
those
things
and
then,
if
it's
like
well,
I
actually
need
to
like
append
this
thing.
Based
on
this
other
thing,
like
they
probably
should
be
dropping
down
to
an
inline
build
pack
or
something
is
what
I'm
thinking.
B
Yeah,
I
think
that
makes
sense.
I
mean
I'm
not
married
to
you
specifically
like
where
that
line
sits,
but
I
think
that
we're
going
to
implement
inline
build
packs
and
it
should
be
used
for
maybe
make
it
easier
like
to
do
things
in
line
build
packs,
but
definitely
like.
If
you
have
much
more
complex
cases,
I
think
you'll
be
very
ugly
to
try
to
encapsulate
that
in
tamil.
F
Yeah,
I
think
I
worry
about
the
java
append.
One
though,
like
those
are
the
ones
that
worry
me
a
bit
like
appending,
more
search,
paths
and
stuff,
like
that,
like
the.net,
one
kind
of
that
came
out
of
that
discussion
like
it's
not
the
same
thing,
but
if
someone
could
have
controlled
that
from
like
a
project,
tom
will
like
appending
a
new
search
path.
E
F
E
I
mean,
I
think
that
definitely
helps
I'll
see
if
I
could
put
an
rfc
together
or
delegate
to
somebody
but
nice.
D
F
D
Actually,
move
it
to
platform
build
pack,
build
packs,
would
never
notice,
there's
a
change
but
then
make
a
platform
lifecycle
like
platform
to
life
cycle
communication.
We
can
make
a
a
place
for
that
to
be,
and
then
we
can
start
putting
things
in
there
right
now.
We
just
have
random
files
littered
around
in
it.
It's
not
great.
E
D
F
D
So,
like
you
mounted
it,
if,
let's
say
our
normal
faces,
don't
read
project
tamil
and
instead
they're
reading
out
of
platform,
then
you
expect
the
platform
to
have
populated
platform
and
then
provide
it
read
only
to
the
lifecycle
and
if
you
have
a
prepare
step,
the
prepare
step
is
more
of
a
platform
helper
than
a
lifecycle
thing.
It's
like.
F
C
F
B
F
D
Open
to
a
lot
of
different
ways
of
doing
this
as
long
as
I
just
like
it,
so
that
the
way
we
do
this
is
setting
up
an
organizational
principle
that
will
allow
us
to
easily
add
things
after
that,
I
feel
like
I'm
tired
of
every
time
we
add
something
having
this
existential
conversation
where
it
goes.
I
just
like
it
to
be
obvious
how
to
how
the
platform
can
give
the
life
cycle
configuration
in
a
file.
That's
not
like
add
a
one-off
file
in
a
random
place.
C
B
B
B
My
issue
with
not
like
blocking
accepting
like
jesse's
pr
on
the
spec,
but
it
just
like
it
goes
back
to
that
discussion
from
the
rfc
of
just
like,
is
layers
really
the
right
place
to
put
ordered
humble.
It
seems
like
we're
just
putting
it
there,
because
it's
convenient
and
there
isn't
a
better
place
to
put
it
right
now,
which
I
think
goes
back
to
what
emily
was
saying
right.
C
F
C
We
have
about
eight
minutes
left.
Do
you
think
that's
enough
time
to
draft
a
plan
to
get
to
1.0?
That's
a
joke.
E
C
Yeah
well,
I
would
like
for
1.0
to
be
on
the
roadmap.
I
mean
I
feel,
like
the
I
see,
what
you're
saying
the
user
research
being
a
prerequisite
for
the
map.
C
February,
I've
I've
gotten
a
lot
of
value
from
the
user
research.
It's
been
really
insightful,
so
I'd
hate
to
not
have
it.
You.
B
E
So
maybe
it's
worth
drafting
something
up
the
way
it
sounds
now
and
then
maybe
see
if
we
could
agree
to
signing
off
on
it,
and
I
guess
yeah
like
I'm
just
trying
to
push
for
that,
so
that
we
have
a
little
bit
more
direction
on
what
kind
of
things
we
want
to
contribute
there
in
this
year.
B
Yeah,
I
think
that
makes
sense.
I
I
think
it's
probably
like
a
hybrid
approach
of
we're.
Probably
gonna
have
a
road
map,
but
no
road
map
set
in
stone.
B
That
was
one
of
the
things
I
think
we're
trying
to
do
at
the
latter
part
of
last
year,
where
we're
supposed
to
try
to
check
in
on
the
rematch
in
the
leadership
meetings,
and
so
I
think
the
user
research
doesn't
block
us
building
a
road
map
and
it
should
have
influence
and
sway
on
changes.
You
know
things
come
up
things
change
so
yeah.
B
B
B
Thanks
sounds
good.
I
I
know
ben
said
he
was
going
to
talk
to
the
vmware
folks
about
figuring
out
meeting
scheduling
stuff
because
you
all
are
super
packed
and
busy
right
now,
so
we
can
make
time
for
it.
C
Yeah,
I
think
we're
really
close
to
getting
the
registry
launched
and
when
that
is
off
my
plate,
I
wanted
I
would.
I
was
thinking
about
doing
what
you
just
said,
javier
kind
of
a
straw
man,
putting
some
things
on
paper
that
we
can
point
to
and
either
agree
or
disagree.
A
I'm
pretty
excited
for
the
post
100
or
like
the
future,
looking
work
kind
of
after
we
wrap
up
all
the
things
we're
we're
working
on
now,
as
we
talked
about
that
roadmap
like
things
like
build
kit,
integration
seem
really
exciting,
but
but
I
feel
like
we
should.
A
I
I
think
it'll
make
most
sense
to
the
community
if
we
tie
that
roadmap
for
future
looking
stuff
into
an
announcement
about
1-0
that
you
know,
that
kind
of
be
the
same
same
thing
like
look
what
we
did
here
it
works.
This
is
this
is
definitely
stable
enough
to
use
in
production
scenarios,
and
the
you
know
here
are
very
ambitious
goals
for
the
future.
Docker
build
and
it
builds
a
you
know,
doesn't
build
tech,
build
whatever
are.
C
D
A
A
B
D
Think
they're
ready
just
one
life
cycle
without
one
owing
the
spec
or
something
right.
The
life
cycle
is,
and
now
we've
been
through
a
couple
cycles
of
being
really
careful
about
compatibility
like
we
want
the
life
cycle
won't
break
you.
We
are
going
to
keep
making
you
make
changes
between
spec
versions
for
a
little
bit,
though,.
A
I
don't
think
there's
an
advantage
to
continuing
to
advertise,
build
packs
as
zero
point,
something
implying
that
you
know
what,
however
you're
using
it
now
may
change
really
drastically
in
the
future.
If
that's
not
the
expectation
we
currently
have
for
our
users
right,
if
we're
talking
about
you,
know
putting
one
project
number
or
one
version
number
for
the
whole
project
right,
it
feels
like
per
you
could
call
it
1-0
much
sooner.
E
I
guess
I
think
that
was
a
very
key
like
realization
is
that
it?
It
sounds
like
you're
talking
about
the
whole
project,
but
then
there's
like
so
many
individual
versions
and
components
within
this
whole
project.
So
I'm
not
sure
how
you
translate
one
to
the
other.
Although
I
I
totally
agree
that
if
you
were
to
say
from
a
build
packs
perspective,
you
know
there's
very
very
little
to
almost
no
concern
about
compatibility
like
that.
Does
sound
like
1.0,
but
then
you
talk
about
like
pack.
A
Yeah,
I
guess
what
I'm
saying
it's
just
a
version
for
the
whole
project.
What
I
really
mean
is
the
pack
and
life
cycle
component
version
numbers
specifically,
because
we
you
know
that's
how
people
consume
the
project
right.
I
think
that's
what
we
would
realistically,
if
we're
announcing
one-o
for
build
packs
right,
I
feel,
like
those
are
the
things
that
we're
going
to
to
pump.
E
I
think
the
one
benefit
of
having
the
pre
100
concept
of
versioning
is
that
it's
let
us
iterate
very
very
quickly
and
I
think,
as
soon
as
we
go,
you
know
1.0
on
anything.
It's
going
to
require
a
lot
more
thought,
so
maybe
to
elementally's
point
like
for
the
lifecycle.
It
seems
like
maybe
they're
already
there,
but
for
something
like
pac
or
even
the
build
pack
apis
and
all
the
specs.
Essentially
I
don't
know
it
just
doesn't
seem
quite
appropriate
without
thinking
about
it
more.
A
C
I
I'd
like
to
go
down
that
list
of
breaking
changes,
because
I
suspect,
when
I
look
at
it
this
time,
I
might
say:
that's
just
not
worth
it.
Let's
just
never
do
that
or
something
like
that,
because
I
kind
of
feel
like
what
you're
saying
stephen
or
the
part
that
I
agree
with
is
like
people
are
using
it
and
we
are
like.
If
we
do
change
something
we
are
going
to
hurt
them
and
let's
either
lean
into
that
or
or
whatever
so
any
sense.
A
C
D
I'm
worried
about
us
having
said
that,
we
wouldn't
make
breaking
changes
in
this
pack
post
one.
I
don't
want
to
want
all
this
back
yet
because
I
feel
like
there
are
still
things
that
aren't.
B
F
D
D
Yeah,
I
think
we
need
to
like
deal
with
it
right,
there's
like
a
lot
of
glamorous
work
that
would
be
involved
in
reorganizing
the
spec,
so
that
things
we
want
to
do
in
the
future
can
be
added
without
breaking
anything
and
it's
hard
to
get.
It
prioritized
because
a
lot
of
it
isn't
really
user
facing
right.
No
one's
asking
for
us
to
reorganize
the
files
and
they'll
reorganize
the
labels
and
come
up
with
a
organizational
strategy.
That'll
make
us
easy
first
make
changes
in
the
future,
but
we
need
to
do
that.