►
Description
B
Welcome
to
the
nodejs
core
technical
committee
meeting
for
July
19th
2017
I
want
to
thank
Ali
in
advance
for
agreeing
to
take
minutes,
so
we're
gonna
start
off
with
some
announcements.
Then
we
review
the
previous
meeting
and
then
we're
going
to
launch
into
our
five
agenda
items
the
one
announcement
we
have
is
code
and
learn.
There's
going
to
be
a
there's,
one
code
alert
schedule
for
note
interactive
in
Vancouver
in
October
there's
another
one.
That's
been
announced
for
note,
convey
you
in
November
the
tayo.
C
C
We
are
also
looking
for
for
mentors.
There
is
a
github
issue
open
on
the
nodejs
code
and
learn
repo.
So
let's
use
that
for
tracking
and
as
far
as
I
understand
that
can
be
some
budget
to
be
allocated
from
the
TSC
for
any
collaborators
that
are
listening.
So
if
you
want
to
come
and
have
very
happy
otherwise
see
you
and
not.
Confuse
I
would
like
to
also
to
say
that
not
confuse
line
up
looks
amazing
and
it
will
be
announced
in
the
next
few
in
the
next
few
days
and.
B
Just
in
case
anyone's
confused
code
and
learn
is
the
event
where
no
node.js
contributors
assist
other
people
who
want
to
start
contributing
with
getting
their
first
contribution
and
if
any
of
you
are
planning
on
being
there,
just
let
us
know
cool
I
mean
the
link
is
in
these
in
the
minutes
to
the
issue.
Another
thing
that
being
announced
is
the
call
with
periodically
the
Google
v8
team
and
the
nodejs
CTC
and
I
think
some
of
its
TSE
as
well
have
a
meeting
and
to
discuss
things.
B
D
Here's
the
link
that
tells
me
that
has
to
have
it
announced
the
a-team
would
just
like
to
do
an
update,
like
just
general
consensus
around
a
handful
of
topics,
there's
a
mostly
listed
in
the
issue.
This
includes
the
turbofan,
the
ignition
stuff,
but
also
a
handful
of
other
things
that
they're
interested
but
yeah.
So
the
configure
of
work-
and
you
know,
hopefully,
set
up
a
call.
Maybe
in
two
weeks
from
now
it
seems
like
a
good
amount
of
time,
cool.
B
Anything
anyone
wants
to
add
to
that
all
right.
Awesome,
okay,
the
last
meeting
which
was
I
think
over
a
month
ago,
we
talked
about
noting
end
of
life
platform
is
whether
supported
or
not.
We
ended
up
having
some
discussion
but
pushing
pushing
the
decision
and
discussion
back
into
github
and
the
pull
request
was
eventually
merged.
That's
nodejs,
slash
mode
pull
request,
number
one,
two,
six,
seven
two!
If
that
sounds
like
it's
of
interest:
okay,
so
that
was
the
announcements
that
was
the
previous
meeting
the
first
item
on
the
agenda
today.
B
B
James
created
an
internal
error
system
that
would
allow
errors
to
have
a
code
that
never
changes,
and
then
the
messages
can
change
as
needed
and
there's
been
some
disagreement
about
whether
or
not
we
can
now
consider
message
changes
to
be
December
patch
or
whether
we
will
only
be
able
to
do
that
at
some
point
in
the
future
or
whether
we'll
ever
be
able
to
do
that.
So
I'm
gonna
kick
this
over
to
James
to
see,
if
there's
anything
else,
he
wants
to
add
as
context
a
whole.
E
Lot
other
than
we've
been
kind
of
working
on
getting
these
error
codes
introduced
initially,
my
very
first
take
out.
It
was
to
do
them
all
at
once,
and
that
proved
unworkable,
because
it
just
record
too
many
read
bases
and
constantly
keeping
up
up
to
date,
so
decided
to
piecemeal
it
out
and
do
individual
modules
at
a
time.
E
Unfortunately,
we've
we've
actually
been
having
a
bit
of
a
difficulty,
getting
those
reviewed
and
landed
quickly.
So
it's
taking
a
longer
time
to
get
that
that
condition.
Open
number
major
change
requires
two
CTC
members
to
sign
up.
Francisca
and
Dawson
have
jumped
in
to
help
move
that
process
along,
but
it's
still
rather
slow
going.
G
You
know,
declare
them
not
semper
major
that
we,
you
know
once
we
add
the
code,
we
need
end
user
code
to
start
using
the
code
instead
of
the
messages,
and
so
you
know
I
was
thinking.
We
need
a
fairly
good
amount
of
messaging
to
the
community
and
maybe
some
amount
of
time
so
that
people
can
adopt
using
the
error
codes
and
then
once
we're
comfortable
that
we're
at
that
place,
then
we
can
make
them
not
December
major
I'm
thinking.
You
know.
G
Once
we
get
them
all
change,
then
you
know
we
should
be
messaging
along
the
way.
Once
we
get
them
all
change,
we
should
really
be
messaging,
saying
hey,
you
know,
as
of
release,
X
we're
gonna
change
our
policy,
and
so
that's
sort
of
what
you
know.
What
I
contributed
to
the
discussion.
I'm
always
a
little
more
conservative
about
those
kinds
of
things,
though.
So
there
were
some
discussion
about
you
know.
Maybe
we
could
change
the
current,
the
ones
that
have
already
been
codified
in
you
know
a
previous
ember.
D
G
E
It's
very
first
contribution
because
of
the
fact
that
landing
one
requires
others
to
be
rebased
and
there's
also
some
coordination.
So
as
long
as
it's
message
properly
with
the
people
that
are
doing,
it
is
their
first
contribution
that
you
know,
maybe
a
little
patience
is
required
and
they
are
assembler
major
changes,
so
they
require
more
review.
Yeah,
okay,.
B
G
I
mean
I
think
for
like
truly
new
new
people.
It
is
a
bit
of
a
it's.
Certainly
I,
don't
know
how
major
but
I'd
say
it's
a
big
step
up
from
the
you
know,
changing
some
strings
concatenating.
You
know
it
getting
the
error
messages
and
sometimes
using
the
the
internal
errors.
The
right
way
takes
a
bit
more
thought
so
I
also
not
sure
it
would
be
great,
a
great
fit
for
the
code
and
learn
would.
B
C
Yeah,
we
need
some
help
on
readable
screen,
good
this
to
happen
in
as
I
noted
elsewhere,
and
they
spoke
a
lot
with
James
as
well
as
this.
So
it's
nothing
new
really
discussion
is
that
you
know
you
seem.
You
would
like
to
maintain
the
same
code,
the
same
code,
the
same
error
codes,
but
in
order
to
do
so,
we
we
will
need
to
actually.
C
G
Why,
like
way,
I've
written
a
short
blog,
you
know
a
little
while
back
just
to
encourage
people
to
contribute
more
to
the
effort.
One
of
the
things
I
did
suggest
there
was
that
if
you
have
to
support
multiple
versions,
it
may
not
be
ideal,
but
you
can
basically
change
your
code
to
say
if
a
code
exists
then
use
that
code,
otherwise
fall
back
to
the
string
that
you
ate
I,
guess
really.
G
E
So
the
issue
is
that
as
we're
changing
the
code
inside
core
to
use
internal
the
internal
errors,
but
if
we,
if
we
migrate
to
the
streams
code
to
use
that,
then
it
introduces
a
variance
with
the
the
read
all
streams
module
itself.
So
the
plan
that
I
have
is
to
act
now
and
I've
actually
already
started
on.
This
is
to
have
a
standalone
module,
which
is
an
implementation
of
the
internal
errors.
Api
that
readable
stream
can
depend
on
so
that
it
can.
You
know,
rather
than
doing
a
you
know
and
require
internal
errors.
E
C
E
E
Browsers,
have
rather
inconsistent
support
for
custom
error
subclasses,
so
we'll
need
to
do
some
additional
testing.
The
thing
that's
holding
that
work
up
is
a
fact
of
the
error
codes
themselves
and
all
the
messages
are
rather
unstable.
So,
if
I
create
that
module
now
and
publish
it,
I'll
be
updating
it
weekly.
So,
ideally
we
would
get
these
error
codes
migrated
as
quickly
as
possible.
I
can
produce
that
that
module
the
gentleman
module
and
readable
streams
will
be
able
to
use
that
as
a
dependency
and
things
just
work
as.
C
A
complete
different
in
following
a
completely
try
to
see
a
different
approach.
What,
if,
as
part
of
the
what?
If
we
instead
of
storing
error
codes
in
in
code,
we
store
their
records
in
a
JSON
file
or
something
that
can
be
actually
closest
and
we
can
actually
say
a
node
give
me
all
this.
Give
me
all
these
error,
codes
or
I
can
read
them
from
source
so
that
we
can
be
part
of
the
transformation
phase
of
readable
string.
Also.
E
And
incrementally
yes,
I
want
to
get
to
that
getting
get
there.
I
mean
the
original
place
where
I
first
started
with
this
effort
was
to
take
all
the
error
codes.
You
know
the
error
information
having
a
sitting
out
and
ICU
resource
for
some
arcs
and
was
told
no,
you
know
having
a
my
sternal
was
too
complicated.
Let's
just
start
simple
and
just
have
them
in
the
code
directly.
That's
right!
That's
where
I
ended
up.
If
we
ultimately
get
to
where
we
can
externalize
these
codes,
then
great,
that's
only
part
of
the
problem.
E
The
other
part
of
the
problem
is
the
API
itself,
the
new
errors,
dot
error
or
new
errors,
dot
Ranger
right.
We
want
to
reduce
the
variance
between
the
code
in
core
and
work
in
readable
streams
if
we
can
have
the
same
API
implemented
and
we
don't
have
to
make
any
code
changes.
However,
the
actual
errors
get
loaded
near
messages
get
loaded
into
the
system.
C
B
So
I'm
gonna
ask
that:
is
it
possible?
We
can
I
mean
this
is
all
good
stuff
as
possible.
We
can
move
it
back
to
github.
The
main
reason
this
was
on
the
agenda
was
just
to
make
a
determination
about
whether
message
changes
in
the
new
system
or
considered
semper
major
or
not,
and
it
seems
like
there's
consensus
that,
for
the
time
being
they
should
is.
That
is
that
clear.
G
B
Okay
thanks
the
next
issue
and
I'm
just
taking
them
in
the
order
that
they
were
added
to
the
agenda.
I
think
this
one's
gonna
be
pretty
quick.
It's
the
es
proposal.
Yes,
module
proposal
that
I've
ever
put
in
I
think
there's
cuz
made
a
little
bit
more
in
the
github
issue,
tracker
and
maybe
pick
it
up
next
time
in
two
weeks,
possibly
inviting
a
guest
or
two
to
to
the
have
anything
they
feel
needs
to
be
talked
about.
B
Okay,
great
then,
let's,
let's,
let's
declare
that
done
we're
going
to
leave
it
on
the
agenda
for
next
time
miles.
I
think
you
wanted
e
turbofan
an
ignition
release,
plan
and
communication
plan
item.
This
is
a
CTC
issue.
155
is
that
right.
C
D
D
We
want
to
make
sure
that
people,
aware
of
what's
going
on
that
there's
good
communication
and
also
making
sure
that
we
do
the
foundation
enough
of
a
heads
up
that
you
know
we
can
do
a
media
push
around
the
same
time,
so
that
issue
was
opened
and
we
pinged
Tzipi
from
the
foundation,
and
you
know
the
foundation
pretty
much
seemed
like
they
just
need
a
couple
days
notice.
If
we
give
them
even
just
a
weeks
notice,
but
definitely
more
than
enough,
then
the
secondary
issue.
D
D
I
can't
find
it,
but
it
lists
a
public
date
of
the
release
of
chrome,
which
is
in
a
couple
weeks
from
today,
so
like
in
less
than
a
month
from
today.
Essentially,
we
have
a
fairly
high
probability
of
6.0
being
out
in
a
release.
So
the
hanging
question
there
is
like
around
you
know:
do
we
actually
have
anything
to
gain
by
getting
5.9
out
earlier
and
I
know
that
we
had
people
from
the
from
the
cgc
who
wanted
to
see
it
up
earlier
to
catch
regressions?
D
F
H
So
so
the
the
getting
more
after
more
code
through
turbofan
and
if
there's
regressions,
that
we
haven't
fixed
yet
that
will
be
found
by
a
few
feedback.
What
would
be
good
to
have,
but
at
the
same
time
there's
the
risk
that
we'll
get
feedback
about
lots
of
regressions
that
have
already
been
fixed
so
so
yeah.
It's
unclear,
I'm
torn
on
this
as
well.
I
guess.
G
H
Yeah,
if
we
are
able
to
ship
with
6.0,
that
would
be
better
because
we
will
be
shipping,
something
that's
closer
to
the
final
thing
that
is
going
to
be
in
node,
a
node,
eight
LPS
and
any
any
feedback.
Profound
feedback
that
we're
going
to
get
is
going
to
be
a
lot
more
pertinent
as
well
like
it
wouldn't
have
known
regressions
that
have
V
effects.
C
D
D
I'm
personally
comfortable
with
it
I
personally
think
that,
to
be
honest,
like
we're,
actually
even
helping
the
chromium
project
by
doing
so,
because
if
we
catch
educators
there,
we
have
the
ability
to
have
those
fixed
upstream
and
landed
into
the
branch.
Officially,
not
just
as
like
patches
that
we
float
so
I.
Think
in
general
we
should
really
be
revisiting
a
more
a
more
like
exact
plan
as
to
when
we
land
particular
branches
of
v8,
into
into
the
particular
relief
lines
and
into
master
I.
D
Think
that's
another
call
on
another
discussion
for
us
to
have
all
together,
but
I
personally
think
that
the
be
kind
of
like
split
the
difference
on
the
two
different
approaches
that
were
thrown
out
in
that
issue
right
now
is
to
actually
wait
for
the
stable
branch
freeze,
which
is,
you
know,
coming
very
soon
and
land
that
and
ship
that
an
aid
and
then
any
of
the
up.
The
extra
patches
that
end
up
getting
landed
between
there
then
any
official
release
of
chromium.
We
can
just
downstream
the
newer
versions
of
the
eight
I.
G
D
H
Chrome
Chrome
Beta
already
has
6.0,
it
will
promote
to
chrome
stable
around
August,
first
or
so
so
so,
if
we
ship
with
ship
a
release
candidate
with
6.0,
then
we'll
be
in
a
very
similar
boat.
If
we
ship
an
actual
release
with
it,
then
we'll
be
shipping
6.0,
maybe
a
week
earlier
than
chrome
ship
said
I
think
can
be
independent.
I,
don't
think
we
necessarily
have
to
follow
the
chrome
schedule
for
declaring
a
v8
version
to
be
stable.
D
That
was
basically
the
point
that
I
was
trying
to
get
across.
That
was
like
as
a
point
of
the
stable
branches
cut,
the
VA
team
is
declaring
it
stable
and
then
it's
getting
smoked,
busted
more
by
the
embedder
before
being
released.
So
there's
no
reason
for
an
example
that
we
couldn't
start
an
RC
process
at
that
point
and
run
like
a
two-week
arty
with
6.0
to
overlap
with
the
RC
process
of
the
chromium
project
yeah.
Certainly,
the
RC
makes
tons.
I
D
D
But
I
I'm
personally
comfortable
with
us
moving
into
that
process,
and
we
probably
do
want
to
like
cut
like
I
mean
speaking
to
the
idea
of
maybe
shipping
five
nine
next
week.
It
would
probably
should
do
on
our
seed
so
like,
since
the
stable
branch
cut
is
happening
like
we
could
do
a
five
3rc
with
the
6.0.
That's
to
that
branch
cut
run
that
our
see
for
like
two
weeks
and
just
update
to
like
whatever
the
latest
version
of
the
ADA
is
right.
Before
we
do
the
release.
F
I
find
it
very
hard
to
follow
this
by
looking
at
the
calendar.
It
would
be
much
easier
and
it
gets
the
issue
and
I'm
not
super
comfortable,
pushing
this
release
earlier
than
what
we
usually
do.
I
mean
usually
we're
conservative
with
the
stable
releases
and
I'm,
not
really
in
favor
of
throwing
out
dates
here
in
a
meeting
and
then
just
rolling
with
it,
because
nobody
is
fully
aware
of
what
the
dates.
F
E
What
I
think
that
another
another
thing
I'm
looking
at
is
that
we
are,
we
are
getting
close
to
the
709
print
and
the
I'm
actually
started.
You
know
going
to
be
looking
at
starting
cutting
b7o
branch.
Probably
early
September
I
mean
I.
G
E
Other
night
no
branch
story
which
means
review,
know
we're
going
to
have
we're
going
to
be
starting.
The
deny
no
release
candidate
process
by
you
know
mid
to
late
September
release
betas.
That
kind
of
thing
I'm,
not
sure,
if
it's
going
to
make
sense,
given
the
remaining
timeline
to
push
too
hard
on
getting
six
into
into
a
text-
and
you
know
any
be
released,
cut
is
next
week.
I
understand
III
understand.
But
if
we're
talking
about
having
a
sever
week-long
release
candidate
process,
I
mean
the
the
timeframe
for
nine
Oh
should
also
be
considered.
A
D
At
this
point,
I
mean
James,
to
be
honest,
like
just
speaking
to
what
you
were
saying
before,
like
we
should
be
likely
running
an
RC
with
offend
ignition
before
doing
the
ruler
way,
so
we're
talking
about
the
difference
of
about
a
week
if
we
want
to
cut
with
the
six
so
stable
trees,
which
is
next
week
so
like
personally,
my
gut
is
saying
we
should
push
this
back
to
the
issue
that
we
just
focused
on
testing
and
releasing
six
now
and
living
with
the
current
time.
So.
A
G
G
You
know,
there's
been
a
fair
amount
of
discussion,
there's
probably
still
a
little
bit
of
discussion.
You
know
refinement
on
the
Charter
itself,
but
I
think
it's
close
enough
to
what
it
you
know.
It
certainly
captures
the
scope
and
and
sort
of
responsibilities
that
would
be
delegated
and
so
I
added
it
on
here,
because
I
think
we
want.
You
know
some
feedback
from
the
CTC
to
say
yes,
we're
comfortable
with
that
scope,
or
you
know,
or
not
so
basically
give
that
first.
G
G
F
G
E
E
B
G
B
Okay,
then,
if
there
are
no
objections,
we
move
on
to
the
last
item
on
the
agenda
which
miles
put
on
at
the
last
minute
here,
not
sure
how
much
we're
going
to
be
able
to
cover
with
it.
But
let's
try
consider
using
another
option
like
Google
meat
instead
of
uber
conference.
Do
you
want
to
have
this
conversation
right
now
miles,
or
do
you
want
to
like
just
make
a
note
that
we
need
to
open
an
issue
or
something
or
anyone
handle
this.
D
D
Okay,
so
quick
one
on
it,
like
basically
I
can
set
up
a
google
meet,
so
we
can
use.
Google
meet
is
very
similar
to
BER
conference.
It
gives
you
a
number
that
you
can
dial
in
with.
If
you
want
to
go
by
phone
or
you
can
go
in
via
the
you
know,
the
message
it
does
video
much
like
hang
up
kind
of
the
next
version
of
hangouts
is
a
Google
employee
sets
it
up,
I've
been
told
we
can
do
it,
we
can
use
it
publicly
and
it
can
support
up
to
50
people.
D
It's
free
I
believe
we
would
have
more
granular
control
over
people
who
would
be
like
be
able
to
like
come
in
and
manage
it
and
make
sure
that
the
people
who
are
going
in
other
people
who
should
go
in
it's
explicitly
invite
only
you
can
make
it.
It
has
built-in
recording
similar
to
what
we
have
on
here,
although
I
believe
it
would
also
record
the
video,
which
is
a
nice
addition.
D
As
far
as
I
know,
it
does
not
have
broadcast
to
YouTube
like
hangouts,
yet
I
can
do
more
internal
searches,
but
either
way
it
puts
us
in
no
different
position
than
uber
conference.
If
we
were
to
do
it,
if
people
are
open
to
it,
we
could
do
just
a
little
test.
I
would
be
more
than
happy
to
handle
running
like
just
a
test
meeting
on
meat,
just
to
make
sure
that
it
would
handle
our
needs,
but
I
think,
like
the
very
simple
proposal
would
just
be
hey.
G
A
G
D
I
think
what
we
could
do
is
a
handful
of
us
are
going
to
be
a
node
summit
next
week.
So
maybe
at
one
point
during
next
week,
what
we're
all
physically
in
the
same
space.
We
should
set
this
up
and
try
to
do
it
and
like
just
since
we're
in
the
same
space,
we
can
just
figure
out
what
all
the
edge
cases
of
other
people
joining
and
like
just
work
through
different
educators
like
I'm,
not
there
and
just
see
what
makes
sense.
I'm
gonna
put
back
before
the
next
meeting
sounds.
B
B
B
My
goodness,
yes
I
guess
we
do
I'm
sorry,
Olli
I
totally
forgot
about
the
Q&A,
hey
so
comment
and
irce
or
in
the
youtube
channel,
or
something
like
that:
I
guess
to
stall
for
time.
While
we
collect
questions,
usually
read
off,
meetings
open
the
calendar,
and
so
we
got
community
committee
meeting
is
happening
in
little
more
than
24
hours,
the
1:30
p.m.
Pacific
Daylight
Time
tomorrow
and
there's
an
odious
board
meeting
next
Tuesday
my
20
film.