-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Node.js Foundation Core Technical Committee (CTC) Meeting 2016-08-31 #8330
Comments
For most participants, this meeting will take place on Wednesday afternoon/night or Thursday morning. The meeting will take place 41.5 hours from the time of this writing. |
Standup portion of the doc is ready to be filled in. |
@Trott care to chair this one? I'm still quite out of sync and mostly have my head in Foundation business and a bunch of Build WG stuff. |
Away from email/slack/phone during this meeting. No updates from last week. On Wed, Aug 31, 2016, 8:09 AM Rod Vagg notifications@github.com wrote:
|
Could we add #7935 for a brief discussion if there would be some time left? |
I unfortunately will not be able to make the meeting this time. I still believe that we should have a single release process across all lines, which includes having a staging branch for current. Consistency makes it easier for us to on board individuals, and makes it easier for contribution between the various release lines. |
@thealphanerd Last week I was told consistency was not the issue... |
@Fishrock123 it is one of a few issues I've brought up in the past. Others include:
Having done both current + LTS releases I have personally found that it adds work prior to the release, but significantly simplifies the process on release day. TBQH I think that the discussion has gone back and forth quite a bit. If the individuals who are primarily doing the current releases are reluctant then I'll let it be. |
It is more than just the releasers that should be considered. As someone who ends up doing, or help others do, quite a few V8 backports, the lack of uniformity of process on how to backport things to all the release branches is a big problem. Consistency is an issue for me. |
I'm traveling and will be on cafe WiFi. Should be OK, but we should have a Plan B and Plan C if it doesn't work out for me. Plan B = @jasnell? Plan C = whoever wants to do it can volunteer? Plan D = @rvagg does it whether he wants to or not? |
I won't be able to make it today. |
Not sure how well I would work as a Plan B today, unfortunately. The kids get out of school at 1pm pacific and I have to drop them off at their Robotics club meeting right after so I'm going to be mobile and away from the laptop for most of the call.... I'll be on the call, just won't have convenient access to the notes or agenda and will have to mute frequently |
OK, I think I'm good to run this one. |
Apologies, I won't be able to attend today. |
A reminder for @nodejs/ctc that we agreed last week that this would be the first item on this week's agenda:
Please be prepared to have a discussion if you think this is something you have an opinion on. As usual, we have a lot to talk about and it would be great if we could avoid (as much as is reasonable) briefing each other on this or trying to problem-solve during the meeting. Please go comment or ask questions in that issue! Thanks! |
Different reminder for @nodejs/ctc: We also agreed to try to get a quick resolution on this this week, so it should probably be the second item:
The consensus last week was that it seemed more-or-less OK but that it didn't seem right to move forward without @bnoordhuis being there for the conversation, since they had the strongest objections. (@bnoordhuis: Sorry for the short notice, but if you're not going to be at the meeting this week, it would be great if you get a chance to indicate that you're OK with it happening, or if you are strongly opposed, or whatever accurately describes your current opinion.) |
Third reminder-ish for @nodejs/ctc: We agreed to defer this from last week until this week:
The main reason was to have @thealphanerd there for the conversation as the two main viewpoints of the conversation seem to be best represented by @thealphanerd on the one hand and @Fishrock123 on the other. Since @thealphanerd is missing the meeting today, and since (AFAICT) this is not time-critical, I move that we table this for another week and try to have the conversation again at next week's meeting (unless, of course, things get resolved in GitHub to everyone's satisfaction between now and then). |
regrets today. |
Apologies, I wasn't home in time to make the call. |
This has been dragged through various long discussions and has been elevated to the CTC multiple times. As noted in #7455 (comment), while this API is still generally considered an anti-pattern, there are still use-cases it is best suited for, such as checking if a git rebase is in progress by looking if ".git/rebase-apply/rebasing" exists. The general consensus is to undeprecate just the sync version, given that the async version still has the "arguments order inconsistency" problem. The consensus at the two last CTC meetings this came up at was also to undeprecate existsSync() but keep exists() deprecated. See: #8242 & #8330 (Description write-up by @Fishrock123) Fixes: #1592 Refs: #4217 Refs: #7455 PR-URL: #8364 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ilkka Myller <ilkka.myller@nodefield.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
This has been dragged through various long discussions and has been elevated to the CTC multiple times. As noted in #7455 (comment), while this API is still generally considered an anti-pattern, there are still use-cases it is best suited for, such as checking if a git rebase is in progress by looking if ".git/rebase-apply/rebasing" exists. The general consensus is to undeprecate just the sync version, given that the async version still has the "arguments order inconsistency" problem. The consensus at the two last CTC meetings this came up at was also to undeprecate existsSync() but keep exists() deprecated. See: #8242 & #8330 (Description write-up by @Fishrock123) Fixes: #1592 Refs: #4217 Refs: #7455 PR-URL: #8364 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ilkka Myller <ilkka.myller@nodefield.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
This has been dragged through various long discussions and has been elevated to the CTC multiple times. As noted in #7455 (comment), while this API is still generally considered an anti-pattern, there are still use-cases it is best suited for, such as checking if a git rebase is in progress by looking if ".git/rebase-apply/rebasing" exists. The general consensus is to undeprecate just the sync version, given that the async version still has the "arguments order inconsistency" problem. The consensus at the two last CTC meetings this came up at was also to undeprecate existsSync() but keep exists() deprecated. See: #8242 & #8330 (Description write-up by @Fishrock123) Fixes: #1592 Refs: #4217 Refs: #7455 PR-URL: #8364 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ilkka Myller <ilkka.myller@nodefield.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Time
UTC Wed 31-Aug-2016 20:00:
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
nodejs/node-eps
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.
The text was updated successfully, but these errors were encountered: