►
From YouTube: Working Group: 2021-04-07
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
Thanks
for
reminder
seems
like
we
don't
have
any
new
faces,
so
we'll
jump
into
release,
planning
and
updates.
B
Yep
trying
to
see
if
dan
was
here-
yeah,
yes,
but
I'll
I'll
speak
to
it.
We
are
thinking
about
releasing
a
patch
for
pac
that
has
to
do
with
the
issue
that
emily
and
jesse
brought
up
in
regards
to
duplicate
layers
on
build
packs,
so
we're
hoping
to
work
through
some
of
that.
I
think
dan's
gonna
be
taking
that
on.
C
On
the
implementation
side,
we
shipped
the
lifecycle
last
week
and
then
we
shipped
a
patch
two
days
later,
just
kicking
off
the
planning
for
the
next
release,
o
12-0,
which
will
have
stack.
C
A
A
So
a
bunch
of
these
are
opened
by
sam.
I
think
it's
here
today.
I
actually
took
those
and
put
them
separately
on
the
agenda
because
emily
and
I
had
a
chance
to
kind
of
sync
up
on
you
know,
I
think
some
things
we
never
got
to
resolving
during
you
know
different
working
group
meetings
about
you
know
how
we
could
more
strategically
push
some
of
those
forward.
A
They're,
really
good
ideas,
and
I
want
to
make
sure
that
we
kind
of
leave
space
to
you
know
talk
about
them,
and
so
I
actually
took
those
and
put
them
separately
on
the
agenda
in
a
thing,
and
we
can
touch
on
them
here.
But
you
know
just
note
that
they'll
be
over
there.
Sam
is
that
okay.
D
A
Awesome
definitely
don't
want
to
leave
you
hanging.
I
know
some
of
those
are.
You
know,
I
think
one
one's
from
about
a
month
ago,
all
right.
So,
let's
start
at
the
top
additions
to
rfc
template.
Where
are
we
with
us.
C
Just
open
that
one,
I
think
it's
just
looking
for
eyes
and
comments.
A
C
E
C
C
C
Also
just
open
this
one,
I
kind
of
felt
was
most
relevant
to
the
implementation
team.
A
Yeah
we
should
copy
the
template
to
anyone.
Cool
sounds
good.
Is
this?
Does
this
need
a
label?
It
has
labels
on
it
already.
A
A
And
sorry
to
refresh
next
thing
is
add:
rfc
for
interaction
mode.
That's
draft
add
bomb
to
layer,
content
metadata.
I
put
this
one
on
the
agenda
today
to
chat
about.
I
don't
think
we're
looking
for
anything
else.
Besides
more
feedback.
A
So
skip
over,
it
propose
creation
of
best
practices
and
guidelines.
I
didn't
actually
put
this
one
on
there,
because
it's
more
about
documentation.
B
A
Pack,
cash
is
a
draft
allow
setting
default
command
arguments
that
can
be
overridden
by
the
user.
This
is
not
when
I'm
on
the
agenda
emily
and
I
had
a
chance
to
talk
about
this
and
want
to
propose
a
maybe
an
easy
path
or
a
path
forward
that
wouldn't
change
this
rfc
too
much
but
may
introduce
some
other
breaking
changes,
but
we
can
save
that
for
the
agenda,
build
runtime
user
ids.
A
A
E
You
had
some
concerns
around
this,
but
they
were.
A
We
can
talk
about
that
when
we
get
to
it
disambiguate
layer,
metadata
files
for
map
metadata.
Also
put
this
one
on
the
agenda.
A
Guidelines
for
accepting
compilable
contributions
is
mine,
and
I
still
need
to
provide
feedback
there.
Issue
generation
is
javier's
where's
where's
this
going.
A
Project
descriptor
domains,
rfc,
is
an
scp
anything.
This
need
who's
the
shepherd
for
it.
Javier
has
issues
created.
C
B
B
I
think
you
could
do
I
didn't
you
could
do
a
team
call
out
right
so
build
backslash,
implementations,
maintainers
and
then
distribution,
maintainers.
C
A
A
C
Yeah
I
put
this
so
yesterday
we
had
a
meeting
about
the
intro
video
under
I
put
a
link
to
the
github
discussion
about
this.
We
had
some
brainstorming
about
what
to
have
in
this
video
and
we
split
it
to
two
sections
like
what
and
why-
and
the
thing
is
that
we
realized
that
we're
not
sure
how
to
put
in
one
sentence
like
a
clear
and
short
sentence.
C
C
I
guess
that
we'll
get
good
ideas
from
this
like
twit,
but
joe
suggested
it
we'll
bring
this
up
in
this
working
group.
So
here
we
are.
F
Yeah
one
of
my
concerns
with
soliciting
broadly
for
it
is
that
well
there's
two
one
is:
we
might
not
actually
get
the
right
answers
like
I'm,
not
sure
I
want
to
shape
that
sentence
based
on
people
kind
of
guessing
at
what
it
is,
and
then
the
other
part
of
it
is
like.
F
It
feels
like
something
that
we
should.
I
don't
know
if
top
down
is
the
right
phrase,
but
it
feels
like
that's
something
that
should
come
from
us
rather
than
we
collect
you
know
from
the
community.
So
that
said,
one
of
the
things
I
suggested
was
that
we
seed
the
conversation,
so
I
actually
just
had
a
chance
to
look
at
the
the
thing
with
the
sticky
boards
that
that
he
sent
me
in.
F
Those
are
those
are.
I
think
that
that
kind
of
idea,
like
you
know,
seeding
it
with
those
sort
of
sentence,
fragments
might
be
an
option.
I
think
I
mean
to
me
it's.
F
They
turn
source
code
into
oci
images
that
definitely
doesn't
capture
everything,
but
it
may
not
be
possible
and
certainly
like
in
shaping
any
kind
of
like
concise
message.
It
has
to
be
imperfect,
I
think
so
it
might
be
just
to
trade
off.
A
I
think
if
I
describe
what
the
project
is,
I
would
say
things
that
are
more
like
you
know
at
scale
or
you
know,
operator,
developer
balance,
whereas
somebody
else
who's.
You
know
just
focusing
on
the
developer.
Experience
describe
what
the
product
is,
they
might
focus
on
different
things,
and
so
it
may
be
a
little
hard
for
us
to
come
up
with,
like
you
know
something
that's
more
specific
than
just
it's
some
stuff
that
builds
oci
and
just
right
to
some
extent.
F
Yeah
in
the
past,
we've
used
the
higher
level
abstraction
phrase.
At
times
it
seemed
like
that
worked
really
well
at
times
it
seemed
like
it
didn't,
but
I
think
overall
I
was
happy
with
it.
B
Yeah,
I
think
yesterday,
through
the
workshop
right
now.
I
think
a
lot
of
this
requires
the
context
of
the
workshop
to
really
try
to
understand
what
we
were
trying
to
aim
for,
but
it's
it's
ultimately
trying
to
create
this,
like
you
know
the
way
it's
phrased,
it's
like
this
one
minute,
intro
into
build
packs
right
and
what's
the
best
that
we
can
do
in
order
to
kind
of
pitch,
build
packs
and
make
it
something
that's
very
comprehensible,
so
that
people
don't
get
turned
off
from
just
looking
at
a
you
know.
B
I
think
it
was
a
lot
of
it
was
based
on
the
feedback
that
we
got
from
that
tweet
that
was
shared
in
the
learning
team
channel.
So
it's
kind
of
trying
to
answer
that
right
or
simplify
that
I
don't
know
if
that
helps,
but
we're
definitely
trying
to
keep
it
short
and
sweet.
To
that
extent,.
F
Do
you
think
it's
more
important
to
capture
the
what
or
the
like
the?
Why,
like,
I
think
what
stephen
was
alluding
to
is
the
that's
why
I
would
use
it
is
because
it's
scalable
or
even
from
a
developer
experience,
because
it
means
I
don't
have
to
do
these
things
like
I.
I
don't
have
to
know
how
to
like
construct
a
docker
image
versus
the.
How
which
is
like
what
I
originally
stated.
It
turned
source
code
into
container
images
or
not
the
how
but
the
what
right.
Personally.
E
B
B
A
Or
for
building
oci
images
from
source
code,
but
as
soon
as
you
get
into
the,
why,
though,
like
like
everything,
you
know
joe
said
about
abstraction
and
you
know
don't
have
to
understand
how
to
write
a
docker
file,
I
say
none
of
that
is
how
I
you
know
I
talk
about
it
like.
I
think
that
y
is
a
a
paragraph,
not
a
you
know.
If
we
have
that,
why
right
it's
a
lot
of
different
points
that
mean
different
things
to
different
users.
A
C
F
So
yeah,
so
I
didn't
mean
to
like
drag
us
back
into
a
discussion.
You
probably
already
had
the
other
day
in
the
workshop.
I
think
the
the
question
that
you're
bringing
up
is
do
we
want
to
like
do
an
iteration
where
we
bring
everybody
in
or
do
we
want
to
solicit
to
the
community,
and
so
I
think
what
I'm
saying
is
like:
let's
do
one
iteration
with
the
broader
team.
Again
I,
like,
I
think
emily
mentioned
it
and
I
said
kind
of
a
similar
thing
of
turning
source
code
into
oci
images.
F
B
So
I
am
curious
to
like
what
what
the
the
next
steps
should
be
right,
because
I
think
the
the
workshop
like
at
least
one
iteration
of
the
workshop,
occurred
right
and
it
was
public
and
the
attendance
was
decent,
but
obviously
not
a
working
group
at
a
working
group
scale
right
so
do
you
have
any
proposals
on
you
know
the
format
right
like
how
do
we
solicit
all
this
information?
Is
it
one-on-one
with
all
the
individuals
that
we're
trying
to
get
their
input
on?
F
I'm
just
saying
we
put
down
some
concrete
ideas,
like
I
think
terence
just
had
one
I'd
probably
do
a
slightly
different
version
of
that,
and
if
we
can
get
consensus
on
those-
and
I
think,
like
I
think,
there's
some
valid
concerns,
like
some
people
have
said
like
that,
tweet
that,
what's
on
the
page,
isn't
clear
enough.
Interestingly,
though
I
have
actually
seen
a
couple,
people
tweeted
us
that
they
love
our
docs.
I
don't
know
if
I
shared
those,
I
don't
share
good
stuff.
I
only
share
bad
stuff.
I.
B
F
There
was,
there
was
just
a
thread
like
the
day
after
I
shared
that
that
people
love
our
docs,
so
we
we
may
want
to
take
that
with
a
grain
of
salt
but
yeah
so
yeah,
that's
that's.
My
response
is
like:
let's
take
one
pass,
where
we
put
some,
maybe
maybe
two
or
three
concrete
ideas
down
and
see
if
we
can
get
consensus
around
those
before
reaching
out.
B
C
Sure
I
can
edit
I
mean
it's
currently
on
the
learning
slack
channel.
Is
there
any
other
place?
I
should
put
it
on.
B
G
Sorry
so
I
do
know
this
was
in
draft
mode,
but
I
still
wanted
to
solicit
feedback
on
it.
The
idea
behind
this
rfc
is
just
that,
basically,
like
we
were
just
saying
pac
services,
a
bunch
of
different
audiences
right,
there's
the
operator,
maybe
someone
who
wants
to
build
their
own
paths
or
you
know,
and
a
casual
application
developer
and
in
particular,
I'm
more
interested
in
the
casual
application
developer.
G
I
don't
think
that
they
very
easily
see
the
value
proposition
of
bill
packs
as
they
are
today,
and
you
know
I
think
there
should
be
some
investments
from
somebody
somewhere
into
that
right
like
how
do
we
make
it
more
apparent
with
pack
the
main
entry
point
into
bill
packs
for
the
casual
application
developer
right
like
what
it
does
for
you-
and
you
know
I
put
some
thoughts
in
here.
Just
to
you
know,
get
the
conversation
going
along.
You
know,
I
think
some
cool
features
like
showing
things
that
get
updated
breaking
between
detection
and
compilation.
G
Some
of
these
things
would
sort
of
drive
it
forward.
But
you
know
a
picture
is
worth
a
thousand
words,
so
I
did
definitely
want
like
a
user
workflow
to
be
depicted
and
then
we
could
sort
of
work
from
there.
I
got
my
terminal
open.
Why
don't
we
like
give
this
a
shot?
Let's
say
I
have
my
my
pack
here
and
I
want
to
build
something.
G
We'll
have
the
detect
phase
run
in
my
application
directory
and
then
oh
as
an
application
developer.
Maybe
I
can
see
I
have
all
my
belt
back.
These
are
implementation.
Build
packs
right
here,
right,
like
these
are
my
steps
that
are
going
to
be
traversed
to
build
my
oci
compliant
image,
and
it's
important
that
I
get
a
nice
little
blurb
about
what
they
do
right
just
to
provide
some
insight.
G
We
have
some
that
the
defect
phase
already
did
and
then
we
have
this
custom
one.
Let's
say
I
want
to
do
some
random
thing.
It's
you
know
it's
important.
I
think
that
bill
packs
does
90
of
the
work
for
you.
That's
what
it
feels
like:
hey,
I'm
doing,
90
of
the
work
and
then
I
get
a
chance
to
you
know
add
my
little
tidbit
and
you
know
you
can
get
some
updates.
Maybe
maybe
that's
something
we
want
to
show.
G
Let's
say
I
hit
b
for
build,
I'm
gonna,
I'm
gonna
build
now,
I'm
gonna
build
the
build
phase,
runs
which
it
normally
does
just
the
rest
of
the
phases.
But
you
know
I'm
going
to
traverse
all
my
build
packs
now
and
hopefully
my
thing
will
succeed.
Oh
no,
it's
failed!
Oh,
what
happened
well,
I
can
tell
I
can
tell
probably
had
to
do
with
my
custom
build
pack
this
random
thing.
Maybe
you
know
I
need.
Maybe
I
know
what
to
do
from
here
now.
Right,
maybe
I
know
I
need
to
work
on
this.
G
Maybe
I
can
jump
into
a
debugging
session.
Whatever
last
thing
I
did
want
to
say
is
cve
support.
G
I
do
kind
of
feel
strongly
about
this
right
because,
because
I
really
think
that
you
know
bill
packs
right
now
is
a
cool
thing
that
you
can
use,
but
having
cve
detection
makes
it
a
necessary
tool
for
some
organizations
right
because
like
if
you
can
get
that
at
build
time-
and
you
know
get
that
feedback
loop
really
tight
for
some
and
you
know,
enterprise
organizations
right
it,
it
becomes
a
little.
The
value
proposition
is
just
so
clear
right.
So.
G
A
G
E
F
C
A
The
images
we
produce
now
are
not
very
scannable,
because,
when
build
packs
install
these
runtimes,
they
don't
install
them
in
ways
that
scanners
can
pick
up.
But
one
thing
we've
been
talking
about
is
like
just
came
up
today
is
standardizing
on
spdx
for
the
build
materials
format
and
once
you
know
like
at
some
point,
vulnerability
scanners
will
need
to
if
they
can't
already
spdx
format
and
say
what
vulnerabilities
are
there
right?
A
That
could
be
a
really
lightweight
way
of
doing
exactly
what
you
see
on
the
thing
right,
because
we
could
ask
pdx
to
build
packs,
we
could
spdx
the
images
that
get
generated.
You
can
know
about
cvs
that
you're
going
to
install
before
you
do
the
build
if
you
wanted
to
right,
because
that
information
could
be
on
the
build
packs
as
well
right.
So
I
think
this
is
like
this
very
much
drives
out,
or
this
you
know
being
able
to
show
the
cvs
in
this
really.
A
You
know
accessible
way,
really
drives
out
that
that
track
of
work
too.
I
think.
E
Even
if
it's
not
what
we
want
to
display
in
the
default
view,
and
let
people
explore
and
it's
a
great
way
to
drive
out
features
that
I
feel
like
we
want,
but
maybe
don't
want
to
pollute
the
standard.
Cli
output
with
and
therefore
haven't,
put
as
much
intention
into
them,
because
it's
not
this
clear
who
the
consumer
is
for
them,
and
it's
much
easier
to
build
some
of
these
metadata
for
a
concrete
consumer
than
an
abstract
somebody
will
consume.
A
Some
feedback
on
on
the
particular
demo
anthony
in
that
plan,
section
it'd
be
amazing.
If,
under
each
of
the
build
packs,
I
could
see
the
layers
that
got
generated
by
each
build
pack
and
then
maybe
even
like
you
could
you
know
view
the
bill
of
materials
for
that
layer
by
hovering
over
it
and
place
a
logs,
pane
or
you
know,
hit
a
button
and
go
into
a
file
explorer
where
I
can
actually
interact
with
the
you
know
like.
I
think
you
could
turn
this
into.
A
E
G
Sweet
you
know
there
are
some
other
latent
thoughts.
You
know,
I'm
glad
you
all
have
some
one
was
definitely
edit,
which
I
didn't
talk
about
right,
like
it'd
be
nice.
If
we
could,
I
don't
know
integrate
with
project
tamil
or
something
right
like
just
have
an
easy
way
to
sort
of
like
switch
these
around.
Maybe
if
you
want,
if
you
want
right,
we
can,
we
can
say
it's
not
a
best
practice
right,
but
you
know
as
long
as
the
user
doesn't
feel
like
encumbered.
G
Okay,
if
there's
anything
else,
I
was
thinking
at
least
from
my
side.
Next
steps
would
be
like
to
get
some
cool
user
testing
around
this
right,
like
I
really
want
to
make
sure
somebody
out
there
is
like
invested
in
this
right
like
because
they've
seen
it
with
their
own
eyes
and
they've
played
with
it.
F
A
I
think
if
we
built
this,
you
know
something
looks
like
this
soon
right.
People
would
like
it,
because,
my
god
I
like
it,
I
definitely
think
yes,
feedback
would
be
great
but,
like
you
know,
we're
we're
so
we're
so
far
behind
we're.
A
We
don't
have
anything
that
looks
like
this
at
all
right
that,
even
if
this
has
some,
you
know
ugly
edge
cases
and
things
like
that
right,
like
you
know,
I
think
it
would
deliver
a
lot
of.
A
G
I
hear
you
no,
no
good,
please.
I
wanted
some
feedback.
I
got
some
good
feedback.
That's
it!
That's
pretty
much
it
for
me.
A
If
you
want
more
feedback
on
like
what
you
know
how
you
could
expand
on
the
design
or
ideas
you
have
about,
you
said
you
meant
editing
the
individual
things
or
changing
the
order.
I'd
really
like
to
just
sit
down
and
like
walk
through
all
those
ideas
and
kind
of
if
you're,
missing
context
on
the
api
and
what's
possible,
like
you're,
really
interested
working
with
you
on
that.
I'm
sure
other
people
here
would
do.
A
All
right,
let's
move
on
to
sam's
rfcs,
so
I
I
listed
them
up
here
in
no
particular
order.
I
actually
wanted
to
ask
sam,
which,
which
of
these
things
is
highest
priority
for
you
to
get
pushed
along,
because
I
know
we've
sat
on
some
of
them
for
a
while.
D
I
think
the
one
that
would
help
a
lot
would
be
the
build
versus
run
uid.
I
guess
that's
I
mean
I'm
already
using
it
in
in
the
platforms
I'm
using,
but
it'd
be
nice
to
have
it
in
the
specs
so
that
I
can
at
least
resist
sure
that
it
won't
change
in
the
future
or
otherwise
I'll
have
to
figure
out
some
other
things.
The
other
one
was
the
bomb
in
the
layer
metadata.
A
Awesome
and
so
that
bottom
of
the
metadata
is
151,
which
one
was
the
user
ids
was
that
146
yeah
146.
so
emily,
and
I
had
a
chance
to
chat
about
this.
I
know
we
were
in
some
of
the
past
working
group
meetings.
We
kind
of
did
a
lot
of
back
and
forth
on
different
ideas,
so
it
would,
you
know,
could
really
change
this
or
not
change
this.
A
A
So
like
a
stack,
provides
a
build
dimension,
a
run
image
right
and
if
the
run
image-
or
we
should
say,
a
stack-
is
allowed
to
have
a
different
user
for
the
run
image
than
the
build
image
and
then
also,
and
then
it
should
right,
but
it
doesn't
have
to,
but
that
should
be
part
of
the
spec
saying
yes,
this
should
be
different,
so
we
move
away
from
this.
Like
the
current
model.
Is
you
know
it
came
from
what
we
did
at
heroku
and
cloud
foundry
a
long
time
ago?
A
But
it's
very
unusual
to
configure
like
a
linux
web
server.
You
know
vm
or
whatever
container,
that
has
that
installs
a
bunch
of
files
as
a
user
and
then
runs
them
as
that
same
user,
where
the
user
could
override
those
files
later
right.
That's
a
that's!
You
know
not
a
very
normal
way
of
of
you
know
doing
things
you
have
have
you
seen
a
docker
file
that
starts
with
like
user
normal
user,
then
installs
everything
you
know?
Usually
it
stalls
everything
and
then
switches
to
that
user
afterwards.
A
So
I'd
add
to
this
that
we
should
make
it
the
recommendation
for
stacks
to
use
a
different
user
and
then
also
allow
stacks
or
explicitly
call
out
that
stacks
may
use
a
different
group
as
well.
But
it's
up
to
the
stack
to
decide
if
the
group
is
different
or
the
same.
Some
some
sets
of
build
packs
may
want
to
interact
with
the
stack
where
you
know
they
use
7
5
5
as
a
umass.
D
C
I
feel,
like
you,
made
comments
before
steven
about
compatibility
with
bill
packs.
So
if
I'm
targeting
say
like
a
bionic
stack
and
then
I
make
like
the
bill,
pax
bionic
stack
and
then
I
make
some
other
company
a
makes.
A
stack
base
on
top
bionic
that
has
that
stack
id.
That
then
does
change
the
user
id,
but
like
guys
bill
pack,
author,
just
targeted
bionic,
so
in
theory
my
bill
pack
should
draw
on
there.
But
I
have
no
concept
that
the
users
potentially
are
different
or
the
groups
are
different.
A
It
wouldn't
be
a
breaking
change
that
you
would
have
to
make.
Nothing
would
break
if
you
did
your
distribution
of
the
bionics
deck
didn't
change
right
after
this
is
approved,
but
the
idea
would
be
that
we
migrate
to
that
model,
and
I
think
we
should
we're
like
just
speaking
on
the
potato
side,
I
think
that's
a
change
that
we
should
make
there
too
for
security,
it's
bad
if
you
can
trick
the
application
process
into
running
arbitrary
code
and
then
that
code
could
override
the
binary
of
the
application
process
right.
E
E
A
What
aspect
sorry,
do
you
mean
to
like
interpolate,
the
port
or
something.
C
Yeah,
just
like
nginx
hardcore
hardcodes
like
everything,
so
you
can't
pass
in
mbars
to
config
file,
so
you
have
to
write
most
nginx
bill
packs
and
similar
things
like
that.
I've
seen
definitely
want
some
configuration,
so
you
don't
have
to
rerun
the
build.
A
A
A
It
seems
like
this
is
some
one
of
those
like
pre-100
things
where,
like
there's,
probably
something
we've
kind
of
cargo
culted
that
we
never
addressed,
and
so
I
know
it's
it.
Could
you
know
the
transition
to
by
changing
the
run
image
user
on
the
kind
of
default
stacks
in
the
different
ecosystems
could
lead
to
some
breakages.
I
think
it's
worth
doing
before.
1-0.
E
I
know,
stephen,
that
you
were
saying
that
we
want-
and
this
made
sense
to
me
and
our
current
stack
model
wanted
to
allow
the
group
ready
to
be
different,
and
I
guess
that
would
be
a
feature
of
a
given
stack
contract.
Do
we
want
to
keep
that
as
a
potential
end
goal,
but
maybe
start
by
requiring
them
to
be
the
same,
so
that
we
can.
E
Like
there'll
be
some
build
packs,
let's
take
terence's
comp
example
that
are
going
to
be
trying
to
write
a
file,
maybe-
and
I
feel
like
as
a
build
pack
author.
If
you
want
to
be
able
to
run
on
anyone's
stack,
which
is
a
goal
in
some
ways.
E
You
want
to
know
whether
that
is
a
pattern
you
can
use
or
whether
you
have
to
move
everything
to
attempt
file.
So
I
wonder
if
leaving
the
option
open,
creates
more
room
for
incompatibilities
between
stacks,
and
we
should
pick
one
of
the
other
and
something
both
now
think
of
this
example.
I
do
feel
like
cross
compatibility
might
be
improved
by
having
a
stronger
suggestion.
There.
A
About
the
group
specifically
yeah
about
the
group,
okay
yeah,
I
I
it's
still
that
configuration
is
still
not
like
if
I
throw
up
a
linux,
vm
or
you
know,
container
running
apache
or
whatever
I
almost
always
change
the
user
to
nobody,
nobody
or
www
right
at
the
end.
I
don't
I
don't
like
keep
the
user
as
root
or
whatever
user
can,
edit
the
you
know,
web
server,
binary
or
sorry
keep
the
group
group
as
whatever
user.
Whatever
group
can
edit
the
web
server
binary.
A
So
it
feels
like
making
that,
as
it
seems
like
a
good
compromise
to
say,
the
stack
can
choose
if
one
or
both
are
different.
If
that
makes
sense,
but
I'm
a
little
hesitant
to
say
the
stack
should
make
them
the
user
and
group
different
and
the
group
match
the
runtime
one,
because
I
think
it's
pretty
unusual,
it's
still
not
not
the
configuration.
C
Yeah,
I'm
just
curious
to
get
feedback.
Does
this
impact
folks
like
digitalocean,
that
are
ready
to
run
the
stuff
abroad
that
has
tax,
or,
I
guess,
jesse,
on
the
salesforce
side
as
well,
because
I
think
these
are
the
people
we
would
potentially
be
breaking
right.
E
A
It
does
break
things
if
you're
using
if
you
consume
the
bionic
stack
id,
and
then
we
say
the
bionic
stack
id
should
change
and
then
stack
maintainers
change,
their
run
images
to
match.
That's
how
it
would
could
break
things
for
users
in
the
end
right,
but
it
you
know
it
allows
or
it
does
allow
those
stack
authors
to
control
the
rollout
of
their.
You
know
stack
changes,
it's
not
a
thing.
We'd
break
in
the
life
cycle
right
for
sure.
C
A
E
Stupid
that
you
missed
our
discussion
on
thursday,
because
I
feel
like
there's,
I
feel
like
there's
a
lot
of
things
that
need
to
change
about
stacks
in
order
to
make
them
more
broadly
applicable.
Like
I
don't
want
to
roll
more
behavior
into
under
the
stack
id.
I
instead
want
to
move
the
other
direction
where
the
stack
id
can
be
more
broadly
interpreted
and
it's
less
specific
to
a
contract
like
it
could
have
all
the
things
in
it.
That
would
go
in
the
platform
section
of
an
oci
spec.
Like
am
I
linux?
E
A
Doesn't
that
I
I
agree
with
that
plan,
but
doesn't
it
just?
I
don't
know
if
this
solves
the
problem
we're
running
into
because
it
just
moves
it
to
like.
Okay,
now,
like
the
problem,
we're
solving
is,
or
I
think
we're
trying
to
solve
is
like
if
you
have
a
whole
bunch
of
different
build
packs.
Those
build
packs
are
either
going
to
expect
the
user
to
be
different
or
the
same
right
and
if
we
say
okay,
a
build
pack.
Author
can
now
say
whether
they
expect
this
user
to
change
or
not.
A
We've
pushed
the
problem
onto
the
build
pack
side
and
now
build
packs
could
be
incompatible
with
each
other
or
whatever,
I'm
okay
with
that
too,
but
it
seemed
like
the
we
wanted
more
uniformity.
There
was
like
you
know
something
we
brought
up
and
past
working
group
meetings
about
this
specifically,
so
that
buildpack
doesn't
unexpectedly
not
be
able
to
write
to
its
app
directory.
It
knows
if
it
chose
that
stack
id,
then
this
is
how
it
needs
to
behave
right.
So
I
agree
with
that
plan.
A
Yeah
so
so
very
tactically,
rob
okay,
saying
that
the
spec
should
allow
stacks
to
say
one
way
or
the
other.
But
in
this
rfc
we
don't
change.
The
bionic
stack
right.
Does
that
so
so,
terence,
it's
not
a
breaking
change
on
anybody
with
a
bionic
stack.
Yet
that
would
have
to
come
in
separately,
but
this
says
that
they
should
either
be
same
user,
different
group
or
different
user
same
group
or
different
user
different
group.
But
we
don't
recommend
same
user
same
group
as
build
time.
A
Is
current?
Yes,
right,
that's
right!
Yes,
the
current
status
is
same
as
build
time.
This
says
that
we
recommend
doing
something
different,
but
it
doesn't
actually
change
in
the
bionic
stack.
We
need
another
rfc
for
the
bionic
stack
to
change.
The
definition
of
the
bionic
stack
to
be
compatible
with
that
right
now.
The
project
would
just
not
be
taking
its
own
recommendation.
A
A
So
I
think
this
is
unblocked
and
sam,
if
you
could
just
add
to
the
rfc
the
thing
about.
You
know
that
we
should
make
this
recommendation
in
the
spec
to
either
do
that
one
of
the
two
ways
and
not
the
keeping
them
the
same.
I
think,
would
be
good
to
approve
and
move
forward.
C
A
151
add
bomb
to
layer,
content
metadata.
A
We
talked
about
emily
and
I
talked
about
this
one
yesterday,
a
little
bit
too.
No
emily
you
wanna.
I
forget
exactly.
A
E
D
E
E
It's
like
build
dependency
changes,
but
if
the
getting
the
exact
same
result
shouldn't
need
to
travel
with
the
image,
but
I
wonder
if
we
were
wrong
about
that
and
people
do
you
want
to
inspect
the
build
bomb?
Instead,
we
should
put
it
in
both
report
tunnel
and
a
separate
label
separate
from
the
existing
bomb,
but
still
on
the
image
itself.
E
A
But
if
the
build
pack
you
know
brings
curl
or
something
and
then
the
version
of
curl
changes
by
a
patch
and
so
the
curl
that
was
used
to
download
your
jdk
into
your
image.
Is
you
know
now
the
version
that
was
used
to
download
the
jdk
is
now
printed
on
the
image
and
you
can't
build
the
same
image
again.
It
feels
like
we've
lost
something.
C
That
knowing
the
tool
like
it
turns
out
there's
a
cve
in
gradle
right.
Don't
you
actually
want
to
know
whether
or
not
to
see
you
built
this
thing
with
the
cv,
not
necessarily
that
the
cv
made
it
all
cv
made
it
the
whole
way
down,
but
just
like
you
were
using
this
particular
thing
like.
It
seems
very
weird
to
me
that,
like
a
build
tool,
would
change
without
changing
the
overall
output,
like
something
you'd
have
put
in
the
bill
of
materials
in
the
first
place,.
C
E
D
The
the
only
thing
is
that,
let's
say
you
are
compiling
some
binary,
either
using
c
plus
plus
or
go
and
you're,
using
some
like
libraries
during
build
time
which
never
end
up
in
the
final
image.
Where
would
you
put
that
bomb?
Would
that
go
in
the
launch
bomb
or
the
bill
bomb?
And
if
it
goes
in
the
bill
bomb,
then
I
know
that's
going
to
affect
my
final
binary,
even
though
there's
no
real
way
to
yeah,
but.
D
So
yeah,
my
argument
was
for
putting
the
build
like
bomb
in
in
a
label
or
something
that
you
can
inspect,
because
I
guess
the
current
way
of
doing
this
is
just
putting
it
in
the
launch
normally,
even
though
it
was
not
technically
in
the
launch
like
like
you're,
not
including
those
libraries
or
those
header
files
in
your
final
image.
But
if
you
want
to
inspect
it
quickly,
you
still
have
to
put
it
in
the
launch
drama.
A
I
think
we
can
do
that.
I
just
my
request
would
be
that
it
should
be
optional.
There
should
be
a
like
flag
to
pack
and
life
cycle.
That
says
yes
put,
this
put
the
build
time
label
on
or
no
don't
put
the
build
time
label
on,
and
you
know
we're
you
know
if
we
want
one
giant,
you
know
bill
of
materials
at
the
end
that
has
everything
together,
then
it
could
do
giant,
builds.
A
D
E
D
I
think
the
only
discussion
point
I
had
was
like
something
natalie
and
I
were
discussing,
which
is
whether
the
bomb
should
be
cleared
so
whether
the
life
cycle
of
the
bomb
and
the
layers
should
be
the
same
or
whether
the
life
cycle
of
the
bomb
and
the
metadata
file
should
be
the
same.
D
E
I
feel
like
if
the
exporter,
you
know
if
the
analyzer
was
restoring
the
bomb
and
the
exporter
was
reading
it
directly
out
of
player
metadata
versus
what
happens
now
or
the
builder
in
an
eater
intermediate
step,
grabs
it
all
and
writes
it
into
metadata
tumble.
At
the
end
of
the
day
that
behaves
the
same.
D
D
A
D
D
So
there
may
be
cases
when
you're
not
restoring
the
layer
but
you're
still
restoring
the
like
the
layer
content
metadata,
in
which
case
do
you
want
the
bill
of
materials
to
stay
there,
or
should
they
just
stick
with
what
the
when
the
layer
is
being
restored,
so
that
it
has
the
same
like
it's?
It's
coupled
closely
to
the
layer
rather
than
the
metadata
you're.
E
You
can
see
the
only
case
where,
like
we'd,
restore
the
layer
content
metadata,
but
not
the
layer
itself
is
for
a
layer.
That's
launch
true,
build
false
and
cache
false.
Let
me
do
that
so
that
someone
can
reuse
the
layer,
and
in
that
case
I
think
that's
the
case
where
we
definitely
want
it,
because
someone
opting
in
to
reuse,
it
might
not
have
regenerated
the
bomb,
but
the
contents
of
the
layer
are
exactly
the
same
as
they
were
last
time
and
we
should
propagate
that
along.