Collaborator Checkin / 2015-07-02 → 2015-07-09

[chrisdickinson]

Hi all! As an experiment, I'm going to start posting a weekly status report issue on the tracker. It'll be closed at the end of each week. If you'd like to participate, respond to this thread!
#2015-07-02 → 2015-07-09

priorities

1. Documentation tooling
   1. Over at the nascent docs WG, I'm investigating using @wooorm's excellent mdast tool for documentation building.
   2. I am building a mdast plugin that will do link checking / doc dependency tracking for us.
2. Static analysis
   1. I've gotten access to a clone of the registry.
   2. I'll be knocking the bugs out of estoc over the next week once the doc tooling stuff is done.
   3. The next step after that is to feed that data into a searchable database and build a simple web UI around it.
3. Code coverage for core JS modules
   1. This was working at Nodeconf, but I've come to find out that it depends which istanbul I run it with.

blocked efforts / ENOTIME

Hey wow! Look at all of this stuff!

• A while back @vkurchatkin and I started an effort to reduce core's use of internal properties from streams. This is stalled, though I'd still be interested in seeing this through!
• statvfs hooks for libuv — This is mostly done and just needs someone to finish it.
• Streams WG meetings — I haven't organized another recently, but there are definitely topics that would be great to cover. If someone is interested in organizing one, let me know and I can run you through the process.
• Collaborator forum — this might end up as a GitHub repo (or just as this status update!)
• Stop the internal repl from corrupting history when two repls are running. This is pretty much done if someone wants to take it over. I'd caution folks against changing the history format for the time being, since that will need to be done carefully in a major version bump.
  • Since we have homedir support in libuv now thanks to @cjihrig, it might be good to start enabling builtin REPL history by default!
• I'd be happy to help anyone interested in building out a streaming fs.createReadDirStream() API — this might involve spelunking into libuv!

[rvagg]

Ooo, fun, thanks for the update @chrisdickinson! Let's ping @nodejs/collaborators to make sure everyone's aware that this is happening and they can participate.

Items from me:

• 3.0.0:
  • We haven't made a fuss of it but we are already up to RC3 for v3.0.0, you can grab it here: http://iojs.org/download/rc
  • This includes node-gyp changes that make it more aware of where to download tarballs, so instead of only working on releases, npm install for addons will also download tarballs for RC's, nightlies and next-nightlies, making them much more useful to testers! Also, instead of downloading the full source, it only fetches the new headers tarball which is a tiny fraction of the size and really quick to download and takes up much less disk space. So much #win. /cc @ljharb
  • 3.0 includes V8 4.4 and it contains a lot of C++ API drama. To catch up, the Addons API WG has basically rewritten NAN to be much more future looking and adaptable. Unfortunately there's an enormous amount of pain in store for addon authors as they adapt to this. The NAN documentation is still a work in progress and there is no straightforward transition script or documentation yet and v2 isn't even in npm. This is the reason why I'm not recommending we promote the RCs for general use; addon authors will be pummeled with requests to adapt but will have no means to do so! Follow progress here: io.js v3 preparation nan#376
• Jenkins:
  • I screwed up Jenkins yesterday, the disk filled up and I cleaned it up by deleting all jobs, including their configuration. doh! Backups are infrequent enough that we had to roll back ~a week. I lost a little bit of work in iojs+release (which now controls all releases including nightlies and RC's) and have recovered but @orangemocha lost a significant amount of work with some new jobs that were almost ready to replace iojs+any-pr+multi with a job that converged test & merge tooling from io.js and joyent/node and could take appropriate actions on all three repos (nodejs/node included). So ⏪.
  • v2.3.2 was released with a new Jenkins + make procedure that makes it possible to build the release without tagging first; this is how joyent/node does it already but we've enforced tagging before building for releases. We've had a couple of borked releases because we only discovered problems during or after building them and had to increment version and tag again to fix. This should save that class of problems.

Lastly I'll note a blocking item that's still on my plate and is high priority but I have yet to be able to allocate a large enough block of time to finish it off. The process.release proposal @ #493 and stale node-gyp support for it @ nodejs/node-gyp#564 are really important, even if we were to stop releasing as "io.js" because they would give us the flexibility to enable node-gyp support across all our release lines without hacks like I put in the next branch for 3.0.0. It's also the blocker for needing to use the npm that ships with io.js and therefore a major pain point for io.js users. I'm not against giving this task up if someone else has the vision to follow it through, I've been a blocker for a very long time on this and dislike it when other people block work because they put up their hand and don't follow through! Perhaps ping me if you want to tinker with it to see if I haven't picked it up again. I am trying to get to it!

[Fishrock123]

~2015-07-03 → ~2015-07-10

priorities

1. Next week is CascadiaJS. I'm going to be there on the browser and server days (days 2 & 3) and will attempt to collect as much feedback as reasonably possible.
2. _unrefActive() (all the details)
   1. I don't typically write data structures like heaps and so this is taking me longer than I'd like. It is also quite a learning experience.
   2. I'm building off of a heap implementation written by @bnoordhuis. I have a little bit of trouble actually understanding the implementation. That fact that it fills from the right side doesn't help.
   3. The heap is backed by linking the objects, not using an array, for performance reasons. It also makes it harder to debug when subtle things go wrong.
   4. Current issues:
      • Re-inserting an object causes issues (even after removal). Not sure why. Fixed. Re-insert check forgot to check the root.
      • Some tests cause a condition where the heap degenerates into a same-value linked list on the side that is supposed to be filed second (in this case, the left side). Fixed by the above.
   5. Then I actually need to run performance profiling on the thing.
3. Issue Tracker maintenance. The usual. Closing what issues I can, and reviewing what PRs I understand. And delegating to others / reminding people who can better handle more complex issues.
4. Setting up a collaborator onboarding. See governance: add new collaborators #VI #2102

blocked efforts / not payed enough to do all the things

Whatever falls through the cracks. Probably some of the issue tracker stuff, no guarantees. I'll also be doing some research on general life stuffs and poke more at company contacts while I wait for someone to employ me.

Edit: Probably also some convergence work will fall through, although some of that is blocked by other people's review of convergence related changes.