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

Node.js Foundation Core Technical Committee (CTC) Meeting 2017-01-25 #63

Closed
Closed
Node.js Foundation Core Technical Committee (CTC) Meeting 2017-01-25#63
Labels
ctc-meeting

Description

@Trott
Trott
opened on Jan 23, 2017

Time

UTC Wed 25-Jan-2017 16:00 (04:00 PM):

Timezone Date/Time
US / Pacific Wed 25-Jan-2017 08:00 (08:00 AM)
US / Mountain Wed 25-Jan-2017 09:00 (09:00 AM)
US / Central Wed 25-Jan-2017 10:00 (10:00 AM)
US / Eastern Wed 25-Jan-2017 11:00 (11:00 AM)
Amsterdam Wed 25-Jan-2017 17:00 (05:00 PM)
Moscow Wed 25-Jan-2017 19:00 (07:00 PM)
Chennai Wed 25-Jan-2017 21:30 (09:30 PM)
Tokyo Thu 26-Jan-2017 01:00 (01:00 AM)
Sydney Thu 26-Jan-2017 03:00 (03:00 AM)

Or in your local time:

Links

Agenda

Extracted from ctc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

  • [WIP] meta: update copyright statements #10599
  • assert: enforce type check in deepStrictEqual #10282
  • [WIP] Restore copyright attribution #10155
  • lib: be robust when process global is clobbered #10135
  • process: Add code to warnings, assign codes to deprecations #10116
  • http: support environment-defined proxy #8381
  • meta: deprecation policy #7964

nodejs/TSC

  • Updating the Copyright #174

nodejs/node-eps

  • Rewrite 002 - esm #39

Invited

Notes

The agenda comes from issues labelled with ctc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Uberconference; participants should have the link & numbers, contact me if you don't.

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

Many of us will be on IRC in #node-dev on Freenode if you'd like to interact, we have a Q/A session scheduled at the end of the meeting if you'd like us to discuss anything in particular. @nodejs/collaborators in particular if there's anything you need from the CTC that's not worth putting on as a separate agenda item, this is a good place for it.

Activity

  1. Trott
    added
    ctc-meeting
    on Jan 23, 2017

  2. bnoordhuis commented on Jan 23, 2017

    @bnoordhuis
    bnoordhuis
    on Jan 23, 2017
    Member

    #10599, #10155 and #10135 can be dropped from the agenda unless there have been new developments. (#10135 I'm certain about because I didn't do anything.)

  3. seishun commented on Jan 23, 2017

    @seishun
    seishun
    on Jan 23, 2017

    Maybe consider including nodejs/node#10853?

  4. evanlucas commented on Jan 24, 2017

    @evanlucas
    evanlucas
    on Jan 24, 2017

    Apologies, but it's quite likely I'll be unable to attend this week. I'll be back on schedule next week. Thanks!

  5. Trott commented on Jan 24, 2017

    @Trott
    Trott
    on Jan 24, 2017
    MemberAuthor

    To clarify why #10282 is on the agenda, see nodejs/node#10282 (comment).

    • Primary/immediate: Do we need to unlock the API to land this? (

    • Secondary/longer term: I want to revisit what "Locked" means and whether assert should be locked or not. Like, shouldn't stuff like Support for comparing ES2015 Maps and Sets tape-testing/tape#342 result in someone submitting a patch making deepEqual() work as expected with Maps and Sets rather than a userland workaround? Can we at least agree that such a thing would qualify as a bug fix and not an API change? (If so, cool, I can live with that, at least certainly for now. If not, then I definitely want to argue that the API should not be locked.)

  6. evanlucas commented on Jan 24, 2017

    @evanlucas
    evanlucas
    on Jan 24, 2017

    shouldn't stuff like tape-testing/tape#342 result in someone submitting a patch making deepEqual() work as expected with Maps and Sets rather than a userland workaround?

    @Trott I had previously submitted a PR for that (nodejs/node#2315)

    I personally think we need to figure out what we want to do with assert. We obviously can't remove it, so why not make it actually work properly. Just my opinion though.

  7. bnoordhuis commented on Jan 24, 2017

    @bnoordhuis
    bnoordhuis
    on Jan 24, 2017
    Member

    I don't have a problem with unfreezing assert. Our story that assert is only for testing node itself isn't very convincing. We could simply cp lib/assert.js test/assert.js and then each version can evolve at its own pace. Given that, it makes sense to fix obvious bugs.

    That said, I still think it's a good idea to encourage people to use third-party modules. Assertion testing is not a core responsibility - the plethora of testing libs shows it doesn't need to be in core - and we have to be extremely conservative. Any API design mistake is a multi-year project to fix and even bug fixes will be semver-major most of the time.

  8. jasnell commented on Jan 24, 2017

    @jasnell
    jasnell
    on Jan 24, 2017
    Member

    I've been considering the possibility that assert could be spun off into it's own distinct module and vendored in to core as internal module.

  9. sam-github commented on Jan 24, 2017

    @sam-github
    sam-github
    on Jan 24, 2017

    We obviously can't remove it

    Sure, we can remove it. We would do this:

    1. create a nodejs/assert repo
    2. publish it to npmjs.org
    3. 

      4. 

    4. re-expose it as require('assert') for backwards compatability
      5. 

    5. doc-deprecate it in the next major
      6. 

    6. runtime deprecate it in the next major after
      7. 

    7. delete it in the next major after
      8. 

    

    Whether we would prefer to have endless debates when people (rightly) point out its not a very good library for writing unit tests, or to just push it into npmjs where it can be developed and semvered and the ecosystem can flourish (or just stop using it and move to one of the other actively developed assertion libs) is the question.
    

    We have a bit of a horror of removing things from node, but IMO, that kind of horror should be balanced with a stronger aversion to adding things to node. Lets not let "easy to get in - hard to get out" be our motto!
  10. sam-github commented on Jan 24, 2017 
    @sam-github
    sam-github
    on Jan 24, 2017
    @jasnell the problem with vendoring into core as a long-term strategy is it makes semver-major improvements  very painful. With npm modules semver-major is NBD, no one gets hurt, though they probably will want to update sometime (or not, if the old one works and there code is stable). When we vendor into core, we force the semver changes on people updating node, even when they update node because they need some critical-to-them feature, but are now forced to eat the price of updating to the latest assert. The assert usage is probably not even in their code, but in their deps, so updating can be quite painful. Its a decent temporary strategy, but not long-term, in my opinion.
  11. Trott commented on Jan 24, 2017 
    @Trott
    Trott
    on Jan 24, 2017
    MemberAuthor
    On the assert thing: The smallest thing we could do to get things unstuck in my opinion is to agree that modifying the assert module to deal with things like Symbols, Maps, Sets, etc. does not constitute changing the API (assuming no function signature changes). So making those sorts of fixes does not require unlocking the API etc.
    

    (The changes may be semver-major out of caution.)
  12. Trott commented on Jan 25, 2017 
    @Trott
    Trott
    on Jan 25, 2017
    MemberAuthor
    Let's add a quick discussion about nodejs/node#10187 (node-inspect) to the meeting.
  13. bnoordhuis commented on Jan 25, 2017 
    @bnoordhuis
    bnoordhuis
    on Jan 25, 2017
    Member
    It looks like I'll probably still be in transit by the time the call starts.  Apologies if I don't join.
  14. joshgav commented on Jan 25, 2017 
    @joshgav
    joshgav
    on Jan 25, 2017
    Contributor
    suggestion: should we add a list of items tagged ctc-review to the agenda and notes? that could remind CTC members each week to review those items yet indicate that we won't spend (much) time on them in the call.
    

    seems like we usually have a few items like that each week, nodejs/node#10970 is an example of one I might add this week, want to put it on your radar but probably don't need to discuss further today.
  15. joshgav commented on Jan 25, 2017 
    @joshgav
    joshgav
    on Jan 25, 2017
    Contributor
    notes in #64
  16. joshgav
    closed this as completedon Jan 25, 2017
  17. thefourtheye commented on Jan 26, 2017 
    @thefourtheye
    thefourtheye
    on Jan 26, 2017
    Sorry, my alarm failed me 😢
  18. addaleax
    added a commit that references this issue on Apr 3, 2017
    assert: add support for Map and Set in deepEqual
    6481c93
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
No one assigned
    Labels
    ctc-meeting
    Type
    No type
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions