►
From YouTube: 2022-02-03-Node.js Technical Steering Committee 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
A
A
The
other
one
that
I
will
pass
on
for
from
mary
is
she's
been
starting
to
to
look
at
the
future.
Bull
build
tool,
chains
initiative.
Again.
She
has
some
good
pr's
to
capture
some
sort
of
initial
assessment
of
things
like
cmake,
bazel
and
gn,
and
the
ask
was
that
we
know
we
we
basically
talk
about
well,
should
we
create
a
team
and
act
as
part
of
the
announcements?
A
It's
like
hey
if
you're
interested
in
joining
a
team,
that's
going
to
work
on
that
there
is
an
issue
in
the
build
tool
chain.
Next,
repo,
it's
issue
number
11,
and
if
you
can
comment
there,
that's
how
we'll
capture
the
people
who
sort
of
putting
their
hand
up
to
work
on
that
initiative,
I'm
sure
there'll
be
other
other
opportunities
to
join
in
or
whatever,
but
that's
a
good
way
to
say:
hey!
You
want
to
get
involved
in
the
initiative
as
it
gets
started.
A
C
Yeah,
I'm
here
I
I
am
having
a
little
trouble
with
the
microphone,
but
the
cpc
session
this
week
was
focused
on
security,
and
I
don't
really
know
that.
There's
too
much
more
to
say
about
that
michael.
What
would
you
add.
A
I
guess
I
would
just
add
that
we're
going
to
see
this
as
a
pretty
consistent
theme
this
year.
I
think
you
know
what
I
see
is
the
log4j
issue
in
the
java
world
has
raised
the
visibility.
There's
lots
of
discussions
at
fairly
high
levels,
and
you
know
it's
it.
It
was
also
discussed
at
the
board
level
in
the
board
meeting
this
week
and
I
think,
there's
going
to
be
a
pretty
big
push
to
help.
A
You
know
figure
out
what
what
what
can
we
do
on
the
the
you
know
the
the
front
of
open
source-
and
you
know
security
supply
chain,
all
that
kind
of
stuff.
So
I
that's.
Maybe
the
only
thing
to
say
at
this
point
is:
there's
gonna,
be
a
pretty
big
push
on
that
and
if
you
have
ideas
of
what
we
should
be
doing
can
be
doing.
A
You
know
now's
the
time
where
you
know
there
may
be
more
opportunity
to
try
and
get
funding
or
try
and
get
support
or
get
people
interested
in
those
kinds
of
initiatives.
A
C
No,
I
mean
it
was
it
was.
It
was
about
that
one
topic
and
we
didn't
cover
anything
else
and
we.
It
was
a
really
great
discussion
and
I
don't
have.
I
don't
have
a
whole
lot
to
add
beyond
what
used
what
you
just
said.
Okay,.
A
You
know,
I
don't
think
there
was
too
much
of
note
other
than
you
know
what
I've
already
said
in
terms
of
you
know
the
the
focus
on
security-
and
you
know,
there's
gonna-
be
a
push
push
on
that
front
yeah,
I
think
otherwise,
you
know
like
planning
for
opengs
world
continues
still
hoping
to
do
that
in
purple
and
person.
A
Definitely
space
for
a
collaborator
summit,
so
we'll
need
to
start
figuring
out
the
planning
for
the
node
component
of
that,
but
otherwise
I
don't
have
any
any
other
updates
on
that
front.
A
Okay,
so
I
guess
we
can
move
on
to
the
issues
that
were
tagged
for
the
agenda.
Then
the
first
one
is
managing
feature
requests.
This
is
number
four
one,
one
one
three.
It
was
on
the
agenda
before
we've
talked
about
it
a
few
times.
A
I
think
you
know
they
asked
last
time
was
that
a
few
more
technical
steering
committee
members
get
involved
review
hopefully
approve
the
pr
that's
out
there.
I
think
that
has
happened.
We
now
have.
Let
me
just
take
a
quick
look.
A
Yeah
we
now
have
five
five
people
who
have
like.
I
see
five
tse
members,
who've
approved
that
the
main
thing
being,
I
think,
of
notice.
You
know
I
would
look
at
it
at
once
that
lands
and
turning
on
something
like
stale
bot
to
start
closing,
really
old
feature
requests
with
the
content
and
discussion
we've
had
in
there.
So
I
I
think
it's
it's.
It's
got
enough
approvals
to
land,
just
if
you
have
any
concerns
or
objections.
A
D
Just
to
be
double
sure,
this
is
a
proposal
to
manage
the
stale
feature
request
and
their
life
cycles
not
necessarily
a
mean
to
basically
segregate
valuable
feature,
requests
and
drive
them
to
closure.
That's
not
the
intent
of
this
pr.
A
No
this
this
one
pretty
much
captures
what
we
do
today,
except
that
it
adds
in
that,
after
a
certain
amount
of
time,
they'll
be
marked
as
stale.
So,
yes,
it's
it's
more
around.
What
do
we
do,
which
is
we
don't
actively
manage
them
today?
We
leave
it
up
to
individual
collaborators
to
to
look
at
them
and
decide
what
to
do
and
then
actually
turn
on
some
automation
to
to
cut
down.
A
You
know
we
have
something
like
200
and
I
think
over
150
of
them
were
like
a
year
or
possibly,
two
years
old,
so
sort
of
try
and
cut
it
down
so
that
we
have
a
list
which
is,
is
more
recent
active,
I'm
hoping
that
you
know
once
this
is
landed?
It's
a
good
place
for
us
to
document
something
more
active
if
we
work
or
agree
on
doing
that,.
A
Yeah
that
sounds
good.
I
think
michael
zasso
has
a
few
ideas
about
it's
like
a
github
project
feature
or
something
like
that.
So
I
think
if
we
could
yeah,
I
think
that
that
is
you
know.
The
next
step
is
to
start
to
discuss
that
and
like
what
could
we
do
to
more
actively
manage
those
if
we
had
a
good
way
of
surfacing
like
the
ones
that
looked
the
most
important,
we
could,
even
like
add
a
section
to
this
agenda
to
go
through
them
or
something
like
that.
A
Okay,
if
not
the
next
one
is
docs
clarification
around
real
world
risks
and
use
cases
of
vm
module.
I
think
we
left
this
one
on
the
agenda
because
we
want
for
visibility,
but
I
I
think
we'd
agreed
that
adding
more
clarity,
there
was
useful
and
it
was
back
to
github
to
actually
do
that.
Is
there
anything
any
updates
people
want
to
add
or
discussion.
We
should
have
here.
C
I
believe
I
had
said
that
I
would
open
a
pull
request
with
the
additional
language
and
I
have
not
done
that,
but
you
know
I
intend
to
if
someone
beats
me
to
it
great
but
I'll.
If
not
I'll,
do
it
and
I'll
try
to
actually
get
it
done
this
week.
A
The
next
issue,
then,
is
rename
default
branch
from
master
domain.
I
don't
think
we've
made
any
progress
on
that
there's
just
a
few
key.
We've
we've
covered
the
vast
majority
of
our
of
our
repos,
but
the
last
few
are
a
bit
harder
because
they
have
more
integration,
other
things.
So
we
have
to
be
careful,
so
I
don't
think
there's
any
update
unless
anybody
else
has
any
updates
on
that.
One.
A
I
think
mary
had
opened
that
we
did
discuss
last
week
and
I
think
the
the
agreement,
the
suggestion
and
I
think
from
what
I
remember
the
agreement
was.
Is
we
should
that
there's
value
to
documenting
what
we
would
do?
Obviously
you
know
there's
there's
things
that
would
a
fi
apply
in
a
case-by-case
basis,
but
having
a
default
set
of
actions
or
whatever
would
help
us
move
quickly
enough,
so
that
things
don't
happen
sort
of
de
facto,
and
I
think
we'd
answered
mary's
question
on
this
front.
A
So
I
don't
know
anybody
has
anything
else
to
add
on
that
one
or
should
we
leave
it
on
the
agenda?
What
do
people
think.
A
A
A
A
Okay,
the
next
one
is
invite
tsc
members
in
the
google
calendar
event
for
meetings
mary
is
was
was
championing
and
pushing
that
forward.
I
I
do
think
I
received
invites
I
don't
know
if
everybody
else
who'd
asked
for
them
has
gotten
the
invites.
F
I
did
receive
the
invite
the
only
remark
I
have
it's
there's
a
google
map
link
instead
of
the
zoom
link.
Maybe
I
can
add
a
comment
to
the
issue.
A
F
Yeah,
so
the
the
vote
is
is
open.
There
already
have
been
eight
dlc
members
who
have
voted,
so
you
should
have
inverted
just
considered
doing
it
and
yeah.
Maybe
I
can
ping
the
gstsc
there.
D
F
Yeah,
that's
the
original
idea.
I
guess,
depending
on
the
result
of
the
vote,
we
can
assess.
What's
the
what
would
be
the
next
foot.
A
Okay,
so
well,
then
next
issue
is
looking
for
feedback
pointer
compression
in
ogs
number
790.
A
B
From
a
practical
point
of
view,
not
shipping
pointer
compression
has
not
impacted
us
in
any
way,
so
one
of
the
risk
original
risk
of
so
we
are
diverging
with
that
setting
compared
to
what
chrome
is
doing
from
the
browser.
The
browsers
are
shipping
chromium
is
shipping
with
pointer,
complex
compression
enabled
everywhere,
which
helped
them
reduce
the
memory
constant
memory
usage
of
their
the
apps.
B
For
us,
this
has
not
impacted
us
in
any
way.
Okay,
so
it's
the
originally
they
were.
The
the
part
of
this
was
a
worry
that
by
enabling
pointer
compression
we
would
we
by
keeping
it
disabled,
we
would
have
some
breakage
in
the
gc
behaviors
or
another
stuff.
G
G
So
I
can't
tell
you
how
many
people
are
actually
downloading
that
it
does
exist.
G
I
think
I
guess
the
thing
we
never
actually
sort
of
just
sold
or
looked
at
because
it
wasn't
clear
if
there
was
a
need
to
do
it
is,
is
the
fact
that
I
think
I
think
it
was
mentioned.
The
point
of
compression
did
did
have
effects
on
things
like
native
add-ons
if
they
were
using
v8
apis,
so
yeah
in
theory,
there
are
unofficial,
builds
if
someone
wanted
to.
They
could
put
put
that
into
a
docker
container,
but
it
doesn't
solve
the
sort
of
compatibility
issue
that
we
never
really
discussed.
G
That
is,
as
far
as
I
know,
I
think
I
think
go
ahead.
I
think
point
of
compression
was
somehow
involved
with
an
issue
you
raised
michael
about
testifying.
Debug
builds
on
arm.
G
A
A
There
was
there
was,
it
was
with
something
like
pointer,
cage
and
now
right
that
I
don't
know
if
that's
pointer,
compression
or
not
so
fair.
A
Yeah,
I
think
I'd
agree
with
with
matteo
that,
like
that
was
the
concern
we
haven't
seen
that
concern
at
the
same
time,
like
it'd,
be
great
to
have,
you
know,
builds
that
gave
a
smaller
memory
footprint,
but
there
doesn't
seem
to
be
enough
push
to
push
people
to
work
on
that.
A
B
Well,
we
we
have
done
what
we
so
something
that
can
be
done
there.
It's
potentially
document
the
fact
that
there
is
an
official
build
with
point
of
compression
enabled
okay
most
and
how
to
install
it.
That's
the
only
bit
that
I
would
say
it's.
G
So
the
only
thing
I'd
say
about
the
unofficial
builds
is
we
don't
want
to
push
them
too
much
because
they
are
an
official
rate?
Well,
the
main
thing
is
that
we
we're
not
guaranteeing
they're
going
to
we're
not
guaranteeing
for
every
version
of
node
that
there's
an
unofficial
yeah,
so
unofficial
builds
is
not
just
point
of
compression.
There
are
other
configurations
of
node.
G
I
think
that
the
mozilla
builds
the
ones
that
are
actually
in
the
docker
images
for
using
using
muzzle
rather
than
those
are
unofficial,
which
is
an
interesting
question
to
look
at
at
some
point.
But
yeah
point
of
compression
is
one,
and
I
think,
there's
another
one-
about
sort
of
some
sort
of
tracing
option
enable
but
they're
they're,
all
kind
of
we've
written
recipes
doc
to
to
sort
of
build
them
in
docker
containers,
and
if
they
work,
that's
fine,
they
produce
binaries.
G
When
we
do
official
releases,
if
they
don't,
if
they
break,
then
it's
really
up
to
someone
volunteering
their
time
to
to
go
in
and
figure
out
why
they've
broken
and
fix
it.
It
is
sort
of,
I
guess,
a
best
effort
thing.
So,
yes,
we
have
unofficial,
builds
and
yeah.
They
exist,
they're
not
guaranteed
to
be
there
for
every
release
of
node.
We
do
but
it's
a
best
effort
thing.
A
A
G
If
anybody
out
there
is
sorry
go
ahead,
I
suppose
I
should
also
remark
that
the
unofficial
builds
at
the
moment
are
64-bit
intel
amd64
only
so
not
on
any
of
the
other
architectures
or
operating
systems.
A
B
B
Especially
on
linux,
I
would
not
you
know
have.
I
would
not
purchase
this
for
other
operating
system,
for
example,
but
you
know
it's
really
it's
up
to
them
if
they
want
to
do
this
to
step
in
and
allocate
more
resources
to
build
or
whatever,
like
I'm,
it's
an
interesting
idea.
Okay,
and
if
it
doesn't,
you
know
you
see
if
yeah.
A
It's
certainly
been
proven
proven
out
in
things
like
java,
where
you
know
some
vm's
offered
as
a
effectively
a
command
line
option,
but
it's
the
way
it
typically
is
implemented
means
that
it's
not
really
a
command
line
option.
It's
like
there's
two
copies
of
the
vm,
bundled
in
or
you
have
separate
vms,
and
so
it's
it's
not
an
easy
switch,
but
it's
certainly
been
heavily
used
in
other
spaces.
So
definitely
interesting.
B
Yeah,
it's
especially
because
you
know
you
like
my
tests,
as
shown
I've
done
so
few
builds
and
tests
on
that
and
it
there.
It
has
shown
that
you
literally
cut
the
memory
usage
in
half,
which
means
that
you
can
stick
double
the
amount
of
node.js
processes
in
the
same
in
on
on
the
same
hardware,
if
they're
not
using
the
cpu
so
which
is
pretty
significant
from
my
point
of
view
so
yeah,
that's
the.
B
C
B
A
Yep,
okay,
that's
that's,
I
think
we're
that's
where
we're
at
so
yeah.
We
made
our
pitch
out
there
if
anybody's
watching
like
we,
don't
it's
not
that
we
don't
think
this
is
useful
or
valuable.
Just
comes
down
to
it's
not
a
trivial
thing
to
turn
on
and
we
need
people
who
will
volunteer
to
move
forward
for
now.
A
A
C
C
Yeah,
I
think
we
can.
We
can
take
this
off
the
agenda.
This
was
this.
Is
this
was
discussed
adequately
in
the
issue
and
I
think
I'm
gonna
end
up
closing
it.
C
Well,
yeah,
because
because
it
was
changing
who
has
owner
permissions
in
the
github
org,
it
seemed
sensible
to
to
put
it
on
the
agenda
to
get
maximum
exposure
to
the
tsc
before
doing
it,
but
we're
not
going
to
do
it.
It
turns
out
it's
not
not
yet,
at
least
at
a
place
where
we
get
significant
value
out
of
doing
it.
C
So
maybe,
as
the
feature
develops
and
becomes
more
yeah
as
it
develops,
if
it
evolves
into
something
closer
to
what
we
would
use
for
the
moderation
team,
we'll
explore
it
again,
but
right
now
I
don't
think
there's
anything
for
the
tsc
to
do
so
I'll
at
least
go
ahead
and
remove
the
label
right
now.
H
Rich,
just
as
a
tiny
follow-up
to
that,
if
you
have
feedback
that
I
could
bring
to
the
team
at
github
about
why
we
can't
adopt
the
future
right
now,
I'd
be
happy
to
bring
that
to
them
and
see
maybe
there's
stuff
on
the
roadmap
that
could
help
us
get
there.
A
A
There
is
a
pr
in
our
collaborators,
under
the
dot
collaborators
section,
to
sort
of
document,
our
strategy
for
http
that
we
we
agreed
on
there.
As
matteo
mentioned
earlier,
one
of
the
things
we
agreed
was
like
it
made
sense
to
land
fetch
as
the
high
level
api
for
clients
and
amazingly
quick
turnaround
thanks
to
michael
zasso
and
everybody
else
that
helped
make
that
happen,
and
we
also
had
a
had
some
discussion
agreement
on
documentation.
So
that's
the
other
action
out
of
there.
A
A
So
I
don't
think,
there's
anything
to
discuss
on
that
one.
It's
a
very
long
way
of
saying
that
strategic
initiatives,
so
we
can
move
on
to
those
mary
gave
a
a
great
update
in
terms
of
the
build
chain:
strategic
up
ships
and
she's-
not
here
today,
she's
written
some
good
drafts
of
cma
gin
and
basil.
A
So,
if
you're
interested
in
this
it's,
I
think
those
capture
sort
of
the
pluses
and
minuses
and
the
discussion
we've
had
about
them
and
you
know-
kicking
off
also
discussion
around
native
modules
tool
chain,
they're
separate,
but
you
know
a
little
bit
related.
So
it's
probably
good
to
have
that
discussion
in
parallel
and
the
callout
was,
you
know,
looking
to
form
a
team
who's
going
to
work
together
on
moving
that
part
forward.
A
So
there's
an
issue
in
that
repo,
which
I
have
up
in
the
announcements
if
you're
interested,
please
chime
in
there-
and
I
think
mary
will
be
looking
to
sort
of
kick
that
off.
You
know
not
too
long
from
now
the
next
one
I
can
see
joey's
added
her
update
as
well
joey.
Do
you
want
to
take
us
through
that.
I
Sure
can
you
hear
me?
Yes,
okay,
so
I
recently
fixed
a
long-standing
bug.
In
the
end,
I
thought
that
prevents
a
user
from
including
class
initializers
in
the
snapshot,
so
that's
not
fixed
and
we
can
finally
move
like
finally
revert
the
the
code
that
was
was
class
initiative
before,
but
we
reverted
those
because
they
couldn't
be
supported
in
snapchat.
So
now
we
can
kind
of
move
them
out
from
the
constructor
again
and
another
one
is.
I
There
is
another
bug
blocking
the
used
line
snapshot
prototype,
which
was
a
memory
bug
that
another
user
found,
so
I'm
looking
into
that
and
also
there
is
a
bug
blocking
the
typescript
tests
types
with
compiler
tests
regarding
the
muted
globals
in
vs
snapshots.
So
I'm
also
looking
into
that.
There
is
some
feedback
in
the
cl,
so
I'm
going
to
address
them,
make
sure
there
are
other
bugs
in
video
snapshots
when
applied
to
more
complicated,
useless
javascript.
I
So
I'm
I'm
trying
to
fix
them
before
landing
their
useless
snapshot
project.
That's
why
it's
been
taking
such
a
long
time
for
that
to
land
and
also
another
thing
that
I
recently
learned
is
that
we
turned
off
snapshot
compression
by
default
on
desktop
in
v8
9.8,
and
that
resulted
in
a
size
regression
in
general,
which
was
kind
of
like
20
megabytes
of
difference
in
in-gear
binary,
and
they
fixed
that
by
switching
to
as
a4
and
the
std
and
do
their
own
compression.
I
Not
sure
if
we
have
those,
but
at
least
we
can
like
do
the
compression
by
ourselves
using
the
whatever
compression
library
we
already
have,
and
the
v8
only
has
like
did
it
by
default,
because
that's
what
chromium
has
so
they're,
probably
not
going
to
looking
into
like
switching
to
a
different
compression
library
in
their
own
codebase
soon.
I
I
They
don't
snap
so
much
in
their
binary
anyway,
so
by
switching
by
turning
that
off
by
default
chromium
like
save
some
time
in
the
snapshot
initialization
because
they
don't
have
to
decompress
the
snapshots,
but
in
our
use
case
that
might
matter
more
because
we
snapchat
more
so
I
haven't
looking
into.
I
haven't
looked
into
like
how
much
size
regression
we
have
after
we
upgraded
to
va
9.8,
but
I
will
check
it
out
and
see
if
we
should
do
it
soon.
I
If
that
doesn't
matter
much
at
the
moment,
then
we
can
kind
of
not
do
it
by
the
phone.
A
A
I
A
I
Yeah
yeah,
okay
I'll
see
if
that
can
be
turned
on
thanks
for
the
suggestion.
G
No,
I
was
just
going
to
say
we
do,
we
do
have.
We
do
have
zedlib
in
the
v8
dependency
and
we
also
have
a
copy
of
that
for
our
own
use
in
depth.
I
think
there's
a
pr
that's,
either
open
or
just
recently
landed
to
update
the
zed
lib
from
the
upstream
chromium
fork.
I
think
maybe
michael's
opened
it
so
yeah.
I
don't
know
how
update
up
to
date
we
are,
but
we
we
have
been
using
the
chromium.
F
Fetch
doesn't
end
it
thanks
to
individuals.
Okay,.
A
Okay,
so
that
sounds
good
that
takes
us
to
the
end
of
the
agenda.
Do
we
have
anything
else
that
we
should
discuss
before
we
close
out
the
public
session
for
this
week?.
A
If
not
thanks
for
everybody
for
taking
the
time
to
attend
and
those
who
are
watching
the
stream,
we'll
see
everybody
in
github
and
next
week,
if
the
tse
members
can
stick
around.