►
From YouTube: CNB Core Team Sync
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).
B
B
Cool
so
for
new
stuff,
that
kind
of
came
through
this
was
from
a
while
ago,
but
actually
took
a
pass
of
it.
This
week.
A
Yeah,
like.
A
Here
yeah
like
that
sentence,
is
confusing
to
both
me
and
jamil,
and
I
don't
know
if
we
want
to
discuss
that
now
and
then
there's
another
one
about
the
cnb
file
extension,
whether
we
want
to
just
do
oci
layout
format,.
C
Re
the
cnb
file
extension.
That
was
just
an
idea
for
you
know
what
what
does
a
build
pack
look
like
on
disk.
If
that
makes
sense,
the
idea
was
just
it's
oci
on
disk
the
standard
layout
for
writing
an
oci
image
on
disk,
but
you
put
dot
cnb
at
the
end.
So
people
know
it's
a
full
pack,
because
it's
not
like
a
runnable
image.
C
A
A
One
of
them
is
that
nowhere
on
the
current
spec
does
it
say
that
it
has
to
be
an
oci
layout
format,
which
that
is
a
spec
thing
now
right
that
we
found,
and
so
I'm
kind
of
suggesting
that
we
add
that
and
then
the
other
piece
is
that
the
dot
cnb
part
of
a
file
actually
gets
lost
in
a
lot
of
cases
when
you're,
basically
just
working
with
bytes
at
a
certain
level
right
and
so
really.
I
was
just
curious
if
it
was
even
necessary.
B
I
think
it's
more
from
when
we
talked
about
it,
a
suggested
file
extension
if
you
were
to
have
like
an
archive
on
disk-
and
I
believe
that
or
means
I
guess
it's
confusing
because
it
says,
must
here,
but
it's
listing
on
a
list
of
things
it
could
do.
I
wonder
if
we
just
move
this
into
a
separate
sentence
that
it
just
suggests
it
like
it.
A
C
Sorry
go
ahead,
stephen
just
to
clarify
the
intent.
I
think
it
looks
like
it's
saying
a
lot
more
than
it's
saying
the
intent
here
is.
We
assume
a
build
package
is
an
oci
image
right.
That
is
a
known.
This
all
build
packages
are
oci
images.
It's
saying
the
art
when
it's
distributed.
If
it's
an
artifact
somewhere,
it's
still
a
build
package.
C
If
it's
in
a
docker
registry,
even
if
the
registry
has
done
some
weird
stuff
with
it,
you
know
it's
still
an
oci
image
in
a
docker
registry
and
a
docker
demon,
even
if
the
docker
dammit
has
done
some
weird
stuff,
still
an
oci
image
and
a
docker
demon,
even
if
it's
not
technically
held
in
that
or
if
it's
on
disk.
It's.
If
you
want
to
put
it
on
disk
for
some
reason
right,
then
it
should
be
an
oci
image
on
disk
with
a
dot
cmb
extension.
C
A
A
Okay,
there
there's
something
else:
that's
kind
of
kind
of
that's
going
to
come
up,
which
is
basically
oci
layout
format
right
again,
something
that
isn't
explicitly
mentioned
here.
C
The
intent
was
for
it
to
be
a
file
in
oci
layout
format,
as
a
tar
ball
on
disk
with
a
dot
cnb
extension.
So
if
you
wanted
to
clarify
in
that
freight
in
that
sentence,
a
build
package
must
exist
as
either
an
oci
image,
an
image
or
some
image
or
or
a
uncompressed
tar
archive
in
oci
layout
format
on
disk
with
a
dot
cnb
file
expansion.
That
sounds
perfect
to
me.
Okay,
cool.
A
C
It's
it's
like.
If
you're,
I
think
this
comes
back
to
what
is
the
spec
specifying
is
it?
Is
it
api
documentation?
Is
it
specification
of
individual
components
or
whatever
the
the
intent
was
to
suggest
that
if
you
put
a
build
package
on
disk
as
opposed
to
a
daemon
or
registry,
that
it
should
look
like
this,
so
that
people
know
it
is
a
build
pack
and
whatever?
But
I'm
not,
I'm
not
even
I'm
not
very
strongly
opinionated
about
that.
That's
just
what
I
was
thinking
when
I
wrote
the
line.
A
Yeah,
okay,
so
we
might
throw
some
suggestions
out
there
and
then
obviously
up
for
review
and
comments
at
that
point,.
B
Had
a
strong
opinion
that
that
sounds
fine,
I
mean
I
would
be.
I
do
like
this.cmb
file
suggestion.
I
don't
feel
strongly
enough
that
it
is
required
like
like
I'm
fine
if
that
goes
from,
must
to
should
or
something
along
those
lines
like
we'll
recognize
it
and
it
should
work,
but
I
do
think
there's
benefit
for
having
a
recommendation.
So
it's
not
just
a
bunch
of
like
dot
tars
everywhere.
A
A
B
B
C
Also
say
bill
packs
must
be
a
candidate
for
detection.
What
what
are
targets.
B
Targets
are
the
stack
targets
like
here,
I
assume
well,
this
has
changed,
but.
C
It
seems
like
it's
a
very
generic
sentence
right,
it's
just
saying
like
for
each.
I
don't
know
if
I'd
say
I
think
target
is
not
a
new
word
for
stack
right.
It's
like
it
was
originally
stack
id,
and
so
I
might
just
get
rid
of
that
part-
and
I
say,
hey
you
know
all
associated
build
packs
must
be
a
candidate
for
detection.
C
When
the
entry
point
build
pack,
id
and
version
are
selected.
Maybe
oh,
I
see
I
don't
have
too
much
context
on
this
pr.
This
is
what's
the
goal
of
the
higher
level
thing
here.
Is
it
it's
redefining?
What
buildpack
looks
like
without
stacks
of
mixens
is
that
the
yeah
got
it.
C
Why
I
wanna,
before
we
get
to
that
sense,
I
wanna
understand:
what's
driving
out
the
suns,
it's
like
the.
What
why
do
we
have
like
before
do?
Could
a
build
pack
run
on
multiple
stacks
and
then
it
like,
like
a
build
package
that
contain
multiple,
build
packs,
run
on
multiple
stacks
and
then
the
right
things
inside
would
get
selected
depending
on
the
stack
they're
using?
C
Was
that
part
of
it
yeah
so
now
shouldn't
we
rely
on
oci
artifacts
to
select
that
and
there's
not
not
always
the
artifacts
rely
on
manifest
list
to
select
that
like
why?
A
That
was
a
question
that
came
to
my
mind
as
to
basically
why
we're
adding
metadata,
if
you
could
scroll
up
turns
so
this
is
the
I
o
yeah
yeah
right
there,
the
build
packs
layers.
A
B
C
Yeah,
like
the
point
of
remove
stacks
mixins,
was
to
simplify
a
bunch
of
things
everywhere,
right,
not
to
rename
them
to
something
else,
and
so,
if
you
run
into
stacks
and
mixing
concepts
and
places,
I
think
the
better
path
is
to
remove
them,
and
you
know
if
we
can
rely
on
manifest
lists
right
in
those
cases
to
create
different
versions
for
the
different
targets
then
use
those
manifest
lists
will
do
more
than
just
because
this
is.
This
is
something
that
our
logic
is
parsing
right.
They
can
do
more
than
just
os
and
architecture.
C
They
can
take
into
account
all
the
different.
You
know
properties
as
defined
in
the
rfc,
so
I
think
that
you
would
actually
get
all.
C
Yep,
look
at
I
don't
know
where
this
section
is.
I
think
this
is
like
is
this
something
that
goes
on?
This
is
something
that
goes
on
a
build
pack
right
and
that
build
pack
is
already
specific
to
an
os
architecture
and
all
those
other
properties
by
the
manifest
list
thing,
and
so
I
think
it
can
be
taken
out
because
it's
you
already
found
the
one
that
corresponds
to
that
subset
is.
A
A
build
package
could
have
multiple
build
packs
and
then-
and
so
that's
kind
of
the
area
that
we're
in
right
now,
it's
like
saying
inner,
build
packs
right
so,
like
I
have
built
packs
inside
of
here,
and
one
of
the
things
that
we
have
are
these
like
layered,
diff,
ids
right
and
all
these
layered
diff
ids,
I
get
would
guess,
would
be
to
very
specific
layers
that
would
only
be
applicable
to
the
oci
specified,
manifest
list
selected,
os
architecture
and
so
forth.
Yeah,
okay,.
C
Yeah,
so
it's
like
it's
like
the
first
thing
that
happens.
Is
you
pick
the
one
that,
according
to
the
manifest
list,
matches
the
os
architecture
distro?
Whatever
that
your
you
know
is
most
selective
for
that
and
then,
within
that
one
everything
is
consistent.
All
the
build
packs
are
consistent
just
for
that.
If,
if
some
of
those
build
packs
are
actually
can
run
in
multiple
architectures,
the
layers
will
naturally
get
shared
in
the
registry,
because
they're
just
references
if
that
makes
sense,
and
so
it's
okay
to
have
duplicated
references.
It's
not
like
we're
duplicating
the
storage.
A
Yeah,
because
I
was
thinking
whether
or
not
that
meant
that
we
couldn't
have
a
build
package
that
supports
multiple
operating
systems
or
architectures.
That's
not
true.
C
That's
right,
and
actually
the
manifest
list
is
not
it's
not
just
for
os
and
architecture.
You
can.
I've
tested
this
on
docker
hub
up
to
10
000,
manifest
entries
in
a
manifest
list
per
list
and
the
there's
a
generic
properties
field
on
each
one,
and
so
I
forgot
what
it's
called,
but
so
you
can
be
as
specific
as
you
want.
We
can
make
them.
You
know
just
this
is
where
debian
7
on
x86
linux
right
right
or
they
can
make
them
very.
C
You
know
high
level
and
just
say
this
works
on
all
x86
linux,
it's,
but
it's
no
longer
like
an
id.
That
represents
an
exact
combination
of
those
things.
Instead,
it's
about
selectivity
towards
the
best
option.
A
Cool
and
I
know
that
this
label,
where
else
does
it
get
used,
maybe
like
on
the
builder
or
something
like
that,
and
so
sometimes
we
do
use-
or
I
guess
maybe
I'm
asking
the
question:
do
we
envision
using
any
of
the
targets?
Information
for
other
purposes
like
when
you
do
an
inspect
builder
or
inspect
build
package.
C
When
you
do
an
inspect
build
package,
I
think
if
the
inspect
build
package
command
runs
into
a
manifest
list,
then
you'll
have
to
be
more.
You
know
it
could
either
give
you
the
information
for
each
potential
build
pack
or
you
have
to
be
more
specific
on
the
command
line.
When
you
do
inspect
and
say,
I
want
the
this,
the
one
that's
for
this
architecture
or
whatever.
A
And
then
one
other
thing
which
I
believe
goes
into
target:
that's
the
not
so
much
architecture.
What
was
it
called?
It
was
like
a
target
id
or
something
like
that
property.
C
Yeah,
so
that's
that's!
That's
not
really
related
to
selecting
it's
not
really
related
to
the
build
process.
It's
more
like
when
you're
going
to
do
a
build.
The
run
image
you
select
can
send
some
information
back
into
the
build
kit
like
they
can
be
included
in
the
build
right
so
like
when
you
say:
okay,
I'm
going
to
pack
build
my
app
and
but
I
want
to
use
this
run
image.
That's
missing
these
libraries.
It
could
set
us
an
identifier
that
build
packs
can
read
during
the
build
process.
That's
like
hey!
No!
C
C
No,
so
it's
information
that
a
build
pack
in
it's
been
build
could
look
for
when
it's
building,
but
there's
no
there's
no
target
id
information
in
buildpectomel.
It's
it's
just.
It's
just
intended
to
be
some
metadata
that
the
selected
run
image
gets
to
provide
into
the
build
process,
so
you
can
use
the
same
builder.
Build
image
with
many
different
run.
Images,
or
you
know
like
another
interplay
with
the
dockerfile
rfc,
is
if
the
dockerfile
rfc
creates
a
stack
in
the
end.
C
That
looks
a
certain
way
like
a
run
image
in
the
end
that
run
image
could
set
an
id
that
then
gets
fed
into
the
rest
of
build
process
if
it
changed
the
base
image,
for
instance,
completely
to
something
else
like
run
image
selection,
then
that
new
base
image
could
provide
a
different
target
id
that
feeds
back
into
the
build
process.
So
it's
it's
not
related
to
or
like
it's,
not
information
that
a
build
pack
goes
statically
at
you
know
it's
put
on:
it's
not
like
a
stack
id.
B
C
B
A
Yeah
and-
and
I
think
it's
worth
bringing
up
right
before
we
get
too
deep
into
it,
but
I
know
emily,
I
I
believe
actually
it
might
have
been
emily's
idea
to
begin
with,
and
it
was
something
that
I
brought
up
to
joe.
But
I
don't
remember
exactly
you
know
if
it
was
on
that
slack
thread
or
something
slightly
different,
but
again
worth
validating
that.
That's
what
I
want
to
do.
Yeah.
B
Other
than
that,
I
didn't
have
really
any
problems
with
the
thing
I
just
it's
definitely
a
different
direction
than
what
exists
there
today.
So
just
wanted
to
raise
that.
B
A
Yeah
now
that
emily's
not
here
and
we're
having
to
maintain
it,
otherwise,
it's
a
good
time.
I
I
do
wonder
if,
if
we
should
discuss
it
again,.
A
B
Yeah,
yes,
I
don't
know.
A
Well,
maybe
next
week,
when
we
have
hopefully
more
attendance,
we
could
just
bring
it
up
in
this
meeting.
Yeah.
B
I
feel
like
the
problem
with
this
means
it
tries
to
jam
a
lot
of
stuff
in
like
30
minutes,
and
it's
hard
to
like,
like
even
this
discussion
would
be
nice
to
talk
about
it.
That
way,
without
feeling
the
pressure
of
like
oh
well,
we
got
to
get
through
a
lot
of
other
stuff.
B
No,
I
I
think
like
if
you're
talking
about
the
spec
root,
though
that's
not
like
a
five-minute
discussion,
yeah
cool.
Do
you
all
mind
if
I
move
to
rc's?
I
guess
that's
where
that
oh
are
there
any
releases
that
are
coming
down
the
pipe.
A
We
we
set
up
a
definitive
date
for
pac,
which
is
november
3rd,
so
next
week
we're
going
to
go
into
code.
Freeze,
okay,.
B
There's
no
spec
releases
that
are
coming
out
for
that.
Right,
like
it
is
just
supporting.
B
Almost
seven
and
stuff:
okay,
cool
moving
on
to
rfc's.
B
Starting
from
the
bottom,
we're
still
blocked,
I
believe,
on
the
endpoint
shin
team
spike
see.
This
is
awesome.
B
Sport
dockerfiles,
I
went
through
this
for
a
good
part
of
this
week,
just
rereading
it
and
stuff.
I
talked
with
stephen
a
little
bit
about
this
off
some
comments.
Overall,
I
don't
have
any
large
issues,
I
think
potentially
extensions
by
itself
is
maybe
confusing,
because
we
already
have
spec
extensions
and
we
should
probably
just
clarify
that
somewhere
and
so
talking
with
steven.
B
Potentially
we
could
just
change
the
like,
maybe
top
level
name
of
it
to
like
base
image
extensions
or
something
along
those
lines,
and
then,
when
we
refer
to
extensions
to
the
rest
of
the
like
kind
of
either
the
rfc
or
the
spec
like
we'll
know
which
one
you're
referring
to
so
imagine
just
like
when
this
actually
gets
specked
out
like
it
took
me
15
seconds
to
realize
I
mean
it
was
very
quick,
but
it
was
just
like.
Oh
extensions,
you
don't
mean
extension
in
the
spec,
which
is
what
it
like.
B
This
one
will
define
it.
So
I
think
it's
a
little
confusing,
but
I
think
the
name's
good
just
talking
with
like
joe
and
jesse,
but
I
think
we
do
need
to
just
clarify
that
a
little
bit,
probably
just
at
the
top
and
then
other
questions
are.
This
seems
tied
to
like
the
builder
extension
spec.
That
has
we
never
finished
or
released.
B
Do
we
want
to
do
that
as
kind
of
part
of
this
work
to
actually
get
that
out
there,
because
it
seems
like
just
rented
rfc
like
that
that
cmdx
folder
is
on
the
builder
image
right
at
least
initially
as
talked
about,
and
we
still
have
that
builder
extension
on
one
release
out.
A
Yeah
to
that,
I
would
say
that
the
whole
distribution
spec
is
with
the
idea
of
moving
the
builder
spec
into
it.
So
essentially
the
build
respect
goes
away
and
it
becomes
a
part
of
the
distribution
spec,
and
so
with
that
said,
if
we
agree
right
based
on
following
conversations
that
that's
the
route
that
we
do
want
to
go,
jameel
could
also
make
or
incorporate
some
of
these
changes
into
that.
B
B
C
C
Well,
it's
not
really
tied
to
builder
right.
Like
the
proposal,
I
propose
a
lot
of
ux
for
builder
in
the
thing
like
what
would
it
look
like
to
integrate
this
into
builders,
but
it's
it's
not
supposed
to
be
specific
to
that
construct
like
you
could
still
use
all
these
just
by
putting
them
on
a
build
image.
Next
to
the
you
know,
along
with
build
picks.
B
Yeah
yeah,
I
just
I
guess,
I'm
thinking
like
if
you
had
an
extension
tumble
and
then
potentially
we
added
a
key
or
something
that
added
functionality,
maybe
of
some
sort
or
extended
even
like
like
down
here.
You
have
some.
You
know
like
we
extended
it
to
support
like
the
lb
stuff
right
in
the
future
like
to
me,
that's
an
extension
of
what
that
contract
is
of
what
we
want
this
feature
to
do,
and
I
don't
know,
maybe
we
make
a
breaking
change
or
something
I
don't
know.
I
can't
see
it
right
now.
B
Would
you
want
a
build
image
or,
like
a
builder
type
image,
be
able
to
support
multiple
types
of
extensions?
That
way
or
are
we?
I
guess
that's
where
my
head's
going.
C
Builder
type
image
to
support
multiple
types
of
extensions
like
like
right
is
it's
kind
of
similar
to
should
we
be
able
to
support
multiple
versions
of
the
build
pack
api
in
the
same
builder
yeah,
it's
the
same
or,
like
I
don't
know
if
I
have
a
good
answer
to
the
larger
question,
but
I
think
it's
the
same
question
as
for
extensions
as
for
build
packs,
if
that
makes
sense
like
like,
if
we
have
a
problem
with
mixing
and
matching
build,
build
or
build
packs
of
different
version,
api
versions
we'd
have
the
same
problem
with
mixing
and
matching
extensions
of
different
api
versions.
C
B
Oh
yeah,
I'm
not
it's
necessarily
asking
for
a
ton
of
change
in
the
rfc,
but
like
that
question
to
me
makes
it
seem
like
the
extension
thing.
Maybe
should
have
some
version
tied
to
it,
whether
that's
it
belongs
in
build
pack
apr
or
something
right,
but
like.
C
I
think
so,
but
it's
like
we
started
shifting
our
specs
our
specs,
to
not
define
apis
but
to
define
components
so,
instead
of
like
we've,
talked
about
instead
of
a
platform
spec
having
a
life
cycle,
spec
right
and
then
because
an
extension
is
a
different
thing,
I
could
see
having
a
different
specification
document
for
it
right.
But
that's
I
I
think.
If
we're
going
to
move
that
direction
with
the
specs,
then
we
should
kind
of
decouple
them
from
the
apis
and
say
things
in
the
build
packs.
C
A
C
Yeah,
so
in
a
spec
in
its
current
state,
where
it's
a
description
of
apis
right,
if
we
keep
it
like
that,
then
I'd
say
probably
put
it
in
the
build
packs
back.
But
I
also
I
don't
have
a
very
strong
opinion
about.
I
like,
I
think
there
are
benefits
and
drawbacks
to
having
to
bump
the
whole
api
when
we
make
an
exchange
to
one
or
the
other
right,
for
example,
and
because
we're
not
at,
I
think
we're
still
not
at
100
with
these
version
numbers.
Yet
everything
is
a
breaking
change.
Technically
yeah,
just
painful.
B
Yeah,
I
don't
know
it
was
just
the
thought
I
had
while
reading
through,
like
I
I
can
imagine
this
feature
evolving
and
having
features
I
mean
it
literally
has
stuff
in
here
of
potential
things
we
would
add
right,
like
I
could
even
imagine
us
doing
stuff
like
as
like,
that
s
bomb
conversations
that
evolves
and
things
like
that.
B
We,
like
even
the
base
image
stuff,
could
change
of
how
we
do
that,
and
maybe
that
could
be
breaking
right
and
we
want
to
be
able
to
have
a
way
to
be
able
to
differentiate
how
some
of
that
stuff
works
so
just
be
able
to
tie
really
extension
tunnels,
just
like
tying
the
feature
to
some
version.
I
just
don't
know
it's
not
clear
to
me
from
the
rfc
like
where
that
lives
or
how
that
works.
So
that's
kind
of
where
this
third
question-
I
I
guess
like
leads
yeah.
C
I
could
see
a
bunch
of
different
long-term
solutions
here.
Like
do.
We
need
to
decouple
the
file
schemas
from
the
api
entirely
and
like
let
you
mix
and
match
file,
schemas
and
apis.
Do
we
need
a
separate
schema
version
for
each
file?
That's
different
from
the
api
to
the
apis.
You
need
to
specify
a
range
of
schema
versions
that
are
allowed
per
api
version,
like
I
can
think
of
a
bunch
of
you
know
different
problems
that
come
out
of
this.
So
I
agree
it's
important.
B
Yeah,
I'm
not
yeah
part
of
it's
just
like
I
want
to
see
this
go
through,
so
I'm
not
like
trying
to
that's
like
what's
blocking
and
like,
but
I
I
think
I
do
want
some
answers
at
least
more
so
for
the
third
one
than
anything
else
of
just
like
what
do
we
want
to
do
in
the
short
term?
B
We
know
it's
not
where
we
want
the
spec
to
be
today,
but
we
should
probably
pick
a
thing
and
then,
with
the
plan
of
what
the
supposed
factor
of
like
how
we're
doing
all
this
stuff,
to
figure
out
what
we
want
to
do
in
the
longer
term.
C
What
do
you
think
we
should
do
in
the
short
term?
What
do
you
want
to
see
in
this
backyard?
I
guess.
B
B
Do
we
tie
this
to
platform
or
do
we
tie
like,
even
though
it
I
don't
know,
I
I
feel
like
there's
not
like
to
javier's
point:
there's
not
like
a
great
place
to
put
this
today.
B
Yeah
because
the
rfc
changes
like
basically
it
touches
everything
right
yep,
I
think
like
maybe
like.
Historically,
we
would
have
maybe
made
this
an
extension
extension
spec
or
something
right
and
then
you
can
just
define
whatever
and
there
and
then
you
can
just
evolve
it.
I
think
that's
what
we're
doing
with
stack
packs
or
something
right.
B
B
I
went
through
this
as
well
because
it's
kind
of
one
of
the
other,
larger
ones
that
I
want
to
see
before
wait
is
it
system
bill
packs,
no
officially
supported
utility
bowl
packs.
I
think
there's
there
hasn't
been
changes
to
the
name
on
the
name
space.
I
know
bill
pax
io
was
one
of
them,
but
it
still
says
cnb
in
the
rfc.
B
B
I
think
some
of
the
guidelines,
like
especially
with
the
remove
stacks
rfc
having
been
merged
in
this
talks
about
one
of
the
requirements
being
like
the
annie
stack,
and
I
wonder
if
we
need
to
update
the
language
with
this
rc
and
do
we
even
care
even
to
have
a
stack
requirement
like?
Are
there
cases
where,
potentially,
if
there
was
a
windows,
only
utility
bill
pack
that
we
wanted
like?
B
Would
it
would?
I
think
it
was
like
one
of
sam's
questions
right
like
if
there
was
a
thing
that
we
did
specific
to
windows
like
that
doesn't
comply
with
the
any
stack
and
especially
with
like
I
think,
targets
it
becomes
a
little
even
more
nebulous
of
kind
of
what
this
means
like.
Will
we
just
not
want?
To
I
mean
I
I
get
the
intention
of
like
we
probably
should
be
writing
things.
That
probably
are
generic
can
support
a
lot
of
things,
but
I
don't
know
if
it
should
be
a
strong
requirement
anymore.
B
B
Additional
exportable
layers,
we
all
met,
and
I
think
sam
still
volunteering
to
rework
some
of
this.
Yes,
thank
you.
I
I
need
to
update
it,
yeah,
no
pressure,
I
just
that's
what
the
status
is
right.
B
B
What
do
we
want
to
talk
about
for
tomorrow
for
agenda?
I'm?
I
definitely
want
to
propose
the
utility
bill
pack
stuff.
I
think,
out
of
anything,
I'd
like
to
get
clarity
on
sam's
question
about
some
of
the
stack
stuff,
along
with
some
of
the
other
open
things.
B
If
there
isn't
anything
else
that
people
want
to
talk
about,
I
think
maybe
it
is
also
worth
talking
about-
maybe
some
of
the
spec
refactor
stuff
at
the
end
or
in
the
latter
part
of
the
kind
of
thing
so
people
who
aren't
interested
in
that
can
drop
off
and
maybe
couple
that
into
kind
of
the
support,
dockerfile
extension
stuff.
As
part
of
that
discussion,.