►
From YouTube: 2021-10-14-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
Okay,
so
welcome
to
the
node.js
technical
steering
committee
meeting
for
october
14th
2021
we'll
follow
our
standard
agenda
which
we
have
outlined
in
the
issue,
which
was
number
eight
one.
Small
adjustment
is
I'll,
get
rich
to
go
through
cpc
updates
just
before
he
has
to
jump
off
so
rich.
Do
you
want
to
kick
kick
us
off
with
that.
B
Sure
so
the
as
you
may
or
may
not
know,
there's
the
whoops
somebody
just
okay
got
disoriented
there,
because
someone.
B
So
there's
there's
the
node.js
certification
and
training
scholarships
that
are
available.
I
don't
know
how
widely
known
this
is,
but
the
deadline's
approaching
soon
link
is
in
the
issue
tracker,
but
it's
the
you
can
search
the
internet
for
the
openjs,
blog
titled,
new
node.js
certification
and
training
scholarship,
but
basically
you
know
for
people
who
want
to
get
node
certified
and
can't
afford
it.
This
is
a
way
you
can
get
some
help,
so
deadlines
coming
soon,
though
so
get
on
that
quickly.
B
Please
and
get
the
word
out.
If
you
know
people
who
might
benefit
from
this,
the
node.js
community
committee
has
been
retired
as
as,
hopefully
everybody
here
knows.
But
if
you
don't
know
now,
you
do
and
changes
are
still
in
progress.
We're
still.
You
know,
trying
to
figure
out
what
to
do
with
the
admin,
repo
and
updating,
docs
everywhere
and
figuring
out
governance
stuff.
Oh
communicating
committee
used
to
have
to
approve
this.
What
do
we
do
now
stuff
like
that?
B
Still
working
it
out,
but
the
community
committee
has
been
retired
and,
lastly,
there's
a
charter
change
that
I
have
proposed
to
simplify
the
automated
process
of
removing
people
who
are
inactive
from
the
tsc,
because
we
are
very
bad
about
removing
them
intentionally.
So
we
have
an
automated
process,
but
the
process
is
kind
of
broken,
so
I'm
trying
to
fix
it
there's
an
issue
in
the
tfc
repo.
I
think
it's
on
the
agenda
today.
It's
one
zero,
nine,
seven.
It
is
overwhelmingly
approved
by
by
tsc
members.
B
As
far
as
I
can
tell
based
on
the
plus
ones
and
the
emoji
reactions
cpc
has
to
approve
a
charter
change,
though
the
core,
the
cross
project
committee,
that
I'm
talking
about
right
now
and
their
process
involves
the
charter.
Change
has
to
stay
open
for
two
weeks
to
give
cpc
members
a
chance
to
review
it
and
possibly
object.
I
don't
anticipate
that
happening.
Everybody
on
the
cpc
who's
weighed
in
so
far
is
somewhere
between
very
much
in
favor
and
and
extremely
enthusiastic.
B
So
so
yeah,
that's
my
cpc
long-winded
update
thanks
for
putting
up
with
my
rambling.
A
If
not,
I
don't
have
any
board
updates
in
terms
of
anything
going
on
on
that
front.
As
always,
if
you
have
anything
that
you
think
I
should
take
to
the
board
or
whatever,
let
me
know
we'll
flip
back
to
announcements.
So
you
know
rich
did
mention
that
the
community
committee
has
been
retired
and
we're
shuffling
around
some
of
the
governance
to
cover
that
as
well.
As
you
know,
working
on
how
the
existing
teams
and
work
groups,
you
know
end
up
getting
integrated
and
documented
any
other
announcements
that
people
want
to
share.
C
Yep,
we
should
probably
announce
that
note.
17
will
be
released
next
tuesday.
The
next
few
days
should
be
picking
up.
The
last
few
commits
that
will
land
and
also
trying
to
source
crowdsource
notable
changes,
so
I've
just
pasted
a
link
for
the
change
log.
C
So
if
anyone
on
the
tse
has
any
suggestions
for
what
to
incorporate
into
the
notable
changes,
please
suggest
them
on
there
and
also
we're
working
as
usual,
with
the
openjs
foundation,
to
put
out
the
formal
release,
announcement
and
I'll
paste
a
link
to
that
into
there
too,
for
people
to
review
all
of
them
work
in
progress
as
we're
we're
still
finalizing.
The
last
few
commits.
A
Okay,
so
that's
good
any
other
announcements
before
we
move
on
to
looking
at
the
issues
that
were
tagged
for
the
agenda.
A
If
not,
okay,
let's
move
on
then
so.
The
first
issue
that
was
tagged
was
document
considerations
for
inclusion
in
core
that
one
I
believe
you
know
rich
mentioned
that
he's.
You
know.
There's
some
discussion.
Discussion
is
going
on
in
the
issue
itself.
There's
been
some
comments
and
his
he's
got
the
action
to
update
those
comments.
But
you
know
the
progression
basically
is
progressing
to
refine
and
incorporate
those
comments.
A
If
not
the
next
one
on
the
agenda
is
doc,
add
initial
list
of
technical
priorities,
40235,
that's
one
where
there
there
has
been
some
ongoing
discussions
still
would
be
great.
If
we
had
a
few
more
people,
you
know
making
sure
that
they've
reviewed
it
make
sure
that
you
know
it
aligns
with
what
the
tsc
thinks
is
important,
as
well,
so
just
on
the
agenda
for
awareness,
and
you
know
to
give
a
spot
if
anybody
has
any
questions
or
anything
that
they
want
to
bring
out
outside
of
the
github
issue
itself.
A
Okay,
if
not,
we
might
as
well
move
on
to
the
next
issue,
which
is
replace
openssl
1.1.1
with
openssl
3.0.0
that
one.
Actually,
you
know
since
this
the
agenda
was
was
created,
the
prt
landed,
so
I
the
issue
is
closed.
I
did
note
nothing
to
discuss.
Although
I've
seen
that
there
there
have
been
some
issues
reported,
I
know
targos.
You
were
looking
at
some
of
those
and
I
thought
maybe
we
could
spend
a
minute
or
two
talking
about
that.
A
I
didn't
get
your
question.
Sorry
I
I
was
just
we
were
on
the
we
were
on
the
issue,
which
was
which
was
replacing
openssl
1.1.1
with
openssl
3.,
and
I
noted
that
the
issue
was
already
closed
and
landed,
but
I
know
I
know
that
you
had
commented
that
there's
been
some
issues
seen
and
I
wondered
if
we
should
spend
any
time
talking
about
that
or
we
think
those
will
just
work
themselves
out
before
the
release.
D
A
Yeah,
I
think
my
quick
read
was
that
was
related
to
you
know.
Open
ssl
by
default
doesn't
enable
some
of
the
legacy
like
some
older,
weaker
algorithms,
and
I
know
dan
is
going
to
look
at
how
we
can
you
know
re-enable
those
or
like
there's
a
command
line,
option
which
you
can
enable.
I
think
there
should
be
something
where
you
can
re-enable
the
the
legacy
provider
that
would
provide
those,
but
I'm
wondering
if
we
need
to
have
like
a
contingency
plan
that
says
you
know.
E
I
I
guess
the
question:
is
we
don't
know
how
widespread
the
problem
is
going
to
be
for
the
particular
things
that
as
claire
and
the
gold
mine
were
flagging
up,
we
think
web
pack
can
specify
a
non.
You
know
an
alternate
hashing
algorithm,
which
would
be
a
workaround,
but
it
will
mean
that
anyone,
depending
on
the
default
for
I
think,
webpack
four.
E
I
think
webpack
five-
has
changed
the
default,
but
webpack
four,
I
think
defaults
to
md4,
which
currently
node
doesn't
provide
because
we
don't
load
the
legacy
crypto
provider.
So
there
is
a
sort
of
work
around
which
we
could,
I
guess,
put
in
the
notable
changes
as
as
a
sort
of.
E
You
know,
I
guess
it's
a
tricky
balancing
one,
because
it
is
assembler
majors,
so
some
breakage
is
possible,
but
it's
the
extent
to
which
that
breakage
occurs.
I
think
it
doesn't
really
do
anyone
any
favors
to
stay
on
openstack
111
for
node
17..
You
know
if
we
hadn't
actually
put
this
into
node
17.
We
wouldn't
have
even
found
this
so.
A
E
Yeah,
so
I
I
know
dan's
looking
at
I,
I
guess
one
of
the
things
we
don't
know
yet
is:
if
providers
are
loadable
in
the
way
that
we
compile
openness
cell
into
notes,
so
we
have
traditionally
statically
linked
openssl
into
node,
but
openssls
re-architecture
to
use
providers
is
all
built
around
this
idea
that
you
could
dynamically
load
providers
at
runtime,
which
kind
of
implies
that
you
wouldn't
be
statically
linked.
E
So
that's
something
we
would
possibly
need
to
look
at
if,
if
include,
if
the
possibility
of
including
those
legacy
providers
is
something
we
think
we
should
be
doing
it's,
it's
almost
also
a
security
question
as
to
you
know
right
how
much
do
we
want
to
support
things
that
aren't
default
and
it's
really
about
the
sort
of
configuration
because,
for
example,
one
of
the
reasons
we
were
going
to
open
soul
3
is
the
fip
support,
but
I
mean
flips
for
a
long
time
has
disallowed
certain
algorithms,
so
you
have.
E
Set
yeah
exactly
so
it's
hard
for
the
ecosystem.
In
that
really
you
shouldn't,
you
should
be
querying
for
available
algorithms,
and
you
know
catering
for
them,
possibly
not
being
there.
For
example,
you
know
someone
else
could
compile
a
version
of
node
and
decide
to
exclude
or
include
algorithms,
depending
on
what
compile
options
you
pass
into
open,
ssl
or
you
know,
even
if
you're,
using
something
other
than
openness
cell-
that's
compatible.
E
It's
not
something!
You
can
really
assume
that
you
are
going
to
have
certain
algorithms
present
in
in
your
runtime.
So
it's
a
bit
of
a
tricky
one,
balancing
how
it
should
work
with
what
is
the
ecosystem's
expectations
and
how
much
brokerage
do
we
think
we
can
tolerate
and
whether
it
really
is
breakage
or
if
it's
a
no.
If
you
update
these
things,
then
you
know
you'll
be
fine,
but.
A
Right,
okay,
I
I
guess
the
question
is:
would
anybody
I
think,
like
from
what
from
what
I
can
hear
from
what
you're
saying
richard
is
it's
it's
kind
of
like
yeah?
It
is
december
major.
I
know
we
try
and
minimize
breakage
but
like
this
is
going
to
happen
sometime
right
and
so
it's
I
unless
we
think
that
it's
going
to
be
so
bad
that
it
doesn't
make
any
sense
that
you
know,
I
think
getting
the
feedback
sooner
than
later
makes
sense
to
me.
A
C
It's
going
to
know
that
considering
we
only
have
like
one
working
day
before
the
release
needs
to
be
built
and
shipped.
I
don't
think
backing
it
out.
Now
is
an
option
like
picking
up
a
couple
of
additional
commits
and
refining
notable
changes
to
inform
people
with
the
impact
is
much
easier
to
do
than
to
revert
a
large
number.
Well,
a
very
large
commit
do
some
very
intensive,
rebuilds
research
him.
So
I
I'd
be
concerned
about
backing
out.
I
don't
think
we
can
at
this
point.
F
I
mean
I
think
about
also
it
might
also
be
difficult
later,
since
the
deadline
for
openms
l1
is,
I
don't
know
before
the
deadline
for
note,
16
and
probably
also
before
the
deadline.
Sorry,
the
end
of
support
for
note
17
we'll
have
to
switch
at
some
point
and
the
switch
is
probably
going
to
be
somewhere
major,
so
breaking
change.
A
So
it
sounds
like
everybody's
comfortable
with
you
know,
proceeding,
although
we
know
this
may
cause
some
some
some
some
issues
in
the
ecosystem.
We
may
want
to
include
something
that
says
you
know.
We
know
this
is
happening
and
we're
looking
at
what
possible
mitigations
there
are
when
17
goes
out,
since
we're
very
close
that
that
makes
sense
to
everybody.
Oh,
I
see
the
mpm
test.
Suite
is
breaking
on
it.
E
F
A
Okay,
so
I
guess
I
I'm
not
hearing
any
strong
like
we
should
change
course.
I
just
wanted
to
sort
of
bring
that
up
and
make
sure
we
we
we're
all
aware,
because
that
there
may
be
some.
I
think
we
should
almost
be
going
out
with
hey.
We
know
this
is
happening
and
we're
doing
some
we're
looking
at
what
we
can
we
can
do,
but
we
feel
17
is
the
better
place
to
try
it
out
than
18.
Is
the
can
be
the
message?
A
Because,
as
tobias
mentioned,
we
we
have
a.
We
have
an
end
date
for
sure
for
18.
It's
it's
gonna
like
we
have
no
choice,
because
18
will
definitely
be
out
you're
right
about
16
17.
I
think
we've
got
six
months,
it's
only
six
months,
so
it
might
squeeze
under,
but.
A
Okay
and
then
maybe
we'll
loop
back
tomorrow,
just
to
see
once
he
gets
back.
Let's
move
on
to
the
next
issue,
which
is
rename
default
branch
from
master
domain,
which
is
33
864..
A
This
is
we've
moved
a
few
more
issues,
a
few
more
repos
over.
There
is
an
issue.
There
was
actually
the
first
dish,
the
first
problem
reportable,
which
was
unreadable
stream
and
it
was
related
to
there
were
some
modules,
basically
pointing
to
readable
stream
through
git,
directly
to
master
and
and
github
wasn't
redirecting
downloading
the
targe
zip.
So
we've
opened
an
issue
and
are
hoping
that
that
that'll
be
resolved
as
well,
but
I
just
thought
it
was
interesting
to
note.
G
So
last
week
we
heard
jordan
and
bradley
presenting
their
ideas
their
arguments
about
what
should
be
the
course
of
action
on
primordials.
G
Basically,
the
bottom
line
of
their
presentation
is
yes
for
primordials
and
yes
for
implementing
them
those
partially
attacking
things
on
a
case
basis,
mostly
true,
with
the
bringing
robustness
to
the
core
around
the
module,
loading
and
related
areas,
bringing
integrity
and
robustness
to
that
part
of
the
code.
So
that
was
that's
that's
what
I
understood
as
the
main
proponents
on
on
that
argument.
G
G
H
So
there
was
definitely
the
argument
of
moving
some
of
this
code
to
the
c
plus
dot
layer,
so
that
we
do
not
have
to
use
primordials
in
the
first
place
and,
and
that
might
still
be
an
option
for
some
of
the
code.
H
We
did
not
really
look
at
what
the
code
would
have
to
change
in
case.
We
only
look
at
and
the
loader
because,
as
you
just
thought,
and
that's
pretty
much
what
they
suggested.
It
is
also
going
to
be
an
issue
about
how
fast
things
load
or
not.
We
had
like
a
lot
of
optimizations
and
done
so
that
we
are
able
to
load
some
code
fast
in
the
beginning,
like
especially
for
for
cold
boot.
H
That's
something
that
mateo
brought
up
last
time
as
well,
and
we
could
just
I
I
guess
it's
going
to
be.
Is
it
going
to
come
down
to
a
vote
at
some
point,
and
we
should
just
then
outline
all
the
different
opportunities,
but
and
before
we
can
do
that,
we
should
document
what
part
we
really
consider
necessary
to
to
be
either
moved
to
the
c
plus
layer
or
using
primordial.
H
G
The
issue
is
a
public
issue
in
the
core
repo.
I
guess
we
are
talking
about
a
thc
voting
here.
G
A
You
know
if
we
had
the
here
are
the
options,
and
then
you
know
that's
where
we
need
to
get
to.
I
think
robin
was
sorry.
Ruben
was
suggesting
you
know.
One
of
the
options
is,
you
know,
can
limit
the
applicability
to
to
primordials
or
an
equivalent
to
just
you
know
a
b
c
and
d,
but
we'd
need
to
define
what
that
a
b,
c
and
d
is,
and
I
think
reuben
you're
suggesting
we
could
basically
say
like
whoever
wants
to
add
something
to
that
list
needs
to
do
so
by
date,
x,
right.
H
I
would
say:
let's
give
it
two
weeks
up
until
yes,
so
two
more
tsc
meetings
until
the
update.
H
A
A
Okay,
any
anything
more
on
that
before
we
move
on
to
the
next
issue,.
A
A
Okay,
so
the
next
one
is
nominating
richard
lau,
there's
an
issue
there
and
we've
invited
richard
as
a
guest
this
week
you
know,
I
think
I
think
there
is
equivalent
to
the
you
know
that
we've
got
lots
of
plus
ones.
I'd
have
to
go
back
and
look
at
our
governance.
If,
like
we
need
more
than
this
issue
as
the
the
confirmation,
but
I
think
it
seems
like
that's
progressing
well
so
and
thanks
richard
for
for
joining
this
time
and
joining
in
the
discussion.
A
A
And
I
think
we'd
already
talked
about
that
rich
already
mentioned
that
one
as
well.
That
he's,
I
guess.
Well,
it's
related
to
40338.
I
think,
unless
I'm
reading
that
wrong.
No,
I
think
that
is
related,
so
so
the
produce
progressing
in
the
pr
I'm
pressing
in
pr.
A
A
I
just
wanted
to
make
sure
we
had
your
input
from
the
npm
perspective
that
it
seems
like
from
the
you
know
our
discussion.
We
believe
the
best
path.
Of
course,
pat
the
fir
the
best
path
forward
is
still
to
leave
openssl
3,
because
you
know
we're
going
to
have
to
take
that
breaking
change
at
some
point
and
it's
better
in
17
than
18,
but
when
it
was
mentioned
that
one
of
the
npm
test
suites
is
failing.
So
I
just
thought
I'd
give
you
an
opportunity
to
comment
if
you
had
any
additional
thoughts.
I
I
was
not
aware,
I
was
not
aware
that
there
were
new
failures
related
to
openssl
at
npm.
I
was
under
the
impression
that
there
were
like
some
internal
tests
based
on
snapshots
that
just
didn't
get
updated
properly,
that
we
needed
to
fix.
Are
there
other
test
failures
that
seem
to
be
related
directly
to
openssl.
E
Yeah
mild,
we
we
noticed
in
citrium
that
it's
not
just
npm.
There
are
some
other
modules,
but
there's
openssl
has
moved
some
of
the
less
secure
algorithms
into
a
legacy
provider
that
we
are
currently
not
loading
in
node.
So
there
seems
to
be
a
few
modules
out
there
that
are
using
md4
to
create
hashes
for
things
like
caches,
yeah.
A
E
At
the
moment,
that's
that
algorithm
is
no
longer
available,
so
the
tests
are
using.
Those
are
failing.
That
seems
to
be
what
we're
seeing
in
citrium.
So
npm
is
one
of
the
citric
modules,
which
is
failing
because
of
this
I
don't
know
how
far
down
the
dependency
tree,
it
is
or
whether
it's
a
test
test
only
issue,
but
we've
only
noticed
it
recently
because
we've
only
recently
merged
the
openness
sl3
pr
into
node,
so
yeah,
and
this.
I
I
I
mean
like
it's
the
only
way
we're
going
to
find
out
the
weird
edge
cases,
and
I
guess
if
one
of
you
could
send
me
the
sitkin
results
or
if
there
is
like
any
issues
or
anything
that
they
could
share
with
the
npm
team.
We
could
start
doing
our
own
evaluations
internally
and
and
like
to
be
honest
having
it
in
17
and
having
17
published,
actually
will
make
it
easier
for
us
to
like
do
that.
I
Work
like
I
can
get
people
rc's
and
stuff,
and
we
can
work
off
of
that,
but
in
general
I
don't.
I
don't
think
that
this
should
be
a
blocker.
Also,
we
do
have
precedent
and
I
don't
I'm
not
saying
that
this
is
what
we
should
do,
but
if
we
have
to,
we
can
revert
it
after
we
cut
17.
I
If
we
find
that,
like
these,
things
could
not
be
fixed
or
we've
made
changes
that
aren't
able
to
be
to
be
dealt
with,
and
I
know
beth,
you
were
saying
it's
like
a
lot
of
work
right
now
to
revert
it
in
time
for
like
the
release.
I
A
A
Okay,
so
let's
move
on
then
to
the
strategic
initiatives
so
I'll
start
with
v8
currency,
since
I
know
michael's
already
added
something
there
so
I'll.
Let
you
talk
about
that.
D
A
Okay,
let
me
just
pull
up
the
list
of
strategic
initiatives,
then
to
see
if
we
have
anybody
else,
just
speak
to
any
of
the
other
ones,
antoine
anything
on
core
promises.
This
week.
K
A
I'm
just
looking
at
that's
all
the
people
we
have
from
the
strategic
initiative,
so
I
think
that
takes
us
to
the
end
of
the
agenda.
If
all
the
tse
members
can
can
stick
around
for
a
private
session,
that
would
be
great
and
everybody
who's
been
watching.
Thank
you
for
taking
the.