►
From YouTube: Working Group: 2021-01-21
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
B
A
E
E
A
All
right,
I
made
some
changes
to
the
move:
analyze
phase
rfc.
I
basically
removed
everything
that
had
to
do
with
project
tunnel.
A
You
know
making
inline
build
packs
a
thing,
basically
anything
that
could
be
blocking
in
this,
because
we
do
want
to
get
to
this
so
that
we
can
start
to.
A
E
A
Question
yeah:
I'm
guessing
zero;
six,
since
that's
we're
talking
about,
but
I
can
put
that
in.
B
E
C
A
It
he
should
be
happy
with
that
when
I
was
going
through
this,
I
did.
I
was
looking
at
all
the
inputs
because
there
were
some
like
you
know,
typos
and
misalignments
and
stuff.
I
I
added
cache
image
here.
I
don't
know
if
I
added
that
yesterday
or
maybe
the
day
before,
but
it
kind
of
in
our
conquest
of
being
able
to
validate
that
you
have
registering
access.
I
added
it
here.
A
You
know
it's
not
something
that
you
technically
have
to
have
for
analyzer,
but
if
you
provide
a
bunch
of
image
tags,
I
did.
I
didn't
add
tags
here,
but
I
thought
about
it
like,
like
the
additional
tags
that
you
do
on
exporter,
so
that
you
can
validate
any
and
all
registries
up
front
that
you
intend
to
write
to
eventually.
But
I
wasn't
sure
if
that
belonged
in
this
rc
or
not.
C
I
think
it's
also
worth
figuring
out
like
adding
caster,
because
there
can
be
layers
that
are
only
in
the
cache
and
not
on
the
previous
image,
and
I
think
we
want
those
layers
to
have
been
built
for
the
correct
stack.
I
think
the
first
path
of
implementing
it.
We
probably
don't
need
to
check
that
because
we
need
to
actually
add
that
information
to
the
cache
metadata
and
it's
not
the
most
important
thing
that
could
go
wrong,
but
I
think
the
cache
metadata
should
eventually
have
the
stack
id
that
the
cache
was
originally
for.
A
B
Yeah
is
that
I
guess
I'm
wondering
we
ran
to.
I
guess
this
discussion
at
heroku
as
well
just
generically,
if
like
should
that
be
up
to
the
bill
pack,
author
of
the
platform
to
kind
of
or
the
builder
or
whatever,
to
kind
of
decide
that,
because
I
know
for
like
a
lot
of
java
caches
right
like
you
can.
B
Have
a
system
level
dependency,
but
I
feel,
like
that's
the
exception
and
literally
everyone
else
definitely
pays
the
cost,
because
if
you
are
depending
on
anything
libsy,
you
basically
have
to
throw
it
out
right.
E
A
B
The
cache
layer,
or
something
or
like
the
layer,
cat,
the
layer
or
something
to
basically
have
a
setting,
be
like
on
stack
change.
Please
throw
this
out
versus
having
every
built
pack
author
have
to
do
it.
Yeah.
B
C
A
A
E
A
E
Sure
I
was
just
gonna
review.
My
changes
to
the
pack
create
command,
which
is
no
longer
called
the
pack
create
command.
E
The
other
option
was
a
knit
which
would
match
mpm
and
maybe
go
mod
and
other
things
I
don't
know,
definitely
not
a
hill,
I'm
prepared
to
die
on,
but
that's
what
I
went
with.
E
So
changed
it
a
little
bit
more
just
to
be
it's
bash.
These
are
the
files.
It
generates
definitely
simplifies
things,
but
it's
a
little
bit
more
restrictive
and
oh
yeah.
I
did
I
had
an
open
question
about
whether
we
should
generate
some
kind
of
like
test
stubs
like
setup
if
we're
doing
bash
setup
show
unit
2
or
something
that
might
be
going
a
little
bit
too
far
in
the
like
template
direction.
B
E
No,
I
mean
I
like
the
most
of
my
bill.
Packs
rely
on.
Do
I
wish
I
did
yeah
I
do
I
mean
I
tend
to
rely
on
like
integration
tests
which,
for
a
lot
of
the
batch,
build
packs.
E
It's
like
a
test
directory
with
some
shell
scripts
that
just
run
the
you
know
the
bill
pack
and
make
sure
it
exit,
0
or
non-zero
or
whatever
or
particular
things
are
created,
runs
the
image
even
that
kind
of
stuff
that
doesn't
really
fit
well
into
something
that
you
would
that
exists
right
like
I
could
imagine,
creating
a
bash
based
integration
test
framework
for
build
packs.
That
would
be
really
cool
but
doesn't
exist
yet
the
like
typical
sha
unit
stuff.
E
I
question
that's
useful
in
this
generally,
like
you
know
like
what
we've
discovered
a
lot
of
the
bash.
Build
packs
is
like
the
things
you
need
to
test
are
like.
Did
this
file
get
created?
Well,
you're,
really
just
testing
whether
the
touch
command
works.
Like
did
this?
Did
this
jar
file
get
generated
in
the
target
directory?
Well,
you're,
really
just
testing
maven
at
that
point,
and
you
have
to
run
like
at
the
point
that
you're
actually
running
maven.
E
But
let's
say,
let's
say
that
existed
like
taking
some
of
the
the
integration
testing
in
bash.
E
A
A
E
Well,
that's
kind
of
what
I
was
thinking
right
like
I'm,
not
sure
I'd
want
to
add
something
that
wasn't
part
of
the
project.
But
then
you
know
two
wouldn't
be
a
part
of
the
project,
so
I
don't
know
like
I
wouldn't.
If
we
were
generating
a
go
build
pack,
I
probably
wouldn't
put
packet
as
a
dependency.
B
B
E
I
should
just
leave
it
out
stevens.
I
love
steven's
testing,
a
strong
opinion
there,
but
yeah
that
feels
like.
A
D
E
E
B
D
B
Yeah
you'll
need
to
have
like
a
million
of
them,
because
I
think
the
darker
fall
problem
is
probably
worse
there,
like
that's
an
explosion
of.
A
A
A
B
I
mean
there's,
there's
still
something
really
nice
about
like.
If
the
hypothetical
batch
thing
joe
said
existed
to
have
a
thing:
that's
like
okay,
well,
one.
I
think
bash
is
also
special
in
that
I
don't
think
people
have
a
strong
like
opinion
on
how
they
test
their
bash,
probably
most
developers-
I
don't
know-
maybe
not
maybe
I'm
wrong
there,
like
I
felt
like
when
we
brought
up
steven's
testing
go
people
were
just
in.
This
call
were
like
well
actually
but
like.
D
B
D
E
E
Given
that
it
doesn't
exist,
it's
definitely
off
the
table
right
now,
and
so
maybe
what
I
would
like
to
create
that
I
I'm
gun
shy
because
of
build
pack
test
runner
and
it's
failure,
but
I
think
I'd
like
to
try
and
create
something
like
that
and
then
once
it
exists,
we
can
have
a
conversation
about
whether
to
put
it
in
or
not.
E
E
Directories
yeah
every
one
of
my
build
packs
has
a
make
file
with
a
package
target
to
run
basically
to
run
pack
build
pack
package
test.
I
think
some
of
them
have
their
own
builder,
so
there's
like
a
create
a
create
command
that
builds
the
build
pack
and
the
builder
and
everything.
D
G
I
I
was
gonna
say
it
seems
like
a
lot
of
this
conversation
is
like
very
future
facing.
The
one
thing
I
wanted
to
add
is
that
a
lot
of
these
you
know,
like
opinions,
are
probably
going
to
be
driven
by
the
community
as
a
whole,
and
I
don't
know
that
we
can
do
too
much
to
predict
that
just
quite
yet
so
for
the
purpose
of
this
rfc,
I
think
the
general
basis
is
like.
Yes,
we
want
this
to
exist
and
then,
overall
you
know,
how
do
we
expand?
G
B
Yeah,
I
I
will
say
the
the
flip
side
of
that.
B
A
counterpoint
to
kind
of
javier's
comment
is
that
I
think
for
a
lot
of
people
they're
looking
for
someone
to
have
an
opinion
on
how
to
do
and
do
that
stuff
right,
like
for
a
lot
of
people
coming
to
build
packs,
if
I
don't
think
they
have
an
opinion
on
how
it
should
or
should
not
be
done,
they
have
an
opinion
after
they
use
your
thing
for
sure,
but
I
think
they're
definitely
looking
for
kind
of
the
project
for
docs
and
guidance
on
how
to
write
and
and
do
that,
stuff
right.
A
D
A
So
important
for,
like
all
the
volumes
and
the
caching,
because,
like
even
if
you
test
this
thing
and
like
like
there's
just
I
don't
know,
unless
you
understand
the
files,
you
need
to
delete
to
like
test
certain
capabilities
with
pack
and
like
do
you
know
what
pac
click
your
cache
does
like?
No,
no
one,
you
know
like
they
don't
know
what
that
does,
and
so
being
able
to
like
sort
of
have
a
build
command.
That's
targeted
at
it,
pulling
in
like
a
particular
build
pack
and
automatically
assuming
that
build
pack
is
going
to
be.
C
Gonna
say
anything
something
like
that.
I
feel
like
there's
just
too
many
opinions
about
how
to
do
this,
that
I
feel
like
even
the
bill.
Peck
authors
in
this
room
aren't
going
to
agree
about
what
the
skeleton
or
the
normal
target
should
be
like.
Even
in
vmware,
we
have
two
different
go,
build
pack,
libraries
right.
I
could
easily
imagine
like
a
packet,
init
command
and
also
a
lib
c
and
b
in
it.
B
C
A
Yeah
worry
about
another
tool,
because
it's
gonna
have
to
do
a
lot
of
the
things
that
pack
already
does
like
volumes,
and
you
know
all
the
same
parameters
so
that
someone's
switching
between
pack
and
and
whatever
this
other
tool
is
like
integrating
with
docker
docker
remote
stuff.
Like
all
the
improvements
that
we
do
to
like
make
pac
work
for
all
these
new
scenarios
and
like
you're
gonna,
have
to
kind
of
backward
that
over
at
some
point
to
make
it.
G
Like
you
know,
a
lot
of
the
other
ecosystems
there's
a
lot
of
different
tools
that
you
can
use
all
together
to
make
a
very
cohesive
experience,
and
we
could
still
do
something
like
that,
but
it
doesn't
have
to
be
under
the
pac
cli
right,
like
look
at
ggcr
right
that
repo
and
its
set
of
tools
like
you
still
know,
and
you
could
still
access
a
whole
bunch
of
really
nice
functionality.
But
it's
not
just
ggcr
cli
right.
F
At
the
same
time,
I
think,
like
part
of
the
spirit
of
the
rfc,
is
ease
of
use,
so
I'm
asking
folks
to
download
a
new
tool
which
then
that
you
know,
creates
more
surface
area
for
us
to
maintain.
F
You
know,
there's
a
somewhat
new
of
a
learning
curve
there
to
learn
the
idioms
of
a
new
cli.
There's,
definitely
a
cost
there,
and
I
mean
I,
I
actually
don't
think
of
something
like
this
as
like,
like
a
tool
for
you
know,
somebody
like
someone
in
the
paquetto
project
really
or
like
somebody
in
heroku
or
google.
Who's
like
like
their
job,
is
making
build,
packs
and
see
them
as
a
tool
for
just
somebody
who's
trying
to
get
their
app
working.
D
With
build
packs-
and
so
it's
like
that,.
F
That,
like
almost
like,
almost
like
the
dockerfile
authorship
or
tweaking
process
where,
like
they've,
got
the
file
open
here
and
they're,
trying
to
run
it
and
see
it
and
like
it's
a
very
fast
feedback,
loop,
working
back
and
forth,
and
this
is
a
tool
that
is
going
to
allow
them
to
to
make
those
quick
edits
to
like
by
by
just
adding
a
couple
lines
to
this
new
build
pack
which
is
going
to
get
them
over
the
line
of
like
the
container
actually
being
able
to
build.
F
So
in
a
way,
I
kind
of
see
it
as
part
of
like
the
build
and
run
workflow.
That
or
I
guess,
there's
no
rod,
workflow
impact
but
part
of
the
build
workflow
in
impact
for
local
development.
And
so
that
would
be
my
argument
to
keep
it
as
part
of
the
same
tool
because,
like
even
a
very
garden,
variety
developer.
F
Who's.
Not
like
a
true.
B
G
E
E
G
Yeah,
I
was
gonna
say
just
the
flip
side.
You
know
I
don't
have
definitely
a
strong.
You
know
argument
against,
but
the
flip
side
would
be
that,
like
in
general,
the
way
I
see
it
is
there's
different,
personas
right
and
if
you're
talking
about
a
standard,
app
developer,
having
to
even
create
their
own,
build
pack
seems
counter
to
what
we're
trying
to
do
here,
because
there's
so
much
that
in
my
opinion,
they
have
to
learn
about
how
to
construct
a
build
pack
right
and
how
to
like
the
whole
build
pack.
G
E
Particular
I
think
that
sometimes
sometimes
in
mind
build
packs,
but
there's
definitely
like
so
here's
a
good
example
of
one
where
that
wouldn't
be
the
case.
I've
been
doing
the
advent
of
build
packs,
and
so
people
have
started
giving
me
ideas
and
someone
said
yeah.
You
know
it's
really
hard
to
write
this
kafka
cli
docker
file.
We
might
have
like
a
kafka
cli
image
and
they
want
it
to
be
a
build
pack
that
you
could
add
to
any
app.
So
it
wouldn't.
You
wouldn't
make
a
good
use
case
for
inline
build
pack.
E
You
don't
want
to
copy
that
project
tumble
around,
but
it's
also
a
pretty
simple
thing
like
install
the
cli
set
up
the
certs
and
all
that
stuff.
You
don't
need
it's
java,
so
you
don't
need
like
root
set
of
certs,
so
yeah
I
mean
sometimes
in
line
build
pack.
I
agree,
but
definitely
not
always.
A
G
So
that
was
the
the
set
of
commands.
I
was
advocating
to
be
externalized
elsewhere,
but
which.
G
Related
to
build
pack,
you
know
management.
C
C
Did
you
why
I
want
a
command
that
will
like
look
at
the
registry
and,
like
pack
builder
update
or
build
pack
update,
that
would
update
all
my
dependent,
build
packs
based
on
what's
available
on
the
registry?
I
want
more
buildback
commands.
G
C
G
C
G
Yeah,
I
think
I'm
getting
convinced
I
I.
The
g
cloud
example
was
really
good.
The
other
one
I'm
thinking
about
is
you
know,
ggcr,
which
I
like
their
independent
components
and
then
red
hat
open
shift
has
a
lot
of
independent,
clies
and
they're
definitely
less
discoverable,
but
they
work
fairly
well
independently.
E
Yeah,
I'm
really
split
there.
You
know
like
I
like
the
idea
of
a
one-stop
shop
and
like
with
the
the
g-cloud
stuff.
It's
like
oh
wait
where
I
gotta
go,
get
crane!
Oh,
where
what
is
this
g
crit?
You
know,
but
then,
at
the
same
time,
when
I'm
setting
up
like
the
github
actions,
it's
like
I
just
want
crane.
I
don't
want
all
this
other,
you
know,
and
so
it
kind
of
depends.
I
don't
know
like
what
situation
you're
in.
B
G
I
think
that's
all
gcloud
is
right.
It's
like
python
wrapper
for
a
whole
bunch
of
other
python
crap.
G
E
E
B
E
Let
me
I
don't
know
if
we
decided.
Let
me
comb
through
the
makefiles
that
I
have.
I
have
like
I
seriously
like
a
dozen
build
packs.
Now
that
mostly
look
the
same,
I'm
gonna
see
what
what
I
can
glean
from
them
that
might
be
just
applicable
across
the
board,
like
a
lot
of
them,
are
around
like
creating
a
builder
for
a
specific
build
pack
like
the
minecraft
one
that
made
sense
to
have
the
aws
lambda
that
made
sense
to
have
but
yeah
most
of
them.
E
I
don't
think
you'd
include
that
across
the
board,
so
tbd,
basically
on
makefile.
A
F
Problem
I
came
late
and
just
added
them
late,
but
it's
perfect
that
it
came
after
your
rfc
because
it's
very
related,
so
the.
F
My
video,
the
idea
part
of
the
idea
for
the
user
research
is
to
have
the
second
phase,
be
like
a
usability
test
of
some
form
of
build
pack
authorship.
I
know
we've
talked
about
a
couple,
different
solutions
we
have
today
and
yeah.
I
guess
I
wanted
to
talk
to
you
all
about
this
and
get
some
ideas
of
like
what
would
be
the
most
valuable
thing
to
or
a
couple
of
things
to
watch
developers
like
stumble
through
and
try
to
do
and
see
where
they
fail.
B
F
We
can
do
a
smattering,
I
think
yeah
I
have
I
I
have
like
one
or
two
people
in
mind.
Who've
tried
to
write,
build
packs
before
but
aren't
like
part
of
paquetto
or
something.
B
F
D
F
A
F
Date,
let
me
know
so
yeah,
basically
for
the
for
those
of
you
who
are
not
super
super
familiar
with
like
a
usability
test.
It's
basically
like
you
just
ask
them
you
just
give
them
the
task
and
share
your
screen
or
like
send
them
a
link
to
something
to
walk
through.
That
could
be
working
code
like
you
know,
actually
ask
them
to.
F
A
F
Cli
or
or
you
know,
even
other
other
methods,
but
basically
just
to
give
them
what
it
would
be
like
to
use
this
thing
and
then
ask
them
to
try
to
accomplish
a
task
and
have
them
talk
out
loud
while
they
are
struggling.
D
F
Doing
great
to
complete
that
task,
yeah
so
basically
like
or
or
it
can
be
done
with
docs
too
it's
like
read.
F
And
like
do
it
and
follow
the
doc
in
front
of
me
and
see
how
it
goes
so,
some
things
that
I
had
heard
mentioned
before
that
we
could
potentially
do
this
for
pac
file.
I
don't
know
if
that's
still
a
thing
just
like
project
tomml
in
general
and
the
process
of
like
either
doing
service
bindings
or
specifying
environment
variables
as
like
a
way
and
that's
sort
of
relevant,
because
it's
like
it's
like
a
way
to
specify
which
dependencies
you
want
in
your
container.
F
So
it's
not
quite
built
back
authorship,
but
it
is
like
it
is
like
container
customization,
that's
kind
of
the
space
and
then
inline
build
packs.
Like
we
mentioned
on
this
call,
and
then
these
are
like
just
a
couple
ideas
that
don't
exist.
That
just
came
up
from
previous
interviews
that
I
don't
think
really
makes
sense.
But
so.
B
B
B
Yeah,
I
may
be
good
to
test
basically
using
bill
pack's
new
to
to
see
how
fast
someone
can
actually
bootstrap
a
bill
pack
together.
D
B
Think
that'd
be
cool
to
see
or
where
they
stumble
and
fall.
I
know
if
I
don't
know
how
easy
this
would
be
to
test,
but
I
know
for
me
one
of
the
things
that
I've
struggled
a
lot
with
with
the
spec
is
the
build
plan
and
how
it's
structured
today,
and
we
probably
would
have
to
sit
down
and
work
with
you
on
it,
but
it'd
be
good
to.
B
E
E
Yeah
inline
build
packs,
aren't
a
thing
yet,
so
we
definitely
won't
be
able
to
test
those.
B
E
E
Yes,
I
can
send
you
the
rfc
I'll
find
it.
It
exists
in
the
fact
that
it's
fully
specced
out
we
haven't
implemented
it.
F
I
think
like
in
the
next
week
or
two
I
would
like
to
like
what
like
we
should.
We
can
agree
on
what
are
the
things
we
want
to
test
and
then
work
on,
writing
the
script
for
that
and
then
practice
the
script
and
then,
hopefully
start
scheduling
people
to
test
with
them.
The
second
week
of
february,
I'm
I'm
going
to
a
conference
for
four
days
on
the
not
not
next
week
with
the
following
week,
so
yeah
in
the
next
two
or
three
weeks.
F
If
we
could
decide
what
we
want
to
test,
but
also,
if
there's
something
really
important,
that
just
needs
a
whole
month
for
it
to
be
ready,
you
know
we
could.
We
could
test
it
later
too.
So.
D
D
F
F
So
one
of
the
things
that
we
should
test
it
as
simple
as
like,
I
want
to
add
a
file
to
be
in
my
resulting
container,
like
I
feel
like
that's
like
the
absolute
simplest
customization
that
somebody
might
want
to
do,
although
maybe
I'm
wrong,
and
then
maybe
we
could
take
a
step
up
in
terms
of
complexity
or
a
couple
steps
up,
but
but
what?
What
might
be
some
like
specific
examples
of
of
of
goals
one
might
want
to
accomplish
when
that
would
require
you
to
offer
a
build
pack
or
customize
container.
B
D
E
I
was,
it
was
kafka
cli,
but
I
think
cube,
cli
might
be
better
cube.
Cuddle
might
be
better.
B
Yeah,
it's
it's
just
like
getting
the
file
being
shirts
executable
and
then
like
putting
it
in
a
layer
or
in
the
workspace
directory
right.
So
you
can
actually
have
it
on
the
path.
E
I
think
another.
This
is
not
about
creating
a
build
pack,
it's
about
using
build
packs,
I'm
not
sure
if
you
were
trying
to
go
one
way
or
the
other,
but
serving
some
static
assets.
You
know
like
using
an
nginx
build
pack
or
something
like
that,
which
is
similar
to
adding
a
file
to
a
container,
but
like
the
next
step,
beyond
that,
it's
like
here's,
some
files,
and
I
want
them
to
be
served
on
a
port
kind
of
thing,
and
I
want
to
be
able
to
use
an
off-the-shelf
build
pack.
E
F
E
Yeah,
like
that
first
bullet
below
the
strikethrough
bullet
is
a
build
pack
author
persona
and
then
my
suggestion
was
for
the
build
pack
user
persona
and
there's
other
pers
there's
at
least
one
other
persona
we
could
hit
on.
But
I
think
terence
is
wondering
if,
if
you
did
want
to
target
one
of
those
or
if
you
did
want
to
go
across
all
of
them.
F
Yeah,
I
think
it's
really
interesting.
I
mean
I,
my
opinion
is
kind
of
that.
The
ideal
state
is
like
it
would
be
great
if
we
could
get
to
the
point
where
those
two
personas
are
very
fluid
and
they
really
exist
on
a
spectrum
in
so
that,
like
a
buildpack
user
can
become
a
buildpack
author
relatively
easily
and
quickly.
F
If
the
situation
arises
where
they
are
trying
to
use,
build
packs
to
build
a
container
for
some
sort
of
application,
and
it
turns
out,
it
does
require
them
to
author
something,
instead
of
just
use
the
existing
build
packs
in
a
more
sophisticated
way.
So
that
kind
of
slides
around
the
question.
But
you
get
what
I'm
saying.
E
Yeah-
and
that
is
so
the
inline
build
pack
thing
is
precisely
that
right,
like
as
a
you
typically
start
as
a
builtpack
user,
and
you
need
when
you
need
to
dabble
and
like
oh,
I
just
need
to
do
this.
One
little
thing
you
use
inline,
build
packs
and
that's
how
you
become
familiar
with
the
api
of
build
packs
and
then
you
might
move
towards
extracting
that
into
a
real,
build
pack,
so
yeah.
I
I
definitely
get
that.
F
E
Yeah,
you
could
do
it
either
way.
Yeah.
E
The
cube
cuddle
cli
build
pack
could
be
tested
as
an
inline
build
pack,
or
we
could
test
it
with
like
a
pack
build
pack
new
command
again
sort
of
it
depends
on.
It
depends
on
where
we
want
to
hit
on
that
spectrum.
You're
talking
about
like
do
we
really
want?
Do
we
want
to
get
people
that
are
just
dipping
their
toe
in?
E
D
F
Okay
and
then
what
about
for
testing
this
scenario,
which
tool
that's.
F
Okay
got
it,
it
would
just
be
to
the
extent
that
they're
able
to
manipulate.
E
Yeah
that
they're,
I
mean,
I
think,
the
questions
I'm
curious
about.
With
that
scenario
are,
can
they
discover
the
build
pack?
They
need
like
how?
How
long
does
it
take
them
to
go
from?
I
need
to
serve
these
assets
to
I
could
use
this
nginx
build
pack
even
before
they
write
a
line
of
code.
You
know
just
that
that
process
of
figuring
that
out.
E
Yes
right
because
yeah
because
they're
institutionalized
with
dockerfile
and
that's
the
way
you
do
it,
but
then
after
they
sort
of
discover
what
build
pack
they
need.
E
F
B
F
Okay,
cool
yeah:
we
can
talk
about
it
next
week.
Is
there
another
scenario
that
maybe
we
haven't
covered
either
with
these
two
or
with
these?
F
Another
thing
I
can
do
is
talk
to
some
of
the
field
folks
at
vmware
who
work
with
customers
to
migrate,
apps
and
like
what
custom,
build
packs
or
like
new
small,
build
packs.
They've
had
to
write
for
customers
and
has
some
scenario
ideas,
but
any
other
ideas
that
come
up.
F
Is
there?
Is
there
any
other
scenario
around
either
customizing
the
build
the
container
or
or
authoring
some
kind
of
simple
build
pack?
In
order
to
accomplish
some
customization
use
case,
for
either
of
those
kind
of
things?
Are
there
any
scenarios
that
come
to
mind
other
than
these
two
examples
we
provided,
one
of
which
is
adding
a
cli
ensuring
it's
executable,
serving
some
static
assets.
D
F
What's
the
what's
like
the
problem
or
goal
that
they
they're
trying
to
accomplish.
E
It
could
be
like
you
need
a
worker
process
like
you
have
a
web
app
that
has,
you
know
some
binaries
in
it
that
do
a
bunch
of
different
things
and
the
primary
thing
is
serving
web
requests,
but
you
also
need
to
have
it
run,
database
migrations
or
have
it
run
a
background
job
in
a
separate
container?
Something
like
that.
D
Are
we
planning
to
use
our
sort
of
existing
documentation
to
guide
them?
You
know
they're
in
potentially
getting
feedback
on
the
docs
themselves
or
you
know,
will
we
be
preparing
our
own
guides
or
you
know
I'm
just
thinking
that
there's
probably
many
gaps
in
our
docs
yeah?
I
would
go.
F
Ahead,
yeah
yeah,
it's
completely
up
to
us.
I
mean
if
we
have
the
time
and
inclination
to
and
we're
ready
to,
invest
in
in
filling.
B
F
Those
gaps
and-
and
because
we
know
these
are
important
situations
we
want
to
ensure
those
those
those
docs
are
are
like
usable
and
make
sense
to
people.
Then
we
can
do
that
or
or
if
we,
if
we
don't
have
time
to
do
that,
and
we
we
just.
We
want
to
look
at
the
existing
docs.
That's
fine
too,.
D
I
think
if
we
could
identify
with
enough
time,
you
know
like
let's
say
we
get
a
little
bit
of
lead
time,
that
these
are
the
things
that
we're
going
to
ask
people
to
to
to
work
with.
It
might
be
worth
investing
in
the
docs.
Regarding
those
you
know
aspects
just
because
it
would
be
a
better
test
right.
F
As
good
an
excuse
as
any
to
finally
make
those
investments.
G
E
Sorry
I
need
to
drop
to
go
to
another
meeting,
but
sam.
I
want
to
let
you
know
how
much
that
user,
research
dock
that
you
shared
in
the
user
research
channel
was
really
incredible
and
just
want
to
thank
you
for
all
the
work
you've
done,
because
it's
been,
I
think,
really
valuable
to
us.
G
Yeah,
so
on
that
same
vein
right,
so
I
think,
through
the
scenarios
that
makes
sense
that
we
probably
want
to
add
some
documentation
like
for
the
things
to
test
right,
like
I
see
things
like
pac
file,
inline
build
packs
things
that
don't
necessarily
exist
yet
right
like
how
do
we
expect
those
to
be
tested.
F
Oh
yeah,
I'm
just
throwing
these
out
as
possibilities.
It
sounds
like
based
on
this
conversation
today.
It's
these
two
things,
plus
maybe
project
tom
will
plus
maybe
just
like
pack
dash
build
pack
apply
environment
variables.
That
way.
G
F
F
B
Yeah,
this
seems
like
a
good
list
to
me.
D
F
Yeah
yeah,
I
can
drop
it
in
the
zoom
chat.
I
can
also
drop
it
in
the
user
research
channel
and.
G
G
Dropping
it
in
slack
that
way,
I
want
to
like
add
myself
some
action
items
from
this
to
at
least
create
issues
in
the
docs
repo.
So
we
have
them
in
time.