►
From YouTube: CNB Sub-Team Sync: BAT
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).
B
A
A
B
Let's
change
them
off
the
agenda
check.
I
don't
see
any
new
faces
status
updates.
I
believe,
since
we
last
met,
we
shipped
a
patch
version
of
lip.
B
I
think
it
had
to
do
with
the
s
form
stuff
erroring
out
for
some
older
apis,
which
we,
which
we
only
move
to
validate
under
api
07..
I
think
that
was
the
only
change
and.
B
Hey,
I
don't
think
there
are
any
buildback
api
changes
being
planned,
actually
there's
the
new
api,
which
introduces
process
specific
directories
or
working
directories
per
process.
So
I
think
once
the
lifecycle
prs
go
in
we'll
probably
add
that
and
so
that
we
can
test
against
it.
But
those
are
still
pending
release
on
the
lifecycle
side,
but
I
don't
think
there's
anything
else
in
the
new
api.
B
A
C
No,
I
think
that
was
really
the
only.
There
was
just
that
one
small
change
in
cnb.
C
B
I
don't
think
there's
anything
else.
Apart
from
this.
A
B
B
But
I
I
don't
know
if
the
rest
of
the
folks
here
are
interested,
in
which
case
we
can
talk
about
it.
But
joe
has
a
summary
here
on
the
changes
that
that
need
to
be
done
in
this
current
rfc
to
make
sure
that
they
have
very
minimal
impact
to
the
existing
group.
There
are
also
some
open
questions
on
how
system
build
packs
would
interact
with
platform
apis
that
don't
support
it
like.
Should
they
just
be
ignored?
Should
there
be
a
warning,
or
should
there
be
an
error?
C
B
It's
not
going
to
be
the
platform,
that's
throwing
the
warning.
I
believe
it
will
be
the
life
cycle,
detecting
an
older
platform
api
and
possibly
detecting
system,
build
packs
and
saying
that
hey.
I
saw
this
default
file
in
some
default
place
in
the
builder.
The
platform
probably
doesn't
know
how
to
deal
with
it,
so
it
should
warn
saying
that
you
might
be
missing
a
few
things.
C
Okay,
I
was
just
curious
from
a
platform
standpoint
as,
as
we
have
the
spring
boot
integration
implements
of
the
platform
stuff.
I
was
just
wondering
offhand.
If
that's
that's
probably
gonna
need
some
work.
Then.
A
B
Seeing
we
also
had
like
a
general
discussion
on
what
happens
when
there
are
new
features
which
are
not
supported
on
older
platform
apis.
This
is
also
something
that
happened
with
the
s
bomb
stuff
where,
like
in
the
older
platform,
apis
the
newest
one
just
entirely
vanishes
silently
and
then
the
new
platform
api,
a
buildback
on
the
newer
api
version,
cannot
output
all
things.
B
So
he
also
spoke
about
what
what
should
be
the
general
like
way
of
dealing
with
buildbacks
that
are
on
a
newer
api
that
require
functionality
that
does
not
get
supported
by
the
platform
they're
running
on.
C
B
I
don't
think
so
far
we
have
like
even
the
end-to-end
poc,
like
so
far,
they've
managed
to
get
kamiko
to
run
the
extensions,
but
you've
not
gone
beyond
the
extension
phase
like
how
it
uses
the
output,
build
and
run
images
to
the
final
export.
So
I
think,
once
those
details
become
a
bit
more
clear,
we
can.
B
We
can
like
have
some
issues
on
the
cnbc.
That's
also
why
the
rfc
is
still
open,
because
we
were
just
waiting
for
the
implementation
poc
team
to
get
back
to
us
on
what
details
need
to
change.
B
I
think
the
initial
version
of
the
dockerfiles
rfc
or
the
implementation
for
that
might
ship
with
the
gen
packages
implementation
like
a
reference
implementation
provided
by
the
project
that
ships
alongside
the
the
lifecycle,
image
that
comes
right
now
and
the
default
implementation
is
probably
going
to
be
sift
based.
A
B
I
believe
we
still
have
to
settle
on
the
the
exact
interface,
but
the
gen
packages.
Interface
would
generally
look
like
a
top
level
input
directory
list
of
directories
or
paths
to
exclude
the
output,
s1
paths
and
I
believe
the
output
spawn
path
will
determine
the
format
that
the
bomb
would
be
generated
in.
So
the
formats
would
be
similar
to
the
ones
supported
by
the
build
fax
api
right
now,
so
sift,
cyclone
dx
and
sbdx
all
in
json
format,.
B
Oh,
the
idea
is
that
the
output
touch
impactors
will
create
will
be
compatible
with
this
rom
images
from
rc.
That
dance
me
as-
and
I
think,
there's
just
one
last
point
that
he
needs
to
address
to
make
it
compatible
with
the
extension
stuff,
but
once
this
is
done,
I
think
we
also
have
enough
ports
on
the
sbom
rfc.
C
C
I
suspect
I
haven't
gone
back
to
look
at
the
code,
but
I
think
we
put
some
checks
in
libcnb
that
prevented
that.
So
I
think
we're
going
to
have
to
go
back
and
relax
those,
so
my
plan
was
probably
next
week
to
submit
a
pr
to
do
that
unless
someone
else
has
time
to
do
it
sooner.
C
The
life
cycle
is
doing
a
warning
if
you
have
bumped
the
api
version
and
are
only
outputting
the
old
format
so
essentially
like
it's
trying
to
catch
the
case.
Where,
like
a
build
pack,
author
would
bump
their
api
version
and
not
know
that
this
changed,
and
so
then
it
would
alert
them
to
say,
like
hey,
you
should
be
outputting,
at
least
both
since
you've
changed
your
api
version.
A
C
B
C
A
B
What
people
think
about
the
current
interfaces?
I
know
we
at
bloomberg
are
hoping
to
use
this
soon,
at
least
the
new
interfaces.
It
provides
because,
like
some
of
the
layered
contributor
interfaces,
which
I
documented
the
shortcomings
of
in
this
one-
they're
sort
of
getting
harder
and
harder
to
get
around
with.
C
So
I
haven't,
I
haven't,
had
a
chance
to
look
at
it
much
lately,
but
if
we
want
to
try
to
define
a
timeline
that
would
probably
help
me
focus
a
little
bit.
So
I
know
you
know
like
what
what
sort
of
time
frame
we're
looking
at
to
cut
like
a
release
of
that
there's.
There's
some
minor
cleanup
things
that
I
still
want
to
do
in
terms
of
things
that
have
been
marked
as
deprecated
in
v1
that
we
should
remove
in
v2.
C
That's
a
little
stuff.
It
shouldn't
be
huge
impacts.
I
think
there
was
still
an
open
issue
or
an
open
pull
request
from
forest
that
was
being
discussed,
and
I
haven't
had
a
chance
to
respond
to
that
and
then
there's
also
some
been
there
with
some
discussion
about
the
logging
interface
and
what
we
exposed
there.
C
I
I
also
asked
emily
to
take
a
look
at
some
of
the
things
that
we
had
talked
about
too.
So
I'm
hoping
she'll
probably
get
some
feedback
this
week,
maybe
on
on
some
of
the
things
that
she'd
like
to
see
too
with
v2.
C
I
think
what
we
had
talked
about
in
the
previous
in
a
previous
meeting
at
least
was
possibly
looking
at
having
like
a
logging
facade
rather
than
or
something
that's
very
easy
for
others
to
overload
and
provide
kind
of
their
own
style
of
logging.
C
It
would,
I
think
it
would
help
with
the
kind
of
integration
of
of
packet,
because
you
know,
then
they
can
kind
of
control
the
output
format
in
a
way
that's
consistent,
so
there
isn't
a
visual
difference
when
they
change,
but
then
also
you
know,
we've
talked
about
things
like
going
forward
about
like
structured,
logging
and
stuff.
You
know
if
we
have
kind
of
a
blogging
facade
that
can
support
some
of
that
stuff,
then
it
might
be
easier
down
the
road
when
we
want
to
go
to
that.
B
C
C
Right
like,
if
there's
a
way
that
we
can,
as
someone
kind
of
extending
you,
know,
libsy
and
be
with
our
own
custom
logger
that
way,
we
don't
have
like
visually
different
outputs.
B
Can
you
can
you
open
an
issue
so
that
we
can
talk
about
what
what
things
are
visually
different
between?
What
lip
can
be
currently
outputs
versus
what
you
expected
to
and
how
that
would
become
in
general
yeah,
there
was
some
discussion
forgetting
who
brought
it
up,
but
we
were,
or
someone
was
looking
into
open.
Telemetry
integration
with
buildbacks
and
the
open
telemetry
has
some
mappings
between
various
popular
structured
log
libraries
to
certain
common
fields,
and
it
also
provides
a
nice
way
to.
B
Sort
of
add
profiling
and
monitoring
to
your
buildback
code.
I
know
that
something
the
heroku
folks
were
interested
in,
like
being
able
to
like
have
a
consistent
way
to
attract
timings,
for
detect,
build
failures
and
then
be
able
to
ship
them
somewhere.
B
So
I
did
a
bit
of
research
into
open
telemetry
and
how
like
what
that
integration
would
look
like,
but
I
I
didn't
go
too
deep
into
it,
but
from
what
I
see,
we
shouldn't
really
be:
inventing
our
own
structured
logging
or
monitoring
formats
like
open
telemetry,
has
a
pretty
generic
and
fairly
well
mapped
out
version
for
both
of
these
things.
So
maybe
it's
worth
just
looking
at
that.
A
What
does,
how
does
that
affect
the
output
of
what's
shown
to
users?
So
do
we
have
to
change?
Would
that
be
a
change
in
life
cycle,
then.
B
Probably
the
so
what
would
happen
is
open.
Telemetry
defines
a
like
some
common
fields
for
structured
log
outputs.
What
we
could
do
on
the
buildback
side
is
define
a
formatter
that
can
use
those
common
fields
to
like
print
out
logs,
so
you
could
potentially
provide
the
formatter
string
or
config
file
alongside
the
builder,
so
that
everything,
that's
all
the
build
packs
included
in
a
builder,
follow
common
formatting.
B
That
way,
if
someone's
running
a
builder-
and
there
are
multiple,
build
facts
from
various
different
places,
if
they're
all
outputting
in
structured
log
format,
you
can
based
on
certain
field
types
to
find
like
what
the
output
should
look
like.
So
if
it's
like
the
defining
level
to
be
born
and
then
in
the
form,
I
think
you've
said
that
all
the
one
log
line
should
appear
in
orange.
B
You
you'll
be
able
to
set
the
config
for
from
various
fields
and
how
it's
presented
in
the
builder
and
as
a
build
pack,
you
can
just
output
all
of
these
things
as
structured
logs
there'd
be
no
there'd,
be
no
formatting
to
it,
like
there'd,
be
no
colors,
pole
strings
whatever.
All
of
that
would
move
to
a
common
formatting
config
and
as
a
build
pack,
you'd
be
outputting
like
structured
logs
and
json,
or
something
now.
B
C
Yeah
I
like
I
like
a
lot
of
that.
I
mean
it
sounds
really
interesting,
I'll
log,
an
issue
and
we
can
kind
of
discuss
more.
It
definitely
seems
worth
like
kind
of
hashing
out
the
direction
that
we
want
to
go
and
making
sure
that
we
can
achieve
that
in
in
v2
rather
than
having
to
do
a
v3.
A
B
It
would
have
to
happen
at
the
project
level.
Not
just
lip
cnb
lipstmb
may
able
may
be
able
to
like
do
some
of
it,
but
like
in
terms
of
common
formatting
and
like
the
builder
level,
can
say.
C
A
B
Testing
library,
so
I
know
we
had
like
this
in
in
the
proposed,
like
the
cnb
design,
we
had
like
the
core
library,
the
utilities
and
the
testing
library,
and
at
least
for
the
testing
library.
I
think
we
should
offer
it
as
part
of
lip
cnb
like
being
able
to
do
like
create
mocks
while
testing
your
build
and
detect
functions
or
being
able
to
do
integration
testing
similar
to
like
awkward.
B
I
don't
know
what
people
think
about
that,
and
also
I
don't
know
what,
like
the
ghetto
folks,
think
about
like
having
an
implementation
similar
to
outcome
or
potentially
even
contributing
or
come
back
to
lip
scenery.
D
The
testing,
like
an
integration
testing
library,
basically
for
build
packs
that,
like
hooks
in
nicely
with
pack
and
lets
you
make
assertions
about
how
images
built
with
build
packs,
behave
pretty
much.
It's
got
like
some
convenient
matchers
things
like
that.
D
D
I
myself
was
in
there
like
making
changes
of
various
sizes
on
multiple
occasions,
so
I
think,
there's
definitely
there's
a
concern
about
like
will
we
be
able
to
move
with
enough
speed
if
the
if
picato,
no
longer
owns
outcome
and
we
need
to
like
deliver
on
you
know,
integration
testing
features
that
are
being
asked
of
us,
but
I
mean
I've
definitely
seen
users.
D
I've
definitely
seen
users
get
benefit
from
it
and
it's
as
far
as
I
know.
It's
mostly
you
can
use
it
with
non-packet.
A
D
B
Yeah
image,
so
I
think,
for
example,
like
one
of
the
things
that
imports
from
packages
like
this
exec
interface,
which
I
think
is
provided
in
lib
cnb
as
well,
but
yeah
like
so
the
only
reason
I'm
saying
is
like
we
will
probably
need
an
integration
testing
library
for
buildbacks
in
the
project.
C
Yeah
we
we
use
that
tool
with
some
the
belt
packs
that
we
manage
like
in
our
sample
apps,
and
it
works
just
fine,
so
I
would
I'd
be
I'd
be
for
it.
That's
not
really
my
tool
to
give,
but.
A
C
Seems
like
it
would
be
a
nice
fit.
I
hope,
maybe
that's
something
we
can
add
to
the
next
paquetto
working
group
and
yeah.
D
C
B
Yeah
I
mean
we,
we
and
I
think
we
recently
was
an
rfc
on
accepting
like
project
level
contributions.
I
don't
know
whether
this
will
come
under
that
if
we
just
import
or
come
as
a
repository
or
whether
like
this
would
just
be
a
series
of
pull
requests
to
webcnb,
but
I
think
in
case
the
pochetto
team
is
amicable
to
doing
something
like
that.
We
can
discuss
on
the
project
side
on
how
we'll
like
do
the
transfer
in
accordance
with
that
rfc.
That
steven
wrote.
A
I
mean:
does
it
make
sense
to
keep
it
as
a
separate
repo
versus
prs
intelligent
b?
If
it's
generically
useful.
B
B
A
D
And
I
think
from
like
a
messaging
perspective,
I
guess
it
could
be
useful
to
keep
it
as
like
a
separate
tool.
D
And
that
it
kind
of
for
people
trying
to
use
the
library
like
you
know,
if
you
just
if
someone's
asking,
how
do
I
integration
test,
the
build
pack
that
I
wrote
and
you
can.
D
Here's
this
repository
that,
like
will
help
you
test
your
build
packs.
There's
like
none
of
the
implication
that
oh,
this
is
only
going
to
be
compatible
with,
like
flip
cnb
or
whatever,
and
it
also
I
don't
know
from
like
a
development
perspective.
D
Keeping
occam
separate
from
packet
has,
I
think,
helped
maintain
occam
as
like,
very
generic.
You
know
this
like
there's,
not
the
temptation
to
like.
Oh
maybe
we
should
test
this
thing.
That's
very
particular
to
packet
like,
for
example,
the
way
that
s-bomb
things
happen.
We
don't
have
facility
to
test
that
in
a
packet-specific
way
in
auckland.
You
know
and
of
course,
it's
possible
to
be
disciplined
about
that
when
it's
like
when
the
testing
is
a
sub-package
of
the
greater
library,
but
that's
kind
of
how
it's
played
out
for,
for
us
at
least.
A
D
Speaking
for
myself,
that
would
be
like
my
main
concern
like,
if
I
think
back
just
literally
in
the
past
one
month
to
the
like
the
way
that
we
kind
of
needed
to
go
about
changing
akam
and
the
speed
I
wish
we
needed
to
do
it.
That
would
have
been.
That
would
have
been
harder.
I
think
if
we
weren't
the
sole
owners,
because
there's
also
the
question
of
just
you
know
like
having
more
stakeholders,
it's
easy
for
us
to
both
logistically
make
a
decision
and
also
not
worry
like
okay,
you
know.
A
D
There,
an
entire
you
know,
multi-vendor,
like
set
of
people
with
lots
of
different,
build
pack
implementations
who
all
need
to
be
okay
with
the
change
that
we're
going
to
be
making
and
how
we
do
this
testing
so
so,
like
sometimes
it's
convenient
to
you
know,
have
have
a
narrower
stakeholder
set.
A
B
B
D
Which
is
also
not
necessarily
a
problem,
but
just
something
to
be
considered
if
this
was
to
be
adopted
more
broadly,
because
then
that's
you
know.
If
that
dependency
remained,
then
forest
would
be
on
the
hook
for
something
a
bit
bigger
like
I,
I
had
to
go
in
and
pr
changes
into
his
repository
in
order
to
like
facilitate
some
things
I
needed
to
do
in
december.
B
B
Example,
but
I
believe
at
least
the
top
level
package
here,
I
think,
is
fairly
generic.
I
think,
and
the
matches
stuff.
B
C
Yeah
just
kind
of
a
share:
we
have
been
getting
some
feedback
about
arm,
64,
support
on
the
paquetto
side,
and
I
went
through
and
created
some
tools
that
just
kind
of
help,
someone
that
if
they
want
that
to
build,
build
packs
in
a
builder
that
are
all
based
on
arm
64.,
we
kind
of
did
that
as
like
a
first
step
to
just
try
things
out
and
let
people
actually
play
around
with
it.
C
I
think
primarily,
it's
like
people
that
are
getting
the
new
max.
You
know
that
are
that
are
wanting
this,
but
there's
some
other.
You
know
there
are
some
server
use
cases
and
stuff
as
well,
but
I
just
wanted
to
share
it
if
anyone's
interested.
I
know
it's
kind
of
another.
One
of
those
like
you
know.
C
We
need
build
packs
that
work
with
it,
but
we
also
need
the
tooling
to
work
with
it
too,
and
so,
hopefully,
just
being
able
to
play
around
with
it
a
little
bit
more
can
help
feed
back
into
our
tooling.
To
improve
that.
C
C
Actually,
it
surprisingly
worked.
Well,
I
thought
it
would
be
a
little
bit
harder
to
to
get
everything
packaged
up,
but
a
couple
things
that
are
make
it
easier
for
the
java
side
is
that
java
doesn't
have
a
lot
of
native
dependencies,
and
so
it's
really
just
getting
an
arm.
64
compatible
jvm.
C
You
know
to
install
so
that
was
fairly
easy
to
get
past
that,
besides,
that
there's
kind
of
the
packaging
issue
like
you
can't
have
two
build
packs
like
with
the
same
name
and
so
like
to
get
around
that
we,
the
scripts
just
tags
like
dash
arm
64
on
the
end
of
everything,
but
obviously
like
down
the
road.
Hopefully
there's
a
more
elegant
solution.
C
You
know
with
like
container
manifest
or
something
so
that
you
know
we
can
use
the
same
names
for
our
builders,
same
yeah,
the
same
names
for
the
build
packs,
and
then
just
have
things
pick
the
right
architecture.
B
Buildback
for
rom
versus
intel,
with
the
same
container
name
so
like
if
you're,
storing
it
on
no
sierra
register.
I'm
not
talking
about
the
buildbacks
registry.
Is
there
something
preventing
you
from
doing
that.
C
I
mean
it
just
gets
confusing
because
you
don't
know
what's
in
that
image
and
you
can
get
into
situations
where
like.
If
someone
had
pulled
the
image
from
docker,
it
would
pull
down
an
x86
image.
But
if
they
built
this
locally,
then
they
would
have
an
amd
image
and
it
can
just
be
a
little
bit
confusing
because
it's
not
clear
what's
in
that
image,
and
so
you
can
end
up
with
like
some
trying
to
run
something.
And
then
it
just
says
like
it's
the
wrong
architecture
and
fails.
C
B
C
Yeah,
I
think
that
the
whole
kind
of
the
point
of
sharing
this
is
to
just
enable
it
to
be
easier
for
people
to
play
with
this
stuff
and
and
to
kind
of
figure
out
the
things
like
you're
saying.
Like
you
know
there
are,
I
feel,
like
a
few
rough
edges.
You
know
that
need
to
be.
You
know
addressed
so
you
know.
Hopefully
this
will
make
it
easier
to
play
with
it
and
see
where
we
can
kind
of
smooth
that
out.
A
Yeah
does
the
what
do
we
need?
I
mean.
Obviously,
we
have
to
figure
those
pieces
out
first,
but
what
do
we
are
there
changes
that
need
to
happen
to
support
stuff
and
registry?
A
There
isn't
really
a
concept
of
architecture
stuff
at
all,
so
I
mean
essentially,
you
can
create
a
new
build
pack
like
entry.
I
guess.
B
So
oci
does
have
a
concept
of
different
architectures
and
platforms,
and
almost
all
container
runtimes
are
able
to
support,
pulling
the
appropriate
platform
and
architecture
version
based
on
what's
requested.
B
It
might,
I
think,
the
last
time
we
discussed
this
was
when
ben
brought
it
up
yeah,
he
refused
whether
the
life
cycle
was
able
to
was
outputting
a
manifest
or
not
sorry,
a
manifest
list,
not
a
manifest
manifest
list,
and
similarly
the
pack
was
capable
of
creating
one,
because
manifest
lists
are
optional
entirely,
so
might
just
be
that
it
it's
not
aware
of
them
and
it
doesn't
create
them.
A
But
even
with
all
that
stuff,
like
I
imagine,
we
probably
want
to
expose
some
of
that
stuff
in
the
registry
on.
A
B
B
B
C
A
C
We,
as
far
as
I
know,
have
like
one
build
pack
that
we're
also
bundling
for
windows,
and
we
are
doing
something
similar
where
it's
just
tagging
dash
windows
on
the
end
of
everything.