►
From YouTube: CNB Weekly Working Group: 2021-12-02
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
I
see
it
on
my
corner
now,
so
I
think
it's
working
all
right
remind
you
to
sign
into
the
document.
If
you
haven't
already
most
of
you
haven't
release,
planning
and
updates.
B
I
guess
I
should
mention
that
we're
planning
to
cut
a
patch
release
of
the
life
cycle.
We
discovered
a
couple
of
bugs
with
a
s
bomb
implementation,
so
look
out
for
that
in
the
next
day
or
so.
B
I
believe
I
was
absent,
but
there
was
an
rc
if
not
a
new
release
going
on.
I
don't
know
sam.
If
you
have
more
context
on
that.
C
So
that
we
shipped
our
lip
cnb
with
all
the
spam
stuff,
I
think
it's
being
used
by
together
folks,
also
research
to
the
google
buildback
folks
and
they're
interested
in
joining
and
giving
us
feedback
and
they'll
probably
also
be
moving
over
to
the
new
api.
Hopefully,.
A
I
think
the
rfcs
are
supposed
to
be
a
little
flatter,
or,
although
I
guess
all
those
rfc
is
related
to
project
descriptor
yeah,
I
think
project
descriptor.
That
was
you
joe.
D
Yeah
sure
I
can
kind
of
drive
this
one.
I
think
we've
got
there's
three
rfcs
that
are
a
part
of
this
one
was
in
addition
to
project
tommel
that
and
that
potentially
introduces
an
images
table,
and
I
think
that
kind
of
prompted
some
larger
discussions
around
project
tunnel
as
a
whole,
especially
since
this
is
one
of
the
cases
where
it
might
be
difficult
or
inconsistent
across
platforms
and
how
that's
supported
or
if
that's
supported,
having
multiple
images
output
from
from
a
single
build.
D
So
I
created
an
rfc
for
a
pactummel
which
is
a
pack
specific
special
case
of
project
tommel,
and
I
think
our
javier
created
another
one,
that's
sort
of
a
new
project
or
a
a
new
descriptor,
that's
built
past,
build
packs
with
an
s
tomml
and
or
yaml.
D
So
I
think
it's
I
think,
it'd
be
good
to
talk
through
some
of
those
and
figure
out
where
we
want
to
take
project
descriptor,
because
I
think
I
think
it's
an
important
topic,
because
it
is
a
key
touch
point
for
any
build
pack
user
and
there's
a
lot
of
cases
where
I
think
we're
we're
held
back
by
kind
of
waffling
on
on
how
we're
gonna
support
this
or
what
it
means
and
so
yeah.
So
we
can
get
out
there.
D
B
Yeah,
I
think
I've
discussed
it
with
some
people
in
the
pack
rfc,
that's
a
relatively
new
one.
So
if
maybe
we
could
go
over
that
one
and
see
what
the
the
idea
behind
it
is,
that
might
help
influence
some
further
conversation.
D
Yep
make
sense,
so
I'm
pulling
it
up
right
now,
but
I
think
the
thing
that
the
the
real
differentiator
for
this
rfc
from
other
proposals
or
from
the
status
quo.
D
Is
that
this
is
a
pac-specific
configuration
file
as
opposed
to
something
that's
meant
to
work
across
platforms,
and
I
think
like
in
some
ways
this
is
accepting
the
thing.
That's
that's
been
a
problem
for
a
while
and
that,
like
we
want
to
expand
the
scope
of
project
tamil,
we
want
it
to
be
more
ubiquitous
to
the
project,
but
there's
things
that
pack
can
do
or
wants
to
do
that
maybe
kp
kpak
can't
do
or
doesn't
want
to
do
or
techton.
You
know
in
worst
cases
like
can't
do
without
additional
tooling.
D
So
what
I'm
proposing
in
this
rfc
is
a
new
file
pactomel.
D
That
would
ultimately
adhere
to
the
same
specification
as
project
tamil,
but
would
be
scoped
just
to
pack,
so
you
could
omit
so
it
would
ignore
anything
outside
of
the.
I
o
build
packs
name
space,
but
would
you
know,
but
you
could
use
it
as
a
sort
of
a
minimal
set
of
what's
in
there,
so
you
could
configure,
for
example,
just
build
packs,
and
you
know
my
thinking
is
that
this
would
allow
us
to
introduce
things
that
are
specific
to
pack,
that
that
supplement
a
project
tamil.
D
So
if
you,
if
you
have
configuration
that
is
meant
to
work
across
platforms
that
belongs
in
project
toml,
and
we
can
you
can
assume
that
any
platform
that
supports
project
tunnel,
that
that
configuration
will
do
something
on
that
platform
and
that
allows
us
to
kind
of
keep
project,
tamil
sort
of
slimmer
or
less
opinionated,
whereas
the
pack
tumble
can
be
more
explicit
and
like
these
are
the
things
it
can
support
a
builder
image,
and
we
don't
have
to
put
that
in
project
tunnel,
but
that
separation
between
pack,
tumble
and
project
tamil,
I
think,
gives
people
a
you
know
a
good
like
cognitive
model
of
what
will
be
supported
by
pac,
specifically
versus
what
will
be
not
potentially
not
supported
by
kpac
or
something
else
so
yeah.
A
A
D
Yep
yep
make
sense.
I
I
was
thinking
the
same
thing
as
an
alternative,
like
one
alternative
is
just
add
this
to
project
tommel
and
that
then,
and
have
the
sort
of
the
same
thinking
behind
it.
We
could
also
do
things
like
simply
like
remove
this
reverse
names,
domain
name
thing
from
pactomel
just
to
simplify
it
but
make
it
you
know
essentially
similar
to
project
tommel
yeah.
I
mean
I'm,
I'm
open
to
all
that
kind
of
stuff.
D
But
more
specifically
to
communicate
compatibility
with
pac
like
I
worry
about
broadly
communicating
like
a
build
pack
file
or
something
like
that,
and
we
really
can't
agree
on
what
would
be
required
to
be
supported
by
all
platforms,
and
I
also
worry
very
much
about
that
actually
being
true
in
reality.
Right,
like
we
can
say,
oh
yeah,
you
got
to
support
this
builder
and
probably
half
the
platform
as
well.
D
A
Just
I'm
sorry,
oh
I
was
gonna
say
I
really
like
the
idea
of
removing
the
domain
prefix
right.
If,
if
the
file's
goal
isn't
to
be
like
project,
humble's
goal
was
to
be
something
larger
than
the
project
to
some
extent
right,
like
a
kind
of
generic
way
using
tunnel
to
define
kind
of
what
a
project
or
application
looks
like
if
we're
going
to
focus
on
something,
that's
more
buildpack
specific.
A
I
definitely
like
the
idea
of
removing
the
domain
notation,
but
I
wonder
all
right
again,
and
I
wonder,
though,
at
that
point,
if
you
have
a
buildpack
specific
file,
if
you
could
instead
of
making
it
because
you
want
some
parameters
that
are
platform
specific
to
be
a
pack
specific
file,
could
you
instead
introduce
like
a
platforms
table
or
something
that
you
can
say
like
you
know,
for
pack
builder
equals
this?
If
we
really
feel
like,
we
want
to
keep
that
kind
of
platform,
specific
configuration
separate.
A
Can
we
just
you
know,
define
a
table
in
the
file
that
allows
you
to
specify
platform-specific
configuration
and
actually-
and
on
top
of
that,
it
doesn't
bother
me
that
much
because
a
builder
is
kind
of
a
term
in
the
project.
If
you
know
builder
is
a
top
level
thing
and
you
can
set
it
and
it
doesn't
do
anything
on
other
platforms
where
it's
not
settable,
then
you
just
complain
about
it.
That
option
is
actually
okay
with
me.
A
A
Doesn't
make
it
look
like
other
tamil
files,
if
that
makes
sense,
or
it's
like
you
know,
it'd
be
a
nice
simplification,
but
but
I
think
it's
it's
similar.
It's
just
that
it
makes
the
file
more
of
an
advertisement
for
the
buildbacks
project
and
simplifies
the
keys.
B
The
one
thing
I
want
to
throw-
maybe
in
there
that
kind
of
applies
to
this,
and
maybe
even
steven
your
your
idea-
is
the
challenge
of
keys
that
we've
at
this
point
in
time.
Kind
of
introduced
at
a
build
packs
domain,
for
instance,
build
packs
right
so
like
I
believe
we
have
like
io,
build
packs
dot,
build
packs
right
where
you
are
able
to
find
build
packs.
B
The
way
I'm
interpreting
this
is
that
this
pact
tamil,
would
inherit
and
use
those
and
we're
saying
that,
because
they're
at
that
domain
right,
that
k-pac
should
also
respect
those
and
that
tecton
should
also
respect
those
and
obviously
that's,
not
necessarily
true.
So
what
then,
that
would
mean
is
we
would
have
to
move
those
build
packs
into
platform,
specific
configurations.
A
Oh,
I
don't
know
if
we
have
to
move
concepts
that
are
defined
by
the
project.
Right
like
this
is
the
group
of
build
packs.
If
the
app
developer
is
going
to
provide
a
group
of
build
panics
into
a
platform
specific
key,
I
think
platforms
can
just
choose
not
to
respect
that
configuration
if
they
don't
want
to.
B
Yeah,
I
guess
I
disagree
with
that
right.
I
I'm
with
you
that
I
don't
see
the
value
if
we're
breaking
it
up
into
individual
platform
stuff,
then
I
would
say
every
platform
should
just
provide
their
configuration
element
so
like
in
this
case
pactomel
right,
it
would
be
a
pac-specific
configuration.
K-Pac
could
have
something
very
similar
and
then
tekton
and
so
forth.
A
B
It's
technology
right
where
now,
as
a
user,
from
a
user's
point
of
view,
it's
there's
unexpected
behavior
and
what
properties
are
actually
respected
are
completely
unknown
to
me
right
because
there's
nothing
at
least
right
now,
structured,
like
the
the
project.
Descriptor
is
an
extension
right,
so,
like
platforms
may
completely
ignore
it.
Things
like
that,
we
think
should
be
on
there
like
excluding
include.
A
But,
but
I
think
this
is
this:
isn't
there
I
think
there
is
a
lot
of
prior
art
for
this?
Sorry.
Sorry,
sam
one
point:
there's
a
lot
of
prior
art
for
this.
It's
like
if
I
use
like
cloud
foundry
as
an
example
or
I'm
sure
heroku
has
things
like
this
too.
If
cloud
foundry
is
configured
so
that
you
can't
push
docker
images,
that
doesn't
doesn't
mean
that
there
shouldn't
the
cloud
foundry's
manifest
ammo
shouldn't
have
a
docker
image
field,
because
some
platforms
are
gonna
or
some
foundations
are
gonna
support
it
and
some
foundations.
B
Yeah-
and
I
think
what
I'm
saying
is
I
don't
want
to
hand
wave
it,
I
want
to
make
it
strict
that
the
platforms
have
to
say
that
I
am
ignoring
certain
things
or
your
build
should
fail
right.
That's
kind
of
my
stance.
I
want
to
be
a
lot
stricter
on
that,
whereas
right
now
it's
going,
you
know
it's.
Basically,
the
these
warnings
or
errors
are
being
swallowed
and
the
user
doesn't
know
anything
about
it
and
they
just
end
up
with
different
results.
A
A
C
C
C
So
you
put
like
prepare
phase
equals,
prepare
secure
and
that's
like
a
binary
that
can
do
things
consistently
and
can
be
reused.
So
like
things
like
inclusions
exclusion,
setting
environment
variables
or
whatever
else
is
handled
by
that,
and
the
platform
explicitly
allows
us
the
list
of
prepared
versions
or
phases,
it
allows
to
be
run
on
itself.
C
So
it
can
either
be
like
something
like
this
or
a
list
of
keys,
that
the
platform
says
that
from
the
default
prepared,
implementation
that
we
provide
here
are
the
list
of
keys
that
are
valid
and
if
it
doesn't
find
that
it
fails
entirely
until
you
change
it.
That
way
at
least
there's
consistency
across
platforms.
C
So
you
you
can
either
encapsulate
the
list
of
keys
by
some
name
and
put
it
somewhere
or
you
can
just
provide
a
list
of
keys
that
are
valid
for
a
platform,
and
the
idea
would
be
that
if
you
run
that
on
pack
pack
will
only
look
at
those
keys
and
process
those
keys
and
ignore
all
the
others.
And
that
way
you
get
people
used
to
put
you
between
back
kpac
techno,
whatever
until
you
find
the
minimal
subset.
That's
compatible
with
all
the
platforms
that
you're
interested
in.
A
So
the
like
equivalent
here,
would
be
like
in
that
project.
Descriptor
parser
functionality,
right
lifecycle.
That
translates
it
into
something
else
that
you
know
platforms
could
use
that
or
provide
that
with
a
list
of
keys
or
kind
of
use
that
to
help
validate
project
tamil
and
reject
in
a
very
consistent
way
and
fail
the
build
in
a
very
consistent
way
when
certain
parameters
aren't
there,
and
so
we
can
kind
of
help
platforms
that
validation
and
then
on
the
google
app
engine
side.
A
If
they're
going
to
use
the
project,
descriptor,
parser
they're
going
to
have
to
say
yes
they're,
going
to
have
to
explicitly
say
that
they
support
all
these
fields
and
that
ignore
them
in
order
to
get
their
google
app
engine
pack
build
to
not
fail.
Otherwise
they're
they're
going
to
inherit,
failing
when
project
time
was
specified,
and
so
maybe
that
addresses
the
app
engine.
So.
C
That's
the
like:
that's
the
allowed
list
of
keys.
The
other
thing
I
would
like
to
see
made
consistent
across
platforms
is
overrides.
So
if
there
is
such
a
prepared
binary
with
a
list
of
allowed
keys,
the
platform
should
have
a
way
of
providing
overrides
from
its
own
configuration
down
to
that
prepared
phase.
C
So,
let's
say
back
currently
allows
for
builder
to
be
set
as
a
flag
in
its
cli
and
that
overwrites,
what's
provided
in
the
project
descriptor,
so
whatever
that
prepare
binary
or
whatever
that
is
going
to
be,
should
be
able
to
accept
these
options
from
various
platforms
for
the
list
of
allowed
keys
and
provide
a
consistent
way
to
override
those
values
from
so.
C
If
there's
a
platform
like
kpac,
which
defines
its
builder
using
like
a
yaml
resource
manifest,
it
should
be
able
to
pass
that
into
the
binary
saying
that
this
is
the
builder
you're,
using
not
this
other
one,
that
you
define
in
project
normal
and
I'm
overwriting
it
because
it
was
defined
by
the
platform
or
overridden
by
the
platform.
Whatever
you
want
to
call,
it.
D
So
I
think
that's
at
least
akin
to
what
I
was
aiming
for
with
this
and
sort
of
like
another
layer
of
like
pactummel
and
and
again,
I'm
like
really
open
to
changing
the
schema
of
what
we're
calling,
what
I'm
calling
pactamal
here
and
how
it
works
and
everything.
But
that
idea
of
sort
of
layering
and
even
down
into
I
think,
the
same.
D
The
further
layer
down
that
you
were
talking
to
talking
about,
which
is
like
the
prepare
phase
or
whatever
you're
having
a
layer
that
is
platform
specific
having
a
layer,
that's
generic
and
then
having
the
life
cycle,
which
has
a
way
of
potentially
accepting
or
rejecting
things.
D
So
we
could
circle
around
that
a
bit,
but
I
think
I
think
I'm
somewhat
aligned
with
it.
Yeah.
D
No,
I
was
gonna
say
I
should
give
javier
a
chance
to
talk
about
his
proposal.
We
can
just.
D
One
one
last
thing
I
wanted
to
bring
up,
though,
is:
I
think
it's
important
to
focus
on
what
are
the
problems
we're
actually
trying
to
solve,
and
I
know
like
we
spent
a
lot
of
time.
Honing
the
reverse
domain
name,
part
of
it
and
like
what
I'm
not
hearing
from
users
is
project
tamil
is
hard
to
use.
The
schema
is
weird.
D
I
don't
even
hear
really
anything
about
the
name
of
the
file
like
yes,
I
one
of
the
problems
trying
to
solve
is
that
we
want
to
advertise
whether
it's
a
build
packs
compatible
project
or
that
it
works
with
pack
and
that
kind
of
thing,
but
what
I'm
hearing
from
users
is
like.
I
want
more
of
this.
I
want
new
tables
in
the
project
tumble.
I
want
it
to
work
across
platforms,
and
so
it's
just,
I
think
it's
important
to
keep
that
in
mind.
D
Like
you
know,
the
problems
we're
trying
to
solve
are
not
like.
Oh
no
project
tamil
isn't
working.
I
think
it
is
actually
providing
a
lot
of
value
to
users,
so
there's
no
need
to
like
burn
it
to
the
ground.
Let's
solve
the
problems
that
we're
that
we're
hearing
about
so.
A
I
agree
with
the
principle
I
feel
like
users,
because
there's
no
descriptor
file
right
now
introducing
any
kind
of
descriptor
file
is
going
to
get
a
lot
of
positive
feedback,
a
user
that
knows
that
the
project
humble
exists
already
isn't
going
to
give
us
feedback
that
they
didn't
recognize
that
it
was
a
build
pack
app
or
you
know
like
that.
The
name
is
something
that
I
think
is
is
a
you
only
get
yeah.
I
agree,
that's
a
problem
that
is
one
of
the
problems
we're
trying
to
solve.
Yeah.
A
I
I
wonder
if
you
ask
people
directly
right,
how
do
you
feel
about
the
reverse
domain
name
notation
and
having
everything
nested
under
domain
keys
right?
We,
I
don't
know
what
feedback
we
get,
but
I
feel
like
it's
at
least
unusual,
compared
to
what
you
know
other
you
know
things
are
doing.
D
C
D
A
It
for
me
as
a
really
specific
reason,
which
is
if
pr
when
project
tamil's
goal
was
like.
You
know,
let's
incubate,
a
new
general
descriptor
file
like
wayne
toml
of
describing
applications
that
can
work
with
the
variety
of
tools.
I
think
the
reverse
domain
adaptation
you
know
in
that
context
makes
sense
right
or
like
it
it.
You
know
it's
a
way
for
any
organization
to
encapsulate
any
configuration
about
a
project,
and
you
know
domain
name,
spaces
or
comment.
Reverse
domain
namespaces
are
common.
A
You
know,
people
understand
that,
but
as
soon
as
it
becomes
a
specific
build
packs
file,
then
anybody
who
looks
at
that
isn't
going
to
understand
or
have
a
like,
there's
not
going
to
be
any
reason
why
you
know
we
require
all
keys
to
be
nested
under
the
build
packs
domain
inside
of
a
build
pack
specific
file
right.
A
A
Guess,
like
the
question
for
me,
is
how
does
it
work
if
you
want
a
bill
pack
file
that
supports
multiple
platforms.
A
Yeah,
I
think
it's
like
kind
of
sam
described
an
approach
there
right
like
we
encapsulate
all
the
build
pack
specific
stuff
in
the
file.
If
there's,
if
there
are
things
that
are
built
pack
specific,
but
some
platforms
important
some
don't,
then
we
have
a
way
of
those
platforms
validating
whether
or
not
those
keys
are
accepted
and
failing
to
build.
A
If
you
specify
keys
that
aren't
accepted
that
can
be
built
into
the
you
know,
prepare
phase
and
then,
if
they're,
really
platform
specific
fields
like
pac
has
a
you
know:
pac
special
do
something
or
kpac
has
a
kpac
special
do
something
field.
Then
we
can
introduce
a
you
know,
platforms
table
that
has
truly
platform
specific
configuration
in
it
for
fields
that
don't
aren't
specified
by
the
project
at
all.
B
Just
for
brevity's
sake,
if,
if
you
all
don't
mind,
I
could
maybe
take
hopefully
two
three
minutes
to
go
over
my
rfc
and
I
I
will
put
in
the
caveat
that
this
just
adds
more
ideas,
but
at
the
end
of
the
day,
I
think
what
sam
proposed
is
something
that
I've
now
been
leaning
towards
and
something
that
I'll,
probably
at
least
try
to
work
with
him
on
putting
together
yet
another
rsc
and
see
how
that
goes,
but
anyways
I'll
go
ahead
and
share
this
just
to
again
kind
of
get
a
full
picture
here.
B
So
this
is
a
build
packs,
config
right
personally,
I
I
don't
care
to
bike
over
the
name
of
the
file
itself,
but
at
the
end
of
the
day
I
would
consider
this
an
evolution
of
the
learnings
from
the
project
descriptor
as
it
currently
stands,
and
the
motivation
for
this
is
is
actually
three
things
for
me.
B
Personally,
it's
cross
platform
support
is
the
biggest
pain
point,
the
biggest
challenge
that
I'm
trying
to
solve
here,
some
of
the
other
things
incorporated
in
this
rfc
or
moving
you
know,
or
kind
of
trying
to
address
that
obscure
idea
of
the
file
name
itself
from
project
tamil
to
something
more
specific
and
then,
lastly,
to
your
point,
stephen
the
idea
that
if
it's
a
build
pack
specific
thing,
you
no
longer
need
this
sort
of
like
nested,
there's
unnecessary
nesting
for
the
properties
there.
B
So,
basically,
what
it
is
is
a
buildpacks.extension
I
I
enjoy
yammel
more
than
I
enjoy
tamil,
so
that
was
kind
of
my
my
little
thing
in
there.
It's
like
it'd
be
cool.
If
we
could
support
both
and
what
I
did
is
I
threw
a
lot
more
configuration
on
here
than
what
project
descriptor
currently
has
to
try
to
paint
the
picture
of
what
packs
options
currently
are
right.
B
What
our
platforms
options
typically
would
be,
and
then
keeping
in
mind
that
some
platforms
are
not
going
to
support
this,
we'll
talk
about
later
how
we
build
that
into
what
what's
called
a
converter.
Essentially,
but
basically
we
have
this
tunnel
here.
There's
the
yama
on
this
side
for
it
and,
let's
see
so
basically,
it
relies
a
lot
on
what
natalie's
prior
work
on
what
was
called
a
converter
and
this
notion
of
an
application
api.
B
So
this
project
descriptor,
would
be
something
that
is
part
of
this
application
api
and
the
reason
why
I
did
that
is
because,
right
now
it's
an
extension
spec
for
defining
the
schema
of
the
project
descriptor,
but
there's
no
there's
nothing.
That
says
how
this
file
should
be
used
right
and
so
the
application
api
now
starts
defining
how
this
file
should
be
used,
and
the
idea
is
that
you
have
it
in
the
source.
B
The
platform
would
essentially
take
that
over
to
the
converter
and
the
converter
would
yield
back
a
platform.tamul
file,
and
that
is
a
platform
api
specific
file
that
now
the
platform
itself
understands.
B
Some
of
the
things
that
I
wanted
to
incorporate
into
the
converter
were
things
about
allowing
the
platforms
to
specify
sort
of,
like
validation,
rules,
for
being
able
to
say
that
hey,
I
don't
support.
You
know
the
builder
property
right.
So
if
the
builder
property
is
provided,
the
converter
itself
could
throw
those
sort
of
warnings
and,
and
that
sort
of
stuff
be
built
into
that
piece.
D
So
I
I
think
the
the
converter
like,
I
think
we
should
separate
that
from
the
descriptor
itself,
like
the
converter,
could
work.
This
could
work
exactly
the
same
way
for
project
omelette
as
it
is
today
and
in
fact
that's
that
was
like
the
genesis
of
the
google
summer
summer
of
code
project
was
a
paraphase
that
you
know
turned
project
tommel
into
like
a
platform
tunnel.
So
I
don't,
I
don't
think
like
like.
D
I
don't
think
that
is
necessarily
coupled
to
this
proposal,
but
so
aside
from
that,
like
how
does
the
the
schema
of
the
file
you're
proposing
solve
cross-platform
portability?
That's
not
clear
to
me
and
what
inherent
in
the
in
the
file.
B
Nothing
in
the
file
structure
solves
it
right.
This
rfc
is
painting
a
new
picture
of
something
from
what
we
all
just
discussed
right
now,
right,
okay,.
B
It
this
is
what
it
feels
like.
I
call
it
an
evolution,
but
you
know
yeah.
If,
if
that's
the
way
you
want
to
take
it.
C
Yeah
we
can
like
we
can.
If
we
want
to
be
backwards
compatible.
We
can
still
do
what
I
proposed
with
project
normal
just
by
introducing
those
new
allowed
like
in
the
long
list
of
keys
and
overrides,
but
I
think
that
also
implies
that
we'll
have
to
support
it
as
part
of
our
implementation
and
that
it
will
become
a
more
concrete
part
of
the
platform
api
than
what
it
is
today.
C
B
I
mean
stephen
alluded
to
this
right.
What
is
our
stance,
and
maybe
this
is
kind
of
the
the
root
kind
of
challenge
that
that
we're
trying
to
maybe
avoid?
But
what?
What
is
like
the
stance
on
project
descriptor
as
it
stands
right
now,
the
project
tamil
file
and
whether
or
not
that's
gonna,
be
something
that
we're
trying
to
incubate
to
be
a
you
know
a
generic
file,
because
if
we
answer
that
question
right,
then
that
tells
us
where
to
go
or
that
could
influence
greatly
where
we
want
to
go
with
it.
B
B
A
strong
you
know,
stance
on
it
at
this
point.
Maybe
we
could
marinate
on
that
question,
but
it
does
seem
like
that's
a
big
sticking
point.
B
A
So
there
is
180,
that's
still
in
the
project
descriptor
stuff,
on
project
descriptor
converter
did
we
want
to
move
this
and
the
sorry?
If
someone
said
this
already,
we
want
to
move
this
and
the
or
to
do
you
want
to
take
all
the
project
descriptor
stuff
and
talk
about
it
later
or
do
we
want
to
move
on
to
the
yeah
they
were.
They
were
like
one
collection
of
just
dying.
C
E
Yeah,
I
hope
you
don't
mind
if
I
talk
about
this
one
again,
it's
been
a
while,
so
I
just
want
to
reiterate
some
of
the
major
points
to
get
us
on
the
same
page
right.
So
the
purpose
of
this
rfc
was
to
be
basically
be
an
addendum
to
the
previous
accepted
rfc
about
s-bomb
right,
the
previous
one
introduced
s-bombs
provided
by
both
backs,
but
for
scanning
tools
downstream
to
consume
it
and
get
a
full
picture,
a
full.
You
know
s
bomb
of
the
application
image.
E
It's
nice
to
have
the
base
layer
run,
run
image
stack
whatever
you
want
to
call
it.
It's
good
to
have
a
s-bomb
for
that
one
as
well.
You
know,
and
they
can
merge
it
themselves
or
do
whatever
one,
but
as
long
as
it's
present
on
the
file
system
right,
so
this
rfc
was
just
basically
not
really
like,
not
really
implying
any,
like
implementation
work
from
our
site,
just
just
a
format
right
for
how
this
s-bomb
will
be
laid
out
on
the
file
system
and
labeled
as
it
could.
E
You
know
as
a
on
the
container
image
just
so
that
you
know
these
downstream
tools
could
pick
it
up
right
and
the
last
time
we
talked
about
it
and
forgive
me
if
I'm
butchering
this
up
right,
but
the
last
time
we
talked,
I
believe
one
of
the
sticking
points
was
around
well,
basically,
the
whole
thing
right.
The
sticking
point
was
that
the
rfc
is
fine
for
the
world
today.
The
bill
packs
world
today,
but
you
imagine
when
the
support
support,
docker
files.
E
Rfc
comes
out
that
introduces
this
gen
package
is
executable,
which
is
supposed
to
be
run
after
every
extension,
and
you
know,
presumably
you
know
put
an
s
bomb
out
after
every
extension.
How
do
we
exclude
this
gem
packages
and
and
whatever
and
whatever
dependencies
it
has
from
the
final
application
image
right?
E
There
were
some
other
points,
but
forgive
me
sam.
I
think
that
was
the
major
sticking
point
and
you
know
if
we
can
address
that.
Maybe
we
can
move
to
other
ones.
C
Yeah,
that
was
the
main
point
I
I
did
try
to
do
a
poc
of
what
an
in
image
base
image
spawn
generator
would
look
like
using
the
current
tools
that
we
have.
It's
not
pretty
it.
It's
a
lot
easier
to
do
this
outside
the
image
when
you're
scanning
the
whole
image,
as
opposed
to
a
specific
directory,
because
it's
very
easy
to
like
include
dependencies
from
that
s1
scanner
in
your
output
respond.
So
it
becomes
really
hard
to
do
this
inside
the
image
you're
scanning.
If
you're
scanning
the
old
image.
A
Why
not
just
exclude
the
or
you
mean
like
while
gen
packages
is
running
jump
packages
because
it's
going
to
find
its
own
things.
C
Yeah
I
mean
like
gen
packages.
We're
assuming
is
this
ideal,
go
standalone,
binary
right.
That
may
not
always
be
the
case
if
it
has
any
dynamic
dependencies
in
terms
of
libraries
any
other
dependencies,
it
pulls
in
then
you've
polluted
your
actual
base
image
with
a
bunch
of
things.
It
doesn't
need
and
scan
that
in
the
output
just
form.
A
C
Let's
say
you
installed
don,
for
example,
and
you
install
that
as
like
it's
a
python
application.
It'll
include
a
bunch
of
python
dependencies
that
it
has
it's
going
to
be
really
hard
to
find
all
the
python
dependencies
that
were
introduced
because
of
like
turn
and
explode
them
like
it's
not
just
like
shared
libraries
like
it's
like
fights
and
packages
and
they're
right.
It's
it's.
C
A
C
Tools
are
implemented
in
the
language
they
scan,
so
the
ntm1
uses
node
python
uses
pip
the
go
one
uses
code,
so
that's
standalone,
but
all
the
others
are
implemented
in
the
language
they
scan.
A
A
C
C
So
I
asked
for
some
implement
some
details
on
like
some
tooling
that
the
project
provides
that
makes
it
easier
I
and
that
tooling,
should
ideally
carry
over
to
whatever
we
support
next,
so
this
rfc
we
can
like
we
can
approve
and
merge
if
we
just
provide
like
some
like
some
proposal
for
tooling.
That
will
allow
us
to
generate
those
as
form
files
in
that
manner,
and
then
we
can
modify
the
support,
docker
files
rfc
to
make
sure
that
it
can
also
do
something
similar.
A
C
E
C
A
normal
like
my
qualm
with
that
was
that's
not
how
we
generate
stack
images
today
and
currently
stack
images
can
be
easily
generated
using
a
single
docker
file.
So
when
we
move
to
this,
that
won't
be
the
case
anymore,
and
I
want
like
that's
a
thing
we
introduced
as
a
project.
We
should
provide
tooling
to
improve
that
experience.
A
E
A
E
A
To
create
the
stack
image,
I
think
so
and
then
then
I
think
sam's
point
is
that
gen
packages,
it's
not
that
this
introduces
a
problem
with
gem
packages.
It's
that
in
general
gen
packages
has
an
inherent
problem,
that's
unrelated
to
attaching
the
thing,
which
is
that
it's
going
to
pick
up.
The
scanner
may
pick
up
its
own
dependencies.
A
We
have
to
figure
out.
Are
we
comfortable
just
saying
you
gotta
use
sift
until
there
are
other
other
tools
or
do
we
need
to
say?
Do
we
need
to
come
up
with
a
different
way
of
allowing
for
dynamic
extensions
to
specify
a
updated
s-bomb,
which
I
think
is
going
to
be
really
difficult
if
it's
not
running
in
the
container,
but
we
can
figure
it
out
and
that.
C
C
B
E
One
suggestion
I
really
liked-
I
don't
know
if
it's
still
past
but
make
this
a
quote-unquote
utility
bill
pack,
this
bomb
generation
tool,
as
you
know,
so
it's
not
really
provided
by
the
stack
author,
but
but
you
know
that
way
it's
always
present
and
we
control
how
it
runs
and
what
it
does
right
are.
We.
C
The
main
issue
I
have
with
it
is
like:
how
do
you
like
once
you're
inside
the
build
pack?
You
don't
know
the
the
layers
directly.
Those
variables
are
stripped
out
like
the
the
top
level
layers
directory.
I'm
not
talking
about
this
one,
I'm
guessing.
You
can
make
some
assumptions
about
what
those
are
and
try
to
exclude
them,
but
that's
not
part
of
the
spec.
C
The
the
other
option
I
was
thinking
about
was-
and
I
was
actually
hoping
to
write
an
rfc
about
it,
which
is
what,
if
back,
could
do
this
on
the
fly
like.
Currently,
we
need
something
to
merge
the
s
bombs
anyway
or
like
whether
it
can
be
a
platform
specific
concern
where,
if
the
platform
is
given
an
image,
and
it's
supposed
to
generate
the
output
as
form
it's
not
like
we're
going
to
use
some
special
tool
or
we'll
have
more
information
as
the
image
builder
about
the
image
or
the
build
image.
C
C
C
E
I
personally
I
don't
like
that
interface,
you
know
I'd
like
you
know,
for
these,
you
know
whatever
persona
this
is
to
not
have
to.
You
know,
use
pack
for
this
one
one
use
case
right,
it'd
be
nice.
If
it
was
just
all
bundled
together,
it
doesn't
have
to
be
in
the
same
image
right.
I
know
we
discussed
it.
It
doesn't
even
have
to
be
in
the
same
application
image
it's
just
somewhere,
some
container
somewhere
right
that
you
know
it's.
It's
published.
B
And
stamped
and
everything
right
what?
What?
What
is
the
accuracy
of
those
scanning
tools
and
discrepancies
between
different
scanning
tools.
C
You
can
pick
any
of
them,
but
as
soon
as
you
get
to
the
point,
where
you're
using
a
run
image
or
a
non
build
packs
like
interface
to
create
the
image,
you
don't
have
actual
data
anyway,.
B
Right
so
so
I
guess
my
point
is
I'm
assuming
it'll
vary
quite
significantly
between
different,
yes,
inspection
tools.
Right-
and
I
guess
that's
where
maybe
a
concern
of
mine
lies-
is
that
pack
might
choose
a
tool
that
might
not
be
the
right
tool
for
somebody
else,
and
then
I
I
wonder
if
we're
essentially
either
adding
that
or
yeah,
whether
we're
adding
value
to
begin
with.
E
Okay,
well
that
that
being
said,
you
know
I
am
looking
for
next
steps
here.
Can
I
get
an
agreement
that
if
I
update
this
rfc
to
have
a
you
know
pack
attached
method
right?
I
think
that's
that's!
You
know
some
some
way
of
pack
taking
a
pre-existing
s
bond.
We
don't
know
how
it
came
about
right
and
attaching
it
to
a
run
image
and
putting
the
diff
id
on
some
label
where
we're
also
making
sure
that
it's
one
existing
one
existing
layer,
it
has
to
be
one
existing
layer
specified.
E
We
can
maybe
move
forward
with
with
this
for
right
now,
right.