►
From YouTube: CNB Sub-Team Sync: BAT 2021/11/19
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
Think,
that's
it
in
terms
of
lip
cnb
release
life
cycle
0.13.
I
don't
know
what
that
did,
that.
B
I
did
it
just
it's
also
just
a
release
that
supports
the
layers
and
the
various
s-bond
files
as
well
that
go
in
tandem
with
that
lip
scene
release.
A
B
I
think
that
frankie
would
be
able
to
speak
better
to
that
in
terms
of
how
we're
testing
the
life
cycle
or
how
we're
testing.
What
exactly.
B
We
are
using
various
hacks
from
various
upstream
folks.
There
is
no
good
like
I
wish,
so
I
could
tell
you
we
were
doing
something
better,
but
we're
really
not
it's.
It's
not
cute.
A
All
right,
I.
A
I
mean
at
least
for
I
I
know
I
I
I'm
not.
I
created
an
issue
for
pac,
I'm
not
sure
when
any
of
the
maintainers
on
the
platform
site
will
have
the
time
to
get
to
it.
Otherwise
I'll
try
to
add
support
for
it.
We
did
it
for
kpack
yesterday,
but
that
vr
is
still
open.
I'm
not
sure
if
you
use
escape
pack
at
all
for
testing
pocket
or
stuff,
but
that
should
it
will
also
take
a
while
to
release
that.
But
the
back
issue
is
and.
A
Yeah
and
I
think
anthony
just
updated
posted
some
updates
there,
so
it
looks
like
mikey
is
working
107.,
oh
and
07,
to
808.
I
think
this
functionally
as
a
platform.
There
are
no
changes,
I
think
back.
Minus
minus
bomb
will,
like
back,
inspect
bomb
will
have
to
be
updated
but,
like
I
don't
think
that
prevents
you
from
creating
images.
A
Next,
standing
item
is
rfcs,
just
something
to
note
the
utility
buildbacks
rfc
was
just
merged,
so
that's
probably
going
to
be
a
new
set
of
responsibilities
for
our
team.
A
I
think
joe's
original
plan
for
that
rc
was
to
allow
for
another
rc
that
emily
had
put
in
a
while
ago,
which
was
to
remove
wall
shell,
specific
logic
from
life
cycle,
so
in
order
to
facilitate
that,
while
still
preserving
compatibility
for
like
profile
scripts
and
other
things,
I
think
that
was
the
main
motivator
behind
that
rfc.
A
Let
me
share
my
screen.
There's
also
this
other
one
for
support.
Docker.
Oh
sorry,
for
there
is
that
system
buildbacks,
which
is
the
ability
to
add
those
utility
build
packs
by
default.
A
There
was
a
healthy
amount
of
discussion
on
it
yesterday
in
the
working
group
meeting.
I'm
not
sure
how
many
people
here
attended
that
specific
segment,
but
it
was
mostly
around
whether
we
would
like
these
system
bill
packs
to
participate
in
the
build
plan
or
not
whether
we
would
want
them
to
affect
other
build
packs
that
are
participating.
How
this
interacts
with
the
pre
and
post
build
packs
that
we
already
have,
in
fact
normal,
and
whether
the
only
the
build
packs
from
the
buildbacks
io
project
should
be
allowed
a
system
buildbacks.
A
I
think
those
were
like
the
major
discussion
points.
I
don't
know
if
anyone
here
has
any
opinions
or
thoughts
on
this,
but
I
think
this
is
an
interesting
rfc
where,
like
we're
trying
to
move
some
of
the
features
from
the
life
cycle
to
the
build
packs
api,
so
that
it's
more
portable
and
it's
easy
to
add
extensions.
B
I
I
was
questioning
the
the
amount
of
like
the
utility.
This
has,
I
think,
there's
a
couple
of
build
packs
that
especially
in
our
builders,
because
this
is
like
a
builder
level
system-
change
yeah,
where
we're
like
yeah
every
group
that
we
have,
we
chuck
ca
certificates
at
the
top
and
proc
file
at
the
bottom
and
yeah.
You
know
that's
the
way
that
it
is
but
like
in
some
respects
I
feel
like
I
mean
I
guess
I
guess
you
wouldn't
necessarily.
B
Why
not?
Why
not
have
those
be
like
default,
build
packs
or
like
default
utility,
build
packs
as
well?
And
I
I
don't
know
I
I
I
kind
of
get
this
but
like
I
feel
like
it's
a
little
more
limited
than
than
that.
A
A
The
other
thing
was
like
by
having
this
as
the
default
they
didn't
want
to
like
couple
each
build
back
with
like
all
of
these
additional
utility
built
back
so
like
they
wanted
default
to
be
on
the
system
level
and
then
no
matter
which
buildback
you
use.
You
get
the
profile
d
behavior
for
example.
A
So
I
think
that
was
the
main
reasoning
behind
this
rfc.
I
think
the
way
poto
has
been
structured,
I
think,
is
slightly
different
than
users
have
come
to
expect
all
these
utility
build
packs
to
be
running
alongside
the
language,
specific
ones
and-
and
they
might
also
know
what
these
utility
bill
packs
do.
A
I
think
in
this
case,
like
I,
I
don't
want
to
speak
for
joe,
but
I
think
like
heroku
has
just
come
to
expect
that
if
you
put
a
dot
profile
in
your
application,
like
it
just
happens
automatically
as
part
of
the
buildback
api,
no
one
has
ever
had
to
write
a
specific
buildback
for
it.
A
And
like
having
that
carry
over
as
a
config
file
instead
of
command
line
flags,
I
think
there
was
also
some
discussion
around
this,
like
what's
the
future
of
project
descriptor
and
project
and
whether
it's
too
generic
or
to
be
recognizable
to
our
project.
So
that's
why?
I
think
there
are
a
bunch
of
suggestions
here
on
descriptive
files.
A
A
as
a
name
as
a
file
name
is
too
generic
and
it
can
be
sort
of
hard
for
just
the
buildbacks
ecosystem
to
own
it
and
work
on
it
and
parse
it
and
know
what
to
do
with
it
and
then
also.
The
other
point
was
like
we
sort
of
have
this
whole
project,
descriptive
concept
as
an
extension
spec,
so
platforms
may
or
may
not
support
it,
but
then
we're
also
trying
to
make
this
configuration
portable
across
platforms,
and
then
that
doesn't
work
well,
because
certain
platforms
can
inherently
not
support
certain
operations
in
the
project.
A
Descriptor
like
randomly
changing
the
builder
or
changing
or
adding
build
packs
in
or
don't
want
to
support
it.
So
I
think
that's
where
all
of
this
has
come
into
play
like
back
door.
Tomorrow
is
supposed
to
be
configuration
just
for
pack,
and
it
includes,
like
all
the
things
like
these,
like
setting
the
group
setting
the
output
image
name
and
other
things
like
that.
B
That's
fair,
I
I
think
I,
if
I
remember
correctly,
I
remember
project
tunnel
being
hairy
for
like
I
was
like.
I
think.
Julia
also
has
like
a
project
tamil
or
I
can't
remember
if
it's
julia
or
if
it's
it's,
but
whatever
I
was
like
well
how
the
hell
am
I
supposed
to
use
that
for
detection
and
how
is
trulia
supposed
to
know
which
project
tom
will
use
now
and
like.
A
It's
that's
what
that's
like
one
of
the
arguments
for
like
like
this.
This
that's
the
reason
why
this
bag
or
domino
rfc
exists,
is
because
project.dongle
is
like
too
generic
and
it's
hard
to
shove
things
in
there,
while
still
like,
preserving,
like
api
compatibility,
multiple
platforms
from
different
versions
being
able
to
support
it.
So
there
are
three
of
them.
There's
this
images
table,
one
which
tries
to
add
the
actual.
Like
images
you
want
to
output
in
the
project,
descriptor,
which
is
again
something
that
doesn't
carry
well
across
platforms
apart
from
pack.
A
There's
this
one
that
joe
opened
yesterday,
which
I
mean
I
had
a
brief,
look
at
it,
but
the
idea
is
that
currently,
the
arguments
passed
to
the
buildback
api
are
hard
to
like
understand,
and
users
have
to
go
and
look
back
at
the
spec
again
to
like
figure
out
okay,
which
of
these
positional
arguments,
is
what
and
also
like
for
certain
shell
scripts
and
things.
A
It
might
be
easier
to
just
get
the
arguments
as
environment
variables,
so
this
rfc
proposes
that
we,
instead
of
using
positional
arguments
to
describe
free,
pass
and
everything
as
an
environment
variable
this
another
reason
for
doing
this
was
also
to
allow
for
like
more
flexibility
and
what
kind
of
arguments
we
add
in
the
future.
A
So
currently
we
are
stuck
with
like
if,
if
you
want
to
change
the
order
or
like
add
additional
flags
or
something
it
might
break
certain
scripts,
whereas
environment
variables
like
if
you're
not
doing
anything
with
them,
they
won't
do
any
harm.
So
I
think
another
reason
was
that,
like
we
can
introduce
new
things
here
without
breaking
compatibility
which
isn't
that
feasible.
If
we
pass
them
as
positional
arguments,
I
I
didn't
have
any
strong
opinions
on
this.
A
A
B
I
wanted
to
have
a
quick
discussion
about
the
ad
run
image
s-bomb
there
was.
There
was
some
back-and-forth
discussion.
I
believe
sam
you
were
having
with
anthony
around
this
rse
and
some
of
the
issues
around
it.
B
And
I
just
wanted
to-
I
guess
in
a
I
I
kind
of
came
into
this
a
little
bit
later.
I
didn't
know
about
this
until
very
recently,
so
so
I
understand
that
there's
a
dockerfile
rfc
that
is
proposing
to
be
able
to
extend
your
images
sort
of
like
as
like
a
additional
layer
that
you
can
almost
strap
on
top
of
images.
And
so
that's
is.
B
Is
that
the
main
conflict,
or
is
that,
like
the
main
technical
conflict
that
we're
having
right
now,
when
looking
at
how
to
support
something
like
a
run
image
s
bomb,
because
all
we
can
all
we're
really
able
to
do?
Is
like
at
distribution
time
attached
to
bill
of
materials
stuff
honestly,
with
the
underlying
run
image.
A
So
I
think,
like
there
were
a
bunch
of
points
around
like
how
we
could
provide
this
functionality
while
still
making
it
easy
to
create
wrong
images.
I
think
we
sort
of
compromised
on
some
of
them,
but
I'll
still
list
out
the
points.
One
thing
was
like
currently,
brown
images
can
be
created
entirely
just
using
docker.
You
don't
need
any
special
tool.
This
proposal
will
require
a
multi-step,
not
not
even
a
multi-stage,
like
multi-step
talkable,
where
you
first
construct
your
own
image,
and
then
you
have
to
attach
and
respond
to
it.
A
So,
like
the
the
concerns
I
had
with,
that
was
one.
You
need
an
additional
tool
now
that
knows
how
to
perform
this
operation,
whereas
previously
you
didn't
and
then
the
other
thing
was
you're
mutating
your
run
image
with
the
s
bomb,
so
by
attaching
the
bomb
to
the
image
you're,
essentially
causing
it
to
change.
A
So,
like
a
bunch
of
these
reasons,
are
why,
outside
of
this
rfc
like
in
terms
of
cosine
and
how
the
osa
artifacts
small
attachment
proposals
are
laid
out,
is
you
add
that
as
a
separate
sidecar
image,
so
that
the
original
image
and
its
integrity
stays
intact
and
the
other
image
is
just
referenced
through
a
nose
artifact?
So
you
can
still
find
out
what
the
s
form
is,
but
it
doesn't
mutate
the
original
one.
A
So
I
think
we
eventually
want
to
be
in
that
place
where
we
use
ocean
artifacts
instead
of
mutating
neuron
image,
because
that
also
has
other
nice
consequences,
especially
during
rebase,
where
like.
If
all
of
these
things
are
like
attached
as
artifacts
you
can,
you
can
do
the
run
image
replacement
like,
especially
if
you
just?
A
If
you
just
look
at
how
cosine
does
it,
you
can
do
the
run
image
replacement,
as
as
the
rebase
operation
works
today,
without
any
changes
and
the
spawn
will
come
for
free,
because
the
ds
form
is
uniquely
identified
by
the
digest
of
the
image
you're
talking.
So
there
were
some
other
discussions
on
like
what
happens
on
registry
relocation.
A
And
I
believe
like
well,
we
still
haven't
like
completely
bought
into
cosign,
yet
at
least
till
now.
So
there
were
like
a
bunch
of
reasons
not
to
go
that
route,
and
this
was
obviously
fast
than
trying
to
integrate
coastline
into
the
whole
thing.
But
the
main
sticking
point
was
like
whether
we
should
be
introducing
something
that
we
know
we'll
probably
defecate
in
the
future,
with
the
large
breaking
change
and
whether
we
want
to
do
it.
Given
the
other
rfcs
that
are
present
and
we
know,
will
be
merged
like
this
support.
A
B
Okay,
cool
that.
I
think
that
that
answer
that
answer,
that
got
to
the
heart
of
my
question,
where
part
of
what
I
think
I
was
really
poking
at
which
is
like,
as
as
a
selfish
stax
producer
in
picado.
What
is
the
thing?
That's
like
the
big
complication
for
me
in
this
rfc
and
it
kind
of
sounds
like
for
the
most
part.
B
B
I
was
just
concerned
that
some
of
them
would
also
fall
down
onto
like
a
stack
producer,
but
it
kind
of
sounds
like
once
the
once
the
original
run
image
is
out
with
the
bill
of
materials,
in
whatever
format
is
appropriate,
it's
kind
of
done,
and
then
the
rest
is
picked
up
by
platforms
or
something
like
that.
Okay,.
A
I
think,
like
we
also
discussed
it
during
the
office
hours
yesterday,
which
is
just
me
anthony,
and
we
are
trying
to
figure
out
how
to
fix
this
think.
A
One
anthony
and
javier
said,
they'll
brainstorm
and
update
this
little
paragraph
here
where
it
says
gen
packages,
this
and
flesh
it
out
in
more
details
on
how
it
will
work
with
the
other
rfc
again,
because,
like
this,
this
whole
swarm,
like
landscape,
has
been
changing
very
quickly
and
we
don't
want
to
introduce
another
change
that
we
have
to
replace
in
the
next
api
version.
B
Sorry,
quick,
quick,
quick
aside:
did
you
did
you?
Maybe
maybe
this
is
preemptive?
Did
you
say
that
pack
would
potentially
have
a
tool
where,
like
I
could
give
it
a
standard
like
you
know,
docker
file
that
I
would
use
to
build
a
stack
and
then
it
would
build
the
docker
file
and
crane
in
the
bill
of
materials?
For
me,.
A
B
All
right
cool,
that's
that's
perfectly
fine!
I
I
I
I
I
I
don't
care
if
it
doesn't
make
everything
for
me
and
wrap
it
up
in
a
nice
bow.
That
is
good
to
know,
though,
that
that
is
a
potential
feature.
That's
coming,
because
I
think
that
we,
I
believe
that
sophie
has
been
working
on
just
trying
to
get
it
to
work
in
its
most
prototype
stage
by
injecting
it
all
all
on
our
own,
using
running
crane
commands
and
all
that,
so
I
will.
I
will
let
her
know
that
there
is
a
potential.
I.
A
Mean
that's
what
I
proposed
in
this
rfc
like
if
you
see
here,
like
I
added
some
proposals,
that
we
should
add
it
in
back,
so
that
it's
easy
for
fullback
or
stack
owners
to
do
this.
So,
like
this
specific
comment
here,
I
I
think
we've
unofficially
agreed
to
it,
but
it's
not
in
the
rfc
as
of
now
so.
B
Yeah
we're
all
good
I'll
I'll
I'll
I'll
I'll
point
her
at
this
and
say:
don't
get
your
hopes
up,
but
here's
the
thing.
A
Again,
going
back
to
my
original
point,
like
cosine
already
has
something
like
this
so
like.
If
you
give
it
an
image
and
a
file
on
disk,
it
will
attach
it
in
the
cosine
formats,
which
was
another
reason
why
I
was
saying
that
we
shouldn't
be
reinventing
a
bunch
of
other
things
in
different
formats,
when
the
industry
might
be
going
in
a
different
direction,
because,
like
large
projects
are
already
using
s,
pumps
they're
already
using
cosine.
A
A
So,
there's
also
the
reason
why
the
other
bill,
fax,
like
the
bill
passes
from
rfc,
has
been
so
generic
convenient
about
different
formats
and
also
like,
even
if
we
do
move
to
cosine
in
the
future.
The
buildback
api
wouldn't
change
at
all.
The
platform
will
have
to
change
the
people
back
api
or
the
user
experience
shouldn't
change
at
all.
A
I
think
that's
pretty
much
it
for
all
these
standing
agenda
items
unless
someone
added
something.
B
Yeah
we've
been
I'm
not
going
to
say
nose
to
the
grindstone,
but
it's
definitely
hovering
a
couple
inches
above
on
working
through
some
of
that
s-bomb
stuff,
trying
to
really
get
it
nice,
I
haven't,
had
the
opportunity.
I
know
that
ryan
I
I
talked
to
ryan
about
it
earlier
this
week.
He
mentioned
that
he
has
a
couple
more
pieces
here
and
there
that
he
wants
to
try
and
get
into
alpha
before
we
try
and
do
a
full
swap
in
and
then
I'd
love
to
get
working
on
it.
B
It's
it's
a
little
fiddly
because
you
have
to
like
like
we
have.
We
want
to
continue
to
use
all
of
our
sort
of
built-up
helper
libraries,
so
you
have
to
kind
of
like
branch,
the
library
dump
all
of
the
utility
go
in
and
then
build
like
proof
of
concepts
to
see
how
it
looks
it's
a
little
fiddly
we
just
haven't
gotten
around
to
it
yet,
hopefully
sooner
rather
than
later.
A
B
Thank
you
so
much
for
giving
me
a
rundown
on
the
rfc
was
super
helpful.