Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

Latest commit

 

History

History
328 lines (225 loc) · 10.5 KB

2017-01-04.md

File metadata and controls

328 lines (225 loc) · 10.5 KB

Node Foundation CTC Meeting 2017-01-04

Links

Present

  • Anna Henningsen @addaleax (CTC)
  • Colin Ihrig @cjihrig (CTC)
  • Evan Lucas @evanlucas (CTC)
  • Jeremiah Senkpiel @Fishrock123 (CTC)
  • James M Snell @jasnell (CTC)
  • Josh Gavant @joshgav (observer/Microsoft)
  • Michael Dawson @mhdawson (CTC)
  • Brian White @mscdex (CTC)
  • Myles Borins @MylesBorins (CTC)
  • Michaël Zasso @targos (CTC)
  • Sakthipriyan Vairamani @thefourtheye (CTC)
  • Trevor Norris @trevnorris (CTC)
  • Rich Trott @Trott (CTC)
  • Bradley Meck @bmeck (observer/TC39)

Standup

  • Colin Ihrig @cjihrig (CTC)
    • Some test PRs. Reviewing issues and PRs.
  • Evan Lucas @evanlucas (CTC)
    • Working more on allowing a buffer in crypto.randomBytes
    • Working on v7.4.0 release proposal
  • Jeremiah Senkpiel @Fishrock123 (CTC)
    • holidays, misc minor stuff
  • James M Snell @jasnell (CTC)
    • Vacation! Glorious vacation!
    • Reviewing and landing PRs
    • Working on URL and HTTP/2 stuff
  • Josh Gavant @joshgav (observer/Microsoft)
    • Some diagnostics PRs
  • Michael Dawson @mhdawson (CTC)
    • On vacation the last few weeks
    • This week catching up on issues and reviewing PRs
  • Brian White @mscdex (CTC)
    • Submitted PRs for various optimizations in core, more to come
    • Reviewed PRs, commented on issues
  • Myles Borins @MylesBorins (CTC)
    • Released latest 4 / 6
    • Reviewed PRs, commented on issues
    • Changed my online handle
    • General work on citgm
  • Michaël Zasso @targos (observer)
    • PR review and issue comment
  • Sakthipriyan Vairamani @thefourtheye (CTC)
    • child_process signal issues
    • PR reviews
  • Trevor Norris @trevnorris (CTC)
    • vacation, some async hooks stuff
    • Thorsten Lorenz helping to write docs and tests
  • Rich Trott @Trott (CTC)
    • onboarded @joyeecheung
    • test/doc/tool PRs
    • PR/issue review/comment

Agenda

  • Landing npm 4 into node 7 node#10505
  • console.log and util.format should support the %i integer conversion node#10292
  • timers: cleanup extraneous property on Immediates node#10205
  • process: Add code to warnings, assign codes to deprecations node#10116
  • doc: Deprecate old debug protocol node#10320
  • [WIP] Restore copyright attribution node#10155
  • Updating the Copyright TSC#174

Previous Meeting Review

  • deps: upgrade npm to 4.0.5 node#10330
  • console.log and util.format should support the %i integer conversion node#10292
  • timers: cleanup extraneous property on Immediates node#10205
  • [WIP] Restore copyright attribution node#10155
  • process: Add code to warnings, assign codes to deprecations node#10116
  • Updating the Copyright TSC#174
  • CTC Meeting Times for 2017 CTC#49

Minutes

Landing npm 4 into node 7 #10505

@Fishrock123: Some minor breaking changes, should we include in a Node 7 release? It’s already in master.

Would allow us to test npm@4 earlier and gauge problems encountered by users.

@jasnell: Would like it to sit in our master for a couple weeks so people have a chance to try it.

@Fishrock123: npm prereleases are more often tested directly, not through bundling in Node.

We could consider an RC and seek testers, but we could also ask people to update to npm4 and test without an RC.

@MylesBorins: We could wait till later in 7 lifetime to reduce amount of time we have to support it.

@Fishrock123: We would most likely revert if problems arose.

@EvanLucas: Better to include now and thereby prepare people for Node 8.

@jasnell: If anyone is opposed they should raise their concerns within the issue/PR. Otherwise we have consensus.

Next steps:

  • Be prepared for quick reversion if necessary.
  • Include in 7.4 release (Evan Lucas).

console.log and util.format should support the %i integer conversion #10292

@Fishrock123: This is not necessarily a single issue, what is the question we are addressing here?

@joshgav: Seems there is a greater issue of what standard console behavior should be, and whether we should adhere to existing quasi-standard behaviors.

@jasnell: Comparable to work on URL spec.

@Fishrock123: That’s what the WHATWG console spec is meant to address, but it’s not complete.

@MylesBorins: Meta-issue is whether we should work with WHATWG to arrive at common conventions. Issue is that browsers will dominate discussion.

@Fishrock123: Much work on timers has been to make Node’s behavior as close to browser behavior as possible.

@evanlucas: API needs for console in Node are different than in browsers.

@bmeck: Inspector hooks into our Console API. So console.log output is captured by the inspector as well. It patches console.log to do this.

@jasnell: Likely because we’ve never given an API to hook into console output.

@bmeck: They also add console.group and others.

@Fishrock123: Question is: Are we interested in following a proper console spec?

@jasnell: Should this consideration hold up this issue/PR?

@evanlucas: This issue could be handled in userland, like the ‘printf’ module.

@bmeck: We actually ship two different consoles - the Inspector console API is different.

Differences between our console and WHATWG console are mostly documented in this issue and its inline links.

Next steps:

  • More investigation into WHATWG work, if we should participate in that work, and if we should follow the final spec.
  • Continue discussion in GitHub.

timers: cleanup extraneous property on Immediates #10205

@Fishrock123: An extra property (_callback) was added 2-3 months ago which just copies another property (_onImmediate) but actually behaves a bit differently 2-3 months ago. Other similar extraneous properties from similar APIs have been removed; this seems to be of the same category.

@jasnell: Any evidence that it’s actually in use?

@trott: Okay with landing this PR, but concerned about hand-wavey nature of determining whether something is semver-major.

@jasnell: If it’s in 6 we should take it through a deprecation cycle, if it’s only in 7 we can remove immediately.

@mhdawson: If it’s in an LTS it should go through a deprecation cycle.

@jasnell: For clarity to ecosystem it’s better to take these through a deprecation cycle.

@Fishrock123: Adding deprecation wrapper may slow down/deopt setImmediate.

@jasnell: If we ensure our code avoids the deprecated property we would avoid any deopt or slow down.

@trevnorris: Almost everything in Node is somehow accessible publicly. Does this mean that any internal change has to be deprecated first?

@jasnell: We need a better policy to define what must be deprecated.

And perhaps to define what is internal and what is a public API.

@jasnell: Because this is in LTS it would be better to go through a deprecation cycle.

@trevnorris: Let’s take to a vote in the PR.

Next steps:

  • Vote in PR.
  • Review James’ issue on deprecation policies #7964

process: Add code to warnings, assign codes to deprecations #10116

Deprecation policy discussion: nodejs/node#7964

@jasnell put on agenda to ensure all review and get some LGTM’s.

  • Adds a static ID (number) to all deprecations.
  • Adds a runtime flag to redirect deprecation warning output to a file.
  • Also allows us to gather all deprecations in one place in docs.

Goal is to make dealing with deprecations easier.

@Fishrock123: Really old deprecations should have reduced information in docs.

Next steps:

  • Review this PR.

doc: Deprecate old debug protocol #10320

Doc-only deprecation is also considered semver-major, but we should go ahead and land now.

@Fishrock123: Aren’t we violating our own policies in deprecating and removing this?

@mhdawson: Because it’s dependent on V8 we’re limited in our options.

@jasnell: Although not ideal, best to include deprecation now in Node 7.

What about runtime deprecation?

@joshgav: A PR is open, needs some updates: nodejs/node#10276

@trott: Can we include a runtime deprecation before we have node-inspect? That is, should we wait till node-inspect is properly bundled and node inspect can replace node debug till including a runtime deprecation?

@joshgav: Can break up 10276 into 2 PR’s, one for --debug deprecation (listener) and one for node debug (CLI debugger). node debug is dependent on landing node-inspect in master.

Next steps:

  • Land docs deprecation.
  • Continue discussion on runtime deprecation.

[WIP] Restore copyright attribution #10155

Updating the Copyright #174

Two PRs:

  1. To revert to previous state including Joyent attribution. #10155
  2. To shift to new header format. #10599

(1) has been requested by the Legal Committee. For questions, go through @mikeal. (2) requires more review and Legal Committee signoff.

Encourage folks to review.

@trevnorris: Can these land at the same time, back-to-back?

Probably not, depends on legal committee review.

Q/A on public channels

Someone: Using npm@4 for a while without issues.

Upcoming Meetings

Node.js Foundation Calendar: https://calendar.google.com/calendar/embed?src=kap.co_i17i575te0aes6kaanfjr2e4hs%40group.calendar.google.com