►
From YouTube: CNB Core Team Sync: 2021-11-10
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).
C
A
Some
of
these
look
different.
Wasn't
this
s
bomb
in
the
rfc.
D
It
was
this,
I
think
it
wasn't
even
under
layers
as
well.
It
was
layers
configures
from
because
of
the
reason
I
pointed
to
below,
which
is
there
might
be
build
pipes
that
are
using
the
id
bomb
and
I'm
not
sure
what
happens
when
they
do.
C
D
D
A
D
A
C
Yeah
yeah,
that
was
that
was
totally
a
mistake
that
I
I
did
it
that
changed
up
to
layers
bomb,
in
which
case
sam
are
you?
Okay,
if
the
buildpack.com
field
name
is
also
s-bomb
formats.
D
Just
whatever
is
consistent
is
fine.
I
I
think
it
was
just
because,
like
we,
the
the
issue
is
like
we
refer
it.
We
have
always
referred
to
it
as
bomb
instead
of
s,
and
there
was
the
other
argument
that,
like
things
like
cyclone
dx
can
describe
services
and
hardware
as
well
in
the
bomb.
So
it's
not
technically
a
software
bill
of
materials.
It's
just
a
bill
of
materials.
A
D
D
One
of
the
threads
around
like
there
was
some
random
twitter
thread
where
someone
was
saying:
containers
don't
use
software
dependencies
like
libraries
anymore.
They
just
call
out
to
microservices
there's
nothing
that
captures
those
version
numbers
and
then
they
were
like
no
cyclone
dx
does
and
whatever
you
understand.
A
I
think
we're
trying
to
capture
the
dependencies
that
are
in
the
image
itself
right,
that's
like,
because
we
want
to
do
security
scanning
on
it
and
you,
wouldn't
it
doesn't
matter.
If
you,
your
microservice
talks,
image
talks
to
another
microservice
image
at
a
version.
We
don't
want
to
reflect
that
in
the
software,
but
I
don't
know
okay
whatever
it's
not
that
important.
I
think
we
should
can
we
try
to
stick
to
what
is
in
the
anthony
implemented
the
rfc
here,
because
I
think
some
folks
are
testing
against
that
unless
we
have
a
good.
D
I
mean
given
that
this
is
still
just
a
proof
of
concept.
We
should
make
decisions
that
are
long-lasting
rather
than
based
on
this
pr.
So
if
people
like
whatever
people
think
is
the
best
name,
it's
just
that
so
far
the
project
is
always
referred
to
it
as
bomb,
not
as
form
and
we'll
be
changing
that.
So
that's
it.
B
Yeah,
I
would,
I
would
say
that
too
right.
I
don't
think
I
really
have
a
preference
on
s-bomb
vs
bomb,
but
I
do
think
that
consistency
is
important
for
a
lot
of
the
existing
keys
and
anything
moving
forward.
C
C
A
I
agree,
I
think
I
think
it
it's
a
nice
advertisement
for
the
future
that
you
know.
Instead
of
the
thing
we
call
the
bill
of
materials
before
right.
It's
now,
a
proper
s-bomb
is
the
terminology
that
people
are
using
to
describe
spdx
and
cyclone
dx
formatted
metadata
added
to
images
in
a
standardized
format,
even
if
it
doesn't
stand
for
standardized.
I
think
it
does
kind
of
convey
that
you
know
a
ton.
D
A
D
The
the
api
exposes
that,
like
users
will
create
files
called
something
not
bombed
or
json
and
instead
of
his
form
so
that
that's
going
to
affect
people.
Sorry
it's
called
layer.bomb.extension,
so
it
just
should
be
consistent.
That's
it!
A
Right,
yeah,
sorry,
but
yes
yeah
this.
We
can
rename
that
as
palm
too.
D
For
for
what
its
words,
I
think,
like
again,
these
are
all
like
random
conventions.
People
have
built
like
cyclone
dx
calls,
it
bomb
calls
its
bomb
files
bombed
or
jason,
and
I
asked
them
to
change
it
to
something
like
dot,
cd,
x
or
json,
so
that
we
have
consistency
with
the
other
formats
that
have
like
name
whatever,
like
name
your
bomb
file.
Whatever
just
have
the
extension
be
something
they
have
a
convention
where
the
bomb
file
itself
must
be
called
mom.json.
So
that's
annoying.
A
D
D
The
rfc
called
for
putting
it
under
the
lifecycle
metadata
label,
but
if
we
want
to
shift
it
to
its
own
label,
I
would
do
it
now
rather
than
introduce
this
in
a
intermediate
stage.
Then
just
move
it
out
into
a
separate
table,
so
whatever
we
are
planning
for,
do
it
now
wait.
Sorry
move
one
to
where
so.
Currently
the
sbom
diff
id
is
under
a
key
inside
the
metadata
lifecycle,
metadata
label
and
the
other
rfc
proposal
to
be
a
top
level
label.
So
I'm
fine
with
whatever
we
should
just
make
those
changes.
Now.
D
It
causes
confusion
right
like
if
which
I
don't
know
like.
I
would
just
pick
one
like
it's
just
convention.
We
are
inventing
it's
nothing
introduced
to
the
api.
So
far,
so
let's
just
pick
one.
A
A
C
D
I
mean
is:
is
there
any
benefit
to
putting
it
into
its
own
label?
I
mean
it's
just
convention
right.
We
they'll
just
look
wherever
we're
telling
them
to
look
so
whatever.
B
Because
I
guess
maybe
I'm
thinking
through
the
run
image
itself
doesn't
have
that
life
cycle
metadata.
The
builder
does
right
the.
B
But
but
there's
a
life
cycle
metadata
on
the
builder
image
or
is
there
not?
I
thought
there
would
be,
and
I
guess
ultimately,
what
I
was
going
to
get
at
is:
if
we're
using
the
same
label
in
multiple
places,
I
would
from
api
consumer
perspective.
I
would
expect
the
structure
to
be
the
same
and
not
mutable
right,
meaning
that
on
the
final
app
image
it
shouldn't
all
of
a
sudden
have
an
extra
key.
A
I
also
I
consider
the
life
cycle
metadata
label
to
be
like
internal
metadata.
That's
intended
for
the
life
cycles,
consumption
and
not
something
that's
external,
and
if
we're
going
to
add
another
label
that
describes
the
base
image
metadata,
it's
going
to
be
on
the
final
image
as
this
is
the
this
is
where
the
base
image
metadata
lives.
C
C
To
make
the
lifecycle
implementation
easier,
since
we're
already
passing
this
struct
around,
you
know,
in
the
cache
and
in
the
exported
image
like.
B
D
A
D
B
A
I
agree
that
it
should
be
its
own
label.
My
question
is,
it
seems
like
it's
going
to
be
we're
about
to
cut
a
life
cycle
release
soon.
We
can
get
this
feature
in
and
get
security
scanning
and
build
pack
images
you
know:
is
it
okay
to
have
the
field
live
in
lifecycle,
metadata
for
one
release
and
then
come
back
in
the
next
release
and
add
two
official
fields
for
both
base
image,
metadata
and
app
image
metadata
in
a
subsequent
release?
A
And
to
me
that
seems:
okay,
because
we're
not
going
to
have
an
official
contract
for
reading
s
bum
for
either
layer
right
until
the
second
release.
That
way,
we
don't
do
half
and
one
release
and
the
rest
the
other.
It's
an
internal
feature
for
now
right
and
then
it
then
we
deliver
the
interface
in
the
next
release
unless
we
think
we
can
get
the
other
rfc
merged
in
in
the
next
day
or
two.
D
A
B
B
You
wonder,
if
are
we
rushing
this
too
much
because
I'm
thinking
like
so
this
is
like
a
hidden
feature
of
the
life
cycle
in
this
api
release.
A
B
B
D
I
think
the
release
candidate
would
allow
like
buildback
authors
to
create
the
build
packs,
and
then
we
can
create
an
actual
release
with
the
label
so
that
once
the
s-bombs
are
there,
the
tools
that
are
consuming
them
can
actually
read
it
off.
So,
at
least
from
my
perspective,
the
rush
would
probably
be
like
having
all
the
build
packs
use
the
new
life
cycle
to
test
out
this
functionality.
They
don't
need
to
consume
it
right.
D
They
just
need
to
output
it
and
see
that
it
works,
and
then,
when
we
release
the
actual
life
cycle
candidate,
we
can
also
include
the
other
things
we
are
currently
missing,
which
is
like
merging
cyclone
dx
and
adding
that
label,
and
I
think
the
cyclone
dx
merge.
Gold
library
thing
is
mostly
done.
It's
going
to
happen
in
the
next
week,
or
so.
This
label
thing,
I
think,
should
be
minor
enough
to
be
doable
once
we
ship
the
release
candidate
out
so.
A
I
think
I
like
the
idea
of
cutting
a
release
candidate
first
and
then
deciding
if
there's
anything
else,
we
need
to
do
before
cutting
the
final
release.
I
don't
want
to
commit
to
like
cycling,
dx
merging
seems
like
it's
a
larger
thing
like
I'm
not
saying
we
shouldn't
add
that
eventually,
but
I
don't
I'm
not
sure.
I
agree
that
it
has
to
go
into
the
next
release
of
the
life
cycle.
The
labeling.
A
A
C
Are
we
stating
that
merging
of
the
cyclone
dx
bombs
is
going
to
be
part
of
the
next
release?
I
guess
my
question
is:
should
that
be
part
of
buildpath
api
or
platform,
api
os
right.
A
I
I
think
we
should
d
scope
the
merging
of
cyclone
dx
in
particular,
because
we
I
mean
not
just
because
I
don't
know
when
it'll
be
finished
upstream,
but
because
I
have
worries
around
rebase
like
it.
I
think
we
can
do
it
eventually,
but
I'd
like
to
think
harder
about
what
rebase
should
look
like
if
it
has
to
do
a
merge
of
multiple
invested.
If
it's
not
just
a
quick
registry
operation,
it
can
be
done
for
many
many
applications
at
low
cost
right.
A
If
there's
something
incurred
there,
if
you
have
large
s-bombs,
I
think
I
want
to
see
more
testing.
First,
I'm
not
saying
we
shouldn't
do
it.
I
just
it
seems
like
we
can
ship
something
very
usable
without
it.
It's
a
feature
that
we
can
add.
You
know
we
can
add
a
combined
merged
label
later
it's
purely
additive.
You
know,
I
don't
see,
reason
to
try
to
get
it
into
the
next
release
before
we
have
a
chance
to
kind
of
evaluate
the
impact
of
trying
to
merge
file
formats
together
from
any
application
simultaneously
in
scale
scenarios.
D
A
D
I
think
what
we
were
discussing
is
to
keep
it
in
the
spec
as
a
may
or
like
a
shirt
rather
than
a
must
in
terms
of
merging.
So
that
way
we
can
ship
the
spec
out
and
then
have
a
life
cycle
version
update
that
adds
the
merging.
So
we
don't
change
the
spec.
It
says
that
platform
may
merge
these,
which
also
gives
some
leeway
for
platforms
to
do
their
own
merge
operation
if
they
want
to
and.
C
I
I
didn't
have
concerns
about
that.
I
think
maybe
it
was
mentioned
at
some
point
that
that
might
be
surprising
to
build
authors,
or
I
mean
like
hey.
I
didn't
change
any
of
my
apis.
My
apis
are
all
the
same,
but
I
bought
my
lifecycle
and
now
I'm
getting
this
extra
layer,
I'm
getting
something
extra
in
my
image
that
wasn't
there
before.
C
B
B
I
don't
have
a
strong
stance,
but
I
would
say
that
if
we
go
down
that
route
we
it
might
be
beneficial,
because
we
could
also
find
something
along
the
way
as
we
try
to
implement
that
that
may
require
additional
changes,
and
that
might
not
be
true
if
we
just
leave
it
at
may
and
and
obviously
not
be
able
to
satisfy
whatever
is
necessary.
Otherwise,
but
I
think
the
risk
is
low.
So
I'm
not
sure
again.
D
I
think
just
from
like
a
consumer's
point
of
view,
if
you're
looking
at
that
bomb
directory
later
on
scanning
it
or
whatever,
like
the
individual
s,
bombs
are
under
a
different
folder.
The
merge
just
form
is
a
top
level
file,
so
your
merged
logic
would
probably
have
to
change
for
to
account
for
that
mergers
from
anyway.
I
don't
think
it
will
be
breaking
anything
but
yeah.
Okay,
it
doesn't
cause
your
app
to
behave
different
functionally.
I
would
say.
B
So
officially
I
want
to
do
a
time
check
on
on
this
topic
only
because
of
other
things
that
I
wanted
to
bring
it
up.
A
A
What
did
you
want
to
bring
up
hop
here?
I.
A
A
B
Yeah,
I
think
that
one's
waiting
on
joe,
I
think
we
need
them
right
for
that
quorum.
A
B
B
A
B
Yeah
we
could
do
that.
I
don't
know
if
the
the
individual
proposing
this
will
be
able
to
attend,
but
we
could
try
cool.
I
could
add
that
as
an
action
item
for
myself.
A
Run
images
bomb,
it
seems
like
there's
still
some
things
to
talk
about
on
this
one
like
when
we
want
to
standardize
some
of
these.
If
we
do
some
of
it
early
so
I'd
say
probably
talk
about
this
one
also.
D
I
mean
like
I'll,
first
update
it,
and
then
we
can
chat
with
the
new
proposal.
I
mean
it's
still
the
old
one.
We
haven't
updated
it
to
the
multiple
outdoors
thing.
We
talked
about.
A
Yeah
got
it
system,
build
packs.
A
I
don't
know
if
anybody
here
is
super
involved
in
that
one,
so
I'm
gonna
skip
over
it
utility
build
packs,
it's
an
fcp,
so
it
probably
doesn't
I'm
guessing.
That's
going
to
get
merged,
probably
doesn't
need
a
comment.
There
were.
D
There
were
a
few
changes
it
asked
for,
but
yeah
there
were
a
few
musts
that
should
be
should
that's
it.
B
How
about
we
added
to
the
agenda
just
for
a
check,
sounds
good.
A
Drafts
docker
files-
I
don't
have
anything
else.
I
think
this
is
kind
of
ongoing.
Oh
I
did
I
did.
I
was
hoping
charles
would
show
up
to
chat
about.
Actually,
let's
add
this
talk
about.
I
don't
know
if
last
time
we
talked
about
too
much
about
the
different
we
talked
about
user
space
versus
you
know
like
a
docker
damage-based
implementation-
I
I
guess
add
it,
but
we'll
only
talk
about
it.
A
Okay,
so
don't
don't
put
it
done
well,
we'll
see
you
for
next
week
we
should
probably
find
extra
time
to
chat
with
him.
Actually,
I
think
that'd
be
good.
Make
build
layers
read
only
for
subsequent
build
packs,
yeah.
B
All
right
and
for
171
writeable
asset
cache
that
was
emily
did
we
did
that
get
handed
over
to
a
new
champion.
D
B
I
guess
does
it
have
somebody
driving
that
change?
I
guess
I'm
thinking
through
either
pocato
or
or
somebody
that
took
the
baton,
saying.
D
B
Yeah,
I
mean
the
the
reason
why
I
bring
it
up
is
because
we
have
some
spec
qrs
that
are
pending
on
whether
or
not
we're
going
to
revert
the
other
asset
packages
or
asset
cash
that
we
have
the
one
that
dan
worked
on
for
quite
a
bit.
A
Yeah,
I
think
we
decided
to
revert
or
to
not
move
forward
with
asset
packages
and
not
move
forward
with
writable
asset
cash
and
instead
create
one
unified,
better
way
of
dealing
with
cashing
that
maybe
also
handles
assets,
but
that
you
know
emily
was
driving
that
effort
and
nobody
has
stepped
up
to
take
on
that
effort.
Yet,
and
the
current
plan
is
wait
till
emily
comes
back
unless
somebody
steps
up
and
says
yep,
I'm
going
to
take
this
on
and
drive
through
the
project
so.
B
There's
no
like
real.
I
guess
need
for
this
feature
at
least
not
pressing
from
anybody
right
now.
A
I
think
the
poto
folks
want
some
kind
of
asset
like
not
writable
asset
cash
during
build,
but
they
want
the
you
know
to
be
able
to
create
an
offline,
build
pack
that
has
vendored
assets
that
has
the
same
id
as
a
build
pack
that
is,
does
not
have
vendored
assets.
They
still
have
that
use
case,
and
so
it
would
be
great
to
see
if
they
someone
on
that
side
wanted
to
step
up
and
own
revamping
the
whole
caching
system
for
cloudy
nipple
packs,
but
so
far
nobody
has
volunteered
to
do
that.
Yet
cool.
A
All
right,
I
think,
that's
it-
do
we
need
to
sort
the
ones
for
the
agenda
tomorrow.
A
Let's
do
it
anything
else,
well,
jump
to
whatever
is
left
at
the
other
meeting.