►
From YouTube: 2020-02-04-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
february
4th
to
2021
we'll
follow
the
agenda,
which
was
in
the
issue
within
the
tsc
repo
number
967,
and
before
we
get
started,
do
we
have
any
announcements
that
people
would
like
to
share.
A
I
guess
one
that
I
will
share
is
that
the
2021
node.js
user
survey
is
open.
So
if
you,
you
know,
do
get
a
chance,
it
would
be
great
if
you
could
go
and
fill
that
out,
helps
us
get
some
feedback
from
how
people
are
using
node.js
and
kind
of
the
current
view
of
what's
going
on
in
the
ecosystem.
A
A
We
have
two
candidates
who
are
identified
in
the
issue
now,
and
so,
if
you
have
any
sort
of
feedback
you
can
talk
to
to
mary,
who
is
our
voting
member
and
he'll
be
and
cast?
I
guess
both
mary
and
joe,
who
are
voting
members
for
the
node.js
project,
who
will
be
casting
votes
in
that
election
and
if
that's
there
aren't
any
other
announcements.
The
next
section
cpc.
I
guess
that
kind
of
covers
the
cpc
update
that
I
had
so
we'll
move
on
to
the
issues
that
were
tagged
for
the
agenda.
A
A
A
Hello,
how
you
doing
I
think
on
that
one.
It
still
sounds
like
it's
we're
hoping
for
some
james
to
to
give
some
feedback.
A
Specific
okay,
so,
let's
move
on
to
the
next
one,
which
is
number
33864,
which
is
rename
default
branch
from
master
to
main
or
something
similar
on
that
one.
We
did
mention
last
time
that
github
has
added
some.
A
You
know
additional
support
to
make
that
easier
in
terms
of
rebasing,
prs
and
and
things
like
that,
we
recently
renamed
the
primary
branch
to
maine
for
node
add-on
api,
and
I
don't
know
gabriel,
I
don't
think
I've
seen
any
complaints
or
issues
so
far.
How
about
you
nope
all
good.
B
A
Okay,
I
know
certainly
for
the
like
the
main
github
repo
is
going
to
be.
You
know
we
need
to
be
the
most
conservative,
because
there's
there's
lots
going
on
there.
I
wonder
for
the
rest
of
the
repositories.
A
A
I
wonder
if
we
could
just
start
renaming
them
and
with
the
you
know,
the
hope
that
we
probably
won't
see
any
issues,
but
if
they
are,
you
know
in
a
lot
of
those
repos,
the
impact
would
probably
be
pretty
low
anyway.
C
A
I
guess
like,
for
example,
in
the
opengs
org
with
much
smaller
scale,
but
we
just
agreed
that,
like
let's
rename
them
and
if
there's
something
that
happens,
you
know
for
the
for
those
other
than
you
know.
There
were
no,
in
that
case
there
weren't
any
ones
like
the
the
main
node
repo,
where
we
have
to
be
much
more
careful.
So
we
just
did
it
and
actually
you
know
we
renamed
them
all.
C
Reports
which
have
high
impact
predicted
the
impact
is
going
to
be
internal
among
the
collaborators
right
either
the
script
failure
or
you
know,
confusion
of
landing,
the
prs
etcetera
there
is
no
customers
or
end
users
going
to
be
affected
by
this
change.
I'm
just
just
making.
I
mean
wondering
about
that.
A
Right,
I
guess
for
people
here
like
if
we
made
a
list
of
ones
that
we
think
we
should
be
more
careful
about
and
then
thought
well
the
rest
of
them.
People
could
just
go
in
like
I
guess
it
needs
to
be.
You
know
one
of
the
the
tsc
members,
but
one
of
us
just
went
in
and
renamed
the
others
and
if
there
was
something
unexpected
we'd
fix
that
afterwards,
if
that's
a
approach,
people
are
comfortable
with.
C
Yeah,
for
example,
I
mean
sort
the
post
based
on
the
increasing
order
of
activities
and
start
attacking
the
reports
which,
with
less
activities
and
wait
for
a
while
to
see
what
are
the
problems
which
they
are
facing.
Learn
from
that
and
then
incrementally
come
to
the
more
more
active
repose
yeah
makes
sense.
A
So
the
the
ones
I'm
just
taking
a
few
notes
like
the
working
group
repos.
I
think
we
should
ask
the
working
group
to
rename.
I
think
node
is
one.
We
need
to
be
careful
with
what
are
the
other
ones
that
come
to
people's
mind
that
we
should
kind
of
put
on
the
let's.
Let's
do
the
other
ones.
First,
like
help,
for
example
jerisha,
I
know
you're
active
there
you
know.
Is
there
any
risk
of
renaming
that
one.
C
Yeah,
I
I
can
say
with
confidence
based
on
the
number
of
pr's.
Coming
there,
it's
pretty
low,
very
low,
maybe
once.
D
A
I
will
volunteer
to
just
do
the
tsc
repo
right
after
we
finish
here.
So
that's
a
good
point.
Are
there
others
that
we
think
are
particularly
like?
I
just
want
to
have
a
list
of
these
ones?
Let's
not
do
right
away
the
rest
of
the
one
people
feel.
You
know
it's
kind
of
okay
to
say
just
go
ahead
and
do
it
and
if
there's
a
little
bit
of
a
problem,
we'll
we'll
try
and
catch
up
afterwards
kind
of
thing.
A
C
A
E
If
the
branch
protection
goals
persist
when
when
branches
are
renamed-
and
that
is
an
excellent
question,.
A
E
So
in
in
github
you
can
you
can
create
rules
for
individual
branches
that,
like
nobody,
can
force
push
to
this
branch
or
pull
requests
can't
be
merged
to
this
branch
unless,
unless
the
the,
unless
the
the
branch
being
merged
from
is
up
to
date
with
with
the
main
branch
that
kind
of
thing.
B
It
says
anything
mikhail
has
has
a
has
a
screenshot
for
us
that
shows
that
when
you
do
the
update
it,
it
puts
checkboxes
next
to
next.
Next,
to
the
the
statement
saying
we'll
update
one
branch
protection
rule
that
explicitly
targets
master,
so
it
looks
like
it
looks
like
it.
It
renames
wholesale
with
with
all
the
settings
in
place,
yep,
okay,
that.
A
Makes
sense:
where
was
that
was
that
in
it's
a
it's,
a
link
in
the
chat
right?
Okay,
I
think
I
see
it
there
right.
Yes,
that's
that's
what
I
remember
seeing.
A
Something
I
think
the
understanding
is
kind
of
like
it
should
rename
pretty
much
what
you
need,
except
for
it
doesn't
change
local
environments
like
it
said
also
things
like
github
actions
if
they
refer
to
branches,
can
run
into
trouble
and
obviously
like
it
does
redirects,
but
that
doesn't
mean
it's
changed
things
in
your
docs
and
all
that
those
are
the
kind
of
things
we've
like
for
the
note
add
on
api
one.
We
had
to
do
doc.
Doc
updates,
update
some
github
actions,
and
that
was
about
it.
A
A
A
How
how
big
an
impact
it
might
be
have-
and
I
guess
also
the
you
know
if
there's
a
if
there's
a
team
or
group
that
manages
it,
we
should
make
sure
that
they're
in
the
loop
before
we
do
something,
but
otherwise
it
seems
like
it
is
the
right
time
to
start
start
renaming
them.
A
A
A
So
yeah,
I
see
a
comment
that
yeah,
let's
discuss
the
tc
meeting
today,
to
see
there's
not
many
concerns
providing
docker
team
has
agreed
that
something
we
should
do.
So
I
think
I'll
just
remove
the
agenda
item
unless
anybody
has
concern
over
that.
A
E
A
A
Yeah
I
I
I
I
like
the
idea
of
trying
to
figure
out
how
we
have
like
the
discussions
at
a
level
like
at
a
higher
level
before
we
get
like
an
implementation
that
then
somebody's
invested
a
ton
of
time
in,
but
I
know
earlier,
efforts
haven't
figured
out
how
to
do
that
either.
Yet
so,
but
I
think
that's
probably
already
been
expressed
there
by
various.
A
Okay
sounds
good.
The
next
one
is
the
apple
silicon
plan.
886,
I'm
just
gonna
see
I'm
just
trying
to
remember
why
this
is
on
the
agenda
in
the
first
place,.
A
G
A
I
guess
you
know
even
tagging
it
as.
G
Comment
yeah
again:
it
needs
to
be
something
that
we
need
to
report
on
it's
once
and
is
if
it's
something
that
needs
to
have
somebody
owning
it
and
and
and
delivering
it
for
with
b16
v16.
So
from
my
point,
I
it
goes
to
the
point
of
it's
really
important
for
us
to
ship
it.
Okay,
it's
if
we
need
to
have
some
changes
done
before
it
needs
to
happen
before
v16
goes
lts
essentially,
and
they
need
so
v16
should
be
lts
with
it.
G
That's
my
that's
my
take
so
if
there
are
several
major
changes
that
needs
to
happen
or
whatever,
and
so
essentially
it
we
need
to
be
from
a
strategic
dash
marketing
adoption
perspective,
it's
it's
critical
because
a
lot
of
like
again
a
lot
of
developers
will
migrate
to
are
starting
to
migrate
to
the
m1s
already
and
they
are
asking
for
it.
So
it's
if
it's
too
hard
we
can
just
I
don't
know,
we
need
to
figure
out
some
ways
to.
G
F
F
There's
a
problem
in
garbage
collection
with
v8
and
apparently
many
people
are
already
using
arm
64
bills,
and
I
don't
know
why,
because
we
do
not
provide
them.
G
G
Yes,
that's
that's
the
take
yes,
yes,
that's
the
the
idea
of
it,
michael!
Yes,
absolutely
so
yeah!
That's
essentially
that's
what
I
was
trying
to
bring
up
to
the
table
and
you
did
it
probably
way
better
than
me
on
the
urgency
of
us
considering
the
aaron,
yes
electron
as
a
an
m1
version
already,
so
people
are
just
using
us
with
m1
with
the
binaries.
We
don't
support.
G
Them
is
not
on
our
supported
list
of
architectures
and
it's
people
think
it
would
just
work
as
and
as
well
as
as
it
does
so
so.
F
G
F
Have
an
m1,
I
got
one
on
monday
and
I
I
tried
to
do
my
best
to
fix
this
issue,
but
now
we,
I
cannot
do
more.
So
it's
on
the
it's
on
the
v8
side,
that
is,
it
has
to
be
fixed
and
well
they
will.
I.
G
A
G
A
So
that's
kind
of
where
I
think
we're
at
is
like
I
I
from
my
perspective.
You
know
I've
done
what
I
can
to
encourage
and
get
our
get
get
like
people
from
from
my
company
involved.
It's
moving
at
a
certain
pace.
That
pace
may
not
be
fast
enough
for
people,
but
if
it
is
then
hey
if
if
they
can
come
and
help
make
it
move
faster
great,
but
we
need
more
people
to
do
that.
G
Yeah,
that's
that's
fun!
That's
fantastic!
The
work
that
you
guys
are
doing
it's
more
to
raise
up
the
concern
of
of
of
the
situation,
not
to
complain.
G
A
G
A
I
think
like
I,
I
would
definitely
agree
with
the
we
could
use
somebody
to
sort
of
champion,
as
it
is
a
strategic
initiative
and
sort
of,
because
there's
a
bunch
of
different
pieces.
There's
like
the
build
piece
and
then
like
michael
michaels,
just
pointed
out,
there's
the
piece
about
well:
does
it
actually
compile
and
run
it
did
it?
It
did
at
one
point,
but
that
can
change
over
time
right.
G
Yeah
it's
I
I
ordered
one,
so
I
I
won't
put
my
name
forward
until
I
have.
I
have
a
device
essentially
for
obvious
reasons.
It's
it
doesn't
seem,
and
I
don't
have
contacts
with
this
anyway.
If
I
just,
I
think
we
should
leave
it
on
the
agenda
and
keep
talking
about
the
problem
yep
the
discount,
it's
not
something
that
will
show
it
on
this
call.
From
my
point
of
view.
A
G
G
Which
is
you
know
it's
it's
slightly
different.
Take
so
yeah
it's
it's!
You
know
we
had
to
lock
like
the
fact
that
we
had
to
lock.
The
thread
is
a
sign.
Okay,.
A
B
In
terms
of
what
what
what
beth
was
asking
in
the
thread
right
like
about
getting
like
m1
machines
into
the
ci
right,
correct
me
if
I'm
wrong,
but
we
get
those
machines
from
another
company
right
like
they're
they're,
just
donating.
A
Amazon
through
our
provider
they've
graciously
donated
like
we
have
some
some
of
the
the
I
forget
what
they're
called
sdks
or
whatever
we
had
some
of
the
early
early
machines,
so
they've
been
in
the
ci
for
a
little
while,
although
ash
has
spent
a
fair
amount
of
time,
you
know
having
to
sort
of
keep
them
going,
keep
keeping
re-imaged.
I
think
once
or
twice
so
that
we
could
upgrade
to
newer
versions
because,
like
the
software
stacks
on
them
is
changing
more
quickly
than
it
would
normally.
A
So
it's
it's
about
spending
enough
time
to
get
the
the
two.
I
think
you
know
I
haven't
been
tracking
it
that
close
to.
But
the
two
things
I
understand
is
one.
There
was
an
issue
in
jip
and
I
don't
know
if
that's
been
resolved
in
terms
of
you
know,
handling
multiple
platforms
when
you
build
native
add-ons
separately.
There's
the
issue
that
michael
just
pointed
out.
I
thought
that
you
know.
A
Initially,
there
were
some
pr's
that
actually
got
knowed
to
be
compiling
okay,
but
it
seems,
like
other
things,
have
come
in
and
then
separate
from
that.
There's
the
build
work
to
go
through
and
flip.
Our
you
know
change
our
build
so
that,
instead
of
building
a
you
know,
an
x86
binary
they'll
build
a
a
fat
binary
that
includes
you
know
both
x86
and
arm
in
it.
B
A
H
A
H
Didn't
exist
at
that
time,
so
I
don't
know,
I
think,
is
that.
A
A
That
that
you
know
we
like
the
fat
buyer,
the
fat
binaries
will
mean
that
the
binaries
are
bigger.
But
you
know
that's
what
we
did
before,
because
you
know
shipping
multiple
binaries
is
more
complicated
for
us,
but
not
even
that
it's
also
more
complicated
for
the
end
users,
because
now
you've
got
to
pick
and
choose
your
binary.
G
A
Yeah,
no,
that's
good,
and
I
guess
it's
like
the
the
other
thing
too,
that
we'll
probably
be
faced
with
at
some
point.
Is
you
know
I
you
know
we're
thinking
about
it
to
like
you
said
for
16.,
so
you
know
16
would
have
fat
binaries,
but
I'm
I'm
not
sure
we're
planning
to
backport
that
to
earlier
versions,
yeah.
G
It's
fine,
I
don't.
I
would
not
be.
I
from
my
point
of
view
like
looking
at
the
the
apple
releases.
Okay
apple.
Does
a
big
splash.
D
G
And
in
june,
and
a
big
splash
in
before
christmas,
so
reality
is
that
it's
if,
if
we
are
going
like
the
larger
machine,
there's
still
not
a
15
or
16
inch
laptop
on
that
lineup.
So
it's
to
be
honest.
We
should
planning
to
have
something
having
something
in
next
year
for
for
the
end
of
the
year
in
lts.
For
the
end
of
the
year
is
for
my
point
right.
G
A
Yeah,
as
as
as
bethany
just
mentioned,
the
chat
ash
we
we
only
have
dtks,
which
I
guess
are
not
the
new
ones.
I
don't
know
that
there's
any
issue
with
that,
like
they
were
the
early
hardware,
the
providers
said
that
you
know.
Of
course,
they
need
they're
getting
m
the
actual
new
hardware
as
well,
but
they
they're
gonna
give
that
to
their
customers
first,
once
once
they
get
through
that
backlog,
we'll
get
some
of
those
other
like
the
actual
new
ones.
A
A
A
A
Okay,
maybe
that's
something
beth.
We
should
follow
up
with
ash
and
we
can
ask
the
provider
if
they're
gonna
need
to
return
them
in
the
short
term
or
not.
They
may
be
a
little
bit
different
than
being.
You
know,
quite
a
large,
a
large
sort
of
source
of
those
versus
like
individuals
right,
but
either
way
I'm
we
should
probably
follow
it.
Follow
that
up
and
make
sure
if
they
do
have
to
go
back.
They'll
give
us
some
other
ones.
A
If
not,
okay,
the
node.js
security
working
group
so
potential
stagnation
that
the
one
on
the
update
on
that
one
is.
We
were
talking
to
a
couple
of
the
the
companies
that
take
reports
today
and
in
terms
of
proposal
to
take
on
the
backlog.
We've
we've
stopped
taking
on
new
reports,
but
to
take
on
the
backlog.
There
has
been
some
discussion
this
week
last
week.
A
A
Okay,
so
upcoming
meetings
or
sorry,
let's
first
of
all
look
at
strategic
initiatives.
So,
let's
pop
over
to
that,
let's
give
me
one
sec.
A
A
F
F
It's
on
on
linux,
okay,.
F
F
A
A
G
A
Okay
sounds
good,
start,
build
resources.
I
unfortunately
still
you
know.
I
don't
see
anything
happening
too
soon.
On
that
you
know
we
we
raised
the
issue,
we
ended
up
talking
to
the
board,
but
it's
been
a
tough.
I
guess
I
would
say
it's
been
a
tough
economic
time
in
terms
of
you
know,
trying
to
get
money
and
funding
and
stuff
like
that.
A
A
The
last
issue,
which
you
know
rich
you
you
mentioned
in
the
issue
itself-
that
we
can
touch
on
which
was
just
the
renaming
of
an
api
to
node
api.
A
We
did
have
a
little
bit
of
a
discussion
at
the
beginning
before
everybody
joined,
and
we
thought
it's
worth
touching.
Based
on
that
a
bit
the
discussion
we
were
having
was
a
little
bit
more
about.
How
far
do
we
go?
You
know
there
was
some
discussion
in
the
issue
itself.
In
terms
of
you
know,
do
we
just
update
the
docs
so
that
it's
you
know
any
api
was
always
node
api
in
terms
of
the
name,
it
was
just
a
short
form.
A
So
do
we
you
know
how
far
do
we
go
in
terms
of
of
changing
that?
Do
we
just
update
in
the
docs
versus
like
actually
adding
duplicate
symbols?
A
You
know,
because
we
can't
we
can't
remove
the
old
symbols,
we
could
add
new
symbols.
So
one
of
the
things
I
was
just
bringing
up
is
this
one
in
particular,
you
know
at
least
my
understanding
is.
The
association
is
not
quite
as
direct
as
some
of
the
other
cases
where
we're
changing
terminology
and
language
for
the
better.
A
So
you
know
if
we
actually
change
it
throughout
all
the
docs
and
make
it
clear.
It's
note
api,
then,
when
you
you
see
an
api
it
may
be.
It
may
be
okay,
because
you
think
that
that's
what
that
is.
B
I
I
for
one
I
for
one,
have
started
submitting
like
somber
minor
stuff,
meaning
new
node
apis
as
as
node
underscore
api,
so
that
when,
when
the
symbol
does
land,
it
lands
as
such,
like
with
node
underscore
api,
underscore,
do
something
useful.
So.
E
B
Yeah
I
mean
going
forward
going
forward,
it's
it's
clear
that
we
were
going
to
drop
an
api
underscore
in
favor
of
node
underscore
api
underscore
right
for
new
symbols.
But
the
question
is:
do
we
do
we?
You
know
hash,
define
an
api,
create
boolean
to
node
api,
create
boolean.
Do
we
go
as
far
as
that
or
or
is
it
okay
to
just
leave
it
because,
like
in
in
the
docs
where
it
says
where
you
know
where
in
english
it
says
end
dash
api,
we
can
replace
that
with
no
dash
api.
B
That's
that's
easy
enough
in
english,
but
the
question
is
about
the
code
like
do
we
provide
this
because
then
you
know:
if
we
do
provide
this,
then
then
things
get
complicated
because
you
know
an
api
underscore
version
would
have
to
have
an
alias
node,
underscore
api
underscore
version,
and
so
now
all
the
if
devs
in
the
header
file,
have
to
check
for
either
of
those
right
and
we
have
to
keep
them
in
sync
and
and
that
kind
of
thing,
so
it
gets
pretty
hairy
pretty
quickly,
depending
on
how
deep
you
go.
D
B
I'm
kind
of
doing
pr's
sort
of
piecemeal
like
for
example,
I
I
just
submitted
a
pr
for
for
doing
everything
in
the
tests.
So
that's
completely
user,
invisible
right!
It's
just
us,
but
I,
I
guess,
we'll
see
some
of
these
issues
as
as
I
put
the
pr's
forward
one
piece
at
a
time
and
then
we
we
could
rule
on
each
pr
individually,
whether
we
need
this
or
not,
but
it
would
be
good
to
have
sort
of
an
overall
direction.
A
Right,
like
basically,
the
the
symbols
would
stay
the
same
and,
like
you
were
talking
about
other
things
that
are
complicated
like
some
of
the
paths
and
stuff
like
that
right,
so
those
would
stay
the
same,
but
the
you
know
the
things
like
the
tests
that
you've
changed
you've
submitted
a
pr4
like
you
said
that
has
no
user
end
user
impact
and
helps
to
make
it
clear
what
it
stands
for
versus
anything
else.
Right.
B
A
C
C
I
think
that's
a
very
good
approach
and
the
symbols
which
are
internal
to
the
code
will
not
come
for
discussion
in
any
of
the
the
the
public
area.
So
I
think
that's
a
very
good
approach,
practical
approach,
which
we
can
do.
C
I
I'm
also
looking
at
the
issue.
420
and
personally,
I
do
not
like
the
proposals
over
there.
For
example,
the
alternatives
mentioned
about
c
api,
technically
c
api
and
s.
Api
also
have
the
same
kind
of
problems
like
capi
gives
an
impression
that
the
rest
of
the
apis
are
not
c
based
and
s.
Api,
stable
api
gives
another
impression
that
this
is
the
only
stable
api
in
the
whole
system.