►
From YouTube: CNB Team Leads Sync - 8 June 2022
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
Update
that
they
would
allow
us
to
do
so
in
the
next
release
of
the
client.
I
don't
know
exactly
how
they
manage
that,
but
so
that
is
slated.
So
I
think
we
won't
have
an
excuse
going
forward
from
not
doing
this.
B
D
A
All
right,
so
we
do
have
the
latest
version
of
pack
an
rc
version
of
that
out
we're
going
to
let
that
sort
of
sit
or
simmer
for
about
a
week
or
so
before.
We
actually
go
ahead
and
do
the
release
for
that.
That
has
the
full
support
of
the
latest
platform
api
or
actually,
I
can't
even
say
the
latest
at
this
point
I'll-
have
to
revisit
on
how
accurate
that
is.
The
other
thing
that
we
have
is
we
have
a
google
summer
of
code
project
underway.
A
The
mentee
was
kind
of
traveling
for
a
bit,
but
I
think
now
we're
kind
of
full
steam
ahead
on
that
we're
planning
that
out
and
getting
some
work
done
there.
Someone
added
damon
removal,
aka
oscar
layout,
rfc
undrafted.
A
D
Well,
it's
my
turn.
I
thought
there
was
a
question
about
the
designer
nevermind.
Yes,
we
shipped
lifecycle
fourteen
one.
It
was
last
week
some
keychain
fixes
and
also
a
fix
to
unblock
the
pack
release
on
the
dockerfiles
track
of
work,
we're
making
progress.
D
So
you
know
just
to
remind
everyone
that
I
put
out
this
phased
implementation
proposal
and
we
have
the
first
of
what
will
be
three
prs
to
make
that
a
reality
merged
just
today
and
then
on
the
shell
removal,
I'm
putting
my
keys
spec
pr's
are,
I
think,
ready
for
more
eyes,
and
then
I
know
this
intersects
with
the
bat
team,
but
the
profile
build
pack
was
incepted.
So.
B
For
the
bad
side
of
updates,
we
switched
the
main
branch
on
lipsynb
to
be
the
2.0
version
of
it.
We
haven't
got
a
release
yet,
but
we
had
a
meeting
today
with
a
smaller
set
of
contributors
about
the
dot
profile,
build
pack
and
we
decided
we'd,
be
trying
out
the
main
branch
for
your
profile,
buildback
and,
like
hopefully,
use
the
feedback
that
we
get
from
using
the
api
to
refine
it
before
putting
a
release.
B
C
B
B
B
That's
right,
so
it's
just.
D
D
Kind
of
unrelated,
but
the
dockerfile
stuff,
I
wanted
to
put
it
in
an
experimental
api,
and
I
think
that
that
api
it's
got
to
be
something
like
zero
dot,
whatever
dash
alpha
one
or
you
know
beta
whatever.
So
I
I
just
kind
of
wondering
you
know,
should
we
make
a?
D
B
I
think
there's
at
least
a
couple
of
places
in
spec
right
now,
where
we've
not
updated
it
as
a
result
of
that
experimental
api
rfc.
So
right
now
there
are
a
couple
of
places
in
the
spec
where
it
states
that
at
least
the
buildback
api
is
zero.
Sorry
major.miner,
that's
it
doesn't
have
a
patch
component
or
like
any
of
the
other
assembler
components,
and
I
believe,
lots
of
tooling
currently
parses
it
like
a
major.miner
and
not
assembler.
B
I
would
not
create
any
pseudo
versioning
schemes
like
it's
easier
to
just
use,
assembler
library,
to
parse.
This
then
try
and
create
a
pseudo
versioning
scheme
and
have
each
library
try
and
parse
it
differently.
I
think
at
some
point
I
also
argued
for
us
to
change
the
wording
to
just
be
somewhere,
but.
B
B
C
B
C
B
C
It's
easier
for
me
to
think
about
what
like
an
alpha
or
beta
api
means
sort
of
more
along
the
lines
of
how
apis
are
handled
in
case
like
where
you
iterate
on
it
before
you
solidify
it.
If
it's
alpha,
you
know
you
can
change
it
and
there's
a
bunch
of
things,
but
I
don't
I
don't
know
about
patches,
that's
where
I
think
it
breaks
down
for
me.
I
don't
know
what
an
api
patch
is,
which
is
why
I
think
it's
sort
of
like
this
with
the
major
minor
and
then
the
qualifiers.
C
B
C
B
No,
no,
I
I
would
at
least
I
we
need
spec
changes
to
include
that
rfc
like
even
if
we
don't
release
an
experimental
api.
We
need
spec
changes
to
indicate
that
these
are
now
valid.
Api
versions
and
the
platforms
and
binding
should
parse
them
as
such.
So
that's
that's
all.
I
wanted
to
point
out
that,
with
the
next
version
of
the
spec,
we
should
update
the
wording
there,
which
says
it's
just
major.miner,
to
include
the
fact
that
it
can
now
contain
these
extra
strings.
B
There
was
an
rfc
morris
that
described
the
versioning
scheme.
We
just
need
the
spec
changes
for
that.
We
never
introduced
that
and
I
think
that's
what
natalie
implemented
with
the
lifecycle
experimental
api,
like
the
rfc
that
we
had
around
these
apis,
it's
just
that
it
was
never
reflected
in
the
spec
like
we
don't
have
any
issues
for
it
to
track
that.
D
It's
very
painful
to
me
the
idea
that
we're
gonna
have
to
block
the
experimental
api
for
docker
files
on
platform
o10.
Given
that
platform
o10
is
waiting
on
the
profile
build
pack,
and
I
wonder
if
we
can
just
like,
can
we
just
send
out
a
notice
like
blast
it
everywhere?
Hey
we're
shipping,
an
experimental
api
make
sure
you
update
your
tooling
to
like
you
know,
recognize
this
string,
or
can
we
ship
a
dummy
version
of
the
spec?
That's
like
platform
o10.
All
I
do
is
recognize
the
new
versions
right.
B
D
C
B
B
B
D
B
C
I
don't
have
any
better
ideas
for
what
to
do
here.
I
do
some
anxieties
because,
like
that
platform,
as
will
try
to
parse
these
things,
the
old
way
and
then
fail,
instead
of
just
ignoring
that
version,
but
we'll
cross
that
bridge
when
we
get
there
probably
need
to
patch
some
platforms,
but
it'll
be
harder
for,
like
people
running
things
like
tomsu
platforms
on
brim,
something
we
got
to
think
about.
D
D
B
Okay,
I
guess
we'll
have
to
rethink
our
own
nine
build
pack,
a
note
and
platform
release
to.
B
Who
do
we
want
to
assign
it
to?
Yes,
we
are
I'll,
we'll
figure
out
the
assignees
on
slack
and
lastly,
agenda
for
tomorrow.