uv: let's discuss the backport policy for LTS

[saghul]

Right now Node 4.x is running libuv 1.8.0. Since libuv follows semver, any further versions in the v1.x branch have a backwards compatible API and a stable ABI.

There won't be another libuv 1.8.X, because we are in the v1.9.x cycle now, so Node v4.x should adopt the latest and greatest, as a general rule.

Now, given the current stdio situation (#6456) let's wait for that to settle before taking action, but I wanted to get the ball rolling.

Edit: The Plan

• libuv 1.9.1
• tty: use blocking mode on OS X #6895
• unix,stream: fix getting the correct fd for a handle #6838
• udp: use libuv API to get file descriptor #6908

[rvagg]

I'm +1 on backporting given:

1. enough delay to let it prove in Node Current
2. review by LTS team of the changes being introduced and explicit sign-off by them

[Fishrock123]

cc @nodejs/lts

[jasnell]

This works for me in general but... my chief concern would be subtle behavior changes such as the stdio small block / flushing issue . Given the impact that has had on the ecosystem I would rather hold off until those issues are adequately resolved. (As suggested by @saghul ;)...)

[mhdawson]

I think it should come down to a risk/reward analysis which would be what I think the conditions @rvagg lists are meant to address. If there is a benefit to the LTS release in terms of fixing defects/problems and the level of change is acceptable, then I believe we should pull it in. If instead it is only new features and there is significant change then maybe its better to wait as LTS users likely value stability over "new". The balance might also depend on how far into the LTS cycle a release is. For example I don't think pulling in the latest into an LTS release a month or two before it goes out of service would make sense.

[saghul]

@mhdawson it's not only the new features, it's the bugfixes that matter here. LTS won't get any Node code backported which uses the new APIs, so that's fine. As it stands, Node 4 is running an unmaintained version of libuv, not even security bugs will make a v1.8.x happen.

@jasnell bugs do and will happen. the stdio thing was by no means an intended behavior change, it's still under investigation.

[jasnell]

@saghul ... yep, understood. The point is only that for the LTS stream we need to be much more conservative about how "up to date" we want to be. Letting things sit in current for a while to ensure that there are no significant regressions makes the most sense here.

[MylesBorins]

I'm not entirely opposed to the update but like others I am concerned about the various subtle changes introduced in 1.9.x

@saghul we should likely use this issue to keep track of the problems / solutions. Would you be willing to do so in the top comment?

[saghul]

I'm only aware of a single problem. Which I'm willing to help resolve (see #6456 (comment)).

Now, this is an interesting dilemma. From libuv's perspective, we fixed a bug, and tty writes are as non-blocking as they were, but Node was relying on "undefined behavior".

Let's try to get this solved together. Here is a tentative patch: libuv/libuv#878

[saghul]

Since Debian is currently wondering about the status of this, I'll make a status update. Note that as far as I'm concerned, there is only one problem caused fater the 1.9.X upgrade.

• in libuv 1.9.0 we switched from reopening /dev/tty to reopening ttynemae(3) in uv_tty_init: Reopen ttyname() instead of /dev/tty libuv/libuv#779
• turns out, that while kqueue can't work with a fd referring to /dev/tty it can work with one pointing to whatever ttyname(3) returns
• this means that after 1.9.0, the OSX select trick is no longer used for stdio ttys
• as luck would have had it, there was a bug in the OSX select trick handling code: darwin: fix setting fd to non-blocking in select(() trick libuv/libuv#879 which made tty handles blocking on OSX when the fallback was used (always)
• there is a dependency on this behavior by many CLI apps
• shit hit the fan

The inadvertent change in behavior only affects OSX, and once #6895 lands, thus restoring the old behavior in OSX we should be able to backport the libuv upgrade plus that workaround to LTS.

[saghul]

#6895 has landed, I'll wait until it makes it to a v6 release and then back port the libuv upgrade + that patch to v4. Is everyone OK with this?

[rvagg]

yes, but I'd still like to be very conservative on timing for this, it's possible other things might arise in v6

[rvagg]

but yes, a PR against v4.x-staging would be good, we can deal with timing separate to that

[jasnell]

Once such a pr is landed in v4.x-staging, we can generate a number of release candidates with the update that can be tested for further breakage.

[saghul]

Updated my initial comment with the plan / issues I'll backport. I'll get the PR worked out over the weekend, hopefully.

[MylesBorins]

@saghul it seems reasonable that this should be able to be mixed in with the v4.5.0 RC

thoughts @nodejs/lts?

[saghul]

@thealphanerd when is it supposed to come out?

[MylesBorins]

tentatively June 14th.

[saghul]

Ok. I'll get the PR ASAP and we take it from there.

[saghul]

PR: #7205

[jasnell]

Closing as there does not appear to be anything more to do