►
From YouTube: 2020-02-25-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
Week,
okay,
it
sounds
sounds
like
not
so
cpc
and
board
meeting
updates
on
the
board
front.
There
is
a
board
meeting
this
week,
so
if
anybody
has
anything
that
they
think
I
should
be
bringing
up
to
the
board,
let
me
know
I
don't
have
anything
currently
on
my
list
in
terms
of
cpc
updates,
just
thinking,
if
there's
anything
key
since
mary
isn't
isn't
here
today.
A
I
don't
think
there's
anything
in
particular,
except
that
it
is
worth
mentioning
that
email
thread
about
some.
You
know
some
reach
out
from
the
openjs
foundation.
In
terms
of
you
know
what
the
standards
team
is
doing,
they're
evaluating
some
different
options
of
what
they
would
focus
on
and
they'd
really
like
some
feedback.
I've
been
in
a
few
meetings
with
some
of
the
other
project
tscs,
and
you
know
it's
interesting
to
kind
of
to
get
that
feedback.
A
So
if
you
can
find
that
email
thread
and
sort
of
respond,
if
you
are
interested
I'll
be
looking
to
set
that
up
in
the
nearer,
you
know,
maybe
I
should
wait
till
the
end
of
this
week
and
then
actually
go
ahead
and
set
something
up.
So
if
you
can
respond
and
look
for
that,
that
would
be
great
and
I
see
that
mary
just
joined
us.
So
maybe
we'll
give
her
a
minute
to
see
if
she's
got
anything
else
on
the
cpc
front
to
highlight.
A
Okay,
so
let's
move
on
to
the
issues
which
are
tagged
for
the
agenda,
then
the
first
one
is
37.
308
doc
update
ci
requirements
for
landing,
pull
requests.
That's
number
37308.
A
I
don't
know
if
anybody
here
has
been
in
that
discussion.
Let's
see
who
put
it
on
the
agenda,
so
I
guess
it
was
added
by
antoine
duhamel
and
I'm
just
seeing
if
anybody
if
anybody
has
commented.
C
I
don't
know
if
this
needs
to
be
on
the
agenda.
To
be
honest,.
C
A
Okay,
so
it's
already
got
the
cpc
approvals
that
it
needs
right,
yeah
and
I
I
think
in
the
end
this
one
basically.
A
Just
documents
that
you
don't
need
to
run
the
ci
like
a
full
ci.
If
there's
you
know
which
directories
we
consider
not
to
be
touched
by,
you
know
basically
running
the
ci
isn't
going
to
help.
Anyway,
I
think
is
the
the
point.
D
It
does
change
something.
Actually,
it
changes
the
fact
that
now,
with
this
change,
we
need
a
green
github
action
ci
to
land,
something.
D
Well
recently,
there
was
a
problem
with
the
asan
job,
which
was
failing,
I
think,
100
of
the
time,
and
that
was
introduced
by
a
pull
request.
So
with
this
requirement
we
would
not
have
had
this
issue.
C
C
Sir,
can
we
promote
cbs.
A
A
A
A
A
We're
talking
about
the
updating,
the
ci
requirements,
pull
request,
it's
this
one.
The
main
difference
that
we
were
discussing
was
that
it
has
the
requirement
for
the
github
actions
to
be
green.
A
G
I
guess
like
just
one
question
that
I
have
there
is,
I
believe-
and
you
can
correct
me
if
I'm
wrong,
the
actions
are
just
running
our
existing
test
suite.
So
if
we
have
things
marked
as
flaky
they're
not
and
they
fail,
github
ci
will
still
be
green.
It's
not
going
to
show
yellow
like
we
do
in
jenkins,
but
we'll
catch
that
in
jenkins.
So
that
would
be
the
only
thing
that
I
would
flag
on
and
I
don't
think
it's
an
issue,
but
as
long
as
flaky
tests
are
respected,
then
I'm
plus
one
on
this.
G
It
can
be
an
issue,
and
maybe
this
is
something
I
can
follow
up
internally
with
github
to
see
if
it
can
get
higher
powered
machines
is
sometimes
and
I've
seen
this
with
the
mac
machines,
for
example,
they
just
take
a
really
really
long
time
and
they
can
time
out,
and
then
you
have
to
run
it
again
and
so
in
general,
it's
just
really
frustrating
when
you're
trying
to
get
something
landed,
and
you
know
that
it's
good,
but
the
problems
that
you're
running
into
are
infrastructural,
but
I
think
we
can
revisit
that
if
this
becomes
an
issue.
A
A
G
G
A
I'm
going
to
remove
the
agenda
tag
and
basically
it
looks
like
it's
walnut's
way
to
land.
It
doesn't
need
any
more
discussion
here.
Okay,
the
next
one.
The
next
issue
is
deps,
add
yarn
to
one
dot,
yarn
1.2.
A
So
I
think
it's
up
to
us
to
decide
what
the
next
step
is.
You
know
do
we,
how
do
we
want
to
progress
in
terms
of
like
coming
to
an
answer
to
that
you
know:
do
we
schedule
a
vote?
Do
we
do
whatever?
So
I
don't
know
what
people's
thoughts.
A
A
A
I
shouldn't
say:
wouldn't
change
my
mind
but,
like
you
know,
the
the
more
discussion
would
effectively
be
the
rest
of
the
tse
or
or
significant
portion
of
the
tc
members
expressing
support
for
it
and
then
I'd
say:
okay,
that's
that's
what
I
was
looking
for
right,
but
that's
effectively,
you
know
forcing
a
vote.
I
guess
anyway,.
A
G
I
I'm
treading
lately
here,
because
I
I
and
I
also
have
not
decided
that
I
may
abstain
from
voting
just
because
of
the
conflict
of
interest
with
npm,
but
the
one
thing
that
I
I
do
think
that
we
should
be
on
the
same
page
about
prior
to
a
vote.
Is
we've
had
the
ongoing
discussion
about,
like
the
package
manager
manager
and
the
binary
manager
summit
that
we
did
and
like
I
recognize
that
there
needs
to
be
work
there
to
move
that
forward.
G
But
I
think
that,
coupled
to
the
vote
to
include
this,
if
we
do,
it
needs
to
be
a
decision
about
those
other
two
things,
because
to
me
it
wouldn't
make
sense
to
include
yarn
directly
in
the
tree
if
the
package
manager
manager
is
also
coming
or
the
binary
manager
is
also
coming
now.
I
recognize
that
this
creates
a
scenario
where,
like
we
basically
have
all
the
stop
energy,
because
the
things
that
we're
talking
about
building
are
really
big
and
we
don't
necessarily
have
people
driving
it,
so
I'm
not
advocating
for
any
particular
approach.
G
Or
at
the
very
least
like
if
we
vote
and
we
vote
to
include
yarn,
we
should
be
like
making
it
clear
that
the
other
two
initiatives
are
likely
not
moving
forward,
or
at
least
the
package
manager
manager.
The
binary
management
thing
I
think,
can
still
work,
even
if
yarn
is
in
the
tree,
because
we're
still
talking
about
managing
npm
with
it.
G
It
just
would
change
the
scope,
but
I
just
think
we
need
to
be
clear
about
what
the
future
of
these
other
initiatives
are,
because
to
me
at
least
this
feels
like-
and
I
don't
I
haven't-
had
a
chance
to
speak
to
mail
one
to
one
but
like
he
was
pushing
for
pmm,
I'm
not
sure
if
he
was
doing
that
because
we
couldn't
like
I
know
at
first.
They
didn't
want
to
just
vendor
in
yarn.
G
So
I
think
that
may
even
be
a
preferred
solution,
but
we
just
need
to
kind
of
settle
all
those
at
once.
A
B
Probably
before
we
vote
on
this,
we
should
bring
the
pr
out
or
to
a
meeting
to
argue
in
favor
of
it.
B
A
G
We
did
do
a
big
kind
of
like
ecosystem-wide
surveys
for
stuff,
like
the
promise
like
unhandled
rejection
errors
and
other
big
changes
that
we
were
going
to
do.
A
I
think
equally,
though,
there's
the
research
related
to
you
know
additional,
like
the
eat,
the
the
collaborators
right,
because
it's
it's
basically
pulling
in
another
thing
and
at
least
for
me
part
of
the
concern,
is
it's
another
thing
to
maintain.
A
You
know
more
security
vulnerabilities,
more
whatever,
so
it's
it's
yeah.
We
could
definitely
use
more
data
from
the
the
community
from
our
own
collaborators.
There's
lots
of
other
discussions
that
we're
starting
are
going
on
on
that
front.
G
I
guess
the
reason
I
asked
that
is,
and
I'm
not
trying
to
lead
it
here,
but
the
promise
of
the
value
of
this
is
for
developers
and
users
like.
That
is
the
reason
why
mail
is
pushing
for
this
right.
It's
like
it's
extra
work
for
developers
to
have
to
install
yarn
separately
from
node,
and
so
that's
where
I
feel
like
doing.
G
Research
like
this
would
would
be
useful
if
we
can
do
some
wide
asking
is
like
we
have
our
own
concerns
from
a
maintainer's
perspective,
but
that
doesn't
really
jive
with
with
like
the
premise
of
why
this
is
a
positive
change.
It's
like
potentially
reasons
not
to
do
it,
but
I
think
that
that,
like
some
research
to
prove
like
the
premise
of
the
change,
could
be
useful
in
helping
us
make
a
decision.
A
Like
it's,
I
I
kind
of
wonder
like,
should
we
be
just
saying
you
know
we're
not
going
to
make
a
decision
until
we
get
more
info?
I
guess
that's
perfectly
valid.
The
other
thing
could
be
just
say.
Actually
our
decision
is
no.
Until
there
is
this
additional
information
right,
which
is
effectively
what
we're
saying,
if
we
just
say,
don't
we're
not
going
to
make
a
decision
until
there's
more
info.
G
I,
I
guess
I'll
frame
it
slightly
differently.
I
think
similar
to
some
of
the
things
that
we
try
to
do
around
performance
right.
Like
it's
easy
to
say
this
will
affect
performance,
and
we
shouldn't
do
this,
but
we've
been
trying
to
put
the
onus
on
the
people
who
are
bringing
those
objections
to
do
the
work
to
to
kind
of
prove
that
it
will
indeed
be
a
performance
problem.
G
We
as
a
project
and
as
a
foundation,
have
the
resources
to
do
this
kind
of
research
that
may
all
may
not,
and
so
I
feel
like
the
onus
is
on
us
and
we
could
say
no
from
like
a
maintenance
standpoint,
but
I
feel
like
if
we
like,
if
we
were
to
make
a
decision
either.
Yes
or
no
doing
a
survey
like
this
to
see
what
our
community,
how
our
community
feels.
G
B
I
think
yes,
as
long
as
we
enumerate
what
those
things
are
otherwise
for
the
out
there.
It's
an
indefinite
await.
G
G
A
B
B
B
I
think
it
should
be
used
the
same
way
we
did
with
the
promises
survey,
it
doesn't
decide
for
us,
but
it
helps
us.
A
B
A
A
G
H
G
G
I
think
I
think,
as
I
mentioned,
I
will
likely
abstain
from
the
actual
vote
in
decision
making
because
of
a
conflict
of
interest.
G
I
think
that
confirming
that
at
least
will
will
help
with
making
the
reason
for
the
decision
clear.
You
know
a
lot
of
the
reasons
to
not
include
it.
I
think,
come
down
to
like
process
and
technical,
so
I
think
that
there
still
are
hanging
questions
especially
around
like
how
do
we
decide
which
ones
to
include?
Do
we
include
pn
pm?
A
G
A
G
E
A
It
sounds
like
the
the
proposal
seems
to
be
that
we
should
we
shouldn't
necessarily
move
to
a
vote,
yet.
Instead
we
should
try
and
get
a
survey
out
there,
and
you
know
the
next
step
is
to
find
a
volunteer.
Who
would
who
would
lead
that
survey
to
gather
more
data
to
help
us
make
to
be
able
to
make
an
informed
decision.
A
Does
that
reflect
what
people
are.
A
No,
no
objections
to
that
everybody's
I'll.
Take
silence
as
like
agreeing
that's.
I
see
at
least
one
one
head
nodding.
So,
okay,
so
we'll
say
that
that's
the
case
and
we're
kind
of
currently
blocked
on
finding
if
we
can
get
a
get
a
volunteer
I'll
leave
it
on
the
agenda,
we'll
see
if
any
of
the
tc
members
who
aren't
here
or
volunteer
to
do
that
or
anybody,
I
guess
there
could
be
other
people
in
the
community
as
well.
A
Otherwise,
we'll
talk
about
it
next
time
as
well,
anything
more.
We
should
talk
about
on
this
one
before
we
move
on
to
the
next
issue.
A
E
J
A
I
I
think
that
the
assertion
was
that,
like
we,
we
probably
understand
the
ex
that
there's
going
to
be
extra
work
and
we
have
potential
for
extra
security
security
vulnerabilities,
but
that
if
it's
gonna
be
super
super
valuable
to
our
end
users,
then
that's
fine.
We
should
take
on
that
extra
work
right
and
there's
been
there's.
I
think
the
point
was:
is
that
there's
an
assertion
that
that's
the
case
but
but
perhaps
we
don't
have
enough.
You
know
information
to
confirm
that.
A
Okay,
yeah,
I
see
the
the
additional
point
miles.
Is
you
know?
That's
actually
true
too:
it's
like
bringing
in
1.0,
that's
not
actively
maintained.
You
know
that's
kind
of
where
I
was
back
to
like.
If
we
got
the
results
from
that
survey,
would
it
basically
I
just
wanted
to
validate
that
it
would
actually
change.
A
A
We
can
kind
of
talk
about
that
as
we
craft
the
I
guess,
as
we
craft
the
survey
you
know,
we
should
make
sure
that
it's
gathering
all
the
info
and
or
these
other
things
I
just
I
just
want
to
make
sure
that
if
we
actually
do
block
on
a
survey,
there's
enough
there's
an
there
aren't
some
other
issues
which
you
know
once
that
comes
back
and
it's
like
then
we're
like.
Well,
it's
just
a
no
because
of
this
other
reason
or
something
right,
because
then
we
should
discuss
that
other.
Those
other
reasons.
First.
A
A
A
So
I
think
antoine
added
this
one
as
well.
It
was
on
the
agenda
for
visibility.
A
A
D
D
It
was
added
in
in
a
minor
during
lts.
I
think
yes,
but
I
don't
know
how
new
it
is.
A
Right
or
I
think
at
very
least,
it
became
non-experimental.
Quite
recently,
it's
kind
of
like
we'd
agreed
with
well
we'll
make
it
non-experimental,
but
then
we're
going
to
deprecate
and
move
to
this
other
approach
so
the
longer
it's
there
that
could
be
a
sort
of
flip
side
of
another.
You
know
another
factor
into
whether
you
want
to
do
it
sooner
or.
A
Any
other
discussion
comments
that
we
should
have
before
moving
on.
I
think
the
the
ask
would
be
like
please
review
comment,
and
then
you
know
we'll
leave
it
on
the
agenda
to
see
if
it's
gotten
or
not
the
approvals
it
needs
next
week.
A
A
E
A
A
A
A
A
A
A
A
A
I
think
this
is
really
on
the
list
for
us
to
keep
attention
on
it.
A
A
I
think
at
this
point
it's
really
just
a
matter
of
people
going
through
and
and
well
it's
figuring
out
our
strategy
for
getting
people
to
go
through
and
actually
do
the
renames.
I
suspect
we
want
to
do
most
of
the
ones
other
than
node
core,
because
that's
gonna
be
the
the
trickiest
one.
I
think,
but.
A
E
A
Okay,
so
basically
I
think
that's
where
it's.
We
should
leave
it
on
our
on
our
list
and
you
know
if
we're
comfortable,
just
sort
of
leaving
it
as
as
and
when
things
happen
we
can.
We
can
just
leave
the
list
if
we
think
we
need
to
be
more
proactive.
We
can
try
and
figure
out
how,
to
you
know,
subdivide
a
group.
You
know
we
could.
We
could
schedule
like
an
hour
where
we
all
got
together
and
looked
at
them
and
figured
out.
A
A
Okay,
I
guess
silence.
I
will
assume
that
that's
the
case
so
I'll
basically
said
okay,
any
interest
in
an
rfc
process.
A
One
there
has
kind
of
been
a
related
discussion
or
issue
about
surfacing.
You
know
like
node
fetch.
There
was
a
discussion
related
to
that
in
terms
of
like
there
may
be
some
sort
of
context
where
people
have
thought
about
it
and
we've
kind
of
made
a
decision,
but
that's
not
documented
anywhere
anywhere.
So
there's
some
discussion
going
on
on
that
front
in
terms
of
should
we
document
those
kind
of
things
somewhere,
but
that's
maybe
it's
related,
but
maybe
a
little
bit
of
a
tangent
to
this
one.
H
H
The
agenda
one,
I
can
read
it
out
if
you
like,
okay,
sure,
yep
so
va
issues
are
fixed
and
they
have
a
green
ci
on
the
job
and
ash
has
turned
on
the
node
test
commit
so
that
all
pr's
should
get
tested
these
also,
in
parallel
having
a
discussion
about
sourcing
the
heart,
the
hardware
sourcing,
because
at
the
moment
we're
using
the
dtks
so
future
future
hardware
resources.
A
I
think
I
I
think
I
don't
I'll
say
we
haven't
had
the
full
discussion
with
all
the
people
in
the
build
working
group,
but
from
some
discussions
with
me,
beth
and
nash,
we're
thinking
that
it
might
make
sense
to
to
build
both
on
m1
and
intel
and
build
fat
binaries
for
both
and
then
test
those
fat
binaries.
So,
basically,
you
know
on
intel.
You
build
and
test
the
fat
binary
on
an
m1.
You
build
and
test
the
fat
binary.
A
Now
for
each
of
those
tests
they
would
be
testing.
Obviously,
the
like.
On
the
x86
case.
We
would
have
tested
the
x86
part
on
m1,
we
would
have
tested
the
the
m1
part,
and
but
our
shipping
shipping
binaries
would
continue
to
at
least
for
the
short
term,
be
built
with
x86
the
the
potential
gap
there
is.
We
won't
have
anything
that
actually
tests
the
you
know
the
x,
the
the
the
fat
binary
built
on
x86
on
m1,
and
we
thought
it
would
probably
be
good
enough
to
do.
A
So
I
guess
it's
like
just
mention
that,
because
that's
one
area
where
it's
like
that'll,
simplify
our
testing
significantly
in
the
work
that
we
need.
But
if
people
have
concerns
with
that,
you
know
this
is
an
fyi
that
that's
one
of
the
options
we're
considering
and
if
you
do
have
concerns
to
let
let
the
build
team
know.
A
Okay,
if
not
we'll
move
on
to
the
next
one,
which
is
renaming
an
api,
I
think
this
one
I
can
take
off
the
the
agenda.
We
discussed
it
in
a
previous
meeting.
I
think
we
had
consensus
on
the
path
it
was
being
proposed
and
there's
work
to
sort
of
slowly
do
some
of
the
documentation
renaming
and
stuff
and
we're
not
planning
to
change
the
symbols
and
all
that
kind
of
stuff.
A
A
No
okay,
so
removed
already
discussed,
moved
agenda
item.
A
Potential
stagnation
of
open
issues
in
h1
bounty
program,
so
there
has
been
some
discussion
in
terms
of
how
we
actually
do
the
the
sort
of
you
know
how
we
handle
the
backlog.
How
we
hand
that,
over
to
the
volunteer,
the
the
company
that
we've
that
has
volunteered
to
to
take
that
over,
I
think
next
step
is
for
me
to
actually
forward
that
proposal
on
to
the
foundation
to
get
their
input
and
then
based
on
that,
we
can
move
forward.
A
A
A
A
Okay,
so
that's
at
the
end
of
our
agenda
items
we
have
a
few
minutes
left.
So
let
me
just
open
up
the
strategic
initiatives.
Selection.
J
A
I
A
A
A
B
B
A
Okay,
that's
good
or
sorry.
I
guess
I
should
have
looked
at
the
updates
on
the
issue
themselves,
but
okay,
so
that
takes
us
to
the
end
of
the
strategic
initiatives
that
we
have
people
here
for
and
we're
pretty
much
at
time.
So
are
there
any
other
issues
that
people
would
like
to
discuss
or
cover
before
we
close
out
for
today.
A
Okay,
so
let's
we'll
close
out
the
meeting
and
if
people
can
stick
around
so
let
me
stop.