►
From YouTube: Working Group: 2021-01-13
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
A
Yeah,
I
spent
a
fair
amount
of
time
with
pat
and
he
was
a
good
guy
until
we'll
be
lucky
to
have.
B
Him,
I'm
sure
they'll
scoop
up
they'll,
probably
scoop
up
some
of
the
old
hires.
They
had
to
scoop
up
some
companies
to
bring
them.
B
B
C
A
B
B
F
Oh
that's.
Good
steven
is
unable
to
make
it
to
the
first
half
of
the
meeting,
so
I'm
gonna
do
my
best
to
facilitate
just
remind
everyone
to
please
sign
into
the
document
and
going
with
our
standing
item.
Do
we
have
any
new
faces
today.
F
Okay,
I
guess
moving
on
to
the
next
item:
release
planning
and
updates.
Does
anyone
want
to
speak
to
that.
G
I
can
speak
to
pack
that
was
released
earlier
today.
We
released
version,
oh
160,
which
has
a
sub
command
reorganization
and
some
improvements
to
the
build
pack
uris.
So
yeah.
You
should
be
able
to
get
that
through
your
typical
package
manager.
A
G
Yes,
that
was
actually
an
older
version
of
pack,
the
the
release
the
o160
fixed,
what
she
was
running
into,
and
it
wasn't
so
much
a
critical
bug
that
we
needed
to
fix.
Otherwise.
C
Now
much
to
add
in
the
lifecycle
front
we're
starting
work
on
the
new.
A
Apis,
since
I
see
matt
on
the
list,
have
you
had
any
trouble
integrating
the
new
version
of
the
lifecycle
into
kpac,
or
is
that
all
going
pretty.
B
Smoothly
released
the
new
version
of
the
life
cycle
as
a
patch
release
in
kpac
just
yesterday,
015
and
we'll
be
releasing
configurable
lifecycle
support
in
the
next
release.
Okay
back
hopefully
in
a
week
or
two.
F
All
right,
I
guess,
moving
on
to
outstanding
rfcs,
I
can
go
ahead
and
share
my
screen.
Let
me
try
to
share
the
right
one.
F
All
right,
the
first
one
is
add
image
working
directory,
rfc.
F
Great
move
layer
types
to
new
table
in
layer
tunnel.
I
open
this
rfc.
I
should
probably
add
it
to
the
agenda
as
well.
E
F
Great
add
lifecycle,
configuration
file.
B
E
F
Great
the
next
one
is
cnb
user
research.
I
don't
see
sam
on
the
call
today,
but
I
can
share
that.
We
had
our
first
user
interview
this
morning,
working
off
of
a
script
that
was
derived
from
the
feedback
given
here,
and
it
was
really
interesting.
So
I'm
very
much
looking
forward
to
sharing
those
findings
and
iterating
on
on
them
for
future
interviews.
F
So
I
guess
moving
on
rfc
to
create
stackify
repo.
Do
we
have
marty
today.
C
I
just
left
a
fairly
long
review
yesterday.
I
don't
think
all
of
the
core
team
has
reviewed
it.
So
I
say
the
update
is:
please
take
a
look.
E
F
That
there
is
supposed
to
be
multiple
rounds
of
interviews,
so
the
first
round
is
kind
of
based
off
of
what
is
described
in
the
document,
but
I
think
there's
also
going
to
be
an
opportunity
to
do
more,
like
user
testing
or
experimentation.
F
That
could
also
benefit
from.
I
think
input
from
this
group.
So
would
that
be
a
separate
rfc
to
get
feedback
on
that
particular
type
of
interview.
D
I
don't
know
if
it
has
to
be
an
rfc
necessarily,
I
don't
know
if
maybe
we
use
the
actual
github
discussion
thing
that.
G
Is
this
our
sorry
is
that
rfc,
then
only
inclusive
up
until
the
initial
interview?
Is
that
what
we're
saying
and
then
put
it
up
to
for
fcp
that
way
and
continue
moving
forward
via
other
means,
like
the
discussion
board,.
D
G
F
F
F
All
right
talked
about
this
one
application.
Mix-Ins
is
a
draft
so
we'll
skip
it
stack,
packs.
C
B
B
F
Great
all
right,
I
guess,
then
we
can
move
on
to
the
first
item
on
the
agenda
image
working
directory.
H
That
would
be
me,
okay,
see
if
I
can
share
my
screen.
H
H
It
would
be
nice
to
be
able
to
set
a
working
directory
on
the
constructed
run
image,
at
least
so
that
when
users
are
executing
into
those
into
like
made
up
containers
or
existing
containers
or
running
new
containers
or
even
copying
things
out,
the
like
normal
docker
commands
can
do
that
and
the
platforms
don't
have
to
do
anything
special
here
in
order
to
like
copy
or
execute
the
right
place
for
a
little
bit
more
background.
H
Toku
supports.
Doku
is
the
platform
that
I'm
I
manage
it's
an
open
source
platform.
It
supports
both
dockerfile
and
heroku's,
build
pack,
v2a
spec,
and
in
adding
the
cloud
native
buildback
support
to
it.
It's
pretty
simple,
just
wraps
pack,
but
for
copying
files
out
or
for
exacting
into
existing
containers.
H
H
What
we
could
for
what
I
had
previously
was
a
hard
coding,
slash
app,
which
works
fine
for
heroku's
v3
stack,
but
it
doesn't
work
for
like
the
spring
cloud
buildbacks
that
exist,
which
I
believe
use,
slash
workspace,
which
is
the
default,
and
I've
also
got
conflicting
information
from
folks
in
the
community
that
are
using
this.
That
say
that
the
working
directory
should
be
slash
root.
So
if
I
had
something,
I'm
like
the
image
says
it's
the
working
directory,
slash
workspace,
then
that
would
be
what
we
would
use.
H
The
alternative
here
is
to
inch
and
I
can
document
this
in
rfc.
The
alternative
here
is
for
the
platform
to
introspect
on
the
cnb
actor
environment
variable
which
is
injected
into
the
built
run
image,
but
that's
fairly
cnb
specific
and
not
something
that,
like
would
be,
I
mean
you
could
fall
back
to
work
there
in
every
other
case,
but
it
seems
kind
of
silly
to
have
something:
that's
specific
to
the
platform
when
it's
easy
for
us
to
just
inject
that
property
to
the
built
image.
H
So
that's
in
a
nutshell,
what
the
rfc
is
for
the
change
would
be
fairly
straightforward,
just
modifying
export.export
in
the
lifecycle
to
set
the
working
directory,
I'm
happy
to
make
the
change.
If
other
folks
think
it's
a
reasonable
change,
and
if
it's
not
I'm
happy
to
hear
what
I
should
do.
A
A
The
guarantee
is
that
the
working
directory
during
build
and
the
working
directory
during
execution
of
the
process
are
the
same.
The
mechanism
for
doing
that
appears
to
be
an
environment
variable
called
cnb
after
or
the
the
mechanism
for
finding
out
what
that
directory
is.
That
was
is
that,
instead
of
working
directly
on
the
outbound
image,
but
I'm
not
sure
why
we
chose
that
strategy
for
the
for
the
built
image.
C
C
I
would
not
change
the
launcher
like
if
someone
ssh
is,
you
know,
someone
gets
a
shell
into
the
container
and
is
in
some
other
directory,
and
they
run
the
launcher
and
the
launcher
runs
some
build
pack.
Exec
dscript
or
something
you'd
still
want
to
enforce
the
spec
and
ensure
that
those
things
are
run
in
the
after,
regardless
of
what
the
working
door
is.
But
I
think
in
addition
to
that,
we
could
set
the
working
door
so
that
it's
a
sensible
default.
E
Yeah,
it's
an
input
to
the
launcher
so
going
along
with,
like
all
the
pattern
that
we
have
for
all
inputs,
there's
flag,
mvar
default
value,
and
I
think
we'd
want
to
keep
that
anyways.
I
mean
the
working
door.
Thing
is
more
of
like
a
outside
of
that,
like
I
feel
like.
There's
like
this
internal
and
external
view
of
it,
and
working
dur
is
definitely
something
we
definitely
want
to
move
towards
using
those
primitives
the
same
primitives
that
anything
else
in
the
ecosystem
would
use.
H
E
Yeah,
so
the
process
will
be
yeah.
The
I
mean
the
sort
of
pedantic
process.
Is
we
all
vote
on
it
and
have
them?
You
know
have
time
to
comment
on
it.
I
think
this
one
will
go
very
quickly.
I'll,
certainly
vote
on
it
today
after
I
just
give
it
a
read
through
make
sure
I
didn't
misunderstand
anything
and
then,
if
after
it
has
the
right
votes,
a
majority
of
votes
technically,
but
usually
we
wait
for
consensus
from
the
core
team.
E
It
goes
to
one
week
final
comment
period
and
then,
at
the
end
of
that
period,
it's
finalized.
So
I
mean
none
of
that.
Prohibits
you
from
going
ahead
and
making
the
pr
we
may
as
a
team,
just
not
merge
pr
until
the
rfc
is
in,
if
we're
being
pedantic,
but
I
mean
I
was
just
this
morning
trying
to
convince
emily
that
we
should
not
do
that
for
a
particular
issue.
So
there
can
be
exceptions.
In
my
opinion,.
A
This
is
an
interesting
leadership
meeting
as
well
today,
I'll
have
to
catch
you
up
natalie.
Can
I
get
you
to
tag
this
thing
with
the
team
that
it
should
actually
apply
to?
This
sounds
like
an
implementation
team
in
the
way.
Is
that
correct.
G
Sure,
also
just
to
make
sure
I
understand
it
would
this
also
mean
that
there
there
would
be
a
restriction
or
a
tie
between
the
working
directory
set
on
the
oci,
manifest
or
config
file,
and
the
environment
variable
like
those
must
always
equal.
H
I
don't
know
yeah
so
like
if
a
particular
stack,
for
whatever
reason
wanted
to
deviate
from
workspace
being
the
workspace
the
com,
the
contract
would
be
that
they
would
have
to
set
the
working
dir
oci
manifest
property
to
be
whatever
it
is
that
their
stack
has
right.
E
The
core
team
will
do
that.
So
whoever
ends
up
shepherding
the
rc
will
make
sure
that
an
issue
is
open
for
the
spec
to
make
that
change.
D
G
C
C
A
Turn
around
given
when
we
first
saw
you
ask
the
question.
F
All
right
next
on
the
agenda
is
move
layer,
types
to
new
layer,
new
table,
and
that
was
my
rfc.
So
I'll
share
my
screen.
F
So
I
had
this
up
as
a
draft
for
a
while
and
just
marked
it
as
ready
today.
So
I
I
imagine
that
not
many
people
been
able
to
look
at
it,
but
just
to
give
a
brief
introduction
to
what
it
is.
This
is
sort
of
a
follow-on
to
the
opt-in
layer.
Caching,
rfc.
F
We
realized
that
that
will
be
awkward
for
bash
build
pack
authors,
because
the
launch
building
cache
keys
are
currently
at
the
top
level,
so
simply
appending
to
the
layer.
Tommle
is
not
going
to
work
to
to
set
them
so
to
remedy
that
this
rfc
is
proposing
a
new
table
in
layer
tunnel.
That
would
you
know
make
this.
G
So
so
what
you're,
trying
to
be
able
to
with
a
single
command
from
bash
be
able
to
append
something?
I
have
two
two
trainer
thoughts,
so
this
is
only
like
new,
because
there's
a
new
meta
like
this
is
a
new
issue,
because
there's
a
new
metadata
table,
that's
being
generated
from
somewhere
else.
Is
that
right.
F
F
So
sorry,
when
the
life
cycle
restores
the
layer
tunnel,
these
keys
will
be
gone
right
and
metadata
will
be
there
as
a
table
with
you
know,
whatever
data
is
already
there
and
then
in
order
to
to
specify
these
keys
you'd
either
need
to
put
them
at
the
top
of
the
file
right.
So
you
need
to
prepend
them
or
you
can
put
a
new
table.
You
know
call
it
whatever
you
like
and
then
and
then
set
them
at
the
end
of
the
file.
G
G
H
A
E
A
It
it's
totally
not
convenient,
because
you
effectively
have
to
write
to
a
temporary
file
cap,
the
previous
file
to
the
temporary
file
and
then
delete
the
previous
file
and
move
the
the
temporary
file
back
to
that
particular
name
like
prepend
is
not
a
thing
in
the
bash
world.
Yeah.
A
A
F
I
guess
the
only
thing
about
this
rfc
that
potentially
makes
or
could
make
things
more
complicated.
Is
you
know
the
potential
to
rename
the
keys
while
we're
here?
I
know
that
that's
sort
of
been
floated
previously
that
maybe
launch
build
and
cache
are
not
the
most
clearest.
Oh,
do.
A
D
Commented
on
the
rfc
that
I
think,
if
it's
reasonable
to
make
that
change,
but
I
think
it's
out
of
scope
of
this
particular
rfc,
like
I
think
it's
reasonable
to
couple
this
rfc
and
another
rfc.
D
That
is
just
the
name,
change
and
implementation-wise
going
out
together,
but
I
don't
think,
given
the
motivation
of
what
you're
talking
about
like
in
the
earlier
section
of
your
rfc
like
it,
has
nothing
to
do
with
name
changing.
So
it
seems
out
of
scope.
In
my
opinion,.
C
At
the
right
time,
I
used
to
be
in
favor
of
the
name
change.
I
started
to
feel
like
the
right
time
to
make
this
name
change
when
we
first
brought
it
up
two
years
ago.
At
this
point,
we
use
these
terms
everywhere,
and
people
who
are
using
the
ecosystem
are
very
familiar
with
the
terms
and
be
a
huge
pain
to
change
it.
E
C
E
A
How
about
I'd
like
to
split
the
difference
here
and
basically
say
it
should
not
be
part
of
this
spec
or
start
not
be
part
of
this
rfc,
but
if
we
are
going
to
do
it,
it's
going
to
go
in
whatever
the
same
spec
changes.
This
rfc
goes
into
like
we.
We
should
sit
down
as
a
leadership
team
and
say
we're
going
to
do
it
or
we're
not
going
to
do
it,
and
this
is
our
opportunity.
I
So
if
we
make
the
change,
you
know,
I
think
somebody
brought
up
names
emily
that
if
we,
you
know
this,
this
could
be
a
big
change
for
a
lot
of
people
that
we're.
You
know,
we'd
be
changing
terms
that
are
pretty
widely
used
right
now,
but
it's
easy
to
make
the
change
without
breaking
any
build
packs
ever
right,
because
we
can
just
support
both
sets
of
keys
for
as
long
as
we
want.
We
make
the
changes
part
of
this
change.
I
Then
we
support
the
old
style
keys
on
the
outside
and
we
support
the
new
style
keys
on
the
inside
right
and
like
there
shouldn't
be
a
reason
why
you
know
this
causes
friction
for
buildback
authors.
It
would
just
be
in
documentation
and
in
discussion.
It
could
get
a
little
bit
confusing
for
a
while
and
just
for
reference
for
people
that
the
names
that
we
had
thought
of
were
export
for,
launch
and
expose
for
build,
because
we
felt
like
launch
and
build
didn't
really
cover
the
functionality
of
the
what
those
flags
meant.
D
H
D
Probably
the
only
other
thing
on
there
was
your
second
unresolved
question.
If.
D
That
is
in
the
scope,
which
is
the
naming
of
is
types
the
right
table.
Name
is
probably
something
I
think
would
be
good
to
get
input
on.
G
F
This
last
question
about
changes
to
the
label.
I
I
suspect
the
answer
is
no.
I
kind
of
put
this
here
actually
thinking
about
you
know.
If
we
did
rename
these
keys,
then
it
would
be
very
confusing
to
have
the
label
have
the
old
names,
but
as
far
as
I
can
tell,
there
doesn't
seem
to
be
a
requirement
that
this
label
has
the
same
schema
as
the
as
the
layered
tunnel,
so
it
shouldn't
need
the
types
right.
I
F
All
right:
well,
I
think
I
think
we've
covered
everything
so
I'll
make
those
updates-
and
please
add
your
comments,
all
right.
I
guess
last
on
the
list
is
a
prepare
analyzer
to
be
run
before
detect.
E
Yep
this
is
mine,
so
this
is
continuing
the
discussion
that
we
had
last
week
on
two
options:
analyzer
moving
before
detect
or
introducing
a
prepare
phase
before
detector,
with
the
purpose
being
to
validate
the
mixins
and
do
mix
again
mix
and
resolution
and
and
stack
validation
too.
You
know,
has
your
architecture
change
or
something
like
that
before
the
holiday
break
emily
and
I
were
working
on
this-
and
I
ran
into
some
problems
with
moving
analyze
before
it
just
kind
of
kind
of
got
messy.
E
It
makes
it
like
sort
of
optimistic
like
it's
going
to
restore
the
tamil
files,
whether
they're
gonna
run
as
part
of
the
build
or
not,
and
then
restore
would
be
responsible
for
just
like
nope
that
one's
not
in
the
group
delete
it
rather
than
the
way
it
works
today,
which
is
here's
the
group
tomml
for
the
ones
that
pass
detection
and
that's
what
we're
going
to
restore
the
thing.
The
the
part
that
was
a
real
blocker
that
I
was
concerned
about
turns
out
that
code.
Just
doesn't
run
like
I
was.
E
There
was
a
chunk
of
code
that
I
was
worried
about.
That
is
you
that
it
gets
executed
for
export,
but
based
on
several
several,
if
statements,
it
doesn't
actually
run
during
analyze.
So
that's
what
made
it
possible
to
open
this
pull
request
which
moves
prepare
before
analyzer,
both
in
creator
or
I'm
sorry,
moves
analyzer
before
detect
and
the
creator
and
then
deletes
the
group
flag
to
analyzer
this
matches
this
draft
spec
pr,
which
is
one
of
an
alternative
with
another
pr.
I
opened
the
prepare
phase.
These
are
essentially
identical.
E
One
is
proposing
a
new
phase
in
front
of
detect.
The
other
is
proposing
switching
analyze
and
detect
one
last
thing
before
we
go
into
discussion.
I
don't
think
we
should
get
hung
up
on
like
the
like
the
sort
of
like
what
is
it
like.
The
dichotomy
between
these
two,
like
the
real
thing
that
we,
I
think
we
know
we
want,
is
a
phase
at
the
beginning.
That
does
some
validation.
E
Maybe
has
some
credentials
to
talk
to
registries,
can
check
that
you
can
write
to
your
the
place
you're
trying
to
export
to
before
you
get
to
the
export
phase,
those
kinds
of
things
and-
and
you
know
how
we
want
to
go
about
that
is
really
the
question.
Do
we
want
to
shift
some
of
these
things
around
and
or
do
we
want
to
change
responsibilities
of
different
phases
or
introduce
new
phases?
That's
these
are
just
some
options.
Those
that's
the
big
question.
I
I
I
think
last
week
to
me,
it
seems
like
the
problem
is
that
we
need
you
know
we
have
this
interleaving
of
privileged
and
unprivileged
phases,
so
much
have
access
to
credentials
and
can
do
things
that
you
know
we
don't
want
to
happen
during
the
detect
phase
or
build
phase
which
need
to
run
untrusted
code
right.
I
So
having
a
phase
that
happens
before
detect
that
can
run
in
that
you
know,
more
privileged
mode
with
credentials
seems
like
something
we'll
eventually
always
need
to
have
or
like
something
will
eventually
drive
us
to
that
need
right,
and
now
that
we
have
you
know
we
have
the
first
thing.
That's
kind
of
you
know
that
might
encourage
us
to
do
that
right,
instead
of
swapping
the
other
phases
around
to
avoid
the
need
to
do
the
interleaving
that
will
eventually
become
the
you
know.
I
I
I
think,
will
eventually
become
the
architecture
anyways
we
might
as
well
just
keep
the
architecture
the
same,
keep
analyze
behaving
cleanly
with
only
pulling
the
stuff
of
the
detected
dual
packs.
You
need
right
and
introduce
the
privileged
phase
at
the
beginning,
and
then,
if
we
need
more
optional
steps
at
the
beginning,
we
can
do
those
too.
It
doesn't
the
fate
the
phasing
and
the
optionality
don't
feel
very
related
to
me.
If
that
makes
sense,
you
can
always
do.
Phases
can
always
do
optional
platform
specific
stuff.
C
The
one
thing
that
analyze
does
right
now
that
I
think
would
make
sense
to
do
before
detect,
is
look
at
the
previous
image,
because,
if
we're
doing
things
like
stack,
id
validation,
previous
image
stack
id
would
matter
for
whether
the
build
is
sane
like
whether
you
could
take
layers
from
the
previous
image
right
now.
Analyze
basically
writes
a
file
that
has
all
of
the
relevant
metadata
that
it
got
from
the
previous
image
that
is
used
called
analyzed
tomml.
C
It
also
takes
pieces
of
that
and
puts
them
in
layer
tommles
for
the
build
packs
to
use.
But
I
don't
think
we
should
have
to
reach
out
to
the
registry
for
the
previous
image
twice
and
if
we
want
to
do
some
validation,
I
think
we
should
take
the
part
of
analyzer
that
reaches
out
to
the
registry
and
grabs
metadata
from
a
label
and
puts
that
in
the
step
that
happens
before
detect.
C
I
think
once
you've
taken
that
out
when
you
describe
what
analyzer
does
it
restores
metadata
from
the
previous
image
to
the
layers
directory,
which
makes
it
seem
an
awful
lot
like
if
you
just
fold
into
restore
and
restore,
does
need
privileges,
because
the
cache
might
be
an
image
I
feel
like.
We
should
take
half
of
analyzer
and
put
it
in
the
repair
step
and
the
other
half
and
put
in
restore
and
once
you've
done
that.
I
might
argue
that
we
should
call
that
first
step
analyzer,
because
what
is
it
doing?
C
It's
like
looking
at
all
the
components
of
the
system
and
analyzing
them,
even
though
it's
not
setting
up
the
layers
directory,
but
I
don't
care
as
much
about
what
we
call
it.
I
just
think
that's
the
right
organization
of
responsibilities.
I
C
I
If
we
keep
this
functional
separation,
I
also
don't
care
what
we
call
the
layers.
If
we
can
combine
the
restore
and
analyze
steps
together
into
one
thing
called
restore,
and
then
somebody
feels
strongly
the
preparer
should
really
be
called
analyze,
even
if
it
might
do
more
more
than
that,
that's
okay
with
me,
I
I
don't
care
anymore
as
long
as
the
functional
description
yeah
that's
talked
about
is
okay.
E
E
Okay,
so
the
million
dollar
question
is
that.
Well
I
mean
that
makes
sense,
I'm
not
going
to
write
an
rfc
for
that,
I'm
going
to
open
a
pr
if
we
need
an
rfc,
I
can
do
that
in
parallel.
E
I
Unless
somebody
explicitly
says
they
want
to
see
an
rfc
out
of
something,
then
I
I
would
lean
against
rfc,
even
though
it's
a
larger
change
right,
because
we
did
commit
to
implementing
that
functionality
one
way
or
another,
and
we
do,
we
will
have
core
team
review
of
the
spec
pr,
but
that
may
be
controversial
or.
I
It
could
be
a
very
brief
rfc
about
the
high
level
you
know:
kind
of
movement
of
the
names
or
whatever
of
the
different
phases.
You
know
that
goes
through
quickly,
but
I'm
I'm
not
saying.
I
think
that
that's
necessary
only
that
if
folks
are
concerned
that
we're
not
giving
the
community
time
to
provide
feedback
on
the
organization
of
the
stages,
then
I'd.
D
It's
working
now,
yeah
yeah,
oh
yeah,
the
this
was
brought
up
and
legit
me
weren't
doing
spec
car,
but
the
the
biggest
concern
I
had
was
mostly
reading
the
spec.
Pr
was
hard
to
kind
of
understand
context
without
any
of
it
and
motivations
behind
it
like
I
knew
about
stack,
packs
and
stuff,
but
it
was
a
little
harder
to
read
the
spec
pr.
Besides
the
actual
few
line
changes,
it
was
just
like
what
is
this
like.
D
I
knew
of
the
prepare
phase,
but
just
like
goals
and
descriptions
and
kind
of
the
stuff
stephen
was
talking
about
like
high
level
stuff.
I
think.
B
E
Well,
in
any
case,
do
look
at
the
spec
pr,
because
I
think
I
guess
even
the
name
there
might
be
something
here
that
needs
touching
up
regard
with
regards
to
the
split
that
we
talked
about,
but
I
think
in
general
the
stack,
validation
and
the
mix
and
resolution
will
be
the
same.