@ -54,13 +54,13 @@ Debugging is one of the first things from everyone's mouth, both developer and e
The goal of io.js' effort is to build a healthy debugging and tracing ecosystem and not to try and build any "silver bullet" features for core (like the domains debacle).
The [Tracing WG](https://github.com/iojs/tracing-wg) is driving this effort:
The [Tracing WG](https://github.com/nodejs/tracing-wg) is driving this effort:
* AsyncWrap improvements - basically just iterations based on feedback from people using it.
* async-listener - userland module that will dogfood AsyncWrap as well as provide many often requested debugging features.
* Tracing
* Add tracing support for more platforms (LTTng, etc).
* [Unify the Tracing endpoint](https://github.com/iojs/io.js/issues/729).
* [Unify the Tracing endpoint](https://github.com/nodejs/io.js/issues/729).
* New Chrome Debugger - Google is working on a version of Chrome's debugger that is without Chrome and can be used with io.js.
@ -17,7 +17,7 @@ There are three relevant Jenkins jobs that should be used for a release flow:
**c.** **[iojs+release](https://jenkins-iojs.nodesource.com/job/iojs+release/)** does all of the work to build all required release assets. Promotion of the release files is a manual step once they are ready (see below).
The [io.js build team](https://github.com/iojs/build) is able to provide this access to individuals authorized by the TC.
The [io.js build team](https://github.com/nodejs/build) is able to provide this access to individuals authorized by the TC.
### 2. <iojs.org> Access
@ -27,7 +27,7 @@ The Jenkins release build slaves upload their artefacts to the web server as the
Nightly builds are promoted automatically on the server by a cron task for the _dist_ user.
Release builds require manual promotion by an individual with SSH access to the server as the _dist_ user. The [io.js build team](https://github.com/iojs/build) is able to provide this access to individuals authorized by the TC.
Release builds require manual promotion by an individual with SSH access to the server as the _dist_ user. The [io.js build team](https://github.com/nodejs/build) is able to provide this access to individuals authorized by the TC.
* Trevor: domains are horrible but we don’t have a good alternative yet
* Ben: +1 on removal but don’t have a good story on what to tell people to use
* Bert: -1, would rather clean up docs to be honest about how it doesn’t do what it was hoped to
* Trevor: domains inhibit progress because of their invasiveness
* Discussed how to document concerns etc.
* Discussed https://github.com/iojs/io.js/pull/15 which adjusts the domain.run() API
* Discussed https://github.com/nodejs/io.js/pull/15 which adjusts the domain.run() API
* Agreed:
- Accept PR #15
- **Document that domains are on the way out: soft deprecation** (no util.deprecate())
### Decide how to go forward with Caine (bot)
https://github.com/iojs/io.js/issues/117
https://github.com/nodejs/io.js/issues/117
* Fedor talked about _what_ caine is and _why_ it exists: too many emails from the repo, want to set up a system where relevant people are pulled into particular issues rather than having to subscribe to the repo for all notifications
* Chris: primary concern with having an automated bot is the incoming experience for users (like having a join bot on IRC)
- Containerized build system is being improved by an active team in the https://github.com/iojs/build-containers repo, on target to enable automatic PR tests and status reports back to GitHub (will likely just be Linux distros for the forseeable future)
- Containerized build system is being improved by an active team in the https://github.com/nodejs/build-containers repo, on target to enable automatic PR tests and status reports back to GitHub (will likely just be Linux distros for the forseeable future)
- Next step is to enable committers to be able to trigger full builds across the build cluster
- Aiming for more automation for a mid-January release, have concerns about Windows and OSX signing and the need for signing keys and how complex they are.
- Chris Lea is working towards nightly builds for .deb-based systems (RHEL / Fedora based systems could come later but the assumption is that people running those systems are _less_ likely to want nightlies)
- https://github.com/iojs/io.js/issues/13 is an ARM build failure that still needs attention to have ARM part of the build mix and not constantly fail (see https://jenkins-node-forward.nodesource.com for some ARM failures)
- https://github.com/nodejs/io.js/issues/13 is an ARM build failure that still needs attention to have ARM part of the build mix and not constantly fail (see https://jenkins-node-forward.nodesource.com for some ARM failures)
### Extending options from a prototype
https://github.com/iojs/io.js/issues/62
https://github.com/nodejs/io.js/issues/62
* Chris is asking for input
* Ben: we’re currently only looking at the object’s own properties, and ignoring properties on the prototype.
### Statement / stance from TC on exposing a Promises API
https://github.com/iojs/io.js/issues/11
https://github.com/nodejs/io.js/issues/11
* Rod: can we come up with some kind of statement from the TC regarding the possibility of adding a Promises API to core, even if it’s vague
* Bert: there’s a convergence of functionality around Promises that are making them more useful in conjunction with other ES6/ES7 features, TC should be _open_ to adding a Promises API in the future
### Working with nvm, nvmw and similar installation managers
https://github.com/iojs/io.js/issues/40
https://github.com/nodejs/io.js/issues/40
* Ben: suggested a dist.iojs.org for hosting binaries
* Ben: suggested a release.txt
* Ben: suggested a release.txt
* Rod: **leave it up to the build team to work out the mechanics of releases and release.txt and/or release.json and come back to TC for approval or adjustments prior to formal release** (i.e. no need to bikeshed on this here right now)
### module: force require('process') to return a reference to process #206
https://github.com/iojs/io.js/pull/206
https://github.com/nodejs/io.js/pull/206
* #157 has a long discussion on this: https://github.com/iojs/io.js/issues/157
* #157 has a long discussion on this: https://github.com/nodejs/io.js/issues/157
* Chris: +1 on a PR adding this
* Trevor: it just returns a global, no point
* Bert: not the way that JS adds new features; discussed the new Intl addition to joyent/node, in favor of making more things requirable rather than adding new globals all the time
* Rod asked if there are any strong opinions about how to handle this
* **Group agreed that Rod will take this issue and seek legal advice to find a way forward**
### Rename v0.12 to v1.0.0
https://github.com/iojs/io.js/issues/218
https://github.com/nodejs/io.js/issues/218
* Trevor: concerns about 1.0 vs 1.x branch naming with maintaining semver releases while also doing LTS, 1.x effectively becomes master until a 2.0 comes along.
* Doc: clarified & split up contribution docs #233 https://github.com/nodejs/io.js/pull/233
* Governance: Add new Collaborators #234 https://github.com/nodejs/io.js/issues/234
* deps: upgrade v8 to 3.31.74.1 #243 https://github.com/nodejs/io.js/pull/243
* Build
* Intl - defaults
* Merge v0.10
@ -42,7 +42,7 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
* colin: triaging issues in io.js and joyent/node. helping with merge of 0.12 to 0.10
* isaac: no io.js, vacation
* mikeal: nada
* rod: build build build ci ci ci. re-did all the build slaves on Jenkins, introduced a bunch more. Ansible scripts for linux machines (CentOS 5,6,7, Ubuntu all LTS + Current 14.10 +32bit versions, 2 ARM v7s one virtual one physical, 2 of each Windows 2012,2008, a couple interim OS X machines more permanent ones coming from Voxer soon). https://github.com/iojs/build Still lacking specific Jenkins setup and secrets. Working on release process.
* rod: build build build ci ci ci. re-did all the build slaves on Jenkins, introduced a bunch more. Ansible scripts for linux machines (CentOS 5,6,7, Ubuntu all LTS + Current 14.10 +32bit versions, 2 ARM v7s one virtual one physical, 2 of each Windows 2012,2008, a couple interim OS X machines more permanent ones coming from Voxer soon). https://github.com/nodejs/build Still lacking specific Jenkins setup and secrets. Working on release process.
mikeal: issue re release?
rod: not yet, a lot of little bugs to get CI working consistently. No grand plan for what’s in release yet.
@ -57,7 +57,7 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
### Invite Colin Ihrig to the TC #223
https://github.com/iojs/io.js/issues/223
https://github.com/nodejs/io.js/issues/223
Asked for vote
@ -67,7 +67,7 @@ Some discussion about TC member addition process
### File copyright policy #216
https://github.com/iojs/io.js/issues/216
https://github.com/nodejs/io.js/issues/216
* Rod: got feedback from NodeSource GC on this, recommendation is to keep the copyright but removal of the license notice is acceptable
* Mikeal & Isaac: removing the copyright should be OK because we have full git record of who made & edited the file, it’s a PITA
### Doc: clarified & split up contribution docs #233
https://github.com/iojs/io.js/pull/233
https://github.com/nodejs/io.js/pull/233
* Rod: discussed changes introduced in #233, this is in TC because there are some minor modifications to the governance structure. Recommended that we deal with further changes to governance as a separate discussion.
* governance: Add new Collaborators #234 https://github.com/nodejs/io.js/issues/234
* The state of ES6 on io.js _(re V8 upgrade policy)_#251 https://github.com/nodejs/io.js/issues/251
Quick recap:
- Whether if it is ok to release 1.0.0 with V8 3.31.74 minus ES6 Classes and Object Literals Extensions, considering that the initial version of io.js will be "beta" quality and probably the stable version will coincide with the stable release of V8 3.31 (~6 weeks), which will have these features reinstated.
- How to handle V8 updates with semver so that if the same issue arised with a different timing it could mean a bump to 2.0.0.
@ -20,7 +20,7 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
* Different version naming (e.g. 1.x+v8beta, 1.x+v8dev, 1.x+v8canary)
* Avoid BC by moving from tip-of-stable-Chrome-branch to the next tip-of-stable-Chrome-branch (~6 weeks release cycle)
* Doc: clarified & split up contribution docs #233 https://github.com/nodejs/io.js/pull/233
* Governance: Add new Collaborators #234 https://github.com/nodejs/io.js/issues/234
* deps: upgrade v8 to 3.31.74.1 #243 https://github.com/nodejs/io.js/pull/243
* Build & release (& Intl)
### File copyright policy #216
https://github.com/iojs/io.js/issues/216
https://github.com/nodejs/io.js/issues/216
Rod: prepared a proposed new LICENSE file, needed for release, adds a new license block for io.js at the top, shifts the Joyent copyright block down but still acknowledges their claim on inherited work. https://github.com/iojs/io.js/pull/294
Rod: prepared a proposed new LICENSE file, needed for release, adds a new license block for io.js at the top, shifts the Joyent copyright block down but still acknowledges their claim on inherited work. https://github.com/nodejs/io.js/pull/294
Group agreed to merge for now until a better (or more legally appropriate) solution is proposed.
### governance: Add new Collaborators #234
https://github.com/iojs/io.js/issues/234
https://github.com/nodejs/io.js/issues/234
Rod asked if we should punt to next meeting since the group was small and we’re 1.0.0 obsessed.
@ -68,7 +68,7 @@ Group agreed.
### The state of ES6 on io.js _(re V8 upgrade policy)_#251
https://github.com/iojs/io.js/issues/251
https://github.com/nodejs/io.js/issues/251
Rod: this is about V8 version matching and V8 version stability. We’re going live with 3.31.
@ -78,7 +78,7 @@ Group agreed to stick with 3.31, too late to do otherwise. Come up with a more s
### v1.0.0 release checklist
https://github.com/iojs/io.js/issues/302
https://github.com/nodejs/io.js/issues/302
* Rod will land LICENSE change after meeting
* Bert spoke about the v0.10 and the things that remain unmerged
- re timers slowness - Bert and Ben don’t like the 0.10 fix, need to find our own - not landing in 1.0.0, probably our own fix in 1.0.1
* Bert spoke about node.exe, has code for it but it’s crashy, could release with a symlink for 1.0.0. Asked for input on the approach.
* Discussed node-gyp - Ben to PR node-gyp (and maybe land a modified version in io.js codebase) for iojs.org/dist/vx.y.z/... for source tarball.
- discussed process.versions.iojs property, https://github.com/iojs/io.js/issues/269 - group agreed to do nothing on this. Rod to find discussion or create issue to have discussion on this.
- discussed process.versions.iojs property, https://github.com/nodejs/io.js/issues/269 - group agreed to do nothing on this. Rod to find discussion or create issue to have discussion on this.
- discussed visual assets not being in the repo, currently copied by CI manually into src, Rod to land a PR with them
* **Original Minutes Google Doc**: https://docs.google.com//document/d/1yOS17cUt7QUHJXxdVmEpS1ZS_N32HMO9QTHb2qL-KHk
## Agenda
Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* Invite Domenic Denicola to the TC Meetings (https://github.com/iojs/io.js/issues/403)
* Governance: Add new collaborators (https://github.com/iojs/io.js/issues/234)
* Stabilization and Release Cycles and Process (https://github.com/iojs/io.js/issues/405)
* also: the state of ES6 on io.js (re: V8 upgrade policy) (https://github.com/iojs/io.js/issues/251)
* doc: bump punycode api stability to ‘stable’ (https://github.com/iojs/io.js/issues/470)
* Invite Domenic Denicola to the TC Meetings (https://github.com/nodejs/io.js/issues/403)
* Governance: Add new collaborators (https://github.com/nodejs/io.js/issues/234)
* Stabilization and Release Cycles and Process (https://github.com/nodejs/io.js/issues/405)
* also: the state of ES6 on io.js (re: V8 upgrade policy) (https://github.com/nodejs/io.js/issues/251)
* doc: bump punycode api stability to ‘stable’ (https://github.com/nodejs/io.js/issues/470)
* Working group reports
* Streams
* Website
@ -59,13 +59,13 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
### Invite Domenic Denicola to the TC Meetings
(https://github.com/iojs/io.js/issues/403)
(https://github.com/nodejs/io.js/issues/403)
Enough agreement on GitHub and in private communications amongst TC. **Done.**
### Governance: Add new collaborators
(https://github.com/iojs/io.js/issues/234)
(https://github.com/nodejs/io.js/issues/234)
* Mikeal: Proposed Chris leads an onboarding process, do a Hangout with a group of people from the original list who are willing to go through the process and take them in the first week and iterate from there.
* Bert: +1 for an onboarding process, more interested in handing out voting rights to a larger group.
@ -86,7 +86,7 @@ Passed
### Stabilization and Release Cycles and Process
(https://github.com/iojs/io.js/issues/405)
(https://github.com/nodejs/io.js/issues/405)
#### V8
@ -129,13 +129,13 @@ Passed
### also: the state of ES6 on io.js (re: V8 upgrade policy)
(https://github.com/iojs/io.js/issues/251)
(https://github.com/nodejs/io.js/issues/251)
Part of previous discussion
### doc: bump punycode api stability to ‘stable’
(https://github.com/iojs/io.js/issues/470)
(https://github.com/nodejs/io.js/issues/470)
* **Agreement**
@ -144,7 +144,7 @@ Part of previous discussion
* Mikeal and Chris to semi-formalise the model
* Mikeal: 6 people actively engaged and growing, “could not be going better”
* Chris: streams group has initial set of members, some discussions going on, first meeting pending
* initial set of members: https://github.com/iojs/readable-stream/issues/97#issuecomment-70399923
* initial set of members: https://github.com/nodejs/readable-stream/issues/97#issuecomment-70399923
* Rod:
- The Docker sub-group is going great and has even got the docker-iojs images accepted as the official Docker "iojs" images.
- Other "build" efforts are all release-focused for now, trying to streamline the process to make it possible to have multiple people able to cut releases.
* dgram: implicit binds should be exclusive [#325](https://github.com/nodejs/io.js/issues/325) / minor version bump / @bnoordhuis
* buffer: implement `iterable` interface [#525](https://github.com/nodejs/io.js/issues/525) / minor version bump / @bnoordhuis
* replace util.isType() with typeof [#607](https://github.com/nodejs/io.js/issues/607) / general use of util.is*() in core re perf
* docs: lower the maximum stability level to "stable" [#633](https://github.com/nodejs/io.js/pull/633)
* maintain our own package registries for io.js related packages [#640](https://github.com/nodejs/io.js/issues/640#issuecomment-71882645)
* Working Groups PR [#599](https://github.com/nodejs/io.js/pull/599)
* Remove “unstable” from messaging [#108](https://github.com/nodejs/website/issues/108)
## Minutes
@ -52,11 +52,11 @@ Apologies from:
### Review of last meeting
* Invite Domenic Denicola to the TC Meetings (https://github.com/iojs/io.js/issues/403)
* Governance: Add new collaborators (https://github.com/iojs/io.js/issues/234)
* Stabilization and Release Cycles and Process (https://github.com/iojs/io.js/issues/405)
* also: the state of ES6 on io.js (re: V8 upgrade policy) (https://github.com/iojs/io.js/issues/251)
* doc: bump punycode api stability to ‘stable’ (https://github.com/iojs/io.js/issues/470)
* Invite Domenic Denicola to the TC Meetings (https://github.com/nodejs/io.js/issues/403)
* Governance: Add new collaborators (https://github.com/nodejs/io.js/issues/234)
* Stabilization and Release Cycles and Process (https://github.com/nodejs/io.js/issues/405)
* also: the state of ES6 on io.js (re: V8 upgrade policy) (https://github.com/nodejs/io.js/issues/251)
* doc: bump punycode api stability to ‘stable’ (https://github.com/nodejs/io.js/issues/470)
* Working group reports
* Streams
* Website
@ -64,7 +64,7 @@ Apologies from:
### governance: Add new Collaborators
[#234](https://github.com/iojs/io.js/issues/234) / feedback and more contribs / @chrisdickinson
[#234](https://github.com/nodejs/io.js/issues/234) / feedback and more contribs / @chrisdickinson
* Chris: Onboarded 2 groups of 4 new collaborators last week. (first group: @vkurchatkin, @micnic, @seishun, @brendanashworth, second group: @evanlucas, @Fishrock123, @Qard, @thlorenz)
- 30 min summary of how everything works, gov, git, etc.
@ -76,13 +76,13 @@ Apologies from:
### Stabilization and Release Cycles and Process
[#405](https://github.com/iojs/io.js/issues/405) / further discussion / @iojs/tc
[#405](https://github.com/nodejs/io.js/issues/405) / further discussion / @iojs/tc
* Mikeal: each distro (Homebrew, Debian, etc.) has their own conception of “stable”, suggestion is to maintain them under io.js and instruct people how to do this. e.g. using our own custom Homebrew end-point and instruct people how to use it with `brew`. Also could bring in complicated packages from the community.
* Mikeal: Should come under the Build WG for now, ideally a single repo where external projects can put in a single PR to update their stuff.
* Chris: difference between Mikeal’s proposal and the original proposal is having a “canary” branch that stuff gets merged in to and eventually is merged in to master, original proposal merged new stuff in to master and used the time delay as “canary” (like Chrome)
* Rod: proposal is to tag this issue as a milestone for now and punt until we have more substantive changes - no disagreements, passed
### Translate installers for OS X and Windows [#819](https://github.com/iojs/io.js/issues/819) / @rvagg / maintenance overhead
### Translate installers for OS X and Windows [#819](https://github.com/nodejs/io.js/issues/819) / @rvagg / maintenance overhead
* Rod: concern here is the maintenance overhead in keeping all of the translations in sync, are we happy to have that headache in core?
* Mikeal: let English be the default and let the translation teams be responsible for watching for changes and making updates as appropriate
* Bert: if there is no technical issue then OK with landing this, the responsibility for translation will have to be with that community
* Resolution: allow this to land unless there are going to be technical blockers to future installer changes needing to wait for translations to be updated
* Group discussed presentations, no major objections so the blessing was given for Mikeal to move forward with ratifying that, expect further discussion on the broader topic next meeting.
* 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.
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.
@ -104,12 +104,12 @@ 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.
@ -140,9 +140,9 @@ 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/iojs/io.js/pull/952) for details on the floating revert.
* 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.
* Domenic: do we have clarity about ABI vs. API implications for io.js major version?
* Ben: ABI change means everyone has to recompile their add-ons so we should bump the minor.
* url: significantly improve the performance of the url module [#933](https://github.com/nodejs/io.js/issues/933) / @mikeal
* Ship websockets in core [#1010](https://github.com/nodejs/io.js/issues/1010) / @piscisaureus
* RFC: upgrade to V8 4.2? [#1026](https://github.com/nodejs/io.js/issues/1026) / @bnoordhuis
* Colin resigning from TC [#1056](https://github.com/nodejs/io.js/pull/1056)
### [#1134](https://github.com/iojs/io.js/pull/1134) Add Docker working group
### [#1134](https://github.com/nodejs/io.js/pull/1134) Add Docker working group
* Rod: originally conceived to be a “sub-WG” of Build WG but this makes sense because there is little overlap with the Build team or skills required for the Build team.
* Rod: this group is already maintaining official Docker images or io.js located at https://github.com/iojs/docker-iojs which are also the “official” Docker images for io.js.
* Rod: this group is already maintaining official Docker images or io.js located at https://github.com/nodejs/docker-iojs which are also the “official” Docker images for io.js.
* Bert: in favour of stream_base now and don’t want it reverted given the fixes that have been made. The real problem was the introduction of a major change that lead to a lot of breakage and a lot of fix commits. Proposed that we have a “ng” (or similar) branch with releases for testing before merging.
* Chris: agree that we need a canary policy of some kind to deal with this
@ -65,14 +65,14 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
* Discussion about test coverage
* Rod asked OpenSSL fix: agreed to punt on a release until OpenSSL fix has been released and go immediately after that.
### [#1130](https://github.com/iojs/io.js/pull/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
### [#1130](https://github.com/nodejs/io.js/pull/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
* Rod: there was some off-record discussion about TC membership process related to #1130 and #1131.
- Neither individual was asked and it would be good to at least have it passed by them first
- Would be good to have a smooth on-boarding mechanism to bringing someone on to meetings before officially making them TC, agreed to invite Jeremiah to next TC _if_ he’s interested in being involved.
- Generally agreed that increasing the size of the TC is a good thing (minus the meeting-overhead added by more people)
### [#1077](https://github.com/iojs/io.js/pull/1077) Pass args to process.nextTick() / @trevnorris
### [#1077](https://github.com/nodejs/io.js/pull/1077) Pass args to process.nextTick() / @trevnorris
* Trevor: passing arguments / context through process.nextTick() in core is common and would be significantly faster if we use a setArgs() feature.
* [#1130](https://github.com/nodejs/io.js/pull/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
* [#1077](https://github.com/nodejs/io.js/pull/1077) Pass args to process.nextTick() / @trevnorris
* Major version bump
@ -65,7 +65,7 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
* Mikeal: they will be taken care of by an LTS schedule
* Bert: IBM agrees that there should be a fast-moving tip and they just use an LTS. Board could also assert influence by way of a corporation threatening to withdraw backing.
### doc: add NAN WG [#1226](https://github.com/iojs/io.js/issues/1226)
### doc: add NAN WG [#1226](https://github.com/nodejs/io.js/issues/1226)
* Rod: discussed proposed move of rvagg/nan and rvagg/node-addon-examples to iojs to be governed by an “Addons API Working Group”
@ -75,11 +75,11 @@ Fedor: +1
Ben: +1
Trevor: +1
### Proposal: Authorise @Fishrock123 to create releases [#1225](https://github.com/iojs/io.js/issues/1225)
### Proposal: Authorise @Fishrock123 to create releases [#1225](https://github.com/nodejs/io.js/issues/1225)
* No disagreement, lots of +1s, good to go
### governance: Raise the bar for changes in membership and governance policy [#1222](https://github.com/iojs/io.js/issues/1222)
### governance: Raise the bar for changes in membership and governance policy [#1222](https://github.com/nodejs/io.js/issues/1222)
* Mikeal: the PR is a bit stale because of a miscount, just want to make sure that there are no concerns with this even though it may not end up being required given the movements with the TC.
* Rod: requested that we not hold up progress in io.js pending movement on the JNAB / Foundation process and we should treat that as a separate thing that may or may not happen.
@ -87,7 +87,7 @@ Trevor: +1
* Mikeal: just a miscount, needs to be changed, wanted to test if people are OK with this once we have more people on the TC. Main point was to flush out any concerns about raising the bar.
* Ben: suggested that it become 2 PRs, make the 2/3rds thing a separate issue.
### Nominating Rod Vagg @rvagg to the TC [#1134](https://github.com/iojs/io.js/issues/1131)
### Nominating Rod Vagg @rvagg to the TC [#1134](https://github.com/nodejs/io.js/issues/1131)
* Rod: fine with this
* Discussed meeting facilitation, agreed that it wasn’t a strictly defined role but it would be good to share it around a bit.
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1EsDjfRGpVKFABH4LcNXNxsAsBTnHsU-i5cehmAcp1A8
## Agenda
Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* [#1101](https://github.com/iojs/io.js/pull/1101) http: allow HTTP to return an HTTPS server / @silverwind / the use of a `tls` option to trigger `https` module functionality
* [#1301](https://github.com/iojs/io.js/pull/1301) Util(.is*) Deprecations / @Fishrock123&@brendanashworth / [this comment](https://github.com/iojs/io.js/pull/1301#issuecomment-90829575) asking for an opinion from the TC on how to move forward
* Discuss https://github.com/jasnell/dev-policy [[comment by @mikeal]](https://github.com/iojs/io.js/issues/1369#issuecomment-90955688)
* Discuss / Review the `require(‘.’)` situation [[comments by @silverwind and @Fishrock123]](https://github.com/iojs/io.js/issues/1369#issuecomment-90933134)
* [#1101](https://github.com/nodejs/io.js/pull/1101) http: allow HTTP to return an HTTPS server / @silverwind / the use of a `tls` option to trigger `https` module functionality
* [#1301](https://github.com/nodejs/io.js/pull/1301) Util(.is*) Deprecations / @Fishrock123&@brendanashworth / [this comment](https://github.com/nodejs/io.js/pull/1301#issuecomment-90829575) asking for an opinion from the TC on how to move forward
* Discuss https://github.com/jasnell/dev-policy [[comment by @mikeal]](https://github.com/nodejs/io.js/issues/1369#issuecomment-90955688)
* Discuss / Review the `require(‘.’)` situation [[comments by @silverwind and @Fishrock123]](https://github.com/nodejs/io.js/issues/1369#issuecomment-90933134)
### Present
@ -31,10 +31,10 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
### Review of last meeting
* reconciliation update (Mikeal and Bert)
* doc: add NAN WG [#1226](https://github.com/iojs/io.js/issues/1226)
* Proposal: Authorise @Fishrock123 to create releases [#1225](https://github.com/iojs/io.js/issues/1225)
* governance: Raise the bar for changes in membership and governance policy. [#1222](https://github.com/iojs/io.js/issues/1222)
* Nominating Rod Vagg @rvagg to the TC [#1134](https://github.com/iojs/io.js/issues/1131)
* doc: add NAN WG [#1226](https://github.com/nodejs/io.js/issues/1226)
* Proposal: Authorise @Fishrock123 to create releases [#1225](https://github.com/nodejs/io.js/issues/1225)
* governance: Raise the bar for changes in membership and governance policy. [#1222](https://github.com/nodejs/io.js/issues/1222)
* Nominating Rod Vagg @rvagg to the TC [#1134](https://github.com/nodejs/io.js/issues/1131)
### Quick stand-up
@ -49,7 +49,7 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
## Minutes
### [#1101](https://github.com/iojs/io.js/pull/1101) http: allow HTTP to return an HTTPS server
### [#1101](https://github.com/nodejs/io.js/pull/1101) http: allow HTTP to return an HTTPS server
***@silverwind / the use of a `tls` option to trigger `https` module functionality***
@ -79,9 +79,9 @@ Ben: what happens when iojs is compiled without TLS support?
**Conclusion**: punt on this. Initial feedback is that if we were to go down this route, we would slightly prefer the explicit tls option; however, there needs to be a discussion about the listen() idea, and also about compilation without TLS.
***@Fishrock123 &@brendanashworth / [this comment](https://github.com/iojs/io.js/pull/1301#issuecomment-90829575) asking for an opinion from the TC on how to move forward***
***@Fishrock123 &@brendanashworth / [this comment](https://github.com/nodejs/io.js/pull/1301#issuecomment-90829575) asking for an opinion from the TC on how to move forward***
@ -48,14 +48,14 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
## Minutes
### [#1393](https://github.com/iojs/io.js/issues/1393) Ready to upgrade to V8 4.2?
### [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
* Ben: `next` branch should be ready to go though needs to be upgraded to 4.2.77.14, C++ changes are fairly minimal.
* Discussed potentially bumping major:
- Mikeal: there was a meeting where it was generally agreed that an ABI change would warrant a version bump
- Rod & Isaac suggested that ABI changes shouldn’t bump major
- Discussion came around to most members agreeing that ABI change _should_ bump major. Rod voted 0 on this, everyone else apparently +1.
- Discussed semver-major changes including process.send() sync regressions, agreed that https://github.com/iojs/io.js/milestones/2.0.0 represents the best info on what’s mergable
- Discussed semver-major changes including process.send() sync regressions, agreed that https://github.com/nodejs/io.js/milestones/2.0.0 represents the best info on what’s mergable
* Discussed git, agreed that we should move back to master, Chris to handle git changes
* Discussed RC build, could use nightly or next-nightly but officially link it off the website and maybe label it differently. Rod to figure this out.
@ -66,13 +66,13 @@ Actions:
- Rod to figure out how to do and publish an RC build that’s not just “nightly-xxxxxxxxxxxxxx”
- Chris will test packages against URL PR and write up results
### [#1413](https://github.com/iojs/io.js/issues/1413) combining TC and Node core call
### [#1413](https://github.com/nodejs/io.js/issues/1413) combining TC and Node core call
* Mikeal: last dev-policy call brought up the suggestion of combining TC calls for both projects, with an eye on merging it would be good to understand what both groups do. Single meeting for both would be good.
* Discussed timing - we span more timezones than they do so our slot of 1pm PST makes more sense to get Rod and Fedor in at the same time. Could either be Tue or Wed UTC, they have a meeting the day before us.
* No strong disagreement
### [#1416](https://github.com/iojs/io.js/issues/1416) io.js diff node.js foundation
### [#1416](https://github.com/nodejs/io.js/issues/1416) io.js diff node.js foundation
* Mikeal: Foundation doc is huge compared to ours and also contains some formalisation of our process that we just haven’t formalised yet. The diff contains a lot of those and some _actual_ changes too. Open for discussion amongst the community.
* [#1416](https://github.com/nodejs/io.js/issues/1416) Diffing io.js and the Node.js Foundation
### Present
@ -34,9 +34,9 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
### Review of last meeting
* [#1393](https://github.com/iojs/io.js/issues/1393) Ready to upgrade to V8 4.2?
* [#1413](https://github.com/iojs/io.js/issues/1413) combining TC and Node core call
* [#1416](https://github.com/iojs/io.js/issues/1416) io.js diff node.js foundation
* [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
* [#1413](https://github.com/nodejs/io.js/issues/1413) combining TC and Node core call
* [#1416](https://github.com/nodejs/io.js/issues/1416) io.js diff node.js foundation
### Quick stand-up
@ -53,7 +53,7 @@ Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
## Minutes
### [#1130](https://github.com/iojs/io.js/issues/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
### [#1130](https://github.com/nodejs/io.js/issues/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
Voted:
@ -66,21 +66,21 @@ Voted:
**Action: Jeremiah Senkpiel is now a member of the io.js Technical Committee!**
### [#1481](https://github.com/iojs/io.js/issues/1481) Nominating @mikeal to the TC
### [#1481](https://github.com/nodejs/io.js/issues/1481) Nominating @mikeal to the TC
* Bert, Rod: Discussion regarding the potential consequences of expanding the TC and how that might work if a merger with node happens.
Discussed consequences of expansion for merger and for the practicalities of meeting.
### [#1500](https://github.com/iojs/io.js/issues/1500) Nominating Brian White @mscdex to the TC
### [#1500](https://github.com/nodejs/io.js/issues/1500) Nominating Brian White @mscdex to the TC
_See above_
### [#1501](https://github.com/iojs/io.js/issues/1501) Nominating Shigeki Ohtsu @shigeki to the TC
### [#1501](https://github.com/nodejs/io.js/issues/1501) Nominating Shigeki Ohtsu @shigeki to the TC
_See above_
### [#1393](https://github.com/iojs/io.js/issues/1393) Ready to upgrade to V8 4.2?
### [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
Rod: no formal “RC” builds yet but master is now going out on nightlies, they have a 2.0.0-pre version string now. Discussed whether we want formal RC builds or not. No strong opinions.
@ -100,17 +100,17 @@ Rod: any other breaking changes worth discussing?
Ben: process.send() ready but not merged, any objections? - no objections.
Chris: https://github.com/iojs/io.js/milestones/2.0.0 new label “land-on-master” to indicate PRs that are still targeting the v1.x branch.
Chris: https://github.com/nodejs/io.js/milestones/2.0.0 new label “land-on-master” to indicate PRs that are still targeting the v1.x branch.
Ben & Bert discussed Ben’s possible timers rewrite - Ben implemented a heap and red-black tree in JS, turned out to be a bit faster but not complete yet and Ben has been distracted on other projects. **
Frederic Hemberger
10 years ago
Roman Reiss