►
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).
A
A
B
I
think
I'm
not
sure
if
he'll
be
able
to
make
it,
but
let's
try.
Oh
so,
let's
go
through
the
agenda.
B
C
Sure
yeah
profile
build
pack.
We
basically
have
a
template
merged
in
so
the
kind
of
the
base
where
the
build
pack
is
there
all
the
just
the
core
boilerplate
stuff.
I'm
really
looking
forward
to
the
the
template
work
in
pack
by
the
way
after
having
done
that,
it
was
more
of
a
pain
than
I'd
hoped,
but
we
got.
We
got
ci
wired
up
and
things
like
that
too.
So
we
should
really
be
ready
to
go.
C
I
think
just
kind
of
implement
the
business
logic
at
this
point
and
then
on
the
lib
cnb
side.
We
caught
a
kind
of
edge
case
bug
this
week
and
also
are
just
there's
a
couple
open
issues.
I
was
hoping
to
talk
about
a
little
bit
more
later,
but
just
as
we
drive
forward
to
like
rc
and
ga
release
for
v2.
B
Cool,
thank
you.
I'm
gonna
link
those
pr's
and
maybe
what
we
can
do
is
tag
the.
I
think
the
the
blocking
the
rs
are
tagged
to
the
v2
milestone,
so
I'm
just
going
to
link
them
here.
A
A
A
Nothing
that
comes
to
my
mind
recently,
but
it
seems
like
the
our
discussion
yesterday
had
large
ramifications
for
billback
authors.
If
we
go
one
way
or
another.
B
I
think
this
is
the
rfc
that
terence
is
talking
about
which
proposes
that
if
people
rebuild
an
app
image
with
a
new
builder
that
has
a
different
stack,
id
lifecycle
should
bust
all
the
caches
and
like
ignore
any
previous
caches
stored
by
the
buildbacks.
B
Instead
of
just
completely
busting
the
cache
for
every
buildback.
I
don't
think
that's.
The
rfc
has
been
updated
yet
with
that.
B
I
think
some
interesting
commentary
in
the
working
group
was
around
how
different
buildback
vendors
handle
it.
So
I
think
both
bloomberg
and
pogetto
currently
store
stack
id
or
some
version
information
in
the
metadata.
So
they
know
when
to
bust
the
cache,
but
I
think
new
buildback
authors
may
not
be
aware
of
something
like
that,
so
they
might
not
be
like
they
might
not
have
accounted
for
something
like
this.
So
it's
just
to
enable
a
safe
option.
A
A
No,
I
think
that
summarizes
most
of
it
ace
of
people
from
this
group
as
representation
representatives
of
people
doing
bill
pack
bill
pack,
things
authoring
things.
If
you
have
opinions,
please
comment
on
the
rfc.
B
I'm
gonna
take
that
I
don't
know
next
up
is
profile.
Buildback
I
see
gabe
is
also
here.
So
I
think,
did
you
put
this
agenda
item
daniel
or
I
don't
know
who
put
this.
I.
C
Did
I
added
that-
and
it
was
just
kind
of
a
follow-up
just
to
make
sure
that
we're
all
on
the
same
page
about
you
know,
what's
happening
next
there
and
who's
who's
working
on
the
to
push
that
forward.
B
We
just
need,
should
we
start
with
some
issues
at
least
or
so
that
we
know,
and
we
can
discuss
a
few
things
before
we
start
implementing
people
request.
I
know
we
had
an
informal
discussion
between
me
dan
gabe
and
mikey,
but
maybe
it's
worth
putting
that
in
form
of
issues
so
that
people
can
start
picking
it
up,
but
I
believe
gabe
you
were
asking
about
the
scaffolding.
It's
ready
so.
A
C
Yeah,
I
can
I'll
have
to
think
about
what
chunks
of
work
there
are
that
could
be.
You
know
how
things
could
be
broken
down.
Yeah
I
can.
I
can
try
to
add
some
issues
in
there.
A
A
B
C
B
C
One
other
thing
on
that
as
far
as
testing:
what
are
what
is
everyone's
thoughts
on
on
testing?
For
that,
obviously,
we'll
write
up
a
you
know
suite
of
unit
tests
to
make
sure
that
you
know
we're
trying
to
cover
the
the
code
the
best
we
can,
but
you
know
as
far
as
integration
testing
do
we
want
to
try
to
add
some
stuff
for
that.
C
You
know
it's.
It's
not
a
standalone
build
pack,
so
to
speak,
so
there
would
have
to
be
other
build
packs.
Part
of
that
integration
test
as
well,
which
is
you
know,
is
a
minor
risk.
I
guess,
or
you
have
to
mock
up
like
test,
build
packs
or
something
to
kind
of
flush
out.
You
know
a
full
build
cycle.
C
I
think
just
to
make
the
the
detection
happen
or,
although.
B
B
So
maybe
that's
the
set
of
issues
like
detect,
plus
testing,
build,
plus
testing
and
a
separate
ticket
for
integration
tests.
A
C
Do
we
want
to
depend
on
sorry
my
mind
is
blanking?
That's
the
library
name
welcome
yeah
yeah.
Do
we
want
to
use
ockham
for
the
testing.
A
A
C
Okay,
I'll
mention
that
in
the
note
issue
for
that
one.
C
It
is
wired
up
in
there
yeah,
you
might
need
to
bump
that
or
kind
of
keep
up.
We
might
need
to
be
kind
of
proactive
about
bumping
that
and
keeping
it
up
to
date,
just
because
it
is
kind
of
a
moving
target
until
we
until
we
do
cut
a
release
but
but
yeah,
that's
the
plan.
C
A
A
B
Okay,
lips
cnbv2
progress.
I
think
that's
yours
down
here.
C
Yeah
so
there's
three,
these
three
issues
that
are,
I
think,
more
or
less
ready
to
go.
I
think
we're
just
kind
of
trying
to
agree
on
the
last
little
bits
of
details,
the
extract
method
for
generating
config.
I
redid
some
of
those
things.
C
Could
take
another
look
at
that?
I
changed
it,
so
it
doesn't
break
the
function
signatures.
So
I
think
it
should
be
a
little
bit
less
contentious
now
and
hopefully
that
will
be
ready
to
go.
Formatters
out
of
the
main
package
is
probably
going
to
need
to
be
rebased
at
least,
and
maybe
touched
up
a
little
after
that,
if
that
config
change
goes
through
because
there's
some
conflicting
stuff
there,
I'm
sure,
but
the
general
ideas
of
it
are
just
kind
of
restructuring
things
to
make
it
a
make.
C
C
Oh,
I
don't
see
forest
on
it.
Anymore
looks
like
he
dropped
off.
A
C
B
B
B
Because
the
the
only
thing
was,
like,
let's
say,
you're,
just
executing
like
a
cli
which
accepts
the
output
flag,
it
makes
very
little
sense
to
me
to
like
stream,
that
to
to
like
a
buffer
and
then
write
it
using
go.
B
B
I
think
there
are
a
few
other
issues
here
which
are
tag
2.0
so
like
there
are
some
things
that
are
like.
I,
I
think
our
structs
are
too
open
at
times,
because
I
saw
like
a
few
prs
trying
to
override
the
exact
d
paths
in
places
which,
ideally
they
never
should
lip
cnb
should
construct
those
like
it
constructs
those
parts
and
puts
them
in
the
strut
and
those
should
all
be
like,
ideally,
private
fields
in
this
truck
that
are
accessible
through
some
function.
That
gives
a
read-only
copy
of
it.
A
B
Because
that
that
might
mean
that
users
end
up
overwriting
that
field
and
setting
it
to
incorrect
values
and
then
in
the
future,
if
we
change
the
api,
then
the
paths
changes
and
they're
still
using
the
old
parts.
They
might
see
some
issues
so
like
that
was
probably
the
only
thing
this
one,
I
think,
is.
B
B
So
I
think
this
is
something
we
should
also
do
for
2.0,
and
I
think
this
was
probably
the
last
one
and
I
think
the
ad
we
added
reset
right.
A
C
Yeah
yeah
I'd
be
helpful
if
we,
if
you
could
add
some
more
detail
on
that,
I'm
and
the
first
issue,
as
well
with
the
the
destruct
visibility.
I
I
agree
with
both.
I
could
probably
find
some
time
to
do
stuff,
but
it's
it's
harder
to
have
to
dig
through
the
code
base
and
hunt
for
the
stuff.
So
if
you
have
examples
of
of
it,
I
think.
B
C
I
think,
instead
of
testing
the
layer,
contributor
you'd
be
testing
your
build
and
detect
funk.
You
know
that
you,
your
implementation
of
that
it's
little,
it's
probably
not
too
far
off.
I
have
not
tried
converting
one
of
our
build
packs,
yet
so
yeah,
that's
that's
something
I'd
like
to
do
before
you
know
we
cut
a
little
c
and
b
two
as
well
yeah.
C
C
That'd
be
another
one:
forest
could
maybe
chime
in
on
a
little
bit,
because
I
know
in
packet
they're
using
that
function
based
approach,
so
he
might
be
able
to
like
give
a
an
example
of
you
know
how
they
test
that.
You
know
what
the
common
test
workflow
looks
like
yep,.
B
I
think
that's
pretty
much
it.
I
think.
Once
these
are
done
and
the
pull
requests
are
merged,
I
think
we
should
be
good
to
go.
We
can
cut
a
rc.
C
I
had
a
question
on
one
of
those
issues:
that's
open.
She
clicked
back
the
130
standardized.
The
logging
interface
is
that
still
something
that
you're
looking
in,
we
did
make
some
changes
around
logging.
Is
that
something
that
you
still
want
to
explore?.
B
What
I
would
have
liked
is
if
this
was
not
on
by
default,
but
like
if
we
had
an
adapter
to
a
logger
interface,
where
we
could
plug
something
that
follows
this
interface:
okay,
cnb.
That
would
have
been
nice
because,
like
if
we
could,
when
we
are
logging
things
if
we
could
add
context
variables
on
like
what
it's
logging
and
so
on.
B
C
B
And
I
think
this
one
aiden
should
I
assign
this
to
you.
A
I
should
be
able
to
reuse
a
bunch
of
stuff
just
for
so
others
have
a
better
context.
A
We've
written
some
internal
documents
to
explain
how
we
use
libcnb
internally,
and
I
should
be
able
to
get
approval
to
adapt
some
of
those.
C
A
Cool
yeah
I'll
see
how
much
of
this
I
can
pull
externally
yeah.