►
From YouTube: 2022-03-31-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
B
Yes,
I've
opened
a
release
proposal
for
the
what
what's
planned
to
be
the
final
node
12
release,
so
we're
planning
to
put
that
out
next
tuesday.
But
I've
opened
the
release
proposal
yesterday
and
there
is
a
release
candidate
build
if
people
want
to
download
it
and
try
it
out.
B
A
Okay,
so
let's
move
on
to
the
issues
that
we're
tagged
for
the
agenda,
the
actually
first
of
all,
we'll
move
on
to
cpc
and
board
meeting
updates.
So
rich.
I
don't
know
if
you,
if
you
can
talk
but
on
the
any
updates
on
the
cpc
front.
C
C
I
think
elections
are
coming
up
soon
for
the
for
the
node
for
one
of
the
two
node
representatives
on
the
cpc,
but
that's
gonna,
that's
gonna
happen
after
the
chair
election,
I
think,
is
what
we
decided.
C
Yeah-
and
I
think
not,
this
is
a
cpc
update,
but
for
oh
by
the
way
it
looks
like
mateo
needs
to
be
promoted.
Okay,.
A
C
But
also
we
should,
I
think
the
chair
for
tsc
election
is
in
may
right.
So
that's
about
a
month
away.
At
this
point.
A
A
Okay
and
on
the
board
front
yeah.
Similarly,
I
don't
think
there's
anything
of
note
to
bring
up
at
this
point.
A
B
I
think
james
has
added
a
comment
to
the
meeting
issue
asking
to
defer
this
for
another
couple
of
weeks,
so
he
can
make
the
meeting
okay.
A
Okay,
I
just
took
that
note.
Okay,
the
next
issue
on
the
agenda
is
module,
ensure
node
colon
dash
only
modules
can
access
node
modules,
42
430.,
I
think
colin.
You
tagged
that
for
the
agenda.
D
D
I
originally
had
opened
the
pr
with
the
test
runner
under
a
new
top
level,
module
called
test
underscore
runner,
which
is
you
know,
available
in
core,
but
also
on
npm.
So
there
were
no
conflicts
in
that
pr.
It
was
requested
to
change
from
node
or
from
test
runner
to
just
node
colon
test
and
to
make
sure
that
the
the
module
was
only
available
under
the
the
node
scheme.
So,
for
example,
if
you
were
to
require
test,
you
wouldn't
get
the
module.
Unless
it
was
in
node
modules,
then
you
could
load
the
userland
module.
D
So
the
the
issue
that
we
have
to
discuss,
which
is
not
specific
to
the
test
runner,
but
really
to
any
new
module
that
we
would
add
is.
Are
we
going
to
enforce
this
this
node
only
scheme?
So
if
you
read
through
that
pull
request,
there's
been
some
discussion
on
on
some
pros
and
cons.
So
my
my
I
guess
opinion
on
it
is
that
we
should
go
back
to
the
the
test.
Runner
bear
module
that
doesn't
conflict
with
npm.
D
D
There's
no
conflict
on
npm,
which
is
obviously
an
issue.
Every
time
we
add
a
module,
there's
less
chance
of
user
confusion.
So
you
know
people
constantly
install
fs
from
mpm.
So
it's
definitely
a
thing
that
happens,
there's
also
security
considerations.
D
So
I
even
linked
to
one
that
just
happened
like
a
week
ago
from
jfrog
where
it
was
using
scopes
instead
of
schemes,
but
the
same
thing
applies.
Basically,
they
targeted
azure
by
publishing
all
the
same
modules
that
azure
publishes,
except
without
the
scope.
So
you
can
go
and
read
through
that.
If
you'd
like
the
downside,
is
that
the
name
is
not
beautiful,
but
we
have
a
lot
of
kind
of
ugly
module
names
in
core
already
and
yeah,
so
we
need
to
come
up
with
a
decision
before
before
node
18.
D
So
whether
that's
you
know
completely
reverting
the
test,
runner
which
I
don't
necessarily
think
is
beneficial
and
we'll
have
the
same
issue
anytime.
We
try
to
add
a
new
module
to
decide.
We're
going
to
commit
to
the
node
scheme,
revert
to
test
runner
etc,
but
yeah.
So
that's
that's!
What's
going
on.
E
Yeah
and,
as
I
said
in
the
thread,
I'd
be
in
favor
of
enforcing
the
the
note
scheme
only
for
all
new
packages
that
we
add
to
core.
E
A
D
I
I
think,
that's
the
biggest
issue,
so
targos
called
out
the
confusion
thing.
The
security
thing
like
I
said
it
was
just
in
node
weekly
last
week
that
there
was
a
security
issue,
and
I
know
jordan
has
also
been
emphatic
that
we
should
not
do
the
node
scheme.
D
You
know
if
we
want
to
do
the
the
node
scheme.
You
know
that's
what's
already
there.
We
just
need
this
bug
fix
pr
to
land.
I
can
live
with
it.
I
just
wanted
to
raise
the
concerns,
but
we
definitely
need
some
path
forward.
Before
note
18.
E
E
I
suggested
as
a
password
that
we
we
could
maybe
use
test
underscore
runner,
but
only
on
the
under
the
note
scheme
and
throw
another
error
if
someone
tries
to
to
load
it
without
the
scheme.
A
E
A
D
I
mean
yeah,
throwing
an
error
certainly
certainly
takes
the
confusion
out
of
it,
but
it
also
then
doesn't
change
where
we
are
from
today.
D
E
And
I
guess
so
go
ahead.
There
are
some
discussion
in
in
the
chat
also
so
to
be
asked
asked,
should
not
glenn
foo
check,
non-modules
and
colleen's
answered
no,
it's
it's
only
loads
core
modules
and
which
said,
if
we're
not
going
to
commit
to
requiring
not
clan
for
at
some
point,
then
there's
very
little
benefit
to
having
not
colonel.
In
the
first
place,.
D
And
then
tobias
just
asked
so
to
be
clear
if
we
had
node
colon
foo,
that
would
only
load
from
core
if
you
had
sorry
to
bs,
if
you
have,
if
you
require
foo,
then
it
would
never
load
from
core
and
it
will
only
load
from
from
user
land.
B
Yeah,
I
I
I
tend
to
agree
if
we
are
not
going
to
allow
user
modules
to
have
the
same
name
as
a
node
namespace
module.
Then
what's
the
point
of
the
node
namespace
yeah?
If
we're,
if
we're
going
to
have
a
policy
where,
whatever
whatever
is
in
the
node
namespace,
has
to
not
conflict
with
userland,
then
there
isn't
actually
really
any
point
in
having
the
namespace.
E
So
what
I
meant
is,
we
probably
also
want
all
core
modules
to
be
required
through
this
node
scheme,
like
in
our
documentation,
for
example,
by
the
way,
it's
really
quite
weird,
to
have
only
one
module.
D
So
rich
mentioned
in
the
chat,
it
provides
clarity
and
end
user
code
if
they
use
the
node
scheme,
and
I
completely
agree
with
that,
but
we
don't
have
to
restrict
it
to
to
only
be
you
know,
requirable
via
the
scheme.
So
it
is
nice
if
everyone
would
write.
You
know
node
colon
whatever,
but
we
don't
have
to
make
a
change
in
the
loader
to
only
allow
that.
A
D
Well,
yeah,
I
mean
it
can
clearly
happen
anywhere.
The
the
linked
jfrog
article
with
the
the
azure
security
issue
is
a
perfect
example
of
that.
I
think
the
the
node
core
modules
are
just
a
little
higher
profile
and
more
likely
to
be
a
target.
B
A
A
A
So,
let's
not
derail
the
actual
conversation
the
like.
I
guess
it's,
it's
there's
it.
I
can
see.
There's
some
some
benefit
to
having
it
clear
that
it's
the
node
scheme
and
then
it's
the
the
flip
side
of
the
confusion.
Like
do
we
long
term?
Do
we
think
that
that
which
one
is
the
most
you
know,
I
guess
also
december
major
part,
makes
it
harder
to
add
things
you
know
which
outweighs
the
other
is
the
real
question
we
have.
D
It's
it's
not
back
portable,
it's
making
the
break
where
we
now
have
node
scheme.
Only
modules
is
definitely
a
breaking
change
because
it
required
changes
in
our
own
test
test.
Suite
yeah.
D
So
I
think
rich
has
a
good
suggestion
in
the
chat
and
that's
that
we
should
take
this
to
the
issue
tracker
and
commit
to
making
a
decision
in
the
next
seven
days
prod
people
in
the
tsc
to
participate.
I've
already
pinged
the
tsc
in
that
issue
a
few
times
now,
but
yeah.
I
think
we
should
do
that.
A
Okay,
so
at
this
point
we'll
take
it
back
to
the
issue
tracker
and
we
can
leave
it
on
the
agenda
so
that
we
make
sure
next
week
we
say:
have
we
actually
made
a
decision
or
if
not,
what
are
we
going
to
do?
A
F
Thing
colleen
when
you're
doing
that
summary
or
prod
like
it
will
be
it's
easier
to
have
us
a
little
bit
of
a
summary
and
saying
the
option:
a
b
or
c
okay.
Something
like
that,
because
the
issue
is
very
long
and
very
confusing
at
certain
points.
So.
A
G
B
Yeah,
I
don't
think
performance
has
ever
been
a
blocker
to
to
mark
something.
That's
stable.
The
experimental
stability
indicators
are
whether
we
are
likely
to
drastically
change
this
sort
of
api
contract.
G
A
H
H
There
is
good
test
coverage
in
our
repo
and
then
the
latest
api
interface
change
has
been
quite
a
long
ago.
Maybe
there
are
one
or
two
other
considerations
than
any
subjective
feelings.
This
was
devised
to.
You
know,
eliminate
any
sort
of
people's
perceptions
about.
Are
we
good
to
get
into
the
stable
state
or
forward
so
can't
we
apply
such
rules
here.
A
E
And
beth
in
the
chat
says,
expose
as
global
and
move
out
of
experimental
could
be
two
separate
questions.
Yeah,
that's
true!
I
handled
them
in
one
pr
because
it
was
easier
for
me,
but
and
also
I
think,
if
they're
no
longer
experimental,
it's
logical
to
have
them
as
global.
It
could
be
a
separate
discussion.
F
F
I
actually
explained
it
because
I,
given
the
issue
of
the
discussion,
I
actually
changed
a
little
bit
my
mind.
I
am
okay,
making
them
global,
I'm
also,
okay,
in
removing
the
big
experimental
warning,
that's
there,
but
I
will
keep
them
flagged
as
experimental
in
the
docks.
Okay
and
the
reason
for
that.
It's
because
we
should
not
recommend
people
to
use
them.
Mine
was
that
the
api
is
there.
F
If
they
want
to
use
it,
they
can
okay,
but
it's
it's
the
essentially
moving
them
in
that
same
gray,
area,
where
we
have
asking
hooks
and
a
few
other
things
in
core,
where
we
are
not
really
confident
in
people
in
making
them
recommending
them
for
public
usage.
But
on
the
other
end
we
are
people
need
to
use
them
or
want
to
use
them
anyway.
So
they
shouldn't
see
a
big
warning
or
or
anything.
G
F
Or
yeah
absolutely,
but
I
would
you
know
for
me
having
a
very
good,
a
good
implementation
of
fetch.
It's
a
good
indicator
that
our
web
stream
implementation
is
is
solid
enough.
Like
that's
why
I
one
of
the
criteria
that
we
used
for
an
api
and
others
was
to
have
a
few
modules
and
a
few
users
that
were
reporting
that
that
thing
was
working,
fine
and
was
working
well,
and
I
I
had
people
trying
to
put
wounded
fetch
in
production
lately
and
they
failed
okay,
it
didn't
work
as
as
expected.
F
Okay,
especially
on
the
performance
front,
it
was
so
problematic
that
they
just
completely
backtracked
from
it
like.
Essentially,
unless
you
really
need
to
use
it,
it's
and
most
of
the
overhead
is
actually
inside
note
fetch
it.
Sorry,
it's
not.
You
know.
Sorry,
it's
inside,
it's
not
it's
inside
web
streams,
not
only
I
can
over.
We
have
a
long
report
that
one
of
my
team
members
is
actually
has
actually
prepared
on
it.
I'll
probably
share
with
you
around.
F
I
guess
sooner
rather
than
later
it's
basically
it's
one
of
our
one
of
the
massive
one
of
the
problems
is
on
the
no
or
not
our
implementation,
which
is
bizarre
basically,
at
the
end
of
the
web
stream.
Implementation
creates
a
type
error
at
the
end
when
a
stream
is
completed.
F
However,
our
node
error,
it's
a
fairly
a
fairly
heavy
object
to
create
that
also
does
a
lot
of
stuff
trace
mangling.
It
does
a
lot
of
things.
Okay,
however,
that
error
is
almost
never
allocated
my
never
used,
but
it
needs
to
be
created
for
the
spec.
So
this
is
not
a
problem
for
other
implementation
or
other
browsers,
because
they
don't
have
this
heavy
type
error
or
error
implementation
that
as
we
that
we
do
have
in
node.
So
sorry,
this
is
sorry
for
the
long
discussion.
F
But
again,
as
I
said
I
have
this,
there
are.
I
have
data
to
to
prove
to
there's
analysis
and
data
to
that
is
relevant
to
this
discussion,
so
I'm
not,
and
by
the
way
this
is
a
30
increase
in
30
increase
in
in
in
in
wounded
fetch
implementation.
Just
that
error
thing.
So
it's
a
lot.
A
So,
in
terms
of
this
particular
one,
I
think
mateo's
put
like
a
new
proposal
in
terms
of
what
we
do.
What
do
people
you
know
any
objections
to
that.
Does
that
sound
good
to
people.
G
A
A
A
A
Okay,
the
next
one
is
a
daily
notable
summary,
a
good
idea.
I
opened
this
one.
It
just
came
out
of
a
discussion.
You
know
I
was
having
a
discussion
with
joe
and
it
was
like
you
know.
A
It
might
be
easier
for
people,
so
there
was
just
the
suggestion
that
you
know
we
might
come
up
with
a
new
tag
that
people
could
tag
things
with
us
to
say
this
looks
like
something
that
we
want
as
many
collaborators
to
be
aware
of
as
possible
versus,
say,
a
bug
fix
or
a
test
fix,
or
something
that
you
know.
We
just
need
enough
people
to
look
at
to
make
sure
we
can
land.
A
Anybody
concerned,
if
we
asked
people
to
add
a
a
new
tag,
whatever
we
named
it.
B
Yes,
because
I'm
I'm
not
I'm
not
convinced
that
people
can
adequately
interpret
what
what
is
interesting
to
somebody
else.
B
So
so,
if
I've
authored
the
pr,
how
do
I
know
that
somebody
else
finds
it
interesting
when
you're
looking
at
collaborator
base,
which
is
what
I'm
sure
we've
got
about?
100
collaborators,
maybe
less
now
that
we've
thinned
out
some
of
them.
But
we
have
like
this
existing
thing
where
people
can
tag
teams,
but
I
think
not
everyone
in
the
teams
are
either
getting
the
notifications
or
it's
all
part
of
the
general
hose
of
notifications.
B
I
mean
we
could
potentially
monitor
or
tags
the
teams
and
summarize
it
in
some
other
way,
but
I
think
the
problem
with
labels
is
labels
are
implied
inconsistently,
we're
finding
that
with
releases
that
not
always
like
sembla
miners
are
labeled
simba
minor,
for
example,
which
is
a
little
bit
annoying
from
this
point
of
view,
but
anything
relying
on
people
adding
text
is
then
reliant
on
the
person
making
the
judgment
call
who's,
adding
the
tag
that.
B
The
problem
is,
I'm
not
convinced
that
this
is
going
to
solve
the
problem.
It's
just
gonna
open
another
another
stream
of
information
to
monitor
and
then
pass
out
to
see
whether
you're
actually
information,
whether
you're
in
whether
you
individually
are
interested
in
the
group
of
things
that
so
I
guess
the
hope
is
it's
a
smaller
group
than
the
firehouse
of
everything,
but
it
still
might
be
a
large
group
depending
on
how
much
people
attacked.
A
B
Not
enough
if
people
are
concerned
that
it's
something
has
gone
in,
that
they
haven't
noticed,
the
question
is:
would
the
person
or
the
people
involved
in
the
thing
landing?
Would
they
have
come
to
the
conclusion
that
they
should
have
added
the
label
to
inform
people
you
know
had
had
they
already,
for
example,
ping
the
team?
So
if
they
ping
the
team,
that
is
the
existing
notification
method,
we
have
to
try
and
alert
people
who
we
think
would
be
interested.
A
B
B
If,
if
it's,
if
a
team
is
ping,
that's
a
comment
or
we
could
add,
you
know
like
a
bot
into
the
teams
to
to
to
see
it
to
to
get
notified.
When
that
happens,
the
question
is:
how
do
you
surface
that,
if
it's,
if
you're
looking
for
a
newsletter,
then
we
could
generate
pages?
I
guess,
based
on
the
existing
notifications.
B
The
thing
there's
a
thing
in
the
in
the
chat
about
notable
labels
and
the
thing
about
notable
is
it's
not
necessarily
a
one-to-one
relation
to
send
venus
so,
for
example,
and
also
depends
who
your
audience
is
so
obviously
the
existing
notable
change
label
is
intended
for
people
consuming
the
releases
and,
for
example,
we
would
tag
things
like
new
releaser
keys.
That's
not
notable
because
if
you're
verifying
binaries,
you
would
want
to
know
that
there's
a
new
release
key,
but
in
terms
of
senderness
that's
outside
of
december
contract.
B
You
know
we
can
add,
it's
just
documentation,
update
other
things
that
so
I
imagine
that
you
know.
Some
of
this
discussion
is
around
things
like
severe
internal
refactorings
and
that's
not
send
the
hopefully
an
internal
refactoring
would
not
be
a
simva
surfaceable
thing.
It
might
just
be
an
internal
reorganization,
but
with
no
actual
change
to
the
end
user
interfaces
so
yeah
the
existing
notable
label
is
for
for
sort
of
end
using.
I
you
know.
If
you
have
another
label
for
intending
for
the
collaborator
base,
then
that's
possible.
B
You've
got
the
disambiguation
problem
that
you
need
to
explain
adequately.
What's
different
between
this
new
label
and
the
existing
notable
changes
label,
but
I
I
still
think
it's
going
to
come
down
to
if
issues
are
being
missed
by
people
who
that
who
was
involved
in
the
issues
that
were
missed.
That
would
have
added
the
label
in
the
first
place,
to
notify
the
people
that.
A
A
Perfect,
like
there's
no
way
it's
going
to
catch
everything,
it's
just
like
wood
crowd,
sourcing
that
so
it
doesn't
have
to
be
the
person
who
opens
it.
It
could
be
somebody
else
who
sees
oh.
This
is
one
I
think
should
have
broader
visibility
and
the
question
you
know
it
could
be
right
that
no,
we
won't
get
enough.
So
it's
just
not
useful,
but
it's
it's
not
going
to
be
100
would
the
whatever
percent
it
might
be
be
useful
or
not.
B
F
Something
that
I
would
recommend
is
to
open
up
for
others,
the
for
people,
not
that
are
not
not
collaborators
to
subscribe
to
that
change.
That
is
a
fundamental
difference
than
our
current
system.
Okay,
and
because-
and
this
enables
a
more
open
crowd
so
of
people
which
I
think
will
will
help
okay
on.
F
Exactly
okay-
and
I
I
had
a
few
people
asking
me
about
that.
Okay,
can
I
have
a
details
of
what
notable
things
are
happening
in
in
node?
Okay
and
people
were
not
getting.
We
are
not
percolating
that
information
down.
Okay,
so
having
you
know
some
sort
of
a
mailing
list
to
to
do
that.
Okay,
that's
it
it's
all
automated!
So
it's
not
that
we
need
to
assemble
it
or
create
it.
It's
just
you
know
more
or
less
a
full
full
run
through.
H
H
A
Thanks
yeah,
the
main,
the
main
reason
I
I
think
we
came
up
with
the
label,
is
it's
easy
and
like
it
doesn't
that
I
can
easily
see
like
a
very
simple
script
that
just
pulls
on
the
tag
fires
off
an
email
as
an
action
doing
something
else
would
probably
require
some
more
thought.
Thinking
that
kind
of
thing.
A
I
think
at
this
point
you
know
we
we've
spent
a
reasonable
amount
of
time
here.
If
people
want
to
chime
in
in
the
issue
itself,
that
would
be
good.
A
The
key
thing
would
be
like
what
is
it
that
we
think
would
be
reasonable
to
ask
people
to
do,
and
then
you
know
once
we
have
the
information
distributing
it
to
mailing
list
or
whatever
I
like
mateo's
suggestion
that
like
it
could
be,
you
know
it
wouldn't
be
limited
to
collaborators,
so
it
actually
would
have
that
advantage
versus
regular
notifications.
A
F
For
me,
that's
the
main,
that's
the
main
advantage,
because
part
of
the
problem
with
that
was
a
few
key
people
that
are
vested
in
the
ecosystem
that
are
not.
Collaborators
were
not
tagged.
So
it's
and
this
pr
this
the
system
will
not
fix
them,
will
not.
Work
will
not
have
fixed
the
test.
Runner
problem,
okay,
because
there
was
no
way
for
people
not
in
the
project
to
chime
in
okay,
in
our
in
our
pr's
that
are,
I
don't
know
they
are
not
collaborators
because
they
don't
want
to.
F
They
don't
want
they
don't
have
time,
but
they
can
still
participate
in
the
issues
right.
So
it's
a
way
to
keep
in
sync
with
the
project:
okay
and
yeah.
No,
I
think
it's,
it
will
be
a
great
service
if
we
can
have
it
and
it's
it's
probably
not
it's
not
a
lot
of
work
to
automate
it
up.
So
it's.
A
A
B
B
Sort
of
go
out
and
search
for
them.
I
guess
it's
different
if
it's
a
change
to
something
that
we're
already
looking
at
that,
you
know,
we
would
then
have
people
subscribe
to
that
topic,
but
if
it's
something
that
we're
new
we're
interested
into
the
call
that
won't
be
something
that
exists,
so
you
wouldn't
be
subscribing
to
it
because
it
wasn't
there
before.
A
But
it's
it's
not
like.
It's
not
like
one
of
those
teams
where
you've
registered
your
interest
in
a
specific
topic,
yeah
yeah,
something.
B
Yes,
but
that
might
not
solve
the
particular
issue
about
the
the
test
runner
thing
where
there
is
a
group
of
people
out
there
in
the
ecosystem
that
are
doing
something,
and
we
have
now
added
a
module.
That's
in
that
sort
of
sphere,
so
so
anything
in
the
future,
where
we're
adding
something
new
to
core,
where
there
are
user
land
implementations
out
there.
B
I
don't
think
this
approach
necessarily
would
help
with
that,
because
unless
you
were
looking
at
the
sort
of
notable
changes,
but
then
that
would
be
everything
and
not
just
this
one
particular
thing
and
if
you're
not
invested
in
node
core,
you
know
if
you're,
just
looking
after
ecosystem
modules,
I'm
not
necessarily
convinced
you
would
be
looking
at
the
whole
flood
of
I.
You
know
it's
all
special.
A
It's
one
of
those
things
right.
You
know
I
I
wouldn't
argue
that
it
would
have
changed
the
outcome
there,
but
on
the
other
hand,
I
think
it
might
help
in
some
cases,
so
yeah
for
the
overhead,
like
my
personal
feeling,
is
the
overhead
of
asking
people
that
the
tag
is
pretty
low
and
we
might
get
some
benefit
from
it
right
and
if
it
doesn't
work
we
can
just
stop.
So
I
don't
see
much
downside
to
giving
it
a
shot,
is
kind
of
where
I
come
from.
A
A
Okay,
so
I
guess,
if
any
other
comments
you
can
take
it
back
to
the
issue
tracker
and
go
from
there.
A
No
distributions
are
not
affected
the
same
way
by
security
releases.
We
discussed
this
last
week.
This
is
1187.,
there's
a
pr
now,
and
it's
got
enough
enough.
You
know
reviews
plus
ones
to
land,
but
I
just
wanted
to
wait
till
you
know
I
could
give
everybody
an
fyi
in
the
tsu
meeting
here.
A
If
you
have
any,
you
know,
concerns
or
want
to
take
a
look.
Please
do
and
I
plan
to
land
this,
maybe
tomorrow.
If
I
don't
see
any
objections.
A
The
next
one
is
publishing
specs
per
buffer
and
event
emitter.
This
is
one
one,
seven
six,
I
think
if
I
remember
correctly,
this
one
we've
been
waiting
for
a
meeting
where
james
can
make
it
to
have
the
discussion,
and
so
we
should
probably
just
defer
till
next
time,
unless
anybody
has
any
thoughts
and
comments
that
we
should
go
into
it.
B
Sorry
I
was
mistaken.
The
comment
james
made
earlier,
I
said
for
the
other
issue.
It
was
actually
about
this
one.
So
so
james
has
commented
saying
with
regards
to
this
one.
He
put
it
on
the
agenda,
but
he'd
like
to
defer
it
to
the
week
after
next,
because
he
won't
be
able
to
make
next
week's
meeting
either.
A
Okay
sounds
good,
I
mean
yeah
and
I
do
have
remind
me.
I
do
have
a
comment
about
week
out
next
week
as
well,
so
once
we
get
through
so
next
next
issue
is
give
alex
robinson
from
linux
foundation.
Access
to
the
youtube
account.
I
added
that
to
the
agenda
and
opened
it.
A
What
I'd
really
like
to
see
is
if
you
watch
the
board
meetings,
there's
always
a
section
on
sort
of
top
youtube
content,
and
I
I
it
shows
the
content
on
the
opengs
foundation,
which
I
don't
think
is
a
good
representation
of
what
people
are
actually
watching.
The
node
channel
has
like
10
times
more
views
of
you
know
of
talks
that
we
have
so
I
think
so.
A
The
idea
is
if
we
can
give
alex
access,
she'll
be
able
to
include
some
of
that
and
have
a
better
representation
of
what
they're
looking
at,
and
I
just
wanted
to
see
if
anybody
had
any
concerns.
Otherwise
I
can
go
ahead
and
add.
A
So
I'll
just
take
a
note
that
there
weren't
any
objections
and
go
ahead
and
do
that
unless
somebody
has
a
concern.
A
Okay,
we
can
move
on
to
the
next
one.
The
next
one
is
the
next
10
mini
summit,
so
we
have
planned
for
next
week
wasm
a
sort
of
a
deep
dive
on
wasm
and
the
permission
policy
security
model.
In
terms
of,
what's,
you
know
important
to
the
future
of
node.js
next
10
years
on
those
fronts,
we've
started
to
line
up
it's
good.
A
On
the
wasm
front,
I
think
we'll
have
a
few
people
from
the
wasm
project
joining
to
help
and
participate
in
the
discussion,
which
is
great
and
we
ping
the
number
of
people
on
security
policy
models.
Hoping
we
get
it's
on
the
agenda.
It's
like
hoping.
We
get
some
tc
members
and
actually
it's
at
the
same
time
as
the
tsc
meeting
next
week.
So
I
wanted
to
ask
if
you
know
either
we
need
to
somebody.
We
need
somebody
else
who
can
volunteer
to
chair,
although
I'm
hoping
a
number
of
tsc
members
will
be
there.
A
B
C
We
do
need
to
make
sure
we
make
a
decision
about
the
test,
runner
issue.
So
right.
If
we're
going
to
cancel
the
meeting,
we
need
to
be
especially
sure
that
we
make
a
decision.
A
C
I'm
sorry,
which
are
we
moving
the
next
10
or
moving
this
no
moving
the
tse
meeting.
Oh,
I
don't
have
a
problem
with
that.
I
think
in
fact
everybody
should
make
sure
who
hasn't
updated.
The
spreadsheet
should
update
the
spreadsheet.
We
should
readjust
the
times
now
that
so
many
people
have
had
time
changes.
C
A
A
You
know
one
last
time,
probably
today
or
if
everybody's
good.
I
mean
I'm
good
with
that.
If
we
think
we're
good
today,.
A
C
I
I
greatly
appreciate
richard
reporting
a
bug
in
the
in
the
time
zone
adjustment
tool,
which
has
been
there
since
it
was
added
in
my
defense.
I
did
not
add
it,
but
it's
been,
but
but
I've
never
noticed
that
it
actually
does
not
work,
but
now
it
does.
A
Okay,
so
we
only
have
a
few
minutes
and
I
think
rich
you
mentioned.
There
is
something
to
stick
around
for
a
very
short
private
session,
so
I
think
it
sounds
like
we're
in
agreement
that
I'll
move
to
one
of
the
new
times
based
on
that
for
next
week
and
hope
to
see
as
many
as
people
as
we
can
at
the
the
mini
summit
itself.