Node Foundation TSC Meeting 2015-09-02

[rvagg]

Time

UTC Wed 02-Sep-15 20:00:

• San Francisco: Wed 02-Sep-15 13:00
• Amsterdam: Wed 02-Sep-15 22:00
• Moscow: Wed 02-Sep-15 23:00
• Sydney: Thu 03-Sep-15 06:00
• Tokyo: Thu 03-Sep-15 05:00

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node+Foundation+TSC+Meeting+2015-09-01&iso=20150901T20
• or http://www.wolframalpha.com/input/?i=8pm+UTC%2C+Sep+01%2C+2015+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1rXBdtsD9PJTExNXgzNZ9bez9oOjW45kLPjun4zdt0dY
• Previous Minutes Google Doc: https://docs.google.com/document/d/1aB76ClCgdjZUw3p-gHq9j6YwU11zWgJ4pmYPEWk6gjE

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to meeting.

nodejs/node

• deps: update v8 to 4.5.103.30 #2632
• Inspecting Node.js with Chrome DevTools #2546
• Node.js v4 Release Timeline #2522

nodejs/build

• Merge job overwrites metadata #179

Invited

• @bnoordhuis (TSC)
• @chrisdickinson (TSC)
• @cjihrig (TSC)
• @domenic (observer)
• @Fishrock123 (TSC)
• @indutny (TSC)
• @jasnell (TSC)
• @mhdawson (TSC)
• @misterdjules (TSC)
• @mikeal (observer)
• @mscdex (TSC)
• @orangemocha (TSC)
• @piscisaureus (TSC)
• @rvagg (TSC)
• @shigeki (TSC)
• @srl295 (TSC)
• @trevnorris (TSC)

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts. I'm using a tool to fetch the list so it's not a big deal to collate.

Joining the meeting

Uberconference; participants should have the link & numbers, contact me if you don't.

[jasnell]

Would love it if we could include a quick discussion on nominating new TSC members.

[jasnell]

(At least just to pull together a short list, not necessarily to decide on today)

[rvagg]

A summary for the TS of Inspecting Node.js with Chrome DevTools #2546 would be appreciated from anyone involved in there, particularly what is it that the TSC needs to care about and are we being called upon to make decisions here. Preferably this should be given here before the meeting so we don't end up wasting all our time trying to grok it all.

I tagged deps: update v8 to 4.5.103.30 #2632 because there is an outstanding question of whether we want to try and slip V8 4.5 into v4 since it (surprisingly) went stable today/yesterday. There's pros and cons to this. Pros: we get a supported V8 for longer, we get some bugs fixed and some new features like arrow functions (a weak justification but I like how this adds to the "upgrade to v4" story that we need to be pushing), possibly some perf improvements (including a potential backport or @indutny's patch that just landed there). Cons: Uncertain at this stage if NAN supports this version, it was supposed to but it looks like the V8 team may have slipped a breaking API change in that wasn't pre-announced, there's also some potential pain for addon authors who may think they are ready when in fact they are not since there has been a full s/Handle/Local and although we knew about this, it wasn't widely known to addon authors who could get away with liberal Handle usage. Also cons: limited testing, while we've had v3.x using 4.4 for a while now.

[rvagg]

TSC expansion discussion absolutely, I started an email thread about that but we should use some of the private time at the begining of the meeting to talk openly about it, I'd love to see us bring in more of the quality collaborators we have and get some more diverse perspectives and skills!

[domenic]

it looks like the V8 team may have slipped a breaking API change in that wasn't pre-announced

It would be good if this could be made a bit more concrete. Based on the thread it looks like this is referring to Local<Value> v8::Function::Call() being marked V8_DEPRECATE_SOON, which is two steps away from an actual breaking change (first, move to V8_DEPRECATE; second, actually remove).

it wasn't widely known to addon authors who could get away with liberal Handle usage.

Just want to point out that this should have been giving deprecation warnings, so there's at least some chance they'd be aware. Although there's no guarantee addon authors have been compiling with new enough V8, so I understand the general point.

[rvagg]

@domenic sorry, it's not Function::Call(), I was talking about Function::New() but looking again it and seeing the full section of the code it seems that this might be what @trevnorris was talking about too.

-  static Local<Function> New(Isolate* isolate,
-                             FunctionCallback callback,
-                             Local<Value> data = Local<Value>(),
-                             int length = 0);
+  static MaybeLocal<Function> New(Local<Context> context,
+                                  FunctionCallback callback,
+                                  Local<Value> data = Local<Value>(),
+                                  int length = 0);
+  static V8_DEPRECATE_SOON(
+      "Use maybe version",
+      Local<Function> New(Isolate* isolate, FunctionCallback callback,
+                          Local<Value> data = Local<Value>(), int length = 0));

Unfortunately I haven't been able to do any testing on this, no time at all. If anyone else has time it'd be great to get some testing of NAN on this version. @kkoopa do you have time to verify the NAN test suite against #2632 on top of vee-eight-4.5?

[targos]

it wasn't widely known to addon authors who could get away with liberal Handle usage.

Handle is defined like this in the header file:

#if !defined(V8_IMMINENT_DEPRECATION_WARNINGS)
// Local is an alias for Local for historical reasons.
template <class T>
using Handle = Local<T>;
#endif

If I understand it well, as long as we don't enable V8_IMMINENT_DEPRECATION_WARNINGS in v4, addons using it will still work.

[rvagg]

@targos my point is about all of the core APIs now exporting Local instead of Handle, but perhaps that's moot since it should just be an alias. Again, some testing would be nice. Those who would like to see 4.5 in should be out there testing addons and seeing what kind of work is required. I'd start by looking at buffertools, bignum, leveldown (ones that the TSC has some connection with), also interesting would be anything in npm that's depending on nan@2.x if you can figure that out. If we can get a level of confidence that there's not going to be much/any pain from this then it's more likely this will make it in.

[targos]

@rvagg here is a list of all npm packages where the nan dependency satisfies 2.0.8:

buffer-indexof-fast
ed25519-supercop
gigecamera-simulator
ifx_db
iobroker.terminal
linux-ns
lru-addon
magickwand
mmap-io
node-shared-cache
nodeos-mount
qrencode-raw
sd-daemon
sdb
sypexgeo-nan
usage-nan
wocr
xenstat
zlib-raw-sync
bignum
blake2
forsake
imageplus
memwatch-next
mitie
nsfw
snappy
sse4_crc32
xz
fsevents
blackbone-node
png-img
utun
v8-debug
addon-emitter
bluetooth-hci-socket
bufferutil
capture-window
edgeswim-uvmon
farmhash
fds
fs-xattr
function-origin
gc-stats
gdx
hackrf
hiredis
inotify
macos-alias
modern-syslog
naio-test
natrium
node-minizip
node-openalpr
node-opencv-zbar
oid
pattimura
phash-image
sha3
torium
utf-8-validate
weak
webkitgtk
xml-conv-json
xpc-connection
deasync
cap
freetype2
lodepng
mknod
mmmagic
nbind
node-expat
node-gpgme
node-sass
re2
sharp
number-smusher
npool
neventemitter
keybase-sodium
sodium-prebuilt
kbd
sleep
lzma-native
node-libcurl
leveldown
nodejieba
pcsclite
traceview-bindings
zmq
iconv
node-ios-device
async_bench
effective
epoll
geoip
mosca
v8-profiler
arc4random
libxl
unix-dgram
arrayfire_js
electron-ref
ref
time
kinect2
microtime
mkfifo
runas
runas-compiled
userinfo

[kkoopa]

All Function::New() does is call FunctionTemplate::New()->GetFunction(). It is probably not even in common use, as it was not available before 0.12.

There are four ways of fixing it:

• Patch V8 to remove the offending commit
• Patch NAN and keep the existing behavior
• Patch NAN and update to the new behavior
• Patch NAN and remove it completely.

Witchever the resolution is, I strongly oppose bumping the major version of NAN for this uselessness. 2.x is here to stay for at year, breakage be damned.

The Handle stuff is a non-issue. It is trivial to fix, it has been known for over two years that it needs to be fixed, and there is no promise of forward compatibility. It was well known already before the release of io.js 3.0.

On September 2, 2015 4:07:59 PM GMT+03:00, Rod Vagg notifications@github.com wrote:

@domenic sorry, it's not Function::Call(), I was talking about
Function::New() but looking again it and seeing the full section of
the code it seems that this might be what @trevnorris was talking about
too.

-  static Local<Function> New(Isolate* isolate,
-                             FunctionCallback callback,
-                             Local<Value> data = Local<Value>(),
-                             int length = 0);
+  static MaybeLocal<Function> New(Local<Context> context,
+                                  FunctionCallback callback,
+                                  Local<Value> data = Local<Value>(),
+                                  int length = 0);
+  static V8_DEPRECATE_SOON(
+      "Use maybe version",
+      Local<Function> New(Isolate* isolate, FunctionCallback callback,
+                          Local<Value> data = Local<Value>(), int
length = 0));

Unfortunately I haven't been able to do any testing on this, no time at
all. If anyone else has time it'd be great to get some testing of NAN
on this version. @kkoopa do you have time to verify the NAN test suite
against #2632 on top of vee-eight-4.5?

---

Reply to this email directly or view it on GitHub:
#2654 (comment)

[shigeki]

Sorry, I can't make it today.

[orangemocha]

Most likely I won't be able to attend today.

[domenic]

@kkoopa so my understanding of your four ways to fix it is that you would find patching NAN to keep the existing behavior or update to the new behavior both acceptable? Neither would require a major version bump, correct?

Anyway, again it sounds like this is not actually a removal, or even a deprecation, just a deprecation-soon. So NAN doesn't need to do anything at all, if it doesn't want to, at least for two more V8 releases. As @rvagg says though, getting some testing in would be crucial to confirm.

[kkoopa]

@domenic Patching to update to new behavior would be a breaking change, but I still do not consider it significant enough to warrant a major version bump, regardless of semver this or semver that. The construct is probably not used outside of NAN's test suite.