Node.js Foundation Technical Steering Committee (TSC) Meeting 2018-06-20 #553
Comments
|
Regarding nodejs/node#19335, removing that from the agenda will require at least one of @addaleax @rvagg @thefourtheye @TimothyGu to indicate whether they support/oppose/abstain-on overriding @vkurchatkin's specific objection in that issue. There are subsequent objections from @Fishrock123 and @ChALkeR but as far as I can tell, they are on different grounds and/or are more open to discussion. @vkurchatkin's objection is firm and there's not much point in continuing discussion if the thing isn't going to land because of it. |
|
i’m traveling and I won’t be able to join this time
Il giorno lun 18 giu 2018 alle 21:15 Rich Trott <notifications@github.com>
ha scritto:
… Regarding nodejs/node#19335 <nodejs/node#19335>,
removing that from the agenda will require at least one of @addaleax
<https://github.com/addaleax> @rvagg <https://github.com/rvagg>
@thefourtheye <https://github.com/thefourtheye> @TimothyGu
<https://github.com/TimothyGu> to indicate whether they
support/oppose/abstain-on overriding @vkurchatkin
<https://github.com/vkurchatkin>'s specific objection in that issue.
There are subsequent objections from @Fishrock123
<https://github.com/Fishrock123> and @ChALkeR <https://github.com/ChALkeR>
but as far as I can tell, they are on different grounds and/or are more
open to discussion. @vkurchatkin <https://github.com/vkurchatkin>'s
objection is firm and there's not much point in continuing discussion if
the thing isn't going to land because of it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#553 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AADL4w7uV5pROpL0J1lH9X_W3YTECfNKks5t-Bh1gaJpZM4UroFC>
.
|
|
I dunno if you'll have time or if this is the proper way but could the topic of features being blocked because they can be implemented in userland be brought up? /cc @bmeck |
|
@devsnek You could add that to the agenda, but I am afraid there will not be anything actionable coming out of regular meetings. |
|
@devsnek Can you clarify what you'd want the TSC to do with the agenda item? Are you hoping the TSC can say either "Yes, that's a legit reason to block a feature" or "No, that's not a legit reason to block a feature"? Can you link to one or more issues that show why this is something the TSC should even bother deciding rather than allowing Collaborators to figure it out through consensus? My initial thoughts which are subject to change and only represent me: I don't think "implementable in userland" is necessary nor sufficient to block something, but is a factor considered along with many others. "Does Node.js need it internally so we have to implement it anyway?" is another consideration. "Is it a standard that would bring enhanced compatibility with web browsers?" is another one IMO although others may disagree about that. |
|
I guess the userland discussion is primarily about this: nodejs/node#21128 But if there are other PRs under consideration that have the same conversation going on, it would be good to know about them too. |
|
Oh, I see it's coming up in nodejs/node#21317 as well. |
|
Regarding nodejs/node#19335 — what if we land that as experimental for now (i.e. under a flag or printing an experimental warning) and see if there is interest in that API in that form and how would ecosystem use that (e.g. take a look at PRs), but while still being able to refine (or remove) it if there would be problems with it? My concern is that that API might turn out not useful and might need to be replaced with something else. Moreover, my opinion is that landing things as experimental with quick cycle (e.g. for one-two minor releases) should be done more often for some new APIs that does not have previous usage history. |
|
RE nodejs/build#1337 (comment). IMHO this could be pushed to a week when @rvagg is available to present the reasoning behind the status quo. |
|
@nodejs/tsc any objections to pushing out nodejs/build#1337 (comment) as suggested by @refack ? |
|
As a non-TSC member (and the OP of the Build issue), would just comment that the next TSC meeting that is at a non-crazy time in Sydney isn't for another two weeks (June 20 is at 12am, June 27 is at 3am, and then July 4 is at 8am). I think that the status quo has been well explained through various comments in nodejs/build#1337, other Build issues, and on places like IRC. Coming to a consensus on 1337 is critical for the WG, and is (for me at least) blocking some daily upkeep work. |
|
Ok I had thought @refack's suggestion meant a slip was ok with those waiting for access, but sounds like that is not the case so I'll leave on the agenda for this week. |
|
Regarding nodejs/build#1337, I have a feeling that much of the TSC will not be comfortable making any decision in Rod's absence. If that becomes evident during the meeting (or here in the issue tracker), I propose this: The TSC should delegate the decision on that one to a subgroup of the TSC. The subgroup will be Rod, me, and anyone else who both has the time and cares enough about this issue to participate in a meeting later this week to hash out something. The current situation (5 people with elevated access, none of whom are usually available, certainly not without any regularity or predictability) is unsustainable. It's already leading to burn out for people who care about Build WG and do work on it day-to-day. However, the concerns that Rod raises in that issue are not to be brushed aside lightly. But we gotta figure something out. So let's do it. I'm happy to take the lead on setting up the meeting if we can determine the membership of the subgroup and agree that everyone else defers to their decisions. If I had to take a guess as to TSC members who are likely to want to be part of this: Rod, Michael Dawson, Joyee, Gibson, and me. Anyway, this is only if people are like "We can't make a decision without Rod!" Which, I predict some sentiment along those lines will be expressed. |
|
I am taking personal time off today and won't be able to attend. |
|
Sorry I have to miss this meeting |
|
It's probably apparent already but: I can't make it (and can almost never make it at this time). |
|
If people are able to take a peek #532 |
|
@Fishrock123 could you list some things you would want to see if a timer diagnostic api became available? I'm going to start working on something but would love to know what use cases it needs to fill. I think the lack of arguments for removing the TimerWrap in the meeting are somewhat troubling.
Inspecting timers through a TimerWrap relies on 3 levels of undocumented internals... The PR that's now being considered for reversion took a long, long time, got plenty of reviews and not only made things faster (in some cases by 100%+) but also clearer. Edit: just saw your comment re: getActiveResources. Mostly makes sense. Perhaps could you create an issue for it? I'll get started on cobbling something together. |
|
PR for minutes #555 closing. |
Time
UTC Wed 20-Jun-2018 14:00 (02:00 PM):
Or in your local time:
Links
Agenda
Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
nodejs/build
nodejs/node
nodejs/TSC
Invited
Observers
Notes
The agenda comes from issues labelled with
tsc-agendaacross 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
Zoom link: https://zoom.us/j/611357642
Regular password
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 TSC that's not worth putting on as a separate agenda item, this is a good place for that
The text was updated successfully, but these errors were encountered: