-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
meta: 32 bit linux is experimental #16723
Conversation
Does dropping public builds for a platform automatically downgrade it to experimental? I mean, we still run CI on it and all. |
I don't think automatically, but that was the consensus in nodejs/build#885 (comment): |
I’m not sure this is the right place, but am I the only one uncomfortable dropping what is, according to the metrics, the architecture with the second-most monthly downloads by far? |
IMHO this is the right place. This PR is the build WG making a recommendation.
|
I'm wondering if those "unknown" values are 32-bit? I am not sure we can safely assume they aren't? I think we should consider supporting 32-bit for at least as long as V8 does. |
It will still be supported. You will just have to build it yourself. |
So the plan is to continue CI on 32 bit linux exactly to make sure "source and headers" 32 bit support will not rot. |
I don't get the reasoning for this. If we are still going to be testing it in CI anyway, why not just make the build artifact available to the public? |
@mscdex Because that artifact wouldn't necessarily work everywhere, see for example nodejs/build#797 (comment). Making a build that works everywhere is more complicated than just building and testing on the same machine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as per the discussion in nodejs/build.
@seishun I don't see that as being any different than the situation with the currently available 32-bit (or any architecture really) binaries? If we're just keeping one 32-bit machine, then just build against whatever the oldest glibc we support on that machine, then make those build artifacts available. It just seems silly for us to test against 32-bit then simply discard the perfectly usable built binary because we don't want to simply tar it up. |
Marking Note that the reason to do this now is so we have six months to test it out before 10.x. Hopefully the Current release cycle will give us time to gather feedback about how many people will be affected. This is definitely something we could "revert" if there is still demand. We could also partially revert, and support a smaller set of platforms on x86 Linux. Removing is semver-major, re-adding is semver-minor. |
You can read more about the current situation in nodejs/build#885. In short: 32-bit Linux releases are currently built on a CentOS 6 machine, but it has gcc 4.8, which is not supported. But the packages with newer gcc versions are not available on 32-bit CentOS 6. |
Is compiling them ourselves from source, for the CI machine, an option? |
Possibly, but that's a lot of work that no one in Build WG seems to be willing to do. See the discussion around nodejs/build#809 (comment). |
A glibc maintainer advised against that, as it will not solve need to distribute a new glibc. nodejs/build#809 (comment) |
It's more an issue of supporting. That binary may simply not work on all 32 bit linux distros out there. Researching this and trying to figure out all the implications has already required substantial effort from the Build WG, and we are still without clear conclusions. So we recommend downgrading 32 bit linux support in order to focus resources on more significant platforms. |
Ok, so then here are two solutions:
|
Downgrading the support is one thing, but throwing away the binary away instead of making it available to those who can use it is silly IMHO. If you want, put the glibc version in the tarball filename or something. |
Well, really at most right? If V8 stop supporting 32-bit, then we will by default.
We might have to stop testing in CI, or change what levels we can test, during 10.x's timeframe.
Whatever we're Tier 1 supporting in April will be what we are supporting till April 2021 (in 10.x). We could definitely consider making binaries available for people to use, experimental doesn't mean "we can't do builds", it means "you shouldn't rely on this sticking around for the whole release line". Definitely open to still shipping some binaries though, maybe we could continue to do nightlies on a different machine, that way people could get node builds while knowing they shouldn't be relied on. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm generally +1 on this. I don't know about calling it "Experimental"... perhaps we need a new term.
Given
This change, with pre-requisites to make sure we are able to build again if need be, looks reasonable to me. |
If someone wants to look deeper into the numbers, grab a month or so from the bottom of the list of files @ https://nodejs.org/metrics/logs/ and see what versions of Node that the x86 builds are being downloaded for. A simple breakdown of semver-major versions would be really helpful here. |
AFAICT there are no strong objections to the documentation change, as long as we keep testing, and releasing the binary for as long as it's simple to do. If anyone objects, please state so, as I'm planning to land this. |
From the definition of Experimental:
It's not true since we run CI on three 32-bit Linux machines on master. Moreover, one of those machines runs Ubuntu 16.04, and Ubuntu 16.04 is going to be supported until April 2021. Which means we can continue running CI on 32-bit Linux until the end of Node 10.x LTS (April 2021) without any effort from the Build WG. (correct me if I'm missing something) And if we want to explicitly drop support for 32-bit Linux during Node 10.x lifetime (by intentionally landing changes that break 32-bit Linux), then Experimental doesn't cut it - it should be removed from the list entirely. So I'm -1 on this, but I would agree with downgrading the support level to Tier 2. edit: never mind, see below. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making -1 explicit.
I don't think that is adequate coverage to say we support
Why? It's experimental as long as we're making some effort to support it. We aren't currently planning to intentionally break x86, if we do then at that point it should be removed. Overall I think it's not semver-major to break an experimental platform, but it is for Tier 1 and 2. And that means we should move x86 to experimental. |
In that case, perhaps it would be reasonable to state that
On a second thought, I agree with it if Experimental basically means "it's okay to break it, but we also welcome patches to un-break it". But I'm not sure if it's really necessary. 32-bit Linux is not an exotic platform that's hard to set up to test your changes locally, so the person who breaks it is probably the best person to fix it (that is, if we want to fix it at all). |
You want
I agree that it might be more accurate to split them out, but in terms of the overall message we want to send here, I think it would be clearer to just say "if you're using 32-bit Linux on Node 9.x+, don't rely on it continuing to work going forward". Sure, people can update to a newer OS level and stay on x86, but I think we'd rather suggest that they get off 32-bit x86 entirely (and if they can't, come and tell us so we can reconsider). Running CI means we can be sure it's not too hard to move it back up if there's demand. |
PR-URL: nodejs#16723 Refs: nodejs/build#885 Refs: nodejs/nodejs.org#1446 Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]>
0f8ca1f
to
dbb3c00
Compare
PR-URL: #16723 Refs: nodejs/build#885 Refs: nodejs/nodejs.org#1446 Reviewed-By: Gibson Fahnestock <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]>
Does this make sense for 6.x or 8.x? |
Don't think so, discussion was specifically about 9.x and above. |
Refs: nodejs/build#885
Refs: nodejs/nodejs.org#1446
[update]
This PR is the Build WG making a recommendation. Detailed discussion is in nodejs/build#885
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
meta