Create proposal for list of officially supported platforms #488
Comments
|
Initial list might be worth taking from libuv: libuv/libuv@be0e24c (/h1 @cjihrig). Also note FTR that this needs to go back on |
|
Not part of the workgroup but I thought it might be useful to share that Mozilla also similarly does Tier 1-3: https://developer.mozilla.org/en-US/docs/Supported_build_configurations and has some nice explanations to go with them. |
|
Nice, I particularly like the way they assign individuals responsible for tier-3 platforms, we can be doing that with the IBM platforms for instance and if anyone shows up super keen to maintain something obscure then we can give them a 👍 as long as their name gets to go next to it and they remain responsive enough to fix stuff. |
|
@rvagg looks good. The list should include SmartOS as an officially supported tier 1 platform with @misterdjules and myself supporting it. |
|
I'm not part of the working group, but I would like to add that the list of platforms supported by libuv is not necessarily a good starting point for the Node.js project with regards to the Solaris and SmartOS platforms. The libuv project currently documents only Solaris (and not SmartOS) as a supported platform. The reason for not using the name SmartOS and for not making it a tier 1 platform, even if tests are run by the CI infrastructure on SmartOS and they all pass, might be that there's no official collaborator to the libuv project who committed to support that platform full time, even though I've been responding quickly to any issue that arose in the past. For the Node.js project, node "sunos" binaries are actually built on SmartOS, and as a result don't run on Solaris. So they are effectively supported only on SmartOS and should really be "smartos" binaries. Finally, there are at least two official collaborators in the Node.js project who can support the SmartOS platform full-time (@geek and me). As a result I would expect the SmartOS platform (named "SmartOS", not "SunOS", "Solaris" or with any other name) to be present in the list at tier 1 level. |
I think that is stretching it a bit. IBM has a magnitude more people working on node.js and I don't think we claim that AIX/zOS/PPC are tier 1. And no offense to you personally but I don't see many code fixes or interaction on the bug tracker vis-a-vis smartos-related issues from you. To claim tier 1 status for a platform, its supporters should be both active and proactive; I think it's fair to say that neither you nor @misterdjules really fit that description. (I'm not attacking or berating you, just stating my perceptions. If you think I'm wrong, please say so.) |
|
Just to throw in my 2 cents in, I like the Mozilla 1-3 but I would like to see the IBM platforms getting to Tier 2 as I think we do better than Tier 3 implies. There is hardware in the CI for these platforms and pretty much all tests are running on them as well. |
I don't think comparing the number of people employed by some of the companies that drive the development of some platforms on which node runs is a good way to approach this problem. It seems that the reason why some of the maintainers of the AIX/zOS/PPC platforms may not be considering these platforms as part of tier 1 yet is that they've been added relatively recently to the CI platform compared to other platforms such as SmartOS, and they still have more tests failing and/or flaky than most other platforms. In comparison, tests for the SmartOS platform have been running for years and now run with a number of flaky tests that is comparable to other platforms, thanks among other things to the great work done by @Trott, @jbergstroem, @santigimeno, the @nodejs/platform-solaris team and others.
@geek joined Joyent only two weeks ago, and thus just started to have the time resources to focus on SmartOS since then, so it's not a surprise you haven't seen him active on that platform yet. But Joyent hiring him is a clear sign of its commitment to maintaining Node.js on SmartOS.
I've been active and proactive in supporting the SmartOS platform, in nodejs/node, libuv/libuv but also in other projects like nvm. When not directly involved in fixing issues that are specific to SmartOS, I've provided support and resources to the build team for issues related to the SmartOS platform on a regular basis. Several other collaborators that I mentioned above have done the same. This is why the level of support for the SmartOS platform in the Node.js project matches both libuv's and Mozilla's definition of a Tier 1 platform. If that level of support is not considered enough, then we should work together to bring it to a level that satisfies the expectations. An example of such an effort is libuv/libuv#1036, where I'm trying to improve the communication channels between the libuv collaborators team and maintainers of the SmartOS platform. |
|
I think that only AIX has more flaky tests (which we are working on). PPC and linuxOne run consistently clean. |
|
Here's a initial stab at a "supported platform" document: https://gist.github.com/jbergstroem/8a4a5b6a602aacc96eb8a171698c324c |
|
No one from the build group has compiled or tested Node.js on Smartos 15 and 16. |
Ah! I see. Never mind. Makes sense to me. |
|
The idea is to have a document on the table for next weeks (Week of September 26th) CTC meeting. |
Does that mean that node binaries built on SmartOS 14 (or any other platform version) would not be available from nodejs.org? |
|
@misterdjules: I'll remove that line. Was there while drafting, doesn't belong. |
|
Isn't "macOS >= 10.7" a little white lie? We only test 10.10, don't we? |
|
Also:
Since we regularly float patches, I don't think we can really make that claim. I'd mellow it to 'best effort' status. |
Yes, you're right. We're hopefully closing in on having this environment up and running -- I guess that won't make it in a week though. It would indeed be a shame to enforce 10.10 seeing how 10.7 is lowest req for v8 5.2 (right? -- recall chatting about that a few months back) and 10.8 for v8 5.4. Would that imply that we just drop support for <10.10 or add >10.7 < 10.10 as a lower Tier?
The last times we've floated (sans v8) - for instance http_parser - could have been avoided. I think we should be more careful with floating. You're correct in this not being the place for that discussion though. C-ares is a bit unfortunate too, but I've successfully linked and tested against the upstream version, windows being the exception. Unless other people chip in I'll update the wording before we put it in front of CTC. |
If we can add 10.8 and 10.9 to the CI, I'd be okay with promoting it to tier 1. I think IBM internally tests from 10.8 and up but I don't know the details. No opinion on 10.7. If that's not an option, we could demote <10.10 to experimental / best effort status. |
|
This is what https://www.netmarketshare.com/ reckon the breakdown is for last month:
Nobody deploys server code to OSX, I suspect that the primary way that OSX is a distribution target for us is now via Electron, although I'm not sure how to factor that in to our deliberations here! The dropoff below 10.10 is pretty sharp, below 10.9 it becomes even more decisive. At 10.9 we're at nearly 1/2 of what Windows Vista still holds and 10.8 is a 5th of Vista. Given those numbers I think I'd be comfortable relegating <10.10 to a lower category and when we get our new OSX testing infra we can make a call on how far below 10.10 we go but it's hard to see the point in even going to 10.9 with those numbers. The only strong opinion I hold here, however, is that I don't really want us to spread ourselves too thin, which argues for keeping things as tight as we can justify without pushing too many potential consumers to the margins. |
Correct. Minimum supported operating systems for IBM built binaries for v6 can be found on the table at the bottom of https://developer.ibm.com/node/sdk/#v6 |
|
@richardlau does that mean IBM only supports OS X 10.8? I don't see a "or later" footnote. |
|
@jbergstroem what are the X and Y in the GNU/Linux Tier 2/3 colums? WIP? |
|
@sam-github It means that's the version of OS X in our internal CI that ran tests on the binary. |
|
@sam-github: the X/Y will be filled in by @mhdawson shortly. |
|
Yes as @jbergstroem says I was just not sure what the X and Y were off hand. I just need to pull then from what ubuntu and RHEL 7.2 use. |
|
I've updated the proposal to reflect the changes in macOS support as well as taking a step back from shared builds. |
|
Linked gist LGTM. |
|
We may need to break out the PPC/BE ones a bit as this is the info for the machines/OS levels we currently build/test on for s390 and PPC. s390: kernel>=3.10, glibc 2.17 |
|
@mhdawson: updated. |
|
Posting it here in its current form: Supported platformsA list of platforms supported by Node.js. This list needs to be kept up to date and released with each version of Node.js. The current version (below) is based on node 6.x but it should suggestively be backported to 4.x as well. InputWe rely on a few dependencies that ‘makes us who we are’ -- most importantly v8 and libuv. We therefore need to adopt their supported platforms and potentially add to their lists based on test and/or release coverage. StrategySupport will be divided into three Tiers:
Supported platforms
Supported toolchainsDepending on your host platform, the selection of toolchains may vary. Unix
Windows
1: For backporting to Node v4.x: Visual Studio 2013 Shared libraries/dependenciesNode.js intends to support building against shared representations of |
|
Is |
|
@Fishrock123 not necessarily but Alpine definitely the more important distribution representing musl. |
|
I will note that we may want to have "experimental" support for the |
|
@saghul: have you had a chance to test libuv on mips? |
|
Another option is cross-compiling and running in qemu-user-static or qemu proper. It has support for quite a few flavors and models: mips, mipsel, mips64el, mipsn32, mipsn32el, mips32r5, etc. A chroot or vm image will be necessary for things like the procfs to work. @jbergstroem I test libuv on mips very infrequently. The LKGR is at least over a year old. :-) |
|
@jbergstroem Not personally, but we've fixed a bug or 2 on MIPS because Debian builds libuv packages and runs the test suite. I did setup a qemu instance at some point to fix a bug, but it was painfully slow. |
Not that I have a horse in this race, but shouldn't that be >= Vista? AFAIK there is nothing (in libuv at least) which is improved by dumping Vista. FWIW for v2 we so far dumped XP / 2k3, so Vista will still be supported (for now). |
|
Maybe a note about other platforms not in the list woud be nice? OpenBSD comes to mind, for example. Something along the lines of "the fact that a platform is not in this list does not necessarily mean it doesn't work, merely that's not officially supported in any capacity, ...." |
|
@saghul re OpenBSD/others: I'm open to that. Also, if others are reading this I'd love to add OpenBSD to our experimental tier if we could get access to vm's running it (anyone at Vultr reading this? :) |
|
Moving to nodejs/node#8922 I'm -1 on putting MIPS on it at this stage simply because even as Experimental it needs to be "There needs to be at least one individual providing maintenace and should strive to broaden CI test coverage." and we don't have that, there's nobody in core afaik that does this. It'd be nice to work towards that and putting qemu host in CI somewhere but until that happens let's leave this off eh? |
|
Seeing how we've passed this back to the node org I'll close this. If we get more feedback/questions I guess we can facilitate the same issue. |
|
|
İsodnc/deps/#488 |
This is an extension of nodejs/node#8265 (making a new issue because we don't seem to have a
build-agendalabel we're using to make agenda items outside of our repo). We're being delegated the task of coming up with a proposal for an initial supported platforms / permutations list for the CTC to accept.Would someone like to put up a hand to start such a list? We did have one on our very first README.md iteration but it's been removed for lack of maintenance (and it was aspirational rather than reflecting anything we had).
My proposal for process is (copied from nodejs/node#8265 (comment)):
Proposal from the Build WG meeting this week goes something like this:
The trick here is the technical pieces to have different levels of support. Ideally we'd be able to prevent failures on the non-official platforms from causing a red/failed build. Perhaps we can reuse the yellow/flaky stuff somehow. The Build WG has some ideas here and some TODOs for experimentation on how to make this work. The other path is to simply deal with this complexity through the new github bot that's going to be reporting all sorts of stuff to github and may even mean collaborators don't need to even touch or look at Jenkins.
The text was updated successfully, but these errors were encountered: