►
From YouTube: 2020-01-22-Node.js N-API Team meeting
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
welcome
to
the
node
and
api.
Sorry
welcome
to
the
node.js
node
api
team
meeting
for
the
22nd
of
january.
We'll
follow
our
typical
agenda,
which
is
to
go
through
the
issues
tagged
for
milestone
11.
before
we
do.
That,
though,
does
anybody
have
any
announcements
they'd
like
to
make.
A
I
guess,
if
not
I
see
we
have
a
you
know
a
new
attendee,
so
I
don't
know
mo
if
you
want
to
just
give
us
a
short
intro
and
answer
what
your
interest
is.
B
I
actually
saw
an
application
for
an
api
and
I
do
web
development
and
I
and
I
also
code
in
python,
so
I
was
just
interested
in
learning
more
and
see
like
what
the
meeting
would
be
about.
Okay,.
A
A
Okay,
well
great
great
thanks,
thanks
for
showing
up
and
welcome,
so
I
will
share
the
things.
We've
tagged
for
the
agenda,
the
first
one
I
added
just
a
little
bit
about
the
the
I'm
just
wondering
if
we
should
make
a
submission
to
openjs
world,
the
call
for
papers
opened,
I
think,
a
week
or
two
ago
and
closes
in
a
couple
weeks,
and
I
wondered
what
people.
A
Yeah,
so
what
I,
what
I
my
first
thought
was
block
blog
and
api.
We
did
an
update.
A
A
We
it's
a
presentation
so
this
year,
there's
like
a
keynote
track,
that's
gonna
be
live
streamed
and
you
know,
basically,
you
can
watch
them
in
real
time.
The
rest,
I
understand
the
rest
of
the
talks
will
be
pre-recorded.
Videos
and
people
can
kind
of
go
in
and
watch
the
different
ones
that
they
they
like
as
part
of
the
conference.
A
So
for
for
the
you
know,
the
submission
requires
like
an
abstract
and
you
know
going
to
be
presenting
it
and
then
the
the
actual
delivery
is
going
to
be
like
a
pre-recorded
video
that
we
can,
we
can
submit
that's
kind
of
nice
and
that
you
know
we
can
get
more
people
from
the
team
involved
to
do
that
right.
So.
A
This
is
that
this
did
occur
last
year
in
july,
open
opengs
world
virtual
again
because
of
covid,
but.
E
D
A
A
So
I
mean
sounds
like
the
answer
is
yeah.
Yes,
we
should
do
something
just
a
matter
of
putting
together
a
abstract
and
title
right.
A
Sounds
good
so
maybe
well,
hopefully
we
can
discuss
in
the
issue
itself
because
I
think
there's
a
couple
weeks
to
go.
C
A
A
The
next
one
was
discuss.
36.
A
A
Right
so
this
was
caught
catching
the
uncut
exceptions
on
calling
into
modules
and
the
the
discussion
we
had
last
time
was
around
the
fact
that
the
you
know
it's
it's
effectively
december
major
because
it
can
break
existing
code
and
we
put
together
based
on
our
discussion,
sort
of
an
outline
of
what
we
thought
would
make
sense,
and
I
tried
to
capture
the
what
we
discussed
in
this
comment
in
the
issue.
A
Does
everybody
had
a
chance
to
have
a
quick
read
of
that
and
think
that
that
does
capture
what
we
discussed
and
still
think
that
that's
the
way
the
proper
way
forward.
C
Yeah,
it
seems
it
seems
like
a
a
pretty
good
way.
It's
it's
sort
of
a
balance
between
being
too
strict
and
and
breaking
people
too
hard
and
and
and
dragging
out
the
transition
process.
I
mean
I
I
can
imagine
a
slightly
longer
transition
where,
where
the,
where
the
initial
value
of
this
is
of
the
option
is,
is
true
rather
than
oh,
wait.
No,
not
true,
I
mean
like
basically,
you
know
by
default.
If
you
do
nothing,
then
this
behavior,
the
current.
C
Continues
rather
than
the
opposite,
but
it
it
may
be
okay
to
to
go
straight
for
the
opposite,
because
otherwise
it
doesn't
have
much
of
an
impact.
You
know,
and
then
people
tend
tend
not
to
not
to
act
if
they
don't
have
to.
A
Apps
out
there
with
uncaught
exceptions
that
aren't
being
being
reported
and
unnoticed
right
because
in
theory
they
would
run
into
some
sort
of
other
problems
in
the
end
and
be
caught
yeah
exactly
yeah.
We
can
always.
You
know.
I
think
I
think
what
you
just
described
is.
If
we
find
out
we're
completely
wrong,
then
you
know
at
least
we've
got
a
callback,
a
fallback
where
we
could
flip
that
to
the
default
being.
A
Okay,
so
it
sounds
like
we're
still,
I
think
that's
our
way
forward,
so
it's
basically
just
needs
to.
I
don't
know
if
legendarcast
has
had
a
chance
to
update
it
to
reflect
that.
I
don't
think
so.
Yet,
right.
C
It
doesn't
say
outdated
on
my
comments,
but
I
I
haven't
seen
if
there
are
commits
at
the
bottom.
Okay,
there
are
none.
C
A
A
There,
thank
you
repromoted,
okay,
the
next
one
I
did
myself
as
well,
which
is
like
github,
has
had
added
some
tooling
to
do
a
rename
of
the
primary
branch
to
maine.
I'm
thinking.
We
should
probably
do
that.
Certainly
for
abi,
stable
node.
We
don't
really
have
any
existing
pull
requests
and
I
think
the
the
impact
is
going
to
be
pretty
minimal.
So
I
was
thinking
unless
there's
objections.
I
just
go
ahead
and
do
that.
C
A
C
A
A
It
will
like
it'll,
manage
the
poll
requests
that
are
in
flight,
okay
and
I
think
that
it
was
supposed
to
handle
redirects,
although
I'm
not
a
hundred
percent.
Maybe
that's
something
worth
worth.
Checking
like.
A
Right:
okay,
so
there's
this
new
thing,
so
it
says
you
can
now
renaming
branch
clear
from
the
web.
Okay
update,
tubal
requests
update
one
branch,
so
it
doesn't
update
local
environments,
okay,
retarget,
so
rename
should
we
target
any
open,
pull
request,
update
any
draft
releases
based
on
the
branch
open,
your
branch
protection
walls.
Let's
push
around
still
name.
A
I'm
just
looking
for
the
thing
where
we
do
the
checkout.
C
Normally,
normally
we
fill
in,
we
fill
in
a
text
box
with
like
refs
pull
pull
request,
number
slash
head
and
then
we
we
do
that,
but
but
otherwise
I
think
the
default
value
for
that
is
master.
But
you
have
to
type
in
the
branch
before
submitting
one,
though
the
nightlys
probably
do
that
by
default
and
and
we
don't
rebase
like
the
way
core
rebases
onto
the
main
branch
before
running,
we
don't
do.
E
A
C
Yes,
yes,
update
the
default
value
and,
and
maybe
the
the
nightly's
ought
to
be-
ought
to
have
that
fixed,
because
the
knight
leaves
one
doesn't
specify
anything
they
just
run.
So
I
think.
A
Yeah,
I
think
if
we
yeah
I'm
just
what
I'm
thinking
we
update
this
one,
then
the
other
main
job
is
the
this
lts
versions,
which
just
runs
that
but
specifies
the
node
version.
E
Point
any
other
questions
on
what
we
need
to
update
there's
also,
the
legendary
cast
is
linter
that
we
added
the
github
action
where
it
references
the
master
branch
on
origin.
A
A
I
guess
what
it
says.
Is
it's
not
going
to
change
the
local,
a
person's.
D
A
C
A
So
how
about
like,
if
everybody's
okay,
I
can
go
ahead
and
do
the
first
three
just
because
they
probably
need
to
be
done
at
the
same
time
and
then
jim.
If
you
can
take
a
look
at
fixing
up
the
docks
and
I
suspect
we
won't
have.
Hopefully
you
know
there's
not
so
much
activity
there
that
you
know
it
should
affect
too
too
many
people
and-
and
you
know,
after
a.
C
C
C
C
A
I
think
it's
basically
you've
just
completely
replaced
one
with
the
other.
You
know,
subject
to
the
few
things:
you've
got
to
fix
up
and
hopefully
like
the
redirects
for
docs
and
stuff
still
work.
But
you
know
there
there
will
be
places
in
the
docks
where
it
says,
like
checkout
master,
which
wouldn't
work
anymore,
because
it
doesn't
exist
right.
A
Okay,
so
I
will,
I
will
do
that
either
today
or
sometime
next
week
and
then
I'll
mention
you
jim
to
just
say:
hey.
If
you
can
start
looking
at
the
docs
and
then
we'll
see
we'll
see
if
anything
goes
and
yeah.
I
think
it's
good
you're
right
that
doing
it
on
this
one
is
probably
good,
and
then
we
can
think
about
the
examples.
One.
A
C
Great,
maybe
maybe
use
this
issue
for
for
things
that
we
we
you
know
stumble
over
as
we
do
this.
So
if
anything
else
sort
of
pops
up
that
needs
to
be
done
that
we
haven't
covered
in
these
points,
then
maybe
we
should
add
it
to
the
issue.
So
then
it
becomes
kind
of
a
recipe
for
for
moving
from
from
one
branch
to
another
for
by
default.
A
Okay,
the
next
one
were
the
stale
issues.
So
let's
see
we'll
just
open
a
few
of
these.
A
Out,
let's
go
to
github.
A
C
This
yeah
this
is
this-
is
a
kind
of
an
old
issue.
Yeah
trying
yeah
the
person
needs
a
handle
to
the
module
and
and
we've
kind
of
not
allowed
that.
C
So
I'm
not
sure
how
you
know.
If
we're
going
to
do
anything
about
this,
because
it's
it's
not
too
many
people
have
this
requirement,
you
know,
and-
and
it
can
be
solved
with
the
with-
with
with
the
javascript
sort
of
module
in
front
of
the
native
module,
but
this
person
doesn't
want
that.
So
I'm.
A
C
C
A
C
C
E
C
A
We
see
it
and
we
don't
see
any
good
options,
discuss
this
and
don't
see
any
good
options.
That
are
that,
with
the
spirit
I
don't
know,
if
spears
is
the
right
word,
but
with.
C
A
A
Like
unless
there's
more
requests
cases
where
it
blocks
adoption.
A
A
C
C
So
like,
let
me
see
here,
maybe
something
like
I'm
typing
it
in
the
chat.
C
Yeah,
like
that,
so
you
know
the
so.
Basically
the
add-on,
the
add-on
exports
a
function
which
receives
the
module,
which
then
you
know,
which
then
adds
on
everything
to
to
the
module,
including
exports.
C
I
may
yes
this
one
right
here.
No,
no!
I
I
do
mention.
I
do
remember
saying
that
at
some
point,
but
might
have
been
a
way
back.
C
C
Oh
here,
maybe
yes,
yes,
this
is
how
you
would
do
it
with
with
a
front
end.
So
I
guess
this
is
a.
This
is
an
alternative
that
what
I
just
wrote
is
an
alternative
where
you
do
require
the
node
module,
but
you
call
a
function
on
it
that
passes
back
the
thing.
A
C
C
A
C
Yeah
yeah,
so
so
you
know
in
the
in
the
init.
You
know
you
return
a
nappy
value
right.
The
the
nappy
value
is
is,
is,
is,
is
the
new
exports
object
right,
and
so
so
so
that
exports
object
is
now
a
function
right
which
gets
called
immediately
as
soon
as
it
returns
into
javascript,
and
then
the
function
receives
the
module
and
then
returns
the
actual
bindings
right.
Okay,.
A
C
Yeah,
I
did
the
only
thing.
The
only
thing
one
forfeits
by
by
using
this
is
is
that
unless
you
do
extraordinary
work
to
to
maintain
the
exports
object
that
was
passed
into
the
init
function
by,
for
example,
adding
it
to
the
to
the
instance
data,
then
you
forfeit
the
exports
object,
which
is
fine
because
you
know
just
returning.
A
new
object
is
just
as
good
it's
it's.
C
It's
there's
no
penalty
for
that
right,
because
the
export,
if,
if
you
just
return
a
function,
then
whatever
exports
object
was
passed
into
the
init
function
is
now
lost.
But
that's
okay,
that
there's
that's
fine!
You
can
just
return
a
new
object.
That's
empty!
You
know
decorate
it
with
with
whatever
bindings
you
have.
You
know,
taking
into
account
the
module
object
that
was
passed
in
and
and
returned
that,
and
it's
just
as
good
just
return
the
exact
same
objects
but
having
stored
the.
C
It
well
no,
because
the
the
init
function
receives
exports
and
is
expected
to
return
a
value
right.
That
value
must
now
be
a
function
right.
So
so
then
you
know
you
could
okay.
C
Well,
I
guess
you
could
create
the
you
could
create
that
function,
that
you
return
with,
with
with
associated
data
and
the
finalizer
that
that
basically
stores
the
export
subject
as
a
persistent
and
then
when
that
function
gets
called
it
can
retrieve
the
data
you
know,
which
is
now
a
persistent
reference
to
exports,
and
then
it
can
even
delete
the
reference,
because
that
call
is
only
ever
going
to
happen
once
so.
A
I
was,
I
was
actually
even
just
thinking
like
this,
you,
you
know
you're
returning
the
require
returns,
you
the
exports
right,
which
you've
made
a
function
and
and
that
function
then
takes
a
method.
It
takes
this
thing,
but
it
it
could
just
as
easily
like
also
have
you
could
have
used
that
same
object
like
it.
You
know,
a
function
is
just
an
object
so
that
you
could
have
used
that
same
object
to
build
your
exports.
C
C
Sorry
result
right
and
then
return
result
and
then
later
on
you
when
that
function
gets
called
you
nappy,
get
cb
info
and
info
x,
ref
and
then
an
api
value
exports
like
that
and
then
an
api
get
reference
value
and
if
you
want
to
share
your
screen,
no,
no!
No!
It's
just
no.
C
C
So
so
in
the
top
function,
you
you,
when
you
create
the
function,
called
something
which
ends
up
which
ends
up
being
the
result
of
init.
In
other
words,
the
new
exports
object,
the
you
you
pass
this
this
persistent
reference
to
exports
as
the
data
item
for
that
function,
which
can
be
retrieved
using
nappy
gets.
Where
is
it
cb
info
right?
C
It
can
be
retrieved
using
that
function
and
then
and
then
it
since
it's
a
persistent
reference,
you
need
to
then
delete
the
reference,
because
you're
only
gonna
you're
only
ever
gonna
use
that
reference
once
so
you.
So
you
kind
of
toss
it
up
in
the
air
in
in
it
and
you
catch
it
in
in
whatever
function
you
export
from
in
it
and
delete
it.
A
C
Not
if
you
wanted
right,
that's
right,
that's
right,
yeah
exactly
so,
so
you
don't
necessarily
need
to
store
it
as
a
reference
you
can,
instead
of
in
in
the
second
function.
Instead
of
an
api
get
cb
info,
I
mean
you'll
still
want
to
call
an
api.
You
get
cb
for
just
to
get.
The
modules
object
right
right,
but
you
you
need
not
do
any
any
an
api
get
reference
value.
You
can
simply
an
api,
create
object
and
then
return
that
object
at
the
end.
And
then
that's
a
brand
new
exports
object.
C
So
yes,
you
don't
need
to,
but
if,
for
whatever
funky
reason,
you
want
to
save
that
that
that
exports
object,
that
the
init
function
received,
because
it's
so
special
to
you
for
whatever
good
and
established
reason,
then
you
can
use
a
reference
to
pass
it
into
into
this.
This
function
that
ends
up
being
the
one
that
creates
the
actual
add-on
so
either
way
works.
A
Yeah,
I
guess
I'm
just
thinking
like
most
cases
you
just
you
know,
we've
already
got
lots
of
examples
where
you
ignore
the
exports
that
was
passed
in
exactly
yeah.
You
just
create
your
own
exports.
Thank
you
and
that
that
exports
can
actually
have
multiple
methods
on
it.
Right,
like
you,
can,
of
course,.
C
C
Yeah,
that's
what
I'm
saying
so
so
this
is
only
if
you
want
to
be
extremely
pedantic
and
and
cherish
that
exports
object
that
was
passed
into
the
unit.
This
would
be
how
you
would
do
it
otherwise
inside
the
second
one.
You
would
just
an
api,
create
object,
decorate
and
return
the
object
that
you
created
and
no
need.
A
A
C
A
The
only
reference,
the
only
limitation,
but
do
you
because
there's
still
a.
A
C
C
So
if
you
do
nothing
with
it
in
the
init
function,
it
it
is
lost,
and
so
any
binding
that
returns
an
object
would
have
to
return
a
brand
new
object
created
using
an
api,
create
object
right
right,
so
the
only
way
to
save
the
exports
during
init
is
to
attach
it
to
something
you
can.
You
can
say
an
api
set
instance
data
or
or
an
api,
create
function
with
that
thing,
as
the
data
parameter
right,
but
I
guess
I.
A
A
A
C
No
okay,
so
you're
you're
thinking
that
that
that
the
the
function
returned
by
init
is
decorated
using
all
the
bindings
right.
Yes,
yeah,
okay,
I'm
assuming
that
it
is
impossible
to
create
the
bindings
without
access
to
the
module
object,
although
otherwise,
if
it
were
possible,
then
why
do
you
need
the
module
object
to
create
the
bindings
right?
Why
do
you?
Why
do
you
need
access
to
the
module
object
at
all
right?
I'm
assuming
that
that,
in
order
to
create
the
bindings,
you
need
access
to
the
module
object.
A
C
Okay,
and
so
so,
that's
why
you
need
to
you
need
to
store.
If
you
want
to
be
pedantic
and
reuse,
the
exports
object,
you
need
to
store
it
as
a
persistent
and
then
pass
it
into
the
function
that
that
is
ultimately
responsible
for
creating
the
bindings
or,
if
you're,
not
pedantic,
you
just
an
api,
create
object
in
that
function,
decorate
and
return.
A
brand
new
object.
C
C
Yes,
but
then
you
would
have
to
pass
the
function
into
the
function
because,
because
the
there
is
no,
we
we
don't
have
a
way
of
retrieving
the
function.
The
javascript
object,
that
represents
the
function
that
is
currently
being
executed.
On
the
native
side.
We
don't
have
a
way
of
retrieving
that
okay.
A
C
You
would
yeah
you,
but
that's
fine.
You
can
still
you
can
pass
that
in
as
as
the
data,
so
so
right
once
you
accept
that
that
that,
once
you
accept
this
two-step
process,
there's
ample
flexibility
in
how
to
implement
right.
But
the
basic
assumption
is
that
you
cannot
create
the
bindings
unless
you
have
access
to
the
module.
A
I
guess
that's
hard
to
do,
because
you'd
have
to
do
that
in
a
two-step
process.
I
see.
C
A
C
D
C
Store
the
module
in
a
persistent
reference
and
then
have
the
rest
of
the
execution
of
your
module,
be
influenced
by
that
so
yeah,
that's
also
possible
right,
so
yeah
as
long
as
this
is
the
calling
convention
for
requiring
the
the
add-on.
All
those
things
are
possible.
A
C
Safest,
the
safest
thing
is
to
is
to
is
to
make
the
is,
is
to
make
the
the
code
that
runs
that
creates
things
as
little
as
possible
until
you
have
everything
that
you
need
to
create
right
right
and
then,
if
the
module
is
one
of
those
things,
then
then
you
you
don't
want
to
create
anything
unless
you
have
the
module
right
that
just
to
be
safe.
But
of
course
you
can.
A
C
Yeah
and
it
requires
buy-in
from
whoever's
consuming
the
native
add-on,
that's
that's
the
bottom
line,
and
and
that's
that
requirement
of
buying,
we
cannot
eliminate
well,
we
we
could,
but
we
don't
like
to
because
we
have
committed
to
to
having
this
super
basic
interface.
C
Yeah
yeah
yeah,
so
I
mean
if
we
were
to
do
this
in
core.
What
we
would
probably
do
is
attach
the
module
to
the
environment
since
the
environment
is
now
per
per
add-on
anyway,
right
we
would
attach
that
object
using
a
persistent
reference
and
then
we
would
add
an
api
like
like
an
api,
get
module.
You
know
right,
but
the
use
case
doesn't
seem
so
wide
because
we're
doing
just
fine
without
it
you
know,
but
the
most
of
the
community
yeah.
A
C
Okay,
so
so
yeah,
that's
that's
basically
why
we
do
not
like
doing
it
right
and-
and
the
thing
is
like
you
know,
for
most
other
engines,
it
would
the
the
the
module
like
an
api,
get
module
would
just
be
an
api,
create
object,
return,
object,
that's.
C
Be
they
don't
have
a
concept
of
a
module
right?
So
so
you
know
we
would
kind
of
be
spreading
this.
This
right,
js
centric
world
view
if
we
started
doing
this
yeah
because
nap
is
certainly
being
used
outside
of
node.js
as
well,
and
so
we
don't
want
to
do
that.
A
Okay,
well,
I
think
that
seems
reasonable,
like
from
there
are
a
few
options,
maybe
a
little
bit
more
work,
but
it
shouldn't
be
completely
stuck
so
yeah
we'll
see
we'll
see
what
the
come
back
to
that
is
probably
get
to
move
on
then
to
this
one
I
think,
then
I'm
gonna
say:
we've
we've
addressed
and
what
was
it?
Somebody
reminded
me:
it
was
like
squiggle
or
something
to
to
get
strikeout.
C
Oh
I
see
this
is
this
is
basically
calling
a
threat
say
function,
calling
a
threat
say
function
with
a
function
pointer
to
execute
on
the
on
the
node.js
side.
So
this
is.
This
is
exactly
what
what
the
original
thread
say.
Function
is,
which
is
you
can
have
a
marshaller
for
each
call
with
a
separate
marshaller
for
each
call,
so
we
kind
of
already
have
that
this
is
just
sort
of
a
convenience
wrapper.
On
top
of
that,
if
I
remember.
A
A
C
E
C
Things
you
know
to
to
sort
of
vet
these
things
and
then
graduate
them
if
needed
right,
but
we
don't
have.
I
don't
think
we
have
a
very
good
process
for
that.
No,
but
yeah.
This
would
definitely
be
a
good
candidate
for
that.
A
A
A
A
C
Yeah,
it's
a
yeah,
it's
a
it's.
A
threat
say
function
that
that
has
like
one
reference
all
the
time
and
then
and
then
you
can
call
it
from
from
there.
Yeah,
okay
and.
C
C
Yeah,
it's
not
it's
yet
another
abstraction
on
top
of
right
on
top
right
say
function.
It.
C
Use
right,
yeah,
yeah,
it's
it's
a
great
way
to
call
from
from
from
one
thread
into
the
note
thread
and,
and
whether
or
not
you
then
call
javascript
or
not,
is
is,
is
becoming
ever
more
beside
the
point.
It's
it's
more
more,
this
disability
to
communicate,
reliably
and
one-to-one
from
a
secondary
threat
to
node.js
right.
It's
a
far
greater
value
that
the
threat
say
function
provides
than
the
actual
calling
to
javascript
that's
trivial.
By
comparison,
it
seems
like.
C
C
A
So
we'll
just
do
that
just
want
to
go
back
to.
I
think,
maybe
at
this
point
we
should
just
to
see
if
there's
anything
else
on
the
agenda
we
should
get
to
because
we're
we've
used
most
of
the
time
on
that.
I
think
we
already
discussed
this
one.
Let's
just
see.
A
A
Yeah,
no,
that's
good.
I
think
it's
kind
of
one
of
these
things
we
want
to
sort
of
it
doesn't
need
to
be
a
big
bang.
Do
everything
overnight
we
should
be
able
to
plan
out
like
you've,
got
like
what
are
the
different
sort
of
steps
we
can
take
one
at
a
time.
A
You
know
because
some
of
them,
like
just
you
know,
working
on
the
docks,
can
be
relatively
low.
Impact
versus
adding
new
symbols
is
significantly
more
so
actually
I
thought
I
just
tried
to
move
that
right.
We've.
A
A
So
I
think
those
are
all
the
things
you
know.
We
didn't
quite
get
through
the
stale
things,
but
is
there
anything
else
that
we
think
we
need
to
talk
about
this
week?
Any
like
major
issues
going
on?
I
I
investigated
a
couple
flaky
issues
which,
in
the
end,
I
couldn't
recreate
and
don't
seem
to
be
causing
problems
in
the
cia
anymore,
but
I'm
not
aware
of
any
other
sort
of
sort
of
problems
on
the
the
api
front.
Node
api
front
this
week.
Anybody
else
have
it.
A
Okay,
okay!
Well,
since
we're
out
of
time.
Maybe
we'll
call
it
for
this
week
and,
like
I
said,
I
can't
make
it
next
week
because
we
have
like
a
team
face
to
face,
but
gabriel
is
gonna
chair,
and
I
look
forward
to
watching
the
video
and
catching
up
with
everybody
in
github
and
and
then
the
next
meeting,
all
right.