►
From YouTube: 2020-04-22-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
So
welcome
to
the
node.js
technical
steering
committee
meeting
for
april
22nd
2022
the
agenda,
as
was
in
the
issue
opened
in
the
tse
repo.
Before
we
get
started,
though
there
any
announcements,
people
would
like
to
share.
A
Nobody
else
is
going
to
mention
it.
I
think
we
should
mention
node
version.
16
was
released
this
week,
yay
it's
on
on
track
to
become
the
next
lts
in
october,
and
thanks
to
to
beth
and
all
the
release
team
that
helped
make
that
happen.
A
In
terms
of
updates
from
the
cpc
or
the
board,
there
is
a
board
meeting
tomorrow.
I
don't
have
anything
specifically
from
the
the
node
side
to
bring
to
the
board
I'm
on
the
cpc
side.
You
know
sort
of
nothing.
I
think
nothing
specific
to
call
out.
A
There
are
some
interesting
discussions
in
terms
of
you
know
some
brainstorming
on
javascript
landia
as
well
as
see
the
last
one
was
around
like
sort
of
how
do
we
put
together
a
a
vision
of
you
know
what
projects
you
know
would
make
sense
in
the
foundation
and
all
that,
but
so
far
still
sort
of
brainstorming
sessions,
so
just
mentioning
as
as
interesting
things
going
on,
if
you
have
any
interest
to
sort
of
come
to
join
those
meetings
and
get
involved.
A
A
A
Okay,
the
next
one
is
deps,
add
yarn
122.5.
So
that's
poll
number
three,
seven,
two,
seven
seven.
We
have
issue
one
zero,
one,
two.
Where
we've
been
discussing
a
vote
on
that
and
I
I
looked
and
I
don't
see
any
real
discussion
in
the
last
week,
so
I
think
it's
kind
of
the
discussions
petered
out
from
my
understanding
the
current
proposals
that
we
use
rcv
for
the
voting
method
and
that
the
question
should
be
you
know
in
it.
A
You
know
add
core
pack
add
yarn,
leave
things,
as
is
where
you
would
sort
of
rank
order,
those
I'm
thinking.
You
know
I
wanted
to
see
in
this
meeting.
If
there
was
any
you
know
any
more
concerns
or
objections.
Otherwise
I
think
we
should
go
ahead
and
schedule
a
vote
on
that.
Does
that
make
sense
to
everybody.
C
One
of
the
things
that
I
would
add
is
it's
more
a
genetic
direction
versus
land
that
pr,
as
is
right,
okay,
it's
especially
corporate
is,
is
very
young,
so
it's
probably
better
to
bless
it
as
experimental
like
in
that
right
right.
C
This
was
called
out
some
other
times
somewhere
else
as
in
in
the
in
the
discussion,
but
I
I
think
it
got
lost
in
the
right
in
the
right.
A
So
so
needs
work
review
and,
let's
see
what
to
say
so,
I'm
just
adding
voters
on
general
direction,
not
land,
as
is
peers,
need
work,
review
and
maybe
experimental
right.
A
Yes,
okay,
okay,
I
know
that's
a
very
important
point,
so
any
other
questions
on
that.
I
I
think,
like
my
next
step
would
be
to
take
this.
I
send
it
I'll,
send
it
to
an
email
for
the
tsc,
basically
with
the
hey,
we'll
we'll
start
the
vote
by
the
end
of
this
week,
unless
there's
objections
kind
of
thing
early
next
week,
unless
there's
objections
that
make
sense.
A
Okay,
good:
let's
move
on
to
the
next
one,
unless
there's
anything
else,.
A
A
A
A
D
A
E
I
edited
it
met
you
as
I
did
the
tsc
agenda
and
another
pure,
which
has
been
closed
since
so
I
thought
maybe
we
we
can
still
discuss
the
issue.
E
C
Yeah,
so
my
my
take
here
is
that
it's
we
should
be
really
careful
in
doing
that
and
avoid
situations
like
the
one
it
happened
with
http.
C
So
you
know
it's
like
because
of
some
changes
in
in
the
in
some
very
sensitive
area
of
the
code
base
that
were
not
benchmarked
against
others
or
were
not
benchmarked
at
all.
In
certain
cases,
we
had
significant
regression
on
http,
but
also
like
20
on
streams
on
like
it
was.
It
was
a
you
know,
it's
the
work
was
done
without
enough
review,
so
it's
it's
very
important
that
the
code
is
reviewed
by
is
reviewed
more
closely.
C
I'm
not
sure
if
we
want
to
keep
pushing
this
activity
or
not,
but
even
if
we
do,
it
needs
to
be
definitely
watch
way
more
closely.
To
avoid
situation
like
because
identifying
those
problems
is
very
hard
because
unl,
like
the
the
way
I
did
identify,
the
problem
was
that
it's
because
I
I
did
essentially
enormous
bisect
over
one
year's
worth
of
comets
and
each
one
of
the
step
was
slowing
things
down.
C
So
you
know
it
was.
You
could
see
that
every
month
the
performance
was
decreasing,
slow,
extremely
slowly
and
it
was
very
like
you
need
to
run
the
benchmarks
for
a
very
long
time
to
actually
detect
it.
So
it
was
very
like
small.
Each
one
of
them
was
not
big
was
very
small,
so
this
is
the
main
like
it's
it's
a,
and
this
is
where
it's
it
gets
tricky
because
you
might
see
that
a
change
on
itself.
It
doesn't
move
much,
but
all
them
combined
will
move
the
needle
and
a
lot.
C
So
I
I
just
wanted
to
you
know,
ask
for
opinions
here,
I'm
not
I'm
basically
ma
it's.
It
was
very.
It
was
not
simple
to
detect
the
pro
like.
Knowing
that
we
had
a
problem.
C
Was
I
and
then
I
I
followed
some
munch,
and
I
saw
it
some
of
them
in
the
flame
graph,
so
that
I
was
able
to
pinpoint
the
areas,
but
it
was
like
to
some
extent
a
desk
of
thousand
cuts
to
some
extent
rather
than
one
single
blow,
like
the
the
other
fixes,
so
the
other
ones
that
we
had
to
revert
so
which
were
simple
to
identify.
Okay.
So
I
just
wanted
to.
D
C
C
Some
of
them
are
good
replacements,
some
of
them
aren't
now.
Antoine
is
probably
no
probably
know
by
these,
which
one,
what
is
actually
causing
the
exact
problem
more
than
me,
because
I
only
identified
the
era
and
then
I
fired
the
cannon
at
it,
basically
destroying
it,
destroying
everything
on
the
path
and
antoine
was
able
to
identify
and
explain
what
exactly
is
is
not
working
as
we
as
we
think
it
should.
It
would
work
because
I
don't
have
a
clue.
So
maybe
antoine
is
probably
better
than
me
at
is
answering
that
question.
E
It's
quite
tricky
actually
to
find
out
which
one
are
harmful
and
which
one
aren't
it's
v8
magic.
I
guess
yeah.
There
are
some
that
we
know
now
for
sure
that
are
harmful
with
this
current
v8
version,
but
yeah
sometimes
we
have
surprises.
E
C
That
is
one
of
the
problems.
That
is
one
of
the
problem.
Most
of
this,
it's
not
documented
anywhere.
So
this
is
this
is
part
of
node.js
lore
that
we
might
want
to
extract.
C
I
was
able,
like
I
was
one
of
the
ones
that
completely
caught
me
very
much
by
surprise,
that
it
landed
was
the
one
that
touched
us
in
cooks,
like
that's
the
probably
most
sensitive
performance
area
of
node.js,
and
you
know
before
somebody
touches
that
code
base,
if
it
like,
when
I
land
something
that
touches
that
I
typically
ask
for
10
people
to
review
my
changes
and
the
pr
landed
with
just
one
or
two
gtms
and
very
little
attention-
and
this
is
the
type
of
things
that
surprise
me
a
lot
that
surprised
me
a
lot
okay
and
like
these
to
clarify
that
was
one
example
of
something
that
has
not
land
did
not
land
with
enough
review,
also
because
there
is
so
many
like
things
that
can
go
wrong
in
that
code
path.
C
That
are,
you
know
it's
it's
very
after
working
on
it.
It's
it's
something
that
I
would
not
recommend
to
anybody
to
touch
and
there's
code
that
we
said
do
not
touch
and
don't,
if
you
don't
know
what
you're
doing
you
know.
This
is
not
a
beginner
beginner-friendly
land.
C
C
Others
were
absolutely
tricky
and
did
not.
Where
should
would
have
not
been
would
not
have
been
easy
to
catch
them.
So
they
were
not
in
things
where
in
areas
that
they
would
consider
hot
paths
at
all,
so
that
is
the,
but
they
were
on
a
very
long
chain
of
you
know
of
a
response
chain
of
an
outpath
essentially,
but
by
themselves
they
were
not
big
problem.
A
big
problem
on
the
single
same
run
method,
but
they
destroyed
some
of
the
lining
magic
that
v8
did
causing
the
problem.
C
So
it's
in
some
cases
it
was
actually
not
even
possible
to
to
detect
them,
and
you
know
the
worst
one
at
all
was
one
it
was
in
fact
it
was
not
him
related
another
one.
So
one
was
the
on
the.
I
don't
remember
which
one
we
exactly,
which
one
landed
antoine
in
the
end,
but
there
was
a
there
was
other
some
other
few
that
were
like.
C
Oh,
this
should
not
be
a
problem,
but
in
fact
it
was-
and
I
was
very
much
surprised
that
that
is
that
actually
turned
out
to
be
a
problem.
So
in
some
cases
it's
actually
very
simple
to
spot.
In
other
cases,
it's
not,
but
I
think
we
should
try
to
document
the
so-called
hot
parts
in
in
some
way
in
the
code
base.
If,
when
we
spot
them,
that
might
be
a
good,
a
good
action
for
for
people
so
that
they
don't
so
they
they
know
when
somebody
opens
the
cause
as
well
be
careful.
C
This
is
a
hot
path,
don't
touch
essentially
or
make
or
anyway
it's
not
on
touch
but
touch
with
extreme
care.
A
C
And
do
more
accurate
testing
even
on
areas
that
are
not
strictly
micro,
like
just
not
micromanches
that
thing,
but
also
like
my
the
my
genetic
test
for
detecting
regressions
is
http
simple.
It's
usually
it
can
catch
all
sort
of
regressions.
You
know
core,
it
can
catch
regressions
or
neck
on
timers.
Next,
stick
streams.
C
I
think
it's
it's
everywhere,
okay,
and
but
it
won't
be
like
a
big
jump.
It
would
be
a
few
percentage
point
up
and
down
on
that
on
on
that
specific
benchmark,
but
it's
typically
one
that
I
recommend
running
as
an
example
because
it
will
most
of
the
time
it
will
actually
touch
some.
If
you,
if
you,
if
we
made
some
mistakes
it
will,
it
will
show.
A
C
These
is,
I
would,
I
would
probably
we
can
probably
make
some
some
faq
or
something
related
to
the
these
primordial
changes
so
that
and
write
some
text
down.
That
would
be
that
would
be
nice
so
that
it's
so
that
it's
there
so
people,
you
know,
know
that
primordials
are
there,
but
they
might
or
might
not
cause
performance
degradation
depending
on
what,
where
and
how
you
use
them
and
maybe
list
the
ones
that
are
known
to
be
performance
because
performance
problems
in
certain
cases
and
and
so
on.
C
E
Yeah,
I
think
the
issue
is
the
http.
Simple
benchmark
doesn't
run
on
jenkins.
I'm
not
sure
why.
I
guess
that's
why
many
problems
haven't
been
copped
when
doing
the
reviews.
It
just
stops
after
a
few
hours,
maybe
times
out.
E
C
I
can
probably
write
something
really
really
too
broad
to
makes
to
make
some
sense.
So
I
I
probably
not
the
best
person
to
say
my
recommendation
would
be
if
you
don't
know
what
you're
doing
don't
do
them.
So
it's
I'm,
probably
not
the
right
person
to
write
such
a
guide.
E
I
mean
I
can
try:
where
would
we
put
this
q
a
or
feq.
A
Under
the
docs
guides,
there's
various
sort
of
you
know
guidance
type
stuff,
so
we
could
put
something
underneath
there,
which
is
like
working
with
primordials
or
that's.
My
first
guess.
Unless
somebody
has
a
better
suggestion.
A
B
C
I
it's,
it
has
not
been
raised
to
v8
and
I
think
we
didn't
understand
exactly.
We
understand
the
ones
that
were
more
problematic.
For
example,
array
prototype
push
those
ones,
I
think,
michael
you
have
done
probably
michael
targos,
whatever
you
have
done,
probably
more
some
more
analysis
on
those,
but
I
am.
I
don't
necessarily
know
why,
like
I've,
no.
F
I
I
don't
really
know
either
we,
I
think
we
need
to
come
up
with
some
benchmark.
That
shows
the
the
difference
between
using
primordials
and
the
the
built-ins
and
open
an
issue
on
the
v8
tracker,
because
I
I
don't
remember
if
we
pinged
the
v8
team
on
those
issues
in
node,
but
from
what
I
experienced
recently,
they
don't
seem
to
be
to
be
answering
the
calls
when
we
ping.
A
A
Okay,
well,
I
guess
our
next
step
is
to
write
that
faq.
I
don't
know
robert.
If
you
know,
in
terms
of
I
guess
we
need
a
a
like
an
example
right.
B
G
A
C
But
yeah,
I
would
from
my
point
of
view,
I
would
pause
for
a
bit,
but
that
would
be
my
recommendation
genetically
if,
if
we
keep,
if
we
are
careful
in
not
landing
like
there
is
one
that
was
moved
through,
that
was
open
recently
on
events,
and
this
is
one
of
the
other
that
will.
Oh
events.
No,
don't
don't
touch
that
bit?
Okay,
you
know
it
has
a
destroying
potential
to
some
extent,
but
it
really
depends.
C
So
it's
it's
fine
to
be
honest,
so
we
can
continue
as
long
as
we
know,
this
is
happening
and
we
are
aware
of
it.
I'm
just
I
don't
have
a
good
answer.
Okay,
I
just
it's
not
great.
If
this
type
of
regressions
happen,
because
you
know
people
will
benchmark,
they
made
the
new
major
release
and
you
know
I
I
spotted
it
by
chance.
C
F
E
A
I
think
that's
a
great
idea
and
we
used
to
run
nightly
benchmarks,
but
we
don't
have
the
people
who've
been
volunteering
to
do
that
and
keep
an
eye
on
it,
and
so
it
would
be
great.
But
we
just
haven't
managed
to
be
able
to
to
have
benchmarks
running
continuously
and
tracking
the.
A
Yeah
richard
mentioned
the
benchmark:
benchmarking.nodejs.org
used
to
have
benchmarks,
but
we've
disbanded.
We
decharted
the
working
group
because
the
the
interest
kind
of
petered
out,
so
they
used
to
be
run
once
a
night
and
there
was
a
graph
generated
and
stuff
but
yeah.
It's
the
machine.
The
machine
that
they're
running
on
doesn't
exist.
We
haven't
updated
for
latest
versions.
I'd
actually
tried
to
remove
those
graphs.
I
just
didn't
get
through
the
full
process
of
getting
them,
so
they
don't
show
up.
A
Yeah
definitely
I
could
help.
You
know
somebody
that
was
interested
in
sort
of
reviving
that
you
know
the
benchmarks
that
were
run
were
sort
of
the
more
macro
benchmarks
we
had
also
looked
at
like
can
we
run
all
of
the
benchmarks,
but
it
was
you
know
we
never
got
to
the
point
where,
like
here's,
the
subset
of
the
benchmarks,
that
would
make
sense-
maybe
you
know
in
the
context
of
primordials
people
could
come
up
with,
like
here's,
a
subset
of
the
micro
benchmarks.
A
A
G
Moderation
yeah,
so
I
was
not
much
has
happened.
There
haven't
been
any
new
nominations,
so
my
intention
was
to
wait
for
the
tsc
chair
election
to
be
resolved
before
and
then
and
then
and
then
just
open
up
open
up
vote
for
tsc
and
com
com
to
recertify.
Everyone.
A
I
think.
Last
week
we
agreed
to
leave
the
meeting
time
in
place
this
week,
because
there
were
a
few
people
who
hadn't
filled
it
out.
I
think
that
a
few
I
see
a
few
more
comments
of
people
who
have
filled
it
out.
A
I'm
suggesting
we
just
ask
chalker
to
do
another
pass
of
the
the
data
review
and
then
we'll
update
to
the
suggested
times.
Does
that
make
sense?
Yes,
okay
and
we'll
try
and
do
that?
Well,
we'll
see
how
quickly
we
can
do
it,
but
if
we
can
do
it
for
next
week,
we'll
do
it
for
next
week.
A
G
Bit
now
we
we
have
11
or
12
replies
in
email
already,
so
we
we
have
enough.
Unless
anybody
here
wants
to
say,
nay
hold
up
and
have
enough
people
say
sure,
let's,
let's
wait
or
something
which
I
don't
expect
to
happen,
so
you
probably
want
to
list
out
all
the
votes
in
there.
Michael
is
that
right?
You
want
me
to
read
them
off
to
you,
so
you
can
type
them
into
the
minutes
or
is
that
not
a
good.
G
A
Why
don't
you
or
do
you
want
to
paste
them
into
the
chat
and
I'll
cut
and
paste
them
in.
G
Okay,
so
you
already
got
duresh
and
to
sorry,
tobias
in
the
in
the
chat
already
with
plus
one
and
then
from
email,
there's
other
plus
one
every
other
plus.
G
G
All
right,
hopefully
there
I
didn't
think
about
the
copy-paste-ableness
of
having
them
in
separate
chats
like
that,
but
two,
three,
four,
five,
six,
seven,
eight,
nine
ten!
We
have
eleven
twelve,
yes
votes.
I
don't
think
anybody
here
hasn't
voted
so
and
there's
19
tse
members.
So
I
think
that
that
we
can
say
that
unanimously
passed
with
seven
non-participants,
but
we
also
only
opened
the
vote
like
a
few
hours
ago.
So.
G
I'm
going
to
take
I'm
going
to
start
doing
the
various
onboarding
tests
right
now,
while
this
meeting
is
happening.
A
Sounds
good,
that's
great
because
you
know
there
was
the
other.
Just
question
was
whether
for
the
the
yarn
vote,
we
should
onboard
people
in
advance,
so
it's
great
that
we
have
and
that
becomes
annoying
great
get
thrown
into
the
fire
right
away
exactly.
A
Okay,
the
next
one
is
any
interest
in
an
rfc
process
962..
So
I
don't
know
rich.
If
there's
any.
I
know
you'd
mentioned
that
a
couple
times.
G
Let's
go
ahead
and
take
this
off
of
the
agenda.
I'm
going
to
leave
the
issue
open,
I'm
gonna
come
back
to
it
at
some
point,
but
I
just
I
I
I
just
don't
yeah
it's
gonna.
Take
me
a
couple
weeks.
So,
rather
than
have
me,
kick
it
down
the
kick
can
down
the
road
every
every
meeting?
Let's
just
take
it
off
the
agenda
and
I'll
react
when
it's
ready.
A
Okay.
The
next
issue
is
apple
silicon
plan.
This
is
866.,
I'm
thinking
we
can
take
this
off
the
agenda
since
we.
A
C
A
C
There
is
also
a
pinned
issue
on
the
main
node
repo
that
we
might
want
to
unpin
and
close
that
I'm
actually
going
to
do
that
right
now.
A
Okay,
good,
so
that's
closed,
perfect
potential
stagnation
of
open
issues
in
h1
bounty
program,
so
I've
been
working
with
snek
and
the
opengs
foundation
in
terms
of
like
finding
a
home
for
the
the
backlog
working
currently
working
on
a
blog
post,
which
would
be
would
go
along
to
sort
of
explain
how
we're
handling
that
so
that
I
think,
should
be
within
the
next
week
going
to
the
tc
that
you
know
basically
say
this
is
what
the
plan
is,
and
hopefully
we
can
get
that
closed
out,
not
too
too
much
longer.
A
A
A
F
That,
yes,
I
can
mention
that
there
are
some
issues
with
the
next
v8
version
and
I
personally
don't
know
how
to
handle
them.
So
if
someone
wants
to
take
a
look
at
the
pull
request,
I
opened
that
would
be
very
appreciated.
So.
F
Now
it's
with
linux
perf,
and
I
have
no
idea
what
this
is
so
cannot
tell
more.
F
C
A
Yep,
there's
that
that
is
true,
so
that's
not
necessarily
related
to
build
resource,
but
thank
you
very
much,
for
we
have
two
m1s
two
additional
additional
m1s
that
near
form
now.
A
Basically,
our
our
release
machine
died
like
two
days
before
our
latest
release,
so
it
was
quite
a
scramble-
and
you
know,
rod
myself
and
and
richard
and
particularly
rod
and
richard
spend
a
lot
of
time
getting
the
machine
back
up
and
running
in
time
for
our
16
release.
So
that
was
it's
a
big
thanks
that
they
managed
to
do
that
in
time,
for
it
not
to
impact
a
release.
That
was
great.
A
And
then
I
think,
that's
all
the
strategic
initiatives
that
we
have
people
here
for
so
that
takes
us
to
the
end
of
the
agenda.
Is
there
anything
else
that
we
should
talk
about
before
we
go
into
the
private
section.