►
From YouTube: BAT Sync: 2021-09-24
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
B
Awesome
so
sign
into
the
doc.
If
you
haven't
already.
B
C
Yeah,
it
is
being
recorded,
there's
some
weird
issue
with
live
streaming
on
youtube
where
it
says
I
don't
have
permissions,
I'm
going
to
sort
it
out
later,
but
it's
recording
onto
zoom
and
I'll
just
upload
it
to
youtube.
Okay,.
B
Cool
thanks
any
new
faces,
I
think
not
right.
B
B
Do
you
have
permission
to
cut
releases,
sam
yep
or
daniel?
This
is
not
here.
C
B
Sounds
good
cool.
B
C
I
think
the
major
one
was
the
s
bomb,
restore
logic
yeah,
which
was
the
I
think,
the
last
item
blocking
the
fcp.
C
To
read
and
make
available
to
the
user,
so
the
back
interface
shouldn't
change,
but
if
you're
interacting
with
the
s1
label
directly
by
the
thing
metadata
label,
I
don't
remember
the
full
name
of
the
label,
but
if
you're
using
that
directly,
then
that
would
probably
be
a
breaking
change.
With
this
new
platform.
Api.
C
C
Apart
from
that,
everything
else
should
remain
the
same.
This
also
includes
this.
There
was
another
rfc
I
put
in
which
we
haven't
just
implemented,
which
was
around
like
associating
the
bill
of
materials
life
cycle
with
the
life
cycle
of
the
layer
itself.
So
with
these
changes,
it
should
do
that.
So
you
don't
need
to
regenerate
people
of
materials
for
the
layer
by
storing
it
elsewhere
and
then
doing
some
sort
of
hackery
to
regenerate
it.
C
I
think
the
only
pending
comment
on
this
rfc
was
the
s
form
list
in
the
build
packs
normal.
In
the
last
working
group
meeting,
we
talked
about
changing
that
from
like
a
human,
readable
string
to
a
list
of
ini,
iana
media
types.
C
I
know
cosign
still
uses
text,
slash
spd-x
as
the
media
type
for
json,
xml
or
whatever
else
spd8
form
format.
So
I
don't
know
what
we
want
to
do
with
that,
because
the
other,
the
other
bom
formats,
have
a
suffix
like
a
plus
json
or
plus
x.
Another.
You
know
the
file
format
and
then
some,
the
the
other
part,
is
just
their
media
type,
indicating
whether
it's
ipx
or
split
or
spdx.
C
The
file
formats,
but
I
think
nishan,
I
don't
know
the
other
person
from
vmware-
said
that
they
would
take
a
look
at.
C
C
B
C
B
Yeah,
I
imagine
we
can
in
the
rfc
just
say,
we'll
use
the
media
types.
I
guess
depend
like
kind
of
contingent
on
this
stuff
going
through
okay
and
then
we
can.
B
C
C
A
Usually
we
try
to
keep
platform
apis
and
build
pack
apis
able
to
move
separately
from
each
other
without
affecting
people,
but
once
we
move
to
this
platform
api,
I
think
older
build
packs
that
are
generating
old
style
bombs
like
we're
just
gonna
drop
that
on
the
floor
and
not
do
anything
with
it.
So
once
you're
in
the
new
platform,
you're
going
to
need
new
little
packs
to
get
a
real
bomb
out
of
it.
Is
that
also
what
other
people
are
imagining,
or
are
we
missing
some
sort
of
compatibility
situation
here.
C
D
A
C
A
A
A
B
It
does
mean,
if
that,
if
you
are
building
images
from
pack
in
that
situation,
you
talked
about
emily.
That,
like
people
cannot
just
continue
using
existing
tooling
if
they
had
it
right
to
process
the
labels.
If
they
were
doing
that.
C
A
A
C
A
B
A
Yeah,
oh,
nothing
should
change
for
legacy.
So
if
there's
anything
that
says
like
we're,
giving
files
to
legacy
build
packs
that
are
new
or
reading
files
from
legacy
build
packs
that
are
new,
we
shouldn't
do
that,
because
legacy
buildback
should
do
exactly
what
they're
doing
now
same
input
same
outputs.
It
would
just
be
about
whether
the
platform
does
something
different
with
them.
Afterwards,.
A
C
A
The
other
thing
we
can
do
is
just
take
what's
in
the
label
now
and
put
it
in
a
file,
whether
it's
we're
telling
people
to
read
metadata,
tumble
or
putting
it
in
a
different
file.
So
the
build
packs
behave
exactly
the
same,
but
you
know
platforms
get
the
thing
from
a
file,
so
they
don't
have
to
do
a.
Is
there
a
label?
Is
there
a
file,
dance.
B
Those
are
new,
I
mean
you
could
also
do
the
label
and
then
we
just
dropped
the
legacy
format
eventually
right.
That's
also
an
option.
B
I
think
you,
you
said,
just
drop
the
label,
but
I
meant
I
just
drop
dropped.
The
entire
legacy
format.
A
B
A
C
A
I
think
we
should
follow
like
if
there
is
a
convention
and
natalie
probably
answered
this
question
the
best
in
the
life
cycle
right
now,
because
we've
made
breaking
changes
of
this
variety
before
we're
like
a
build
pack
he's
able
to
set
a
field,
and
now
I
can't
anymore
or
the
name
change
if
whatever
we
do
right
now,
let's
just
stick
with
that
policy
in
terms
of
whether
we
worn
or
fail,
we
never
just
ignore
it,
though
I
think
it's
either
worn
or
fail.
I
don't
remember
which
it
is.
A
B
B
Kind
of
dependency
on,
I
guess
the
buildback
api
version
to
some
platform
api.
At
some
point
I
just
like
when
we
eventually
stop
doing
anything
with
the
old
format
in
the
platform.
A
A
B
Right,
but
I
assume,
if
you
don't,
it
does
mean
we
just
drop
every
drop
all
that
stuff
on
the
floor,
even
though
the
bill
pack,
if
you
haven't,
if
you're,
using
like
the
current,
build
pack
0.6.
I
think
this
is
what
we're
on
right.
A
B
Because
that
I
guess
the
errors
check
that
we're
talking
about
is
a
life
cycle
change
from
the
bill
pack.
Api
version
right.
A
B
Yeah,
probably
step
one
is
to
update
the
talks.
Yes,
I
feel
like
they
aren't
anymore,
because
I've
had
people
on
my
team
kind
of
go
through
it,
but
yeah.
I
feel
like
we
had
a
lot
of
point
shoot
bill
packs
in
the
last
year
being
made
from
people
that
were
just
trying
bill
packs
out.
Yeah
that
seems
old.
B
Awesome,
the
other
one
I
feel
like
there's
been
a
good
amount
of
changes
on.
That's
maybe
worth
bringing
up
our.
I
haven't
gone
through
all
the
stuff
in
detail
that
joe
talked
about
yesterday,
but
I
assume
emily
is
since
you're
the
one
who
had
that
discussion
with
him.
B
I
think
if
people
want
to
maintain
I'm
fine
with
it,
I
only
think
I
I
personally
think
it
only
half
hits
with
our
charter
of
maintaining
like.
I
think
it
fits
with
our
chart
because
it's
maintaining
bill
packs,
but
I
don't
think
the
actual
bill
packs
themselves
necessarily
fit
with
our
charter
would
be
my
only
pushback,
but
it's
like
whatever
like
I.
If
we're
excited
to
do
it,
I'm
not
you
know,
I
don't
feel
that
strongly
that
about
it.
A
B
Yeah,
I
guess
like
thing
when
you
talk
about
like
a
profile
adult
patch
just
like
do
do.
I
have
a
lot
of
like
I
guess.
That's
like
a
bill
pack
ish
concern,
but
I
don't
know
if
we
talked
about
like
all
those
kind
of
things
on
here,
but
if
we
do
want
to
get
this
changed,
we
should
probably
get
it
changed
in
the
rfc
itself.
So
there's
that,
but
I
think
the
that
is
not
a
new
thing
since
last
time
this
was
talked
about.
D
A
B
A
Yes,
I
think,
there's
an
idea
that
we
should
rfc
new
utility
bill
packs.
I
think
that
gets
into
defining
like
in
this
particular
case
whether
this
falls
into
like.
If
you
read
our
rfc,
we
always
talk
about
sort
of
like
material
changes
needing
an
rfc
yeah,
and
this
is
just
basically
explicitly
calling
out
that
adding
a
new
one
of
these
is
a
material
change.
So
we
need
an
rfc.
B
A
Would
be
sort
of
like
an
optional
thing,
for
platforms
to
be
like
at
least
for
now,
like
we
can
get
into
it
more
with
system
build
packs
if
we
want
to
later,
but
it'd
be
like
the
platform
would
like
to
provide
this
default
feature
set.
Like
add
all
of
the
build
packs,
I
o
build
packs
to
every
order,
something
something
something.
D
A
Mean
I
feel
like
the
only
reason,
I'm
having
trouble
answering
this
because
I
feel
like
somewhere.
We
should
put
the
list
in
the
docs
in
our
docs
right
and
like
if
someone
wanted
to
add
a
list
somewhere
else.
Like
that's
fine,
but
I
don't
think
there's
like
a
requirement
that
there's
an
official
list
that
we're
maintaining
somewhere.
B
You
can
have
build
pack
utility,
build
packs
that
do
things
that
like,
if
it
is
doing
stuff
that
exists
in
the
spec,
there
definitely
can
be
overlap
between
functionality.
Look
how
you
do
that.
D
B
Change
in
the
spec,
yes
yeah,
like
we're
moving
that
thing
down
the
spec,
but
like
the
bill
pack
already
could
already
exist
for
that
before.
That,
for
instance,
is
I
guess,
upgraded
to
by
platform.
A
So
what
I
would
like
to
see
is
like
in
the
migration
docs
for
that
platform
api,
it's
a
platform,
api
change
to
stop
running
the
user,
stop
profile
right,
so
I
think,
like
in
the
migration
guide
and
the
docs
be
like
we're:
removing
support
for
user
provided
dot
profile,
but
if,
as
a
platform,
you
would
like
to
maintain
this
feature.
Add
this
book
pack
to
every
group.
D
B
B
Yeah,
I
know
joe
mentioned
at
some
point
like
trying
to
auto
add
stuff
to
the
builder,
but
that
was
like
in
the
other
rfc
or
something
right,
yeah.
A
B
Yeah,
I
guess
in
kind
of
I
think,
that's
where
the
case
is
the
most
interesting.
Just
like
it's
the
auto
adding
of
stuff
like
I
guess
for
me
like
that
list,
is
that
it's
just
a
doc
thing
so
like
do
we
auto
add
the
thing,
but
if
you
didn't
upgrade
your
platform
kind
of
api
to
have
that
feature
removed
like
what
is
that
I.
B
B
B
A
C
No
it
it
was
like.
We
have
a
ball
right
now,
so,
like
there's
the
that's
why
you
can't.
B
A
D
Yeah,
the
doc
is
sort
of
like
a
messy
regurgitation
of
emily's
writable
asset
cash,
rfc
draft
rfc.
A
Yeah,
that
has
more
information.
I
think
at
this
point
it's
in
the
middle
of
the
page,
171.
A
B
Yeah,
I
didn't
know
third
graders
made
flow
charts.
I
just
definitely
was
not
doing
that
in
third
grade.
B
A
A
D
Yeah
be
curious
to
understand
more
the
problems
that
other
folks
are
trying
to
solve
like
I
know
our
problem
domain
and
the
reason
that
we
want
this
pretty
well,
like
you
know,
it's
the
whole,
you
know
I
build
with
one
image
name
and
then
I
change
the
image
name
and
I
have
to
redownload
everything
again.
It's
a
big
problem
for
a
lot
of
our
users,
but
I
don't
know
necessarily
what
what
other
folks
are
hitting
what
how
this
would
solve
their
issues.
D
Yeah,
there's
kind
of
a
notion
most
of
our
users
expect
that
let's
say
the
jdk
is
downloaded.
They
expect
it
to
only
be
downloaded
once
and
not
once
per
application
image.
D
So
I
don't
know
I
could
start
a
document
to
just
try
to
capture
some
of
the
use
cases
that
that
people
require
in
terms
of
caching.
A
A
Other
build
packs,
making
changes
to
one
of
these
layers
for
a
good
reason
that
these
layers
can
sort
of
like
end
up
in
the
image
or
like
affect
the
rest
of
the
build
process.
Because
they're
part
of
you
know
it's
it's
one
of
our
layers.
We
do
special
things
with
them
and,
like
add
things
to
the
path
and
run
them,
and
they
have
these
far-reaching
effects.
A
But
I
think
if
you
just
had
a
cache
volume
that
was
not
part
of
our
layers,
you
know
restoration,
export
life
cycle
that
whole
thing
like,
even
if
you're
just
using
it
for
the
same
image.
The
set
of
problems
that
can
happen
with
it
are
a
lot
lower.
If
then,
to
actually
use
it
in
a
bill,
the
build
pack
had
to
go
like
you
know,
opt
into
doing
something
with
it
like
copy
something
out
of
it
or
link
to
it.
A
Yes,
part
of
the
reason
I'm
doing
that
is
because
this
rfc,
which
solves
just
one
of
those
problems
which
I
thought
was
great,
and
we
should
just
do
it-
the
big
pushback
against
it-
is
that
we
have
other
types
of
capturing
and
it's
confusing,
and
we
have
other
upcoming
caching
problems.
B
Yeah
I
get
that
sentiment.
I
guess
just
from
those
two
individual
use
cases.
They
feel
like
very
different
problems
to
me
even.
C
A
Yeah,
I
think,
there's
a
variety
of
types
of
caching
problems,
but
I
think
there's
really
only
two
types
of
caches
they're
like
cross,
build
cache
so
like
this
is
a
cache
that
a
platform
could
choose
to
share
across
builds
of
different
images.
A
Yeah
and
like
you
know,
if
we
rename,
you
know
if
we
come
up
with
the
right
schema
for
passing,
things
in
definitely
want
to
make
it
such
that
platforms,
don't
need
to
provide
an
arbitrary
number
of
volumes
based
on
metadata,
like
let's
set
this
up,
so
the
platform
can
just
do
the
same
thing.
Every
time.
C
I,
the
the
apart
from
these
two,
the
other
main
issue
we've
been
facing
lately,
is
like
just
how
inline
buildbacks
work
and
they
break
the
entirety
of
the
buildback
api
or
like
any
equivalent
of
an
inline
build
pack
just
breaks
everything
where
if
an
inline
build
pack
uses
one
of
the
tools
exposed
through
a
build
layer,
it
can
mod,
and
if
that
build,
there
is
also
a
launch
there.
A
It's
similar
to
like
in
some
ways
it's
not
any
different
than
like.
I
can
inject
my
random,
build
back
into
the
order
and
then
break
everything
right,
but
maybe
it
is
different
because
the
way
platforms,
you
know
more
restrictive
platforms
might
be
good
at
saying
these
are
the
allowed
build
packs
in
the
order,
but
then,
if
they
go
and
support,
inline
build
packs,
they've
broken
their
guarantees
there,
but
maybe
I
think
the
answer
there
is
just.
A
B
I
know
we
had
one
other
thing
on
the
agenda.
I
guess
as
an
action
thing
dale
did
you
want
to
do
start
that
dock?
I
guess
of
just
the
different
use
cases
for
the
caches
for
the
caches
as
a
starting
point.
C
C
B
C
C
That's
pretty
much
it.
We
have
a
couple
of
minutes.
I
wanted
to
talk
about.
Oh
wait.
We
have
that
on
the
agenda
anyway,
I
think
did
that
dan
did
you
put
the
contributors
thing
on
the
agenda.
C
That
was
me
okay,
so
this
thing
was
put
in
by
ryan
and
from
the
ghetto
around
layer
contributors
as
a
concept
from
lip
cnb
there's
an
attached
issue,
which
explains
why
they
have
hindered
development
of
certain
kinds
of
build
packs
through
whip
cnb.
But
this
is
a
breaking
change.
I
think
I
also
wanted
to
use
this
as
an
opportunity
to
kick
off
the
lip
cnb
api
redesign.
C
D
C
D
Yeah
so
that
I
think
the
primary
motivation
for
us
on
the
picato
side
on
this
is
that
there's
two
libraries
being
used
right
now:
there's
the
lib
cnb,
the
pack
and
then
there's
packet,
which
is
a
totally
different
rewrite,
and
what
we
were
trying
to
do
is
close
the
gap
so
that
lease
packet
could
be
based
on
the
cnb
and
kind
of
inherit.
All
of
the
goodness
that
comes
from
cnb,
and
so
this
was
kind
of
the
first.
I
guess
roadblock
to
that
happening,
that
they
can't
they
can't
get
the
apis
to
work.
D
The
way
that
they
want,
with
with
the
layer,
contributor
concept
and
so
having
a
a
lower
level
like
just
layer
concept
like
described
here,
would
allow
them
to
do
that.
It's
obviously
a
change,
a
breaking
change,
but
you
know,
I
think
that
the
intent
really
is
just
to
kind
of
spur
like
you
know.
What
does
v2
look
like
you
know
this
build
pack.
C
I
looked
at
like
the
list
of
core
requirements
we
had
for
lip
cnb
and
apart
from
this
and
the
exactly
the
face,
I
couldn't
find
anything
else
that
was
missing
in
lipscomb,
apart
from
like
minor
api
changes.
That
ryan
mentioned
about
the
main,
accepting
an
interface
instead
of
a
function,
and
apart
from
that,
it
looks
very
similar
to
packet.
Now.
D
Yeah
yeah,
I
think
we're
close
you
know
then
there's
obviously
other
things
that
could
potentially
fit
into
a
v2.
You
know
that
we
discussed
in
in
previous
meetings
and
in
that
dock
that
that
you
had
pulled
together,
I
mean,
is
it?
Is
it
just
kind
of
like
is
this?
Is
this
the
time
to
kind
of
just
have
everyone
on
the
same
page
that
it's
like
a
good
time
to
start
working
at
the
on
v2?
D
You
know,
I
I
mean
we've
got
the
branch
now
we
could,
you
know,
submit.
You
know,
pull
requests
specifically
to
that
and
and
kind
of
start
development
on
a
v2.
B
I
I
mean
I
feel
like
this
is
a
big
enough
change
in
of
itself
that
the
two
changes
sam
was
talking
about
is
without
kind
of
adding.
Even
more
things
into
v2
would
probably
make
sense
too.
C
D
D
I
think
I
think
part
of
the
hope
for
this
as
well,
is
by
sort
of
allowing
packet
to
pull
in
from
libsynb.
We
would
then
have
a
bunch
of
unifi,
and
then
we
could
have
a
better
under
build
utility
on
top
of
that
base.
If
we
wanted
to
add
that
as
well,
so
we
were
hoping
to
be
able
to
get
this
in
and
be
able
to
make
that
switch
so
that
we
had
a
better
understanding
push
forward
on
better
utility
for
the
whole
space
as
opposed
to
better
just
what
we're
doing.
D
What
do
people
think
about
like
like
the
support
cycle
for
for
version?
One
you
know
if
we're
starting
on
version
two
yeah?
Obviously
we
would
keep
working
on
version
one.
I
guess
backboarding
things
that
from
version
two
to
one
that
that
makes
sense
that
are
just
additive
but
like
at
what
point
do
we
call
it
on
version
one
and
and
start
moving
people
to
version
two.
C
D
I
mean
we
could
table
until
next
next
meeting.
You
know
it's
probably
easier
to
discuss
in
person
and
it's
not
urgent.