- Audio recording: https://www.youtube.com/watch?v=0gssTOvFsXg
- GitHub Issue: CTC#140
- Minutes Google Doc: https://docs.google.com/document/d/1W690JFykwVpN_V8zCSs_6yDTnFqAgE3juRz5k28SMWg
- Previous Minutes Google Doc: https://docs.google.com/document/d/1ZoLJImAGLJxivjLyCqzl7qXpjTOts1cKLwiR2XnzOLA
- Anna Henningsen @addaleax (CTC)
- Сковорода Никита Андреевич @ChALkeR (CTC)
- Colin Ihrig @cjihrig (CTC)
- Evan Lucas @evanlucas (CTC)
- Franziska Hinkelmann @fhinkel (CTC)
- Jeremiah Senkpiel @Fishrock123 (CTC)
- James M Snell @jasnell (CTC)
- Joyee Cheung @joyeecheung (CTC)
- Matteo Collina @mcollina (CTC)
- Michael Dawson @mhdawson (CTC)
- Myles Borins @MylesBorins (CTC)
- Ali Ijaz Sheikh @ofrobots (CTC)
- Rich Trott @Trott (CTC)
- announcements
- review previous meeting
- meta: semver impact of Error messages #13937
- proposal: ES module resolver spec for package.json "module" property #60
- Turbofan + Ignition release plan && comms plan #155
- doc: charter the Release working group #223
- Consider using another option like Google Meet instead of Uberconference (@mylesborins)
- Code + Learn @ NodeConf EU in November 5-8: nodejs/code-and-learn#69
- Code & Learn is an event where Node.js contributors assist people in starting to contribute to Node.js.
- Also looking for mentors, please sign up at the issue.
- Hoping for a budget for travel as well.
- Call with the V8 team #3: #156
- V8 team would like an update around TurboFan & Ignition, modules, performance, and other topics.
- Hopefully in a few weeks from now.
- doc: note that EoL platforms are not supported node#12672
- Discussion returned to GitHub. PR was eventually merged.
- meta: semver impact of Error messages #13937
James: working on introducing error codes. Doing it piecemeal. Having difficulting getting those reviewed & landed given that these are a semver major change. A concentrated effort to introduce these codes would make it a lot easier. MD: not ready to declare these changes not-semver-major. Need a fairly good amount of messaging, time to get the ecosystem ready. After than we can declare the policy that error message changes are not semver major. MB: Is this a good first time contribution? MD: A guide already exists. We could message this as a good first contribution more? James: each PR requires rebasing all the others. MB: pick some 2 days to do this? RT: maybe october code & learn. MB: doing this before october (node 9) would be better. RT: maybe an ad-hoc working group could do this. Happy to help if it was something scheduled. MC: Need some help on readable-stream for this to happen. We will need to back-port the error code system and make it work with older node versions. James: spinning out internal error code module could help. Problem is that the internal error code module uses ES6 features etc. Creating that module now and publishing it would require it to be updated weekly. MC: alternative idea: what if we stored the error code was stored in json files rather than in code. James: incrementally we want to get there. Originally wanted a resource file with these. Feedback was that is too complicated. Another problem: the API (errors.error): want to reduce the variance between core and standalone. RT: Move this back to GitHub? The key reason for this being on agenda was whether there is clear consensus that error message changes are semver major. That seems to be the case? general agreement MD: link to blog to promote awareness/asking for more help https://developer.ibm.com/node/2017/07/05/node-js-errors-changes-you-need-to-know-about/. I have also suggested for the node collection which would make it more visible.
AI: update the issue with the consensus (RT).
- proposal: ES module resolver spec for package.json "module" property #60
Leave it on the agenda for next time.
- Turbofan + Ignition release plan && comms plan #155
MB: A few questions: 1) best way to do communication about the release, 2) give the foundation enough of a head's up to be able to do a media push. For the latter a couple of days notice was sufficient based on feedback. Another question: whether to move forward with 5.9 or 6.0 for the release? We can go with 5.9 right now, but there is some known regression. Most of them have been fixed in 6.0. Some concerns (from V8 team, others) about giving a bad first impression of TF+I.
Is there something to gain from 5.9 out earlier?
AS: torn between 6.0 and 5.9. More feedback from community is better, so there is benefit of shipping 5.9 if it is ready. MB: The stable cut for 6.0 is next week. Maybe we should come up with a determination about when to ship 6.0. MC: Maybe ship a release candidate with 6.0? That way we could get feedback before making it official. MB: Supportive. Another discussion would be having a more formalized plan on when to pick new V8 version. MD: Maybe problematic for folks who are on the 'current' branch? We would be shipping a V8 version as stable before chrome ships. AS: Chrome beta is already shipping with 6.0. We could do an RC with 6.0, and that would be analogous. We don't necessarily have to mirror chrome in their behaviour though. It might be acceptable to 6.0 as stable before chrome does. MB: Given that the stable cut is soon, maybe an 2-week RC makes sense with 6.0. FH: not comfortable deciding this in a meeting - would be better to have dates in an issue. James: getting close to the 9.0 branch point. Not comfortable with pushing the decision too late. Jeremiah: puts LTS in a very bad position with backporting fixing. James: we should consider whether it makes sense to not go to 6.0 at all. MB: what would be the benefit of doing a 5.9 vs 6.0 RC. Jeremiah: could flip to 6.0 in the middle of RC. EL: already have been running an RC w/ 5.9.
Next steps: Back to GitHub.
- doc: charter the Release working group #223
MD: LTS + Release + CitGM teams chartered as a Release working group. Want to make sure people get an opportunity to review to proposal, scope, delegation. James: initially, does anyone on the call have reservations? crickets RT: Probably everyone would like to see it chartered. It's a matter of reviewing the charter. MD: please take a look!
Myles: next version of hangouts. If a Googler sets it up, we can have up to 50 people. If people are open to it, we can run a test meeting. At present it doesn't stream directly to youtube, but our current solution with uberconference should continue to work. MD: any effect on how we currently stream: Jeremiah: as long it provides audio to the desktop, should work. MD: Does youtube have a dial-out option? MB: maybe/probably? Let's do a test. If we can do a working demo and if it works, propose it for the CTC meeting next week. MB: let's do it in person next week at Node Summit.
Next Steps: Myles to take lead on this one.
- Node.js Foundation Calendar: https://nodejs.org/calendar
Click +GoogleCalendar at the bottom right to add to your own Google calendar.