~webapps/unity-js-scopes/node.js

Rod: I need to get the fix for node-gyp in place. Also we should see if we can get nvm to allow testing nightlies so that people can test them more easily (including on Travis).

106

107

Jeremiah: when I last talked to Jordan (@ljharb) he wanted to make sure that the mechanism we used for nightlies would also be the mechanism used in the converged project.

108

109

Mikeal: well that’s definitely true. So we should be good.

110

111

Trevor: do we have a way of measuring uptake?

112

113

Domenic/Rod: npm traffic is probably the best metric.

114

115

Rod calls for a vote.

116

117

Domenic: can we clarify whether we allow minor, covered-by-nan breakages between 4.3/3.0.0 and 4.4/4.0.0, or do we require no breakages at all?

118

119

Mikeal: is nan released?

120

121

Jeremiah: not yet; it is experimental and they don’t release until we merge next into master

122

123

Mikeal: that seems bad

124

125

(General agreement that we want nan to release first.)

126

127

Trevor: looking at nan they seem to be working to encapsulate changes all the way out to V8 4.6.

128

129

Bert: what was the problem with putting nan into core?

130

131

Rod/Ben: sometimes V8 makes big changes that cause breaking changes in nan. E.g. isolates, buffer changes, maybes. Until now it’s been just individual APIs, but the 4.3 and 4.4 change has been very big. nan’s promise is just that you can write against a single, possibly-changing API that will support multiple node versions.

132

133

### Expose `deepEqual` and `deepStrictEqual` in `util`. #1172 [#1177](https://github.com/nodejs/io.js/pull/1177)

134

135

Jeremiah: what do we want to expose from core, there’s pressure from some parts of the community for core to be more isomorphic and support a lot of browser stuff. This issue is specifically about exposing what’s already implemented.

136

137

Ben: why not pull it out of core and put it in npm? util has always been about utilities that core uses.

138

139

Rod: when you expose something you’re stuck with it forever, minimising surface area should be our goal because the more we have to officially support the slower our release cycle will be.

140

141

### Proposal: Split TSC agenda in to two meetings [#1879](https://github.com/nodejs/io.js/issues/1879)

142

143

Mikeal: the scope of the TSC responsibilities are too wide, making meeting times go to long. The suggestion is to split up in to “project” related issues and “core” related issues.

144

145

Rod: can there be a clear distinction between the issues?

146

147

Domenic: assuming nobody wanted to attend two meetings, would there be enough?

148

149

Mikeal: yes because there are lots of people that aren’t here who would be in the other group

150

151

Rod: I wonder about the timing, e.g. letting the foundation kickoff happen first; it feels a bit premature to split now.

152

153

Mikeal: it’s a little premature but that’s because we haven’t onboarded the core working groups to this meeting.

154

155

Bert: in favour of the proposal.

156

157

_Discussed the pros and cons and agreed to tentatively move forward with experimentation, time slot for the new “project” meeting would either be after the current meeting or the day after that meeting._

158

159

### TSC needs to elect a board representative. [#1697](https://github.com/nodejs/io.js/issues/1697)

160

161

***Call ended prematurely due to Uberconference difficulties***

162

163

## Next meeting

164

165

166