►
Description
A
B
D
A
F
Right
so,
like
everybody
else
note,
interactive,
also
still
trying
to
get
octane
added
to
the
benchmark,
run.
Results
than
review
miscellaneous
review
comments,
lands
working
a
little
bit
on
the
process
to
get
work
groups
more
control
over
builds
associated
with
their
own
work
groups
like
such
a
mobile
people
being
able
to
launch
those
jobs
and
so
forth
and
ongoing
work
on
the
VA
stable
module
front.
I
J
A
G
K
A
A
One
will
do
that
and
discuss
the
EP
for
the
API,
a
stable
module,
API
or
napi
nappy,
node,
ap
I,
suppose
that's
the
short
form
for
and
then
we're
also
going
to
talk,
moving
node
in
dash
inspect
into
core.
So
for
the
previous
meeting
we
discussed
reverting
the
runtime
deprecation
of
calling
buffer
without
new.
That
has
landed
in
seven
point
two
point
one.
So
that's
closed
out
unless
anyone
has
anything
else
to
mention
on
that
will
move
into
day's
agenda.
A
A
Was
me
ok,
so
the
gist
is
that
npm
has
gone
to
the
next
major,
which
means
that
three
point
x
is
pretty
much
only
going
to
be
in
maintenance
mode
or
their
version
of
maintenance
mode
just
pretty
similar
to
ours.
I
think
so
the
question
is
really
like:
how
much
impact
do
we
think?
Well,
I,
guess
there's
a
couple
questions
like
how
much
impact
do
we
think
this
will
have
and
then,
when
do
we
want
to
do
it?
A
F
M
F
A
They
did
indicate
that
then
the
v5
is
probably
not
going
to
be
a
particularly
large
jumpy
there.
So
I
think
we're
discussing
on
between
v7
and
v8,
maybe
v6,
but
I
don't
think
we'd
want
to
do
this
in
an
LTS
release,
but
for
a
current
release
it
might
might
be
okay
to
do
it's
not
really
part
of
our
API
I.
M
Think
it
becomes
difficult
I
know.
Yesterday,
I
saw
that
there
was
an
issue
and
there
they
had
consider
not
back
pouring
into
beef
version
3,
but
they
think
they
ended
up
back
for
unit
2
version.
3.
So
I
think
that
that
is
something
we
need
to
take
into
account
like.
If
version
3
is
just
maintenance
mode
and
they're
not
going
to
be
doing
any
more
releases
on
it,
then,
if
there
is
a
broken,
when
we
would
either
have
to
like
float
patch
or
go
with
the
whatever
one's
being
maintained,.
F
Because
it's
still
it's
in
these
sick
in
our
notes,
X
right,
yeah
right
so
they're
going
to
have
to
you
know
we're
gonna.
Have
that
same
issue,
I!
Guess!
The
question
is:
is
there
what's
the
advantage
of
putting
it
into
these
into
note,
7,
as
opposed
to
waiting
to
pumping
it?
When
we
make
a
note
8,
it
should
land
in
master
regardless
right.
A
A
A
F
A
I
I
think,
like
the
only
real
reason,
would
be
that
well,
I
guess,
there's
two
reasons
number
one:
it
is
a
little
bit
of
a
transition
so
that
when
mpm
five
comes
out
and
if
we
do
that
in
v8
and
if
there's
a
little
bit
more
breakage
Delta
well,
some
that's
kind
of
like
already
been
taken.
Care
of.
The
other
thing
is
like
I
mean
we
are.
Current
branches
are
essentially
four
features
and
I
mean
I.
It
would
maybe
be
nice
to
get
like
your
new
mpm
features.
A
I
guess
the
chip
by
default
I
mean
I,
don't
I.
Don't
really
think
like
that.
We
particularly
that
like
installing
it
particularly
is
like
any
amount
of
lock-in,
because
once
you've
installed
like
if
you
globally
installed
NPM
after
that,
like
you're,
going
to
I
think
default
to
that.
Even
if
you
reinstall
a
new
version,
node.
A
F
N
K
H
All
right
so
so
yeah,
so
that's
Rick
mentioned
there's
the
yawn
I,
don't
know
if
you
want
to
jump
in.
Let
me
know
otherwise
I'll
keep
going
so
so
the
the
old
debug
protocol
has
been
deprecated
for
two
years
and
we
had
just
removed
it
in
we
at
5.7,
so
so
by
the
node
version.
8
time
frame,
the
old
debugger
protocol
is
no
longer
be.
There
will
no
longer
be
there
an
hour
flight
CLI
debugger
is
currently
built
on
top
of
that
protocol.
So
we
need
to
stop
using
that
protocol.
H
We
do
have
the
v8
inspector
protocol
and
a
GNU
debugger
can
be
built
on
top
of
the
the
v8
inspector
protocol
and
we
actually
have
one
that
yon
has
built
a
based
on
the
new
protocol.
So
so
now
we
have
some
interesting
questions,
whether
whether
we
want
to
continue
having
so
so,
if
you
want
to
continue
having
as
first
of
all
whether
we
want
to
continue
having
a
CLI
debugger
in
node
core
itself.
H
Secondly,
whether
we
want
to
not
have
it
in
core
have
it
separately
that
works
with
the
new
protocol
but
ship
it
and
bundle
it
along.
With
note
covert
the
same
way,
we
do
for
NPM,
for
example,
or
we
can
say
actually.
This
is
something
people
can
externally
install
from
from
NPM
if
they
need
to
use
a
CLI,
debugger
and-
and
there
has
been
some
debate
about
whether
or
not
it
makes
sense
to
have
a
debugger
that
comes
by
default
with
your
new
installation.
H
Some
some
people
feel
very
strongly
about
it,
but
other
people
feel
that
actually
we
haven't
maintained
the
world
debugger
for
years,
so
so
just
having
it
in
core
isn't
doesn't
mean
it
is
not
necessarily
a
good
thing.
In
fact,
decoupling.
It
may
encourage
people
to
collaborate
on
it
more
there's
a
Grady
on
between
on
whether
or
not
it
should
be
bundled
by
default
or
not.
I
used
to
have
strong
feelings.
I
no
longer
have
strong
feelings
on
it,
but
other
people
do
so.
A
So
I
mentioned
this
in
the
thread
by
kind
of
I'm,
not
very
clear,
on
what
bundling
it
would
be
like
because,
well
does
bundling
mean
it
would
be
like
food
and
using
light
as
to
I,
inspect
I'm
like
argument
to
node
will
bring
it
up
or
what
it
would
just
install
like
note,
inspect
globally
somewhere
as
a
global,
node
module
or
like
would
bundling
it
make
it
like.
You
know,
be
just
that
argument
like
pulls
up
the
bundled
version.
H
E
I
was
actually
going
to
reply
on
that
issue.
T
Jeremiah
so
I'll
just
say
it
here.
One
way
we
could
do,
it
is
put
it
in
depth
and
then
either
put
it
behind
an
abstraction
that
gets
called
when
you
do
no
debug
or
note
inspector
yeah
I
can,
if
def
statement
or
something
that
is
behind
a
build
flag,
but
like
the
core
thing
could
be
in
in
depth,
but
it
could
still
be
surfaced.
It
seems
to
me
from
the
on
the
current
no
debug,
that's
an
option.
Alright,.
H
Yeah,
sorry
about
dropping
so
so
yeah,
so
whether
whether
we
keep
it
the
exact
same
option
or
we
say
well
instead
of
using
node
space
debug,
you
need
to
use
node
dash,
debug
or
something
it's
just
I
mean
as
long
as
it's
available
as
part
of
a
node
installation
by
default.
I
think
we
have
some
flexibility,
because
we
are
doing
a
similar,
a
change
in
which
we
are
going
to
drop
this
so
I
think
we
do
have
some
flexibility
on
how
we
want
to
bundle
it.
If
we
do
want
to
bundle
it
yeah.
E
Right
to
clarify-
and
we
should
make
sure
everyone's
on
board
with
this-
we
did
say
that
one
way
or
the
other
we
think
note
inspect-
should
be
in
the
foundation
and
a
repo
in
you
know.
Nodejs
and
just
the
question
would
be
if
it's
bundled
or
embedded
in
core.
So
if
anyone
is
opposed
to
being
a
foundation,
let
us
know
but
we're
going
to
recommend
that
to
the
tsc.
B
B
A
H
So
there's
one
complexities,
so
there
are
some
complexities
on
the
topic
of
bundling
so,
for
example,
so,
right
now,
when
we
send
sig
user
one
or
two
I
forget
which
one
that
starts
the
old
debug
protocol
and
that
label
protocol
is
going
away.
So
so
so
those
aspects
we're
probably
going
to
have
to
deprecate
right
right.
H
L
E
H
A
A
M
F
I
also
think
having
it
there
like
it's
one
of
those
fundamental
things
that
you
know
if
you're
in
production
and
needed,
or
something
like
that,
it's
not
always
easy
to
get
it
installed.
So
having
one
built
in
by
default.
There's
certain
set
a
tool
that
having
built
in
by
default
to
do
make
sense
is
the
at
the
collaborator
some
that
was.
You
know
the
keeping
note
course
small,
and
even
though
it's
shipped
this,
you
know
userland
it
stills
something
that
now
becomes.
A
Okay,
but
going
back
to
my
question,
is:
is
there
anyone
that
sees
a
win
by
having
it
not
bundled
compared
to
bundling
some
externally
maintained
solution,
I
understand,
there's
like
differences
between
maintaining
it
and
core
and
maintaining
it
somewhere
else
in
bundling
it,
but
is
there
like
any
actual
win
that
anyone
can
see
from
not
bundling
it
considering?
Well,
especially
considering
we've
already
like
had
no
debug
for
forever
pretty
much.
O
O
So
yeah,
so
one
argument
that
was
made
was
that
if
it
is
bundled
in
8.0
and
it
turns
out
to
be
a
mistake-
it's
hard
to
remove
it.
So
because
if
it
is
released
with
80
0,
then
it
has
to
stick
around
for
a
long
long
time.
So
one
question
would
be
that
would
make
sense
to
delay.
Bundling
it
until
eight
point.
X.
N
L
O
So
so
my
argument
against
aliasing,
no
t
back
directly
is
because
say
this
thing
with
remote
debugging.
So
if
you
install
node
eight
and
you
try
to
remote
you
back
something
on
a
server
running
note,
60
node
four,
then
it
suddenly
behaves
very
differently
between
six
and
eight
in
a
surprising
and
potentially
misleading
way.
We're
just
put
get
random
protocol
errors
that
aren't
hard
to
understand.
If
there's
two
different
commands,
like
note
debug,
that's
one
thing
note
inspects,
that's
a
completely
different
sinning
because
a
protocol
at
least
I
would
think
that
less
confusing,
also.
K
E
Actually,
really
interesting
point
that,
even
if
we
deprecate
the
debugger
well,
what
what
is
our
story
for
using
a
later
node
runtime
to
debug
an
earlier
one?
Maybe
we
have
to
extract
out
the
current
debugger
to
like
node,
old
debugger
or
something
and
people
could
just
use
that
on
its
own
as
a
module
48
and
later
cuz
way,
I
mean.
How
long
is
that
going
to
go.
N
B
So
I
think
like
as
far
as
as
far
as
we
talked
about
like
including
note
inspect
in
some
way
in
core
I
think
we
have
consensus
on
that.
I
mean
I
personally
would
prefer
to
DB
just
ship.
It
like
we
do
with
NPM
solution
and
just
remove
all
of
the
old
debugger
stuff
I
mean
I.
Guess
somebody
could
try
to
open
up
a
PR
with
that
and
we
will
see
where
that
goes.
F
E
A
I
think
Ali
said
in
the
thread
that
he
might
be
able
to
actually
get
removing
it
delayed
until
after
version
8,
which
would
we
be
preferable.
We
might
be
able
to
then
deprecated
it
in
version
8
and
have
the
thing
there.
Otherwise
I
think
we're
kind
of
forced
to
get
deprecated
in
version
7,
whether
or
not
it's
in
a
release,
branch
or
not,
and
possibly
bring
noting
spectacle
to
like.
If
we're
gonna
do
that,
then
we
could
discuss
having
that
as
like
an
experimental
feature,
maybe
in
version
7.
N
O
So
so
the
one
question
that
actually
attacks
work
on
those
inspect
itself
is
so
right
now
the
way
that
the
coda
structure
is
optimized
for
not
making
a
decision
whether
it
is
in
core
is,
it
would
be
bundled
so
I
think
that
there
is
a
rough
consensus
that
if
it
would
move
into
note,
if
it
would
be
bundled
it
would
be
bundles
like
NPM,
which
would
also
simplify
the
code
structure
in
no
time
spectacle.
It
wouldn't
be
constrained
to
basically
dumping
everything
in
one
big
file.
O
A
A
O
Actually,
you
know
what
belongs
to
what
is
a
little
bit
harder
to
see
if
you
split
up
into
different
files,
but
yeah
I
know
that
it
would
be
possible
to
split
those
apps
but
and
he's
at
this
stage,
where
I'm
developing
interest
in
a
separate
repository.
It
was
a
lot
easier,
as
you
put
it
into
one
file,
because
it
was
easier
to
copy.
O
O
I
O
I
experimented
with
something
like
roll
up
and
also
like,
rather,
if
I,
the
obvious
ones.
The
thing
is,
then
you
end
up
with
a
clearly
bundled
file
which
looks
a
little
bit
awkward,
that
might
be
just
aesthetics,
but
it
seemed
a
bit
hacky,
but
yeah.
So
I
think
there
was
a
rough
consensus
that
which
good
they're
getting
around
the
whole
discussion
that
if
it
would
be
funner
than
core
it
would
most
likely
be
NPM
life,
not
right.
Inside
of.
N
Lip
you
might
yeah,
I
mean
my
sense
is
that
is
that
as
long
as
there's
something
there
for
the
end
user,
that's
the
you
know
when
they
install
know
that
they
don't
have
to
go
and
install
something
else
themselves,
that's
the
important
part
and
that
the
rest
of
it.
You
know
whether
or
not
it's
included
in
the
node
binary
or
whether
it's
treated
like
we
do
npm.
You
know
that
that
can
actually
be
a
decision
based
on
what's
easiest
to
maintain
and
etc,
etc.
At
least
that's
my
impression
from
this
conversation
they
told
me.
K
B
Just
so
like,
so
everybody
knows
that
the
possibility
exists.
We
can
include
the
debugger,
even
if
we
ship
it
as
a
separate
thing
can
also
include
it
in
the
executable.
It's
really
not
huge
and
V
I
think
we
also.
We
really
do
that
for
some
of
the
v8
tools,
like
tick
processor
that
we
have,
and
those
are
also
like
taking
from
debs
v8
and
just
include
it
as
multiple
files
in
our
node
binary.
This.
E
O
O
F
F
N
And
I'm
have
I'm
I'm
happy
to
make
some
time
to
work
on
that,
but
I'm,
probably
not
the
best
person.
Honestly,
there
are
no
doubt
better
qualified
people
on
diagnostics
and
elsewhere,
but
if
nobody
else
is
like
available,
I'll
figure
something
out
but
and
I
suspect,
although
I
also
suspect
yon
won't
have
a
hard
time
doing
it,
but
yeah
eyes
on
it.
Yes,.
O
It's
like
it
isn't
just
create
a
PR
to
get
a
discussion,
started
moving
into
depth
and
just
seeing
what
what
what
people
think
I
would.
I
would
appreciate
with
someone
else,
could
do
the
like,
CBC
or
pse
thing,
because
I'm
just
not
familiar
enough
with
the
processes
and
like
how
to
do
that
part.
Yah
she's.
A
F
I
could
talk
to
that
so,
basically,
that
EPS
is
in
draft
state
and
the
goal
was
to
get
it
landed.
Not
as
you
know,
this
is
what
the
final
shape
that
the
API
is
going
to
be,
but
to
have
some
information
in
a
starting
point
for
people
to
go.
Take
a
look
at
what
what's
being
worked
on
it
kind
of
stalled
out
in
some
of
the
comments.
F
In
terms
of
you
know,
the
latest
comments
were
some
people
was,
was
one
individual,
basically
asking
for
it
to
become
more
completely
finished
before
we
did
that
the
discussion
in
the
collaborator
summit
was
that
you
know
it
likely
should
just
landed,
it
is,
and
then
it
can
be.
You
know
worked
on
as
we
move
forward,
because
in
draft
it's
not
intended
to
answer
all
the
questions
and
be
you
know,
fully
complete
and
it
was
brought.
You
know
tagged
a
ctc
to
come
back
to
this
group
to
stay.
F
N
N
F
A
very
specific
comment,
so
I
actually
transferred
those
comments,
two
issues
in
the
a
bi-stable
node
repo,
because
you
know
the
things
we
can
change,
but
there's
going
to
be
lots
and
lots
of
those.
So
one
thought
I
had
is
you
know
we're
far
enough
along
now
that
we
potentially
could
just
remove
the
part
of
the
dock
that
actually
specifies
the
functions
and
point
them
to
that
file
in
the
repo
as
a
hey,
you
can
go
look
here
earlier
on.
F
J
F
Yeah
that'd
be
great,
like
an
issue
on
the
a
bi-stable
repos,
the
best
place,
to
put
that,
so
we
can
have
the
team,
discuss
it
and
start
to
you
know
if
it's
like
change,
this
API
call
to
have
different
options
or
whatever
you
know,
we
can
start
actually
implementing
that
piece
with
suggestions.
Okay,.
K
F
There
was
an
issue
open
on
some
of
these
thing,
they're
looking
at
something
completely
different.
It
was
like
n
vine,
which
is
a
dynamic
set
of
bindings,
so
I
gave
them
some
pointers
to
look
at
what
we're
doing-
and
you
know
I
quit,
but
in
that
case
I
think
that
might
be
more
of
an
overlap
with
SFI
because
it
looked
like
it
was.
You
know
dynamically,
generating
the
code
for
a
certain
library,
so
we'll
work
through
how
those
suggestions,
map
or
don't
map
to
the
different
options.
K
And
just
not
sure
if
it
was
market,
I
def
pop
way
for
just
a
second
but
the
along
with
this
work.
For
so
everyone's
aware,
they're,
the
folks
at
Google
are
working
on
the
effort
on
an
FF
I
based
approach
for
simplifying
native
module
development.
There's
they
were
hoping
to
have
a
demoed.
They
could
show
off
how
it
works
with
next
couple
weeks,
but
what
we're
going
to
try
to
do
is
probably
by
in
the
january/february
March
time
frame
right
in
there
have
something
where
we
can
compare
this.
J
A
N
A
F
I,
don't
think
so
I
think
there
was
just
you
know.
There
was
some
community
there
at
least
one
community
comment.
That
said:
hey
we
need
you
to
rewrite.
The
whole
thing
I
think
was
brought
back
to
you
know.
If
the
CDC
says
no,
we
should
just
go
ahead,
then
we'll
just
do
that
right
or
fourth
and
I.
Don't
know
that
we
need
a
formal
vote,
but
we
were
looking
for
a
consensus
that
that's
the
right
thing
to
do.
F
A
F
And
you
know,
they'll
come
with
the
discussion
that
the
meeting
was
yes,
we
should
just
go.
Do
that
and
then
you
know
was
added
to
the
CTC
agenda.
I
guess
just
to
confirm
that
there
weren't
objections.
If
we've
got
enough
people
here
and
we
don't
think
we
need
to
do
anything
further
than
we
could
just
proceed
based
on
the
agreement.
You
know
we
can
basic
stay
with.
You
know
we
raised
at
the
ctc
this
TDC
meeting.
There
are
no
objection
so
we're
going
to
go
forward.
F
A
A
So
in
the
meantime,
upcoming
meetings,
there
only
seems
to
be
two
listed
here
next
week,
wednesday.
Again
there
will
be
a
CTC
meeting
at
twenty-hundred
UTC,
which
I
believe
was
the
normal
original
or
not,
not
necessarily
normal,
but
the
original
meeting
time,
and
then
there
will
be
a
TC
meeting
next
week
on
Thursday,
which
was
the
still
on
its
regular
meeting
time
of
20
hundred
UTC,
usually
I
thought
we
had
a
couple
of
the
working
group
meetings
listed
here,
but
maybe
that's
helmet,
tsc1.