►
Description
A
Well,
I've
now
welcome
everyone
to
the
node
foundation,
core
technical
committee
meeting
for
februari
februari,
the
first
2017
we're
going
to
go
through
a
stand
up
first
and
then
on
to
our
agenda
on
all
that
is
linked
in
the
issue
link
in
the
description
for
the
live
stream.
So
stand
up
we'll
start
first
with
Anna.
D
F
A
G
G
Not
that
terrible
over
the
past
week,
due
to
a
variety
of
things,
but
I've
got
somewhere
progress
done
on
the
hd2,
but
the
PRS
landed.
Do
issues.
I
I
did
get
the
deprecation
policy.
Pron
I,
don't
sound.
I
got
enough
reviews
and
articles
I've
done
so
I
couldn't
land
early
money,
I'm
not
in
front
of
the
list
right
now,
so
I'm
not
sure
is
Nick.
I
guess.
H
I
I
did
some
updates
to
the
smart,
smarter
West,
build
test
job,
so
we
could
allow
the
new
version
of
the
tool
and
some
minor
tweaks
to
the
benchmarking
chart
generation.
We
dropped
at
the
12
x
results
and
some
other
miscellaneous
improvements
did
some
work
to
try
out
the
new
mate
coverage
target
in
the
CI
and
sort
of
make
some
review
comments
on
that
set
up
a
couple.
I
Special
special
benchmarking
meetings
this
week
in
terms
of
one's
a
benchmark
that
Intel
is
working
on
for
no
GS
and
the
other
one
is
programmed
guided,
optimization
on
more
ongoing
work
with
the
API,
stable
module
group
of
people
who
are
working
on
that
and
then
just
general
review
comments
and
lands
in
the
repo.
Next
is
brian
white.
J
Okay,
sorry
about
that
just
stumbling
with
the
UI
here,
so
security
release
for
v4
and
v6
went
out
yesterday.
I
updated
the
RCS
for
the
the
minor
releases
as
well.
You
need
to
go
through
and
collect
a
few
more
things
on
the
four
for
the
cert
related
stuff
I'm,
going
to
be
a
little
bit
less
hands-on.
You
may
have
noticed
the
last
couple
weeks
in
between
switching
gigs
and
no
figuring
out
where
my
time
comes
from
just
kind
of
like
getting
used
to
it,
but
still
plan
to
be.
J
You
know
involved
like
before
general
review
of
PRS
and
issues.
We
did
a
minor
release
of
canary
the
gold
mine
last
week
planning
this
week
to
get
that
back
up
to
date
with
the
ABI
testers.
So
we
can
get
55
landed
into
the
seven.
You
know
as
long
as
it
works
and
I
was
also
at
the
tc39
last
week
as
well,
and
next
up
is
Ali.
K
C
G
E
E
A
Speaking
of
which
I
like
we
really
need
to
swap
these
agendas,
so
the
the
agenda
part
doesn't
exist,
and
it's
just
like
in
the
meeting
in
the
minutes
and
that's
always
confusing.
Let's
just
go
over
stuff
from
last
week.
I
guess
first
might
make
no
sense,
updating
the
copyright
any
we
have
anything
to
talk
about
on
that.
G
A
A
D
E
Issue
there
was
was:
are
we
okay
with
like
what
this
stable
mean?
Does
that
mean
like
because,
like
in
the
past,
we've
used
that
to
say
no
we're
not
going
to
fix
deep,
equal
and
deep,
strict
equal
to
work
with
you
know,
maps
and
sets
and
symbols
and
I,
don't
know
if
I
don't
know
if
that
was
resolved
last
week,
because
I
wasn't
here,
but
that
was
the
that
was
the
crux
of
the
issue.
A
A
There's
a
lot
of
discussion:
there
were
not
too
much
if
anyone's
interested,
follow
up
or
not.
Depths.
Odd
note
in
dash
inspects,
I,
don't
remember
actually
discussing
this
much
last
week.
I
know
that
we
do
have
knowed
dash
inspect
as
approved
come
to
the
foundation.
So
I
think
we
probably
need
to
decide
on
that.
Sometime
might
still
be
on
our
agenda.
It
is
and
yes,
module
discussion
stuff.
We
are
going
to
be
talking
out
that
today,
too,
is
there
anything
else
on
the
CTC
review,
so
on
CTC
review
in
general.
A
There's
the
copyright
stuff
people
need
to
look
at
the
deprecation
policy.
Even
though
has
landed
be
good.
If
everyone
should
take
a
look
at
that
and
sort
of
understood
what
we
have
landed,
there
is
a
pull
request
to
deprecate.
No
dash
dash
debug
at
runtime
on
the
be
useful
for
people
to
review
and
a
runtime
deprecation
of
FS
that
sink
right
stream
and
also
there's
a
PR
to
remove,
I
think,
is
mine,
might
be
even
approved.
A
node
underscore
TTYL,
unsafe,
async
environment.
Variable
any
comments
on
the
other.
A
E
B
D
We
had
a
little
bit
of
like
ketchup
meeting
two
weeks
ago
on
the
topic,
essentially,
if
from
a
user
perspective
boils
down
to
when
you
require
an
es
module,
do
you
get
a
promise
back
or
do
you
get
a
module
name?
Space
object
there.
There
are
concerns
about
temporal
dead
zones
with
the
module
name,
space
object.
However,
that
is
how
Babel
currently
works.
Is
you
basically
require
your
ES
module?
You
get
an
object
back.
This
is
roughly
equivalent
to
that
for
an
asynchronous
loader.
D
D
A
D
G
K
G
Think
the
tc39
would
really
like
to
see
a
clear
decision
from
from
us
in
terms
of
what
we
want,
rather
than
it
being
well.
You
know
we
seem
to
have
an
idea
I've
seen
to
have
a
preference
one
way
or
not.
It
should
be
rather
clear
if
we're
not
able
to
come
up
with
a
clear
decision
in
the
fingers
now.
Thats
also
says
something
to.
G
G
Slur
choir
and
you
know
we're
imports
only
being
used
if
we're
looking
at
it
from
a
a
yes
six
modules
point
of
view,
in
which
case,
if
we
need
to
change
some
of
the
semantics
and
have
loading
bays
of
a
sink
in
some
cases
and
okay,
it
just
needs
to
be
very
clear:
separation
between
what
we're
not
using
a
choir
and
Chloe,
expect
there
and
stop
forming
my
opinion
on
it.
It's
not
super
clear
to
me
yet.
J
J
B
So
so
one
thing
that
I,
like
would
like
to
say
and
I,
think
I
confirmed
that
with
Bradley,
is,
is
that
having
a
single
owner
would
mean
that
note
can't
do
like
any
future
implementation
of
top-level
await
and
that
would
kind
of
suck
so
generally
I
I.
I
think
I
agree
with
what
mile
said
and
the
direction
in
which
I
think
Bradley
is
tending
to
which
was
like
having
an
icing
loader,
even
if
it
sucks
yeah.
D
There
are
different
parts
of
tc39
because
it's
a
very
individual
driven
place
and
some
people
really
want
to
push
for
top
level
of
weight
and,
to
the
extent
that
they're
viewing
note
is
being
okay.
If
node
cannot
support
it
like
honest
EDD,
if
we
ship
a
synchronous
loader,
we
can't
ship
top
level
away
because
it
requires
running
j/s
code
on
different
terms
of
the
event
loop.
D
D
E
K
I'm
also
forming
my
opinion
and
both
of
these
option
look
like
a
big
amount
of
hurt
for
either
the
JS
ecosystem
as
a
whole,
meaning
if
we
go
with
sink,
then
there's
a
lot
of
you.
Don't
get
interrupted
ouster
if
we
go
with
a
sink
now,
where
we'll
have
a
lot
of
issues,
subtle,
behavior
differences
between
people's
expectations
or
from
what
a
module,
how
module
should
be
loaded,
and
we
have
so
much
ecosystem,
that's
written
in
a
way
that
assumes
that
everything
is
going
to
be
sink
and
nothing
underneath
the
covers
a
few
levels.
K
B
K
D
B
So
one
thought
that
I
had
this.
That
then
I
would
expect
the
module
seduction
to
start
like
from
from
from
the
end
user
kind
of
yeah
like
in
applications
themselves
and
not
necessarily
in
the
ecosystem,
because,
like
our
for
the
foreseeable
future,
all
NPM
modules
are
going
to
use
common
GS
because,
like
just
to
support
old
versions
of
node
so
having
an
async
loader
might
not
be
as
painful
because
I
I
think
it's
still.
It
won't
make
any
problems
I'm
lot
in
common
jazz
modules,
from
from
yes
six
modules,
so
that
yeah.
A
Yeah
so
as
like,
as
I
said
earlier,
I
set
up
a
meeting
with
three
people
to
kind
of
get
a
better
idea
from
people
who
actually
help
new
people,
learn
javascript
and
node,
or
have
done
that
in
the
past
or
programming
in
general.
What
they
thought
would
be
better,
for
you
know
people
and
now
and
in
the
future
learning
these
things
so
I
talked
to
Ashley
Williams
who's
previously
done
on
education,
stuff,
Steve,
kill
knee
from
Chung
school
and
rice
rankest,
any
of
hack
of
you
and
pretty
much.
A
Everyone
agreed
not
really
necessarily
moving
my
opinion,
but
I
want
to
show
these
anyways
so
no
matter
what
we
do
would
be
really
good
if
we
could
have
behavior
around
existing
things
specifically
require
be
explicit.
So
if
we
do
change
it,
so
I
know
Matt,
no
matter
which
way
we
do
it,
but
more
specifically,
for
the
async
case,
where
you
could
have
two
behaviors
from
require
I
would
be
a
lot
better
if
we
could
just
not
have
required.
A
A
A
So
that's
that
perspective,
Thanks
I
still
think
it
will
be
very
painful
for
the
existing
ecosystem
to
move
on
to
yes,
modules.
I
think
it's
a
nice
sentiment
to
have
that
modules
won't
necessarily
be
the
first
ones
to
switch
to
using
ES
modules,
but
I'm
worried
that
they're
still
be
a
large
enough
portion.
That
does
that
will
cause
large
downstream
issues
and
well
yeah.
E
For
the
benefit
of
people
listening
on
the
stream,
I
want
to
read
what
I
wrote
in
the
chat
for
everybody
that
nobody's
responded
to
which
I'm
going
to
take
is
meaning
that
people
generally
agree
with
it.
So
since
we're
voting
on
an
EP,
what
we're
really
really
saying
with
it?
Well,
if
we
vote
what
we're
really
saying
is
if
we
had
to
build
this
today,
this
is
how
we
think
we
do
it.
It's
not
a
commitment
to
doing
it.
E
D
E
A
E
F
D
No
matter
what
import
as
a
function
will
return
a
promise.
It
will
never
do
any
actual
evaluation
on
the
same
tick,
so
it
is
always
a
synchronous
and
all
the
existing
EPS
we've
accepted
so
far.
We've
somewhat
mandated
that
you'd
be
able
to
require
es
modules
and
you'll
be
able
to
import
common
Jess
with
what
Jeremiah
said
it
may
may
seem
that
require
should
throw
when
you
try
to
get
ahold
of
the
newest
module.
According
to
those
people
who
more
experience,
teaching
things
which
would
be
different
than
anything,
we've
accepted.
A
H
F
D
F
G
J
D
A
D
F
D
D
We'd
be
able
to
get
a
hold
of
these
module
name.
Space
objects
reliably
because
they're
a
static
shape.
You
know
what
properties
they
have
after
parsing,
but
they
have
the
same
problem
that
let
and
const
can
have
where
if
they
are
not
fully
initialized
and
you
try
to
access
a
property
off
them,
it
throws
an
error.
So
if
you
try
to
access
an
impotent
variable
and
it
hasn't
been
initialized
because
it
requires
some
asynchronous
thing
or
it's
a
circular
dependency-
then
it
grows
on
variable
access.
E
We're
we're
coming
up
on
the
end
of
the
I
mean
like
we
basically
a
choice
at
this
point.
We
can
keep
talking
about
this
inside
that
we're
not
talking
about
anything
else
on
the
agenda
which
I'd
be
okay
with,
but
I'm,
not
sure
everybody
else
would,
or
we
can
try
to
make
a
decision
on
this
now
or
we
can
decide
that
we're
not
actually
make
a
decision
on
this
today
and
we
need
to
make
a
decision
and
get
up
or
something
or
I
don't
know.
A
You
I'm
going
to
answer
two
quick
questions
from
the
chat
that
are
specifically
about
this,
so
why
does
node
want
to
have
synchronous
imports
that
is
so
that
you
could
require
using,
require
Gnaeus
module
and
have
it
exact
act
exactly
the
same
or
essentially
the
same
two
to
you,
your
perspective,
using
it
as
requiring
a
common
test
module
and
also
if
node,
follows
the
spec,
would
it
be
required
to
eye
doc
js2
the
pass
nope?
It's
not
required
in
browsers:
either
they
use
content
I
protection.
We
use.
We
actually
use
extension
detection.
E
G
F
G
E
G
G
E
So,
hey
for
a
long
time,
we
gets
treating
the
assert
modules
locked
status
as
sort
of
like
we're
not
going
to
fix
bugs
in
it
unless
it
affects
us
in
our
tests
and
I.
Don't
think
that's
right,
I
think
we
should.
I
think
if
you
know,
if
someone
wants
to
make
it
work
with
maps,
you
know
make
assert
equal
warp
maps
or
something
or
whatever
is
broken
with
it.
We
ought
to
except
those
things
as
long
as
it
does
not.
You
know,
as
long
as
we
don't
expect
it
to
cause.
E
You
know,
ecosystem
breakage
and
as
long
as
it's
not
adding,
you
know
adding
new
API
components
as
long
as
it's
just
doesn't
change
the
actual
API,
but
you
know
the
method,
signatures
and
I
guess
I
think
the
ctc
should
make
a
firm
decision
on
that
one
way
or
the
other,
because
there's
definitely
some
people
who
feel
one
way
and
some
people
feel
the
other
way.
So
I
would
like
to
call
for
a
vote
on
that.
G
A
And
I'm
I'm
pretty
sure
I've
suggested
in
the
past
that
I
think
we
should
actually
I
think
it's.
The
way
we
deal
with
the
assert
module
is
perhaps
a
little
bit
silly,
although
we
do
need
to
be
careful
about
it.
I
think
the
current
policy
was
to
not
change
it,
except
if
we
needed
it,
but
that's
like
kind
of
weird.
Maybe
we.
J
Anyway,
someone
else
for,
if
we're
going
to
deprecate,
it
would
make
sense
that
we
should
at
least
like
break
it
out
into
a
module
that
people
can
install.
But
it
seems
to
me
the
kind
of
thing
that
would
be
pretty
breaking
a
lot
of
people
are
relying
on
our
assert
whether
or
not
like,
I'm
pretty
sure.
If
you
go
in
and
take
a
look
at
like
glob,
a
cert
is
being
used
in
there
like
whether
or
not
we
want
it
being
used.
E
A
Know
I
mean
I,
don't
really
think
like.
We
probably
want
to
add
new
features
to
it
like
pretty
much
ever
if
possible,
but
I
mean
I,
don't
it
I
mean
there's
been
at
least
in
like
es6
new
new,
deep
structures
added
specifically
like
maps
and
sets
and
I
mean
treating
those
difficult
differently
than
we
do
objects
of
the
objects
or
arrays.
It
just
seems
strange
and
kind
of
archaic
to
me.
E
E
Okay,
so
I'm
going
to
write
this
up,
I'm
going
to
write
this
up
as
a
separate
like
I'm
gonna,
I'm
going
to
remove
this
label
from
the
mostly
unrelated
PR
that
it
was
attached.
2,
I'm
going
to
write
this
up
as
something
separate
that
then
CT,
you
know
I'll
put
a
ctc
review
label
on
it
and
people
can
can
you
know,
plus
one
lgtm
or
whatever
and
hopefully
that'll
just
take
care
of
this
and
I
could
leave
everybody
alone
about
it,
and
then
we
can
go
about
fixing
bugs
that
are
in
the
cert
module
here.
B
E
E
I'm,
okay,
with
it
being
locked
just
as
a
signal
that,
like
we're
not
going
to
add
new
methods
to
it,
I'm,
okay,
with
that,
just
as
long
as
we
don't
treat
locked
as
meaning
that
we're
not
going
to
fix
bugs.
That's
that's
that's
my
my
issue
like
I,
think
the
fact
that
treats
maps
differently
than
objects
is
above.
J
So
so
one
thing
I
think
that
may
be
worth
looking
at.
This
is
like
a
higher
level
thing
that
we
could
fix
is
maybe
we
need
to
change
our
system
in
general
for
how
locked
works,
because
when
the
language
isn't
moving
as
fast
locked
made
sense
in
the
fact
that
you
wouldn't
have
to
add
new
things,
but
since
we're
going
to
be
the
sense,
is
kind
of
like
more
we're
having
new
things
come
every
year
we
may
be
needing
to
make
changes
to
all
sorts
of
locked.
J
A
H
H
H
A
I
mean
I,
think
I'm,
okay,
with
it
lending
in
the
depths
in
some
way
well
in
in
corn.
Some
way
I
was
actually
thinking
but
I
think
it
wouldn't
be
too
hard
in
the
future.
If
we
really
wanted
it
to
it's
code
base
to
live
in
core
or
if
it
was
living
in
corn,
we
want
it
to
move
out
and
bender
it
I.
Don't
think
either
way
would
be
too
difficult
to
do
so.
I'm
not
sure
if
it
really
matters
too
much
in
which
way
we
do
it
at
first.
A
I
G
I
A
A
A
You
like
that
as
a
as
a
no
so
I
just
at
the
end
here,
I
think
that's
everything
unless
someone
else
basically
has
someone
someone
brought
this
up
and
wanted
us
to
discuss
it.
If
we
had
time
so
there
is
a
summer
major
pull
request
for
symbol,
key
props
to
be
visible
and
inspection
by
default,
I
think
from
util
dot
inspect
that
is
so.
I
have
labeled
that
with
ctc
review,
I'm,
not
sure
if
anyone
has
anything
to
nope
here,
but
then
we
can
at
least
get
a
decision
on
it.
A
E
A
A
A
I
think
at
what
time
zone
is
this
in
at
seven
p.m.
gmt
tomorrow
there
is
a
benchmarking
working
group
meeting
for
profile,
guided,
optimization
and
then
there's
another
one,
the
next
day
at
two
p.m.
UTC
on,
for
you
don't
think
that
first
time
was
quite
right.
That's
what
it's
on
the
calendar,
7pm,
UT,
sorry
gmt!
Maybe.
A
A
A
So
do
we
have
it
like
the
most
viewers
we've
ever
had
at
like
21?
What
concurrent
the
person
who
brought
up
that
issue
that
we
last
discussed
asks
what
would
help
bring
most
people
into
knowing
this
ish
issue
other
than
time
I
think
the
CCC
review
label
should
hopefully
help
with
them.
Anyone
else
have
comments.