►
From YouTube: 2021-10-27: CNB Core Team Sync
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
Cool
awesome,
so
please
sign
to
the
doc
if
you
haven't
already
paste
it
chat.
A
A
Well,
can
everyone
see
this
so
these
are
all
draft.
I
did
want
to
ask
joe
if
you
want
me
to
kill
these
like
kind
of
stack
pack
yeah,
we
can
go.
A
Cool
do
we
feel
the
same
way
about
acid
packages?
I
know
these
have
been
around
for
a
while
and
I
feel,
like
they've,
been
kicked
out
of
the
releases
for
stuff.
A
Maybe
I
don't
know
if
we
actually,
I
think
we
got
anthony's
rc
in
and
through,
but
I
don't
know
if
we
actually
officially
did
that.
So
that
is
probably
to
call
out
to
actually
get
that
through
before
closing
those.
C
Yeah,
I
think,
ultimately,
I'm
just
comprehensive
about
who
is
going
to
drive
the
alternative.
C
And
if
it
doesn't,
then
we
might
have
to
fall
back.
But
that's
kind
of
where
my
mind
is
at.
A
I
was
not
at
the
last
bat
meeting
last
week
because
I
was
out,
I
know
in
the
one
before
these
discussions
have
come
up
somewhat,
at
least
occasionally
in
the
back
sync,
for
what
to
do
about
caching,
at
least
from
a
build
pack
author
perspective,
because
I
think
almost
all
forms
of
caching,
in
fact
build
pack
authors,
even
though,
obviously
it
has
high
implications
for
the
implementation
team.
A
Yeah,
I
I
think,
maybe
coming
at
least
some
proposals
coming
out
of
the
bad
group
working
group.
C
So
maybe
I
would
just
propose
that
we
officially
kill
the
asset,
rf
yeah,
rfc
and
then
kill
these
then
after
that,
it's
more
explicit
our
intent.
A
A
A
A
A
Were
there
besides,
your
you
had
to
comment
that
he
updated.
Were
there
any
other
outstanding
things?
I
guess
we
wanted
to
change
from
this.
C
No,
I
think,
I'd
really
like
to
get
more
eyes
on
it
or
get
it
moved
in
as
quick
as
possible.
Just
as
a
forewarning,
we,
we
passed
our
midpoint
for
the
mentorship
program
right,
so
we
want
to
get
a
lot
of
this
done
before
he
essentially
needs
to
go
elsewhere
or
he
may
go
elsewhere.
C
So
that
I
think
that's
a
call
out-
and
I
think
I
added
everybody
as
a
reviewer-
but
if
you
can
just
get
your
eyes
on
there,
get
your
approval
on
it
and
get
some
traction
behind
it.
Cool.
A
Is
there
stuff
steven
joe?
Do
you
have
time
to
take
a
look
at
this
in
the
coming
week?.
A
A
I
guess
for
this
this
seemed
pretty
non-controversial
to
me.
Do
you
any
of
you?
Have
I
guess
steven?
Do
you
have
issues
with
me
merging
this
one.
A
B
A
Awesome,
I
guess
I
was
also
curious
about
this.
Do
you
have
thoughts
on
basically
just
a
pending
and
buildback
api
version
here,
stephen
that
they
need
to
be
unsigned
editors
on
side64
bit
integers,
because
that's
what
it
that's
at
least
how
it's
codified
in
lifecycle?
A
That
sounds
good
to
me,
and
I
know
when
we
were
implementing
this
came
out,
because
we
were
implementing
our
like
lib
cnb
stuff
on
the
salesforce
side
in
rust,
like
we're
wondering
basically
which
type
to
use
and
it's
not
specified
in
the
spec.
B
A
For
this
particular
one,
I
think
we
should
id
false
numbers
for
other
stuff,
where
we
are
actually
doing
a
major
minor
patch
and
potentially
alpha
as
well.
C
I'm
gonna
throw
this
on
the
table.
I
believe
if
ben
was
here,
I
I
think
I
heard
it
from
him
is
this
is
pointing
to
maine
right,
and
I
think
the
intention
is
our
current
branching
strategy
is
that
it
would
be
off
of
or
it
would
be,
a
very
specific
next
version
of
the
api.
A
Yeah,
thank
you
out
here.
A
I
remember
doing
this
for
another
pr.
Did
we
just
want
like?
Do
you
repoint
all
this
stuff?
What
did
you
do.
C
C
When
they
create
a
pr,
they
get
a
little
check.
Checkbox
that
says
that
a
maintainer
could
update
their
branch
and
typically
that's
the
thing.
C
No,
I
mean,
I
don't
think
you
could
do
it
from
the
con
from
the
ui.
I
typically
do
it
from
the
terminal.
Okay,
do
a
rebase
and
then
just
put
force
push
into
his
branch
and
then
feel
guilty
about
it.
A
A
A
B
I
think
that's
fine
to
be
especially
restrictive
that
you
can't
have
version
numbers
over
the
limit
of
a
64-bit
integer.
A
A
Okay,
all
right
so
distribution,
life
cycle
decision,
spec.
A
I
basically
pulled
up
kind
of
the
rfc
that
I
think
emily
wrote
on
a
lot
of
this
stuff,
and
I
noticed
that,
like
lifecycle,
tamil
is
not
actually
in
platform,
or
I
don't
know
where
else
we
would
put
it
in
time.
The
pre.
This
change.
A
But
it
sounds
like
we
don't
include
lifecycle
tamil
when
we
aren't
doing
non-tarball
stuff.
A
Is
this
spec
for
distributing
life
cycle
as
a
whole,
so
it
should
cover
both
the
image
and
tarball.
I
think
use
case
is
that
correct.
C
It's
when
I
spoke
to
emily
its
intent
was
to
be
oci
specific.
That
being
said
for
build
package.
We
also
talk
about
its.
C
You
know,
cmb
tar
format,
I
don't
have
a
personal
preference,
but
ultimately
I
would
ask
what
the
end
goal
is
and
I'm
not
sure
that
for
the
life
cycle
as
a
tar
or
in
tarp
format
is
something
that
needs
to
be
specced
out,
depending
on
how
the
platform's
intended
to
use
use
it-
and
I
guess
maybe
that's
the
question
right
is:
do
we
intend
to
specify
exactly
how
a
platform
consumes.
A
Yeah,
I
guess
to
some
degree,
if
I'm
a
platform,
and
I
am
pulling
down
a
life
cycle,
should
it
be
specked
what
is
in
the
image
and
or
what
is
in
the
tarball
and
how
that
layout
looks
right,
like
that's
kind
of
the
question.
C
C
So
is
there
I,
I
guess,
natalie
if
we
want
to
dive
into
those
sweets,
or
maybe
we
should
talk
about
it
in
working
group,
I
don't
want
to
pretty
much
into
the
weeds
and
derail
us
again
like
last
time.
A
Let's
talk
about
it
in
more
detail
tomorrow,.
A
I
guess
for
releases
spec
releases.
A
C
A
Okay,
if
that's
the
case,
I
think
jonah.
I
can
probably
sit
down
and
finish
out
price
descriptor
and
get
that
release
for
point
two
and
then
walk
back
and
came
back.
A
And
the
next
one,
probably
that's
closest,
would
be
distribution
of
three.
Does
that
sound
right.
C
Yeah,
I
do
have
a
question
since
it
kind
of
ties
to
what
is
it
called
a
lot
of
the
other
work,
removing
snacks,
whether
or
not
we
would
be
treating
each
spec
independently
or
if
we'd
be
kind
of
waiting
for
other
parts
of
the
spec
like
the
platform
or
the
build
pack
to
kind
of
adapt.
A
I
mean
ideally
it's
independent,
so
that
makes
me
think
like
do.
We
have
to
account
for
stacks
and
stuff
in
the
distribution
as
like
a
backwards
compatibility
measure
if
your
platform
or
if
your
bill
pack
or
whatever
is
using
that
stuff.
C
I
I
would
favor
not
blocking
the
distributions
back
because
to
your
point
they
should
be
independent.
C
I
think
that's
preference
and
then,
in
regards
to
compatibility,
I'm
not
sure
that
the
spec
is
the
right
place
to
put
in
compatibility.
I
think
that
should
be
deferred
to
the
implementation,
not
talking
strictly
of
the
life
cycle,
but
just
in
general
of
platforms
and
stuff
like
that.
A
C
A
Cool,
so
that's
gonna
be
all
right
anything
else
on
that,
I
guess
we
also
need
to
then
resolve
the
asset
package
stuff
for
0.3
to
get
that
at
least
punted
or
removed.
A
We're
still
blocked
on
make
build
layers
read
only
for
subsequent
fill
packs.
Is
that
correct
status
for
this
this
week.
A
Forgot
to
tell
javier
what's
happening,
I
think
the
action
item
here
is
to
resolve
kind
of
this
bottom
thing
of
like
how
we
actually
want
to
kind
of
spec
spec
this,
and
I
think
that's
a
thing
I
think
stephen
said
he
doesn't
have
time
to
lead
that
effort,
but
I
mean
joe
and
I
were
talking,
I
think
yeah.
B
B
So
I
like,
I
wonder
if
there's
a
way
we
can
approach
this
as
like
spec
by
committee,
or
something
like
that
where
we
can
divide
it,
you
know
divide
pieces
of
it
up
among
a
group
of
individuals
or
have
some
kind
of
working
group
for
the
spec
changes.
B
A
That
sounds
good
to
me.
I
just
I
are
there
folks
who
are
volunteering
for
that
committee
or
yeah.
I
can
definitely
contribute.
B
B
Both
yeah,
I
mean,
I
think,
like
I
think,
terence's
ask-
is
more
clarity
around
what
spec
changes
are
going
to
happen,
and
I
think
we
need.
You
know
like
a
combined
effort
to
do
that,
and
I
think
that
same
group
I
I
would
argue
that
same
group
should
be
responsible
for
seeing
it
through
to
a
spec
vr.
A
B
B
B
A
Figure
out
the
next
next
step,
I
don't
know
the
the
planning
for
the
planning,
yeah
yeah.
I
mean
that
sounds
good
to
me.
I
just
want
to
see
this
kind
of
help
move
forward.
I
mean
this
thing
can
just
even
be
in
slack
right.
It
doesn't
have
to
be
a
meeting
yeah.
B
A
B
I
have
two
action
items
from
last
week
that
I
did
not
address
so
others
still
yeah
they're
still
out
there
cool.
I
need
to
update
the
I
need
to
mention
the
rfc
for
each
build
pack
and
then
the
bat
friendship.
A
Sounds
good
system
built
backs
are
blocked
on
that
additional
exportable
layers.
I
think
I
haven't
seen
updates
to
this
by
soon,
just
still,
depending
on
sam,
getting
time
to
kind
of
make
those
changes
yep
and
then
the
project
descriptor
converter
kind
of
forget
where
we
stand
on
this
every
time.
C
I
I
still
have
some
reservations
about
this
rfc
or
the
idea
in
general,
and
I
think
we
had
talked
about
maybe
discussing
in
our
working
group.
But
then
a
whole
bunch
of
stuff
happened.
B
A
Or
you
were
out
and
then
you
were
out
again
freaking
out
like
yeah,
two
or
three
in
a
row.
Should
we
put
it
on
the
agenda
for
tomorrow,
yeah
that'd
be
great.
A
That's
it
for
active
rfcs.
Did
we
want
to
add
stuff?
I
guess
from
kind
of
the
draft
things
looks
like
both
javier
and
anthony
have
added
things
from
here.
B
B
It's
basically
an
addition
to
the
previous
s
bomb
rfc,
where
now
there's
a
basically
a
stack
s
bomb
right
like
if
your
stack
creator,
you
put
a
layer
in
a
specified
directory
for
for
your
stack
s
bomb
and
then
the
life
cycle
can,
if
cyclone
dx
combine
it,
you
know,
I
don't
know
if
it's
worth
our
working
group,
because
that
you
know
I
don't
know
if
there's
any
questions
about
it
yet.
B
But
I
I
think
this
is
like
there's
the
earlier
rfc
that
worked,
that
for
build
pack
s-bomb
where
we
de-scoped
the
you
know
how
we
ingest
a
stack-s-bomb
right.
I
think,
sam.
That
was
like
one
of
the
things
that
the
comment
when
that
was
opened,
but
the
dockerfile
rfc
refers
to
io
buildpack's
s-bomb
as
a
label,
for
you
know
how
the
s-bomb
could
get
regenerated.
B
C
C
B
In
the
stack
file,
sorry
stack
five
rfc
yeah,
it's
in
the
docker,
it's
the
support,
docker
files-
rfc,
that's
you
know
open
right
now,
but
that's
kind
of
getting
close
to
closing.
There's
that
gen
packages
interface
that
regenerates
that's
like
a
hook
that
lets
you
regenerate
the
s-bomb
and
it
just
says
I
o
build
packs.
S-Bomb
is
the
label
and
it
doesn't
talk
about
the
format
of
that,
and
so
I
think
you
can
kind
of
like
conclude
that
it's
probably
the
same
format
as
the
buildback
label.
B
You
know-
and
you
know
it's
like
a
layer
on
the
you
know
in
the
file
system
and
it
references
that
digest
like
you,
can
draw
conclusions
from
what
that
rfc
says
and
from
what
your
rfc
did,
but
there's
nothing
explicitly
states.
This
is
what
that
part
looks
like,
and
I
think
that's
what
anthony's
trying
to
define.
C
B
I
forget
what
the
interface
is.
I
think
outputs
cycle
and
dx
or
and
spdx.
B
B
B
It
was
supposed
to
be
paired
with
your
rfc,
and
then
you
got
the
scope
from
that,
and
so
so
I
think
adding
that
label
is
what
anthony
is
trying
to
do
and
defining
what
the
output
format
looks
like
and
all
of
that
stuff
I,
I
would
definitely
add
it
for
working
group
tomorrow,
anthony
if
that's
okay,
I'd
just
like
to
talk
about
the
directory
structure
and
the
inside
there
and
get
it
worked
out,
but
I
don't
think
we
need
to
hold
up
the
s-bomb
stuff
on
it
right
like
we
already,
we
already
committed
to
the
work
that
got
merged
in.
B
I
think
we
can
cut
that
it's
ready
almost
in
the
life
cycle.
I
can
cut
that
out
and
cut
an
api
release
and
then
follow
up
with
the
stuff
later
after
there's
more
discussion
you
might
take,
but
thanks
anthony
for
opening
it.
I
think
it's
really
good
cover
the
cap.
A
A
Compatibility
for
distribution,
discussion,
yeah,
yeah,
okay
and
then
we
have
the
project,
descriptor,
converter,
rfc
and
then
anthony's
s,
bom
rc.
Does
that
sound
right.
A
A
All
right
that
sounds
good
to
me
anything
else
before
we
close
this.
C
Just
so
I
know
the
agenda
items
are
those
being
added
to
the
working
group.
Future
topics.
A
Yeah
I'll
make
sure
to
edit
after
this
meeting.