* Ben: PRs, bugs, perf improvements, same old awesome Ben
* Bert: talking, child process bugs, looking further in to Windows bugs that are still outstanding, no coding
* Chris: reviewing PRs, onboarding Julian, Christian, Brian, Robert, Ben. Code for core module discovery / use in packages in npm.
* Domenic: Streams work WHATWG sync with io.js streams ideas.
* Fedor: fixing bugs, PRs
* Isaac: coding for fun, node-tap rewrite, global/window alias discussions, node_modules flattening, Windows stuff. Looking in to TLS issues for io.js and 0.12, TLS over Pound causes problems, possibly OpenSSL problem.
* Mikeal: Website and Evangelism WG work, lots of new collabs and work, getting things in sync
* Rod: Releases, Windows bug / Jenkins drama, ARMv8 support
* Ben: @orangemocha did some work on Windows for libuv, unsure if this helps.
* Bert: process.send() has been made sync on *nix because otherwise it’s a breaking change, but on Windows it’s always been async so changing it to sync would also be a breaking change. So the situation is crazy.
* Isaac: ideal is that they behave the same and behave well
* Discussion about whether this would be a breaking change or a bugfix
* Bikeshed, moving to GitHub
* Bert: proposed that we revert Unix behaviour and leave Windows as it is
Chris: lets us have modules that can’t be required from outside of core. I’m in favor; it’s a nice insurance policy, especially in light of the stability policy that we will try not to make any breaking changes to the JavaScript API.
Mikeal: this doesn’t change the existing pseudo-internal modules to become truly internal, right?
Chris: correct, that is separate.
Domenic: but, doing that operation would be a good thing to do in a major version bump.
Isaac/Mikeal: yes, but don’t do that for `util._extend`, too many people use it.
Chris: *gives example of how this would have been helpful for a recent refactor*
Ben: how will the test suite test internal functions from then on?
Chris: there would be a flag, e.g. --allow_internal_modules.
Mikeal: I like it.
Bert: I like it too. However I am concerned about products that do monkeypatching; would that still be possible?
Chris: I think so, as long as they monkeypatch the public APIs…
Ben: not sure that’s quite sufficient…
Domenic: seems like a pure win because it allows you not to have to put everything in one file to keep things private.
### url: significantly improve the performance of the url module
Bert: I’m not sure I believe in this any more; the major reason I wanted this was that building native addons is terrible, but people brought up that the native part of the web socket implementations only do some bitwise buffer stuff and so we could probably just add *those* to core.
Discussion of how we should probably just add more Buffer methods to core.
Bert: there’s another aspect of this. At some point Node was really modern, but we’ve fallen behind. We can’t even get HTTP/2 or web sockets, we’re in trouble.
Domenic: we’ve learned a lot over the last few years that pushes us to userland code instead of in core. But we need to have some things be “official.”
Bert: I think as a TC what we should say is “we would like to support HTTP/2, but want to see some userland ideas first.” We don’t need to actually start implementation progress right now.
Discussion of how Fedor already has a SPDY implementation.
Trevor: are we going to do TLS-only HTTP/2?
Mikeal: we probably don't want to, because our HTTPS is not as fast as terminators.
Conclusion:
We should start an issue in NG about the core modules/modernity stuff.
We should publicly state that we’re interested in supporting HTTP/2 in the related issue thread, although we’re not sure about implementation strategy and want to see experiments.
* Ben: V8 4.1 has gone gold/stable so we should probably upgrade by un-floating a revert we placed on top of it. I propose we revert that revert, so that we get 4.1-as-shipped-in-Chrome. [#952](https://github.com/nodejs/io.js/pull/952) for details on the floating revert.
