►
From YouTube: CNB Sub-Team Sync: BAT 22/10/2021
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
Okay,
so
the
first
item,
which
is
start
the
youtube
live
stream,
is
done.
I
don't
see
any
new
faces,
so
let's
jump
right
into
status,
updates,
there's
a
new
release
of
lip
cnp.
That's
pending
release
on
this
last
bump
pipeline
pull
request.
A
The
new
release
adds
the
ability
to
create
exact
de-helpers
in
libcnb,
which
was
a
missing
feature
for
a
long
time,
and
I
think
lip
back
implements
it.
I'm
not
sure
if
packet
also
has
support
for
exactly.
A
But
that's
something
we
added
and
we
will
cut
that
as
part
of
the
release
version.
1.24.
B
A
There's
this
redesigned
document,
which
has
a
bunch
of
things,
broken
down
into
what
like
the
various
additional
packages
we
want
and
what
to
go.
Where
is
this
issue
which
acts
the
core
functionality
not
including
the
utility
which
I
believe
checked
off
the
list,
except
for
that
four
requests
that
fine
has
around
removing
layer
contributors
and
replacing
them
with
just
normal
layers?
A
So
I
think
the
main
changes
to
the
core
api
would
be
just
that,
like
from
a
removal
of
player
contributors,
I
think
everything
else
is
covered
in
terms
of
the
v2
core
respect
and
then
we'll
be
starting
off
with
the
other
additional
packages
that
we
have
testing
utilities,
and
I
still
don't
have
a
plan
around
like
the
ci,
cli
library
and
cicd
parts,
and
I
think
we
need
more
discussion
with
the
rest
of
the
team
on
how
to
deal
with
some
of
those
things.
A
A
B
B
I
know
that
that's
something
that
we
want
to
investigate
and
pack
it
and
it's
one
of
the
things
we're
hoping
one
of
the
one
of
the
reasons
we're
hoping
to
be
able
to
merge
that
v2
branch
in,
like
the
layer
contributor,
dropping
sooner
on
to
the
v2
branch.
That
way,
we
can
start
experimenting
and
doing
some
conversion
with
like
this,
the
libraries
that
we
have
and
seeing
what
kind
of
overlap
we
have
and
what
kind
of
utilities
we'd
be
looking
for
as
well.
A
B
A
A
So
yes,
that
would
be
a
breaking
change
in
terms
of
ryan's
like
comments
on
how
it
would
be
possible
for
users
to
move
on
to
the
new
layer
structures
to
their
contributor
one.
The
the
only.
A
The
only
real
issue
I've
seen
is
around
some
tests
like
there
are
like
some
tests
that
can
assume
some
build
outputs
and
testing
the
contributors
separately,
but
I
think
it's
still
doable.
It
would
be
nice
to
have
like
some
experiments
and
documentation
on
how
to
move
or
migrate
easily.
A
C
C
One
of
the
things
that
I
think
we
had
talked
about
in
in
the
pacquiao
meeting,
some
of
the
stuff
in
lib
cnb
has
some.
I
guess
like
plays
on
words
for
things
like
like.
The
logging
package
is
called
poet.
C
It's
kind
of
boring
just
calling
it
logging
or
something
like
that,
but
I
was
curious.
What
people
thought
about
that
sometimes
I
feel
like
these,
like
plays
on
words,
can
be
hard
for
people
getting
started
with
something
to
to
know
what
that
means,
and
then
obviously,
if
you're,
not
a
native
english
speaker,
I
imagine
that
could
be
even
harder
yet.
So
I'm
curious
what
people
think
on
that.
B
A
A
I
think
we
can
make
that
we
should
probably
make
that
decision
on
some
issue
or
discussion
on
github
rather
than
in
this
meeting.
C
A
A
C
C
If
that's
something
that
maybe
we
can
explore
some
alternative
naming
conventions
so
that
when
you're
using
the
api,
it's
a
little
more
ergonomic.
I
think
that
might
be
an
improvement.
C
I
think
it's
just
the
way
that
the
structs
and
the
packages
are
named
I'll
have
to
try
to
find
some
examples
and
and
write
that
up
in
an
issue.
So
we
can
kind
of
document
how
it
can
get
a
little
weird.
A
C
I
was
going
to
ask
about
in
the
working
group
meeting
yesterday.
C
They
were
talking
about
the
utility,
build
packs,
rfc
and
assigning
that
to
the
bat
team
it
seemed
like
it
seemed
like
they
were
gonna
make
that
change.
Did
I
hear
that
correctly.
C
A
C
Yeah
I
I
like
that
change.
I
I'm
curious
like
what
I'm
not
sure
how
far
out
that
rfc
is
from
being
accepted,
though-
and
you
know
if
it's
if
it
should
be
something
we
should
start
planning
for
now
or
if
we've
got
time
so.
A
Yeah,
I
think
one
of
the
things
that
that
rfc
is
still
figuring
out
is
how
to
deal
with
this
whole
stats
removal,
those
that
are
the
point
around
making
build
packs
generic
enough
to
be
run
on
any
possible
stack,
but
with
the
removal
of
x.
I
think
we
also
want
to
reevaluate
that
that
clause
in
the
rfc,
I
think
joe,
is
gonna
update
that
okay.
A
C
A
It
obviously
depends
on
the
operating
system
and,
what's
the
most
easy
language,
to
maintain
these
build
packs
and
across
a
bunch
of
targets.
I
know
terence,
has
some
opinions
about
windows,
buildbacks
being
written
and
go
because
go
makes
some
assumptions
about
paths
that
don't
particularly
work
well.
A
And
some
other
things,
but
I
think
for
the
linux
ones
so
far
go
seems
to
be
the
most
appropriate
language
to
write
buildbacks
and
the
most
compatible
at
least
hey
yeah.
B
A
Yep,
that's
it
for
sales
updates
for
rfcs.
Let
me
just
check
if
there's
anything.
C
A
Is
this
additional
exportable
layers
rfc,
which,
like
steven
terence
and
I
had
a
separate
discussion
on
around
how
this
could
be
improved
and
made
compatible?
I'm
not
sure
if
this
is
something
of
interest
to
the
rest
of
this
group,
otherwise
we
can
skip
it.
Apart
from
that
all
the
other
rfcs
are
old.
A
A
Lastly,
we
have
standing
docks
issues
items.
A
A
B
B
I
think
that
you're
right,
but
I
I
have
to
actually
go
through
and
verify
that
and
then
terence
said
that
he
was
going
to
take
a
look.
So
I
might
just
bump
him
on
this
issue.