Skip to content
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

Closed
Trott opened this issue Aug 30, 2016 · 20 comments
Closed

Node.js Foundation Core Technical Committee (CTC) Meeting 2016-08-31 #8330

Trott opened this issue Aug 30, 2016 · 20 comments

Comments

@Trott
Copy link
Member

Trott commented Aug 30, 2016

Time

UTC Wed 31-Aug-2016 20:00:

Timezone Date/Time
US / Pacific Wed 31-Aug-2016 13:00
US / Mountain Wed 31-Aug-2016 14:00
US / Central Wed 31-Aug-2016 15:00
US / Eastern Wed 31-Aug-2016 16:00
Amsterdam Wed 31-Aug-2016 22:00
Berlin Wed 31-Aug-2016 22:00
Moscow Wed 31-Aug-2016 23:00
Tokyo Thu 01-Sep-2016 05:00
Sydney Thu 01-Sep-2016 06: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

  • Process for determining supported platforms #8265
  • child_process, win: fix shell spawn with AutoRun #8063
  • fs: undeprecate existsSync; use access instead of stat for performance #7455
  • doc: add Google Analytics tracking. #6601
  • Introduce staging branch for stable release streams #6306
  • Move ecosystem detection tool to nodejs org #7935

nodejs/node-eps

  • AsyncWrap public API proposal #18

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.

@Trott
Copy link
Member Author

Trott commented Aug 30, 2016

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.

@Trott
Copy link
Member Author

Trott commented Aug 30, 2016

Standup portion of the doc is ready to be filled in.

@rvagg
Copy link
Member

rvagg commented Aug 31, 2016

@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.

@hackygolucky
Copy link
Contributor

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:

@Trott https://github.com/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.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8330 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB46oEZIdR3VmgG48zZgVLdtJWgPKMqZks5qlW7pgaJpZM4JwFVJ
.

@ChALkeR
Copy link
Member

ChALkeR commented Aug 31, 2016

Could we add #7935 for a brief discussion if there would be some time left?

@MylesBorins
Copy link
Contributor

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.

@Fishrock123
Copy link
Contributor

@thealphanerd Last week I was told consistency was not the issue...

@MylesBorins
Copy link
Contributor

@Fishrock123 it is one of a few issues I've brought up in the past. Others include:

  • Handling conflicts in advance
  • having a place to land things intermediately that does not pollute the release branch

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.

@ofrobots
Copy link
Contributor

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.

@Trott
Copy link
Member Author

Trott commented Aug 31, 2016

@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.

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?

@misterdjules
Copy link

I won't be able to make it today.

@jasnell
Copy link
Member

jasnell commented Aug 31, 2016

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

@Trott
Copy link
Member Author

Trott commented Aug 31, 2016

OK, I think I'm good to run this one. Can someone email (or otherwise private message) me the dial-in info just in case WiFi availability torpedoes my audio stream? EDIT: Thanks to @bmeck, I now have the info.

@chrisdickinson
Copy link
Contributor

Apologies, I won't be able to attend today.

@Trott
Copy link
Member Author

Trott commented Aug 31, 2016

A reminder for @nodejs/ctc that we agreed last week that this would be the first item on this week's agenda:

  • fs: undeprecate existsSync; use access instead of stat for performance #7455

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!

@Trott
Copy link
Member Author

Trott commented Aug 31, 2016

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:

  • doc: add Google Analytics tracking. #6601

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.)

@Trott
Copy link
Member Author

Trott commented Aug 31, 2016

Third reminder-ish for @nodejs/ctc: We agreed to defer this from last week until this week:

  • Introduce staging branch for stable release streams #6306

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).

@srl295
Copy link
Member

srl295 commented Aug 31, 2016

regrets today.

@Fishrock123
Copy link
Contributor

Livestream viewers: (max 9)

node_livestream_viewers-2016-08-31

@bnoordhuis
Copy link
Member

Apologies, I wasn't home in time to make the call.

@jasnell jasnell closed this as completed Sep 1, 2016
Fishrock123 pushed a commit that referenced this issue Oct 5, 2016
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>
jasnell pushed a commit that referenced this issue Oct 6, 2016
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>
Fishrock123 pushed a commit that referenced this issue Oct 11, 2016
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests