►
From YouTube: Working Group: 2021-05-06
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
You
all
know,
sam
pianado
he's
a
designer
in
the
build
program
at
vmware
and
he's
been
leading
this
effort
along
with
me.
So
today
is
the
first
of
two
sessions.
The
next
session
will
be
at
office
hours
next
week.
So
please
join
us
as
well
today,
we'll
be
digging
into
the
raw
data
and
doing
some
exercises
that
will
hopefully
inspire
conversation
and
gather
insights.
A
We
figured
that,
since
the
contributors
in
this
forum
will
be
responsible
for
putting
the
findings
of
the
research
into
action,
we
didn't
want
to
deliver
a
pre-packaged
slide
deck
of
findings,
but
instead
we
want
everyone
to
have
a
relationship
with
the
data
and
be
able
to
generate
findings
and
insights
that
are
hopefully
relevant
and
actionable.
A
So
what
we'll
do
today?
First,
I'm
going
to
give
a
quick
background
on
what
we
did,
what
the
process
was
like
and
then
we'll
have
two
sections
of
silent
reading,
followed
by
discussion.
Sam
is
going
to
speak
in
a
little
bit
more
detail
about
what
that
looks
like
next
week.
We're
planning
to
do
a
review
of
our
assumptions
from
the
beginning
back
in
january
and
then
discuss
what
actions
we
might
take
next
and
what
else
we'd
like
to
learn.
A
So
what
did
our
process
look
like?
We
talked
to
seven
subject
matter:
experts
within
vmware
who
are
all
familiar
with
buildpacks.
Then
we
talked
to
nine
people
in
the
industry
who
are
working
with
containers
every
day,
but
may
not
have
heard
about
buildpacks
before
this
is
very
intentionally,
not
a
large
sample
size.
A
A
Put
that
out
there.
So
what
did
the
interviews
look
like
with
the
subject
matter?
Experts?
It
was
a
more
freeform
conversation
just
kind
of
spitballing,
but
with
the
industry
interviewees,
it
was
more
structured,
so
we
spent
the
first
half
of
the
interview
understanding
what
they
do,
how
they
use
containers,
what
they
like
or
dislike
about
their
current
build
tooling,
which
was
usually
docker
and
what
they
expect
from
a
container
build
tool.
A
So
one
of
the
things
we
ask
them
to
do
is
rank
10
features
of
a
container
build
tool
in
order
of
importance
to
them,
we'll
be
going
over
that
in
one
of
the
sections,
and
then
we
introduce
the
concept
of
build
packs.
You
know
kind
of
at
the
high
level
and
ask
for
their
initial
thoughts
and
observations
so
and
we'll
be
seeing
snippets
of
what
they
had
to
say
in
in
this
board.
If
you've
taken
a
peek
ahead.
A
Oh,
that's
right,
yeah,
so
we
we
had
a
plan
to
to
take
someone
who's
relatively
fresh,
to
build
packs
and
kind
of
walk
through
the
process
of
authoring
a
build
pack
with
them.
But
what
we
found
was
that
you
know
someone's
relatively
new
to
build
packs.
We
spent
the
entire
time
allocated
for
the
session
just
kind
of
explaining
what
we
do
and
walking
them
through
their
first
pack
build.
A
So
we
kind
of
felt
that
that
wasn't
the
best
format
for
for
an
interview,
but
we'll
hopefully
dig
into
that
a
little
bit
more
next
week
when
talking
about
you
know
any
future
interviews
that
we'd
like
to
conduct
what
what
should
those
look
like
and
who
should
we
talk
to
any
questions
about
the
process
or
you
know
what
we
plan
to
do.
B
Awesome
thanks
so
much
for
coming
folks,
so
we
are
going
to
dive
right
in
and
we're
gonna
set
off
a
timer,
and
let
everybody
read
this
first
section
here:
we're
only
gonna
give
you
eight
minutes
to
read
this,
I'm
sorry
for
the
short
amount
of
time.
Please
definitely,
you
know
come
back
and
read
more
if
you're
curious,
so
if
you
want
to
scan
through
it
to
try
to
get
through
it
in
eight
minutes,
that's
totally
fine
and
then
we're
gonna
discuss.
What
do
we
find
interesting?
B
What
do
we
learn
and
if
you,
while
you're
reading,
if
you
want
to
use
this
green
chalkboard
over
on
the
right
and
add
sticky
notes
about
you,
know
what
you've
learned,
what
what
do
you
think
we
maybe
need
to
make
more
visible?
B
What
existing
features
of
build
packs
need
to
be
explained
better
and
what
new
things
can
we
build
to
get
more
adoption
or
any
other
thoughts
that
you
have
so
that
chalkboard
green
area
is
our
workspace,
so
please
go
crazy
over
there
and
add
lots
of
ideas
and
thoughts,
and
with
that
I
think
we
will
just
kick
off
this
silent,
read
so
we're
just
reading
this
first
white
board
here.
Does
anybody
have
any
questions.
B
Cool
so
excited
to
hear
people's
thoughts.
C
I
could
start
with
one
that
maybe
I
just
found
a
little
bit
confusing
I'd
like
to
maybe
get
a
little
bit
more
insight.
So
I
think
on
the
what
is
it
like
the
ranked
list?
If
I'm
looking
at
that
correctly,
like
the
two
most
important
things
for
these
individuals
were
the
app
updating
you
know,
patch
releases,
for
application
dependencies
and
for
os
packages?
Is
that
right.
D
C
B
Yeah,
I
think,
that's
a
great
tension.
That's
really
important
to
bring
out.
I
think
I
think
that's
spot
on.
A
License
from
the
interviews
that
I
participated
in
is
it's
kind
of
it's
kind
of
like
this
tension
between
it
someone's
saying
it's
important
for
me
to
know
everything.
That's
in
the
file
in
the
docker
file,
and
also,
I
really
don't
know
everything
that's
in
the
docker
file.
You
know
it's
like
identifying
that
something's
important,
but
also
in
practice
not
being
able
to
really
meet
that
expectation.
E
Like
that
gap,
analysis
was
one
of
the
things
that
sort
of
caused
us
to
do.
The
cloud-native
build
pack
project
in
the
first
place
or,
let's
say
build
packs
generally-
was
that
people
wanted
that,
but
could
not
get
it
with
their
existing
tools.
So
I
think
that's
actually
like
very
strong
backup
for
the
entire
foundation
of
the
project.
We.
C
E
I
believe
the
way
I
typically
experience
this
with
customers
is
it's
a
developer
concern
in
so
much
as
their
company
requires
an
outcome
right.
It
requires
a
complete
inventory
that
everything's
on
there
right
a
bill
of
materials
and
to
the
extent
that
a
tool
can
provide
that
so
that
those
developers
aren't
on
the
hook
for
it
themselves.
It
does
overlap
there.
F
I
think
this
ties
into
one
of
my
insights
I
feel
like
sometimes
when
we
talk
about
how
much
to
emphasize
security
aspects
of
cloud-dated
build
packs
like
we
know,
security
is
important,
but
sometimes
we
go
back
and
forth
being
like
devs.
Don't
care
about
this
at
all,
but
I
think
that
the
sort
of
the
outcome
of
asking
people
to
prioritize
across
a
wide
range
of
personas
seems
to
be
that
a
broader
range
of
people
care
about
security
than
we
give
them
credit,
for
maybe
they
care
for
different
reasons.
F
E
Yeah,
I
think
your
idea
emily
that
they
care
in
different
ways
about
it
is
the
key
point
here
like
there
are
operators
and
other
people
in
the
back
office
in
enterprises
who
care,
has
a
sort
of
first
class
concern
about
making
sure
that
things
are
secure
developers,
maybe
a
better
way
to
phrase
it
would
be
developers
don't
want
to
care.
They
just
want
the
answer
right
so
that
they
don't
have
to
introduce
all
of
the
added
complexity
in
their
day-to-day.
They
just
get
a
thing
that
is
secure.
F
C
All
right
I'll
just
throw
that
on
here.
I
think
one
of
the
things
I
do
want
to
call
out,
though,
is
like
in
this
ranked
list,
there's
only
what
like
11
items
right
and
so
I
feel
like
maybe
we're
not
getting
the
full
picture
either
like
there's,
probably
other
things
that
developers
you
know
in
in
doing
this
survey
actually
care
about
a
lot
more
than
security
patches.
B
E
Yeah,
so
I'm
going
to
jump
in
and
highlight
line
four
in
this
ranked
list,
total
control
and
flexibility
for
customization.
Anybody
want
to
take
a
stab
at
how
to
reconcile
that
with
the
ability
to
patch,
which
is
generally
in
direct
opposition
to
that
easy
ability
to
understand.
What's
in
something
which
is
in
direct
opposition
to
that
like
how
do
we
as
a
project,
try
and
reconcile
a
priority?
That's
that
high
compared
to
other
things
that
it
almost
can't
exist
with.
F
Personally,
I
think
we
should
call
some
types
of
flexibility
out
of
scope
like
I
think
we
should
look
at
certain
cases
that
we
want
to
support
really
well
and
make
sure
that
people
have
total
control
and
flexibility
to
change
the
things
they
care
about
in
those
situations.
But
I
don't
think
that
you
know
if
someone
who
wants
to
you
know
add
ip
tables
to
their
image
is
going
to
choose
a
docker
file
instead,
like
I
think
it
is.
G
I
think
this
leans
into
like
the
escape
hatch
stuff
as
well.
Like
I
think,
if
there
are,
I
mean,
maybe
inline
bill
pack
is
one
way
to
help
mitigate
some
of
this,
but
the
ability
to
extend
a
thing
that
doesn't
work.
I
think
I
saw
that
theme
a
lot
with
some
of
the
the
cards
that
I
saw
right
like
like
the
moment
it's
broke.
G
If
I
have
to
like
dig
into
and
understand,
because
the
assumption
is
like
I
can
read
and
understand,
docker
files
seems
to
be
like
a
lot
of
the
it's
like,
oh
well,
I
can
at
least
read
the
simple
dsl,
but
I
guess
they
aren't
reading
these,
like
127
line
python
docker
files
to
kind
of
set
that
stuff
up.
G
So
I
doubt
when
people
read
the
from
images
that
they're
inheriting
some
of
this
stuff
from,
but
even
given
that,
like
the
fact
that
I
can
like
edit,
the
thing
that's
checked
in,
I
think
goes
a
long
way
for
kind
of
helping
with
that.
So
I
really
think
that
this
is
tied
a
lot
to
like
escape
hatching
that
people
feel
like
they
at
least
have
that
out
or
option,
and
it's
not
hard
to
do.
G
I
thought
there
was
an
interesting
note,
even
along
those
lines
of
like
someone
said
that
they
can
either
edit
either
the
dockerfile
or
their
code,
and
so
it
seems
like
it's
not
like.
They
have
to
force
they're
willing
to
change
their
code
to
make
the
docker
builds
work
for.
B
B
A
A
A
C
C
Okay,
I
guess
I
I
could
I'm
going
to
change
the
topic.
So
unless
somebody
has
a
reply
to
that
good
move
on,
I
wanted
to
maybe
unpack
the
documentation
piece
a
little
bit
more
and
I
don't
know
if
I'm
I'm
really
looking
for
solutioning
just
yet,
but
I'd
maybe
like
to
know
a
little
bit
more
of
you
know
again.
C
This
callout
for
great
documentation
was
10
out
of
11
right,
and
I
know
that
we've
put
that
as
like
a
pretty
big
focus
for
the
roadmap
this
year
and
we
felt
like
we
needed
it,
but
I
do
wonder
if
there
are
better
alternatives
right
and,
as
I
was
thinking
about
it
just
now,
one
of
the
things
that
kind
of
resonated
was
like
the
ease
of
use.
Right
like
how
simple
it
is
to
write
a
docker
file
like
the
the
syntax
itself.
C
It's
like
very
minimal
right
that
you
have
to
learn,
and
so
I
do
wonder
if
there's
a
better
alternative
that
we
could
be
using
as
opposed
to
documentation
right
like
not
to
say
that
documentation
is
not
important,
but
maybe
minimize
the
efforts
there
and
put
them
elsewhere,
and
so
one
of
the
things
I
think
about
is,
like
you
know,
npm
as
a
very
like
hand-holdy
type
of
way
of
you
know,
guiding
you
through
the
process
of
whatever
you
want
to
do
right
so
like
you're,
creating
a
react
application
it
like
guides
you,
through
with
these,
like
scaffolding,
processes
right
an
error
occurs,
it
kind
of
like
guides
you
how
to
fix
it
as
opposed
to
like.
C
F
F
Maybe
I'm
just
like
willfully
trying
to
explain
this
away,
but
I
feel
like
good
documentation
is
table
stakes
for
a
tool.
It's
not
like
the
killer
feature,
but
it
is
just
an
expectation
of
a
mature
product
like
is
it
possible?
That's
why
it's
so
low
on
the
list.
It's
not
a
reason.
You
pick
something,
but
it's
just
something
that
you
need
to
even
have
it
enter
into
the
category
of
things
that
could
be
picked.
E
Yeah,
like
this
is
a
lie
from
all
the
participants
they
care
way
more
because
the
a
documentation
being
good
or
not
is
whether
anybody
gets
beyond
opening
the
home
page.
Fundamentally,
there
isn't
a
good,
install
experience,
good,
getting
started
experience.
They
just
leave
it's
not
like
they
dislike
the
product
and
the
way
they
would.
If
it
you
know
they
were
using
it
that
had
a
feature
or
not.
They
just
don't
engage
right
at
the
start.
C
Yeah,
I
guess
maybe
I'm
framing
it
more
in
whether
the
level
of
effort
right
of
document
all
the
things,
which
is
something
that
I've
said
in
the
past
right.
It's
worth
the
value
right
and
if
we
could
offset
that
much
effort
right
and
leverage
something
else,
some
other
methods
that
are
closer
to
the
end
user,
as
opposed
to
them
having
to
come
to
the
documentation.
E
It's
an
admirable
idea,
but
I
think
if
you
just
take
a
look
at
any
open
source
project
that
you
contin
you
consider
to
be
successful.
Javier
right,
like
the
one
thing
they
all
have
in
common,
is
really
really
really
good.
Docs,
there's
no
anemic
documentation
on
a
successful
project.
As
emily
says
it's
undervalued,
because
it's
considered
at
table
stakes
you
don't
even
get
to
enter.
The
conversation
of
this
is
one
of
the
most
important
projects
in
the
world
without
that
level
of.
H
H
You
go
to
these
things
out
of
frustration
right
because
the
thing
you're
looking
for
to
maybe
to
build
your
platform
isn't
in
the
search
bar
in
the
docs
right
I
do
feel
like
docs
are
great
when
people
are
already
invested
that
people,
you
know,
need
the
right
resources
to
build
their
business
on
top
of
right
that
those
those
are
the
people
that
sort
of
need
it
right
and
will
complain
the
loudest
about
it.
But,
like
you
know,
to
get
people
to
read
through
dry
docks
right.
You
know
it's
not
very
fun
to
do
it
right.
E
Read
through
dry
docs,
I
think,
is
a
symptom
of
bad
documentation.
But
let
me
ask
you
anthony
the
first
time
you
had
to
install
mini
cue
or
install
kind.
Take
your
kubernetes
cluster
of
choice
started
stack,
overflow.
H
I
E
F
If
the
docs
were
missing,
I
might
have
given
up
on
some
of
those
things,
even
though
they
support
what
I
want
it's
like.
Can
I
get
kind
to
talk
to
my
local
registry
in
an
insecure
way?
You
know
like
something
that
doesn't
work
by
default.
If
there's
no
doc
that
describes
how
to
make
it
work,
then
I'm
like
screw
this,
I'm
going
to
use
a
different
cluster.
You
know,
but
if
there's
a
nice
how-to,
then
then
I'll
keep
going.
G
I
I
do
think
to
anthony's
point,
even
if
you
have
good
docs,
I
do
think
the
google
ability
of
that
helps
a
lot
or
or
even,
if
you
don't
have
good
docs.
If
other
people
are
writing
blogs
or
other
things.
I
know
that's
like
a
comment
out
so
like
sometimes
I
I
often
see
like
kind
of
maybe
it's
just
new
programmers
up
and
coming
like
they
are
not
as
good
at
perusing
and
reading
docs,
and
they
definitely
will
google
something
first
and
oftentimes.
G
The
thing
that
does
come
up
is
the
documentation,
which
is
a
good
sign
for
the
documentation
and
for
the
indexing,
because
it
is
being
referenced,
a
bunch
of
places,
but
yeah
I
mean
I
I
do
think
people
tend
to
instead
of
having
to
navigate
the
docs
and
find
it
themselves
there.
They
will
just
try
to
google
a
thing
and
then
read
kind
of
whatever
comes
first.
B
Oh
okay,
great,
let's
do
another
silent,
read
on
section
two.
Was
that
the
right
amount
of
time
you
want
a
little
bit
less
a
little
bit
more.
A
Maybe
I
think
his
internet
connection
has
been
not
great,
but
I
guess
we'll
just
open
the.
D
D
Yeah,
I
guess
so
got
some
thoughts,
which
is
when
I
read
a
lot
of
this
stuff
about
difficulties.
People
have
adopting
it.
It
just
looks
like
a
snowball
problem
where,
once
we
start
getting
momentum,
a
lot
of
this
stuff
becomes
less
difficult,
but
who
can
we
like
pull
in
to
start
the
snowball
like
who
can't
who
gets
so
much
value
out
of
this
project,
but
they
can't
possibly
be
like?
Oh,
these
other
checks
against
it,
which
are
really
just
like
who's
making.
These
don't
weigh
that
down
right.
B
Yeah,
I
think
that's
a
really
good
point.
It's
super
interesting
to
think
about.
Like
you
know,
we
know
that
this
product
can
be
challenging
under
certain
circumstances,
for
for
some
people,
and
so
who
are
the
people
who
are
so
compelled
by
the
value
prop
that
they
will
be
willing
to
suffer
through
the
challenges
of
product
in
order
to
get
the
benefits,
I
think
there's
maybe
another
way
to
say
what
you're.
B
E
E
Packs
because
they
don't
know,
go
well,
don't
write
it
and
go
right,
failed,
build
pack
builds
or
a
black
box
to
troubleshoot.
Well
right,
better
logs.
I
love
the
one
that
says
the
logs
are
explicit.
I
still
don't
know
what's
going
on,
but
it
appears
that
that's
probably
the
same
guy
who
says
you
can
always
write
a
build
pack
is
not
an
answer,
and
I
guarantee
that
guy
says
just
write.
E
A
doctor
file
is
actually
always
an
answer,
but,
like
all
of
these
basically
look
like
we
have
a
problem
with
build
pack
implementations,
not
with
build
packs
as
a
structure,
and
then
I
guess
the
question
to
ask
ourselves:
is
there
something
in
the
nature
of
build
packs
that
causes
them
to
suffer
from
all
of
these
things?
Or
is
it
because
the
build
pack
implementers
have
opted
to
do
things
that
are
problematic.
D
I
think
I
generally
agree
with
that,
except
I
think
there
is
a
little
case
here
where
it's
like
the
extensibility
of
or
like
that
you
know
like
when
something
goes
wrong,
you're,
just
kind
of
stuck
in
a
way
that
you
aren't
without
profile
like
that
is
sort
of
inherent
to
build
packs,
and
there
are
things
we
can
do
about
that.
But
I
mean
I
generally
agree
with
you.
D
So
I
think
the
I
don't
want
to
like
jump
to
solution,
but
I
think
like
what,
in
particular
in
that
top
row
in
the
middle,
there
is
like
begging
for
the
inline
build
pack
where
it's
like.
I
can
just
drop
this
thing
in
my
phone
and
my
repo,
and
it
runs
this
extra
command
like
rake
db,
migrate
or
whatever.
You
know
so,
and
I
think
that's
like
that
is
an
inherent
limitation
of
build
packs.
D
But
I
I
mean
I
still
totally
agree
with
you
about
the
implementation
point.
B
Well,
another
another
sort
of
framing
on
it
might
be
like:
how
might
we,
how
might
we
better
support
our
build
pack,
implementer
teams
and
projects
that
are
associated
so
that
you
know
help
them?
You
know
conform
to
what
we
believe
might
be
some
best
practices
around
doing
this
to
resolve
this.
You
know,
how
can
we,
potentially
you
know,
be
advisors
or
thought
leaders
to
have
to
them
to
avoid
some
of
these
pitfalls.
E
F
I
got
a
couple
things.
One
is
as
much
as
people
said
they
didn't
care
about
documentation
like
half
of
the
usability
complaints
in
here
were
like
this.
One
thing
wasn't
in
the
docs
I
didn't
know.
I
could
do
this
because
it
wasn't
in
the
docs,
so
I
do
think
that
that's
a
signal
that
people
care
think
care
about
usability
and
part
of
that
is
documentation,
even
if
they
don't
make
that
connection
themselves.
F
The
sort
of
off-the-wall
thing
I
was
wondering
is:
could
we
write
some
sort
of
shim
that
would
turn
a
docker
file
into
a
build
pack?
If
people
want
to
be
familiar
with
the
syntax
like
that,
like
it
runs
in
the
after
and
commands
like
you
know,
label
run
end
entry
point.
E
F
F
Yeah,
a
simple
dsl,
maybe
a
simple
dsl
that
looks
like
I
guess
this
gets
into
the
whole.
What
was
it
called
pac
file
thing
exactly,
but
I
wonder
if
just
making
something
look
familiar
would
get
more
people
being
willing
to
try
it
and
work
through
the
pain
points,
because
I
don't
know
if
tomml
is
exciting
to
people
like
that
they're,
not
I
don't
know
if
people
look
at
tom
will
and
think,
like,
oh
yeah,
I
totally
know
what
to
do
here
like
maybe
we
need
to
revisit
pac-file,
but
with
a
simpler
flatter.
G
I'll
send
a
comment
on
emily's
comment
like
I
wonder:
if
that's
what
inline
build
pack
if
inline
build
pack
is
not
solving
that
problem,
you're
saying
emily,
then
maybe
we're
not
doing
it
right.
Maybe
we
do
need
to
eject
that
tamil,
but
I
do
think
like
that
is
kind
of
the
goal
right
like.
G
Let's
make
it
easy
for
people
to
kind
of
do
this
stuff,
but
we
do
have
more
restrictions,
and
so
I
think
we
should
be
making
it
possible
for
people
to
kind
of
really
easily
write
stuff
that
you
probably
would
write
in
a
docker
file.
Given
those
constraints.
F
G
B
J
J
I
put
some
sticky
notes,
I'm
just
since
people
are
just
keep,
I
mean
it
looks
like
people
are,
keep
telling
like
how
docker
is
so
great
and
they
trust
it
and
they
like
it's
very
easy
to
get
familiar
with
this.
So
I
don't
remember
the
point
where
I
got.
I
mean
I
started
working
with
docker
files,
so
I
don't
remember
what
made
me
like
feel
comfortable
with
this,
but
I'm
wondering
if
we
can
do
something
very
similar
so
to
our
project.
J
I
just
I'm
not
sure
how
to
I
mean
we
should
try
to
pick
someone
that
is
not
familiar
with
docker
and
and
see
how
he
can
he
gets
familiar
with
this,
but
yeah
I
I
just
I
mean
personally.
I
just
don't
remember
how
I
mean
what
happened
to
me.
K
K
It
was
hard
the
companies
to
to
go
into
the
containers
course
and
stuff
right.
Then,
at
some
point
everybody
was
using
it,
so
they,
the
company,
said,
says:
okay,
we
have
to
move
to
this
container
stuff.
I
don't
know
how
we
are
going
to
do
it,
but
we
have
to
do
it
because
everybody's
using
it
and
everybody
is
moving
to
that,
so
they
start
using
docker
and
everybody
start
learning
docker
and
right
now
you
can
pick
up
someone
in
icy
war
and
do
you
know
docker?
K
K
And
after
you
get
into
that
point,
then
you
can
improve
the
documentation
and
stuff
and
because
at
the
beginning
the
documentation
from
docker
was
not
so
good.
So,
but
they
reached
that
point
where
everybody
was
using
it
and
it
you
know,
and
then
you
move
there,
so
I
think
and
and
and
when
I
can
see
buildback.
K
I
know
that
if
we
are
able
somehow
I'm
not
sure
I
just
two
weeks
here
so,
but
if
if
if,
if
we
are
able
to
you
know
to
getting
to
that
point
where
I
don't
know
some
huge
partner
is
using
and
they
said,
I'm
using
buildback
and
buildback
solved
me
these
issues
and
this
stuff.
So
probably
some
others
are
going
to
listen
and
say,
but
that
guy
solved
his
problems
with
buildback.
K
So
let
me
try
to
do
it
and
if,
if
we
are
able
to
to
hit
that
probably
will
will
reach
some
popularity
and
and
then
will
people
will,
you
know,
go
into
and
try
to
understand
how
it
works
and
and
all
these
things
that
they're
saying
is
difficult
or
it's
probably,
we
can
improve
that,
and
obviously
we
can
do
that.
But
I
believe
the
thing
is
how
we
can
hit
some
popularity
with
the
tool,
because
after
that,
everything
else
will
become
probably
the
guys
that
says
now.
K
I
I
prefer
to
go
to
docker
it's
better,
because
I
already
know
it.
No
probably
with
kobernetis
was
was
the
same
thing
at
the
beginning.
Nobody
was
using
it
at
some
point,
popularity
was
reached
and
then
everybody
start
talking
about
kubernetes
and
everything.
So
that's
what
I
feel
from
the
comments
and
stuff
for
me.
Popularity
is
actually
the
key
point
in
the
game.
If
we,
if
we
do
that,
then
everything
else
will
be
more
easy
because
we
have
many
people
on
our
shoulders,
but
I
don't
know
how
exactly
to
reach
it
but
yeah.
B
Yeah
totally,
I
know
we're
at
the
top
of
the
hour
here
so
folks
need
to
leave.
That's
fine.
I
see
sam
as
hand
raised
just
wanna,
give
him
a
chance
to
speak
and
then
to
see
you
all
next
week
and
we're
gonna
do
more
dig
into
some
of
the
initial
assumptions
that
we
validated
and
invalidated
talk
about
those
and
then
also
talk
about
next
steps.
An
action
item
so
hope
to
see
you
same
time
next
week,
but
before
we
break
wanted
to
hear
from
you,
sam.
I
Yeah,
I
I
just
wanted
to
bring
up
that
point
about
someone
new
to
docker
learning,
docker
files.
I
think,
like
I've,
seen
new
hires
completely
new
to
dockerfile,
like
start
with
it,
and
they
can
read
the
dockerfile
like
they're
reading
bash
script,
so
like
something
else
they're
familiar
with
where
they
know
run.
That
means
this
command
would
be
wrong.
I
Copy
means
something
would
be
copied
or
like
at
least
those
two
basic
instructions
are
very
easy
for
someone
to
understand,
even
if
they
don't
know
what
docker
is
or
what's
happening
underneath,
and
even
if
you
compare
some
like
really
similar
tool,
which
does
they
have
similar
operations
like
builder,
which
has
like
a
random
copy
on
the
because
it
exposes
something
slightly
like
it,
it
exposes
the
fact
that
you're
running
some
other
random
command,
which
is
creating
these
ocr
layers.
That
gets
a
bit
harder
for
people
to
grasp,
as
opposed
to
simply
saying
that.
I
Okay,
I
don't
care
about
oci
images,
I
just
care
about.
Okay,
these
are
the
random
series
of
commands
that
I
have
to
run
and
the
output
would
be
like
if
I
start
from
this
base
image.
I'm
running
these
commands,
that's
my
output.
They
don't
care
about,
what's
happening
underneath
and
being
able
to
provide
something.
I
Similarly,
intuitive
is,
I
think
what
would
help
people
who
are
new
to
the
project
adopted
currently
build
packs
are
shorter
in,
like
so
many
terms
and
layers
that
people
don't
even
like
as
soon
as
they
start
they
give
up
and
unless
they
really
really
want
to
have
like
they,
they
are
sort
of
looking
at
these
features
and
resonating
with
their
past
problems,
at
which
point
they're,
probably
some
like
some
dev
set
cops
person
who's
like
dealing
with
it
on
a
large
scale,
rather
than
a
singular
person.
I
D
B
I
think
that's
all
for
today.
Folks,
thank
you
all
so
much
looking
forward
to
talking
again
next
week
do
one
more
read
and
then
next
steps
items.
So
thank
you
again.