Repository navigation
Create proposal for list of officially supported platforms #488
Description
This is an extension of nodejs/node#8265 (making a new issue because we don't seem to have a build-agenda label 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:
- It's entirely up to the CTC to sign off on a "supported platforms" list
- The Build WG can be used as an expert group to (a) come up with an initial proposed list and (b) occasionally advise on updates to the list or be consulted on proposed updates. If we had an active Hardware WG then they could also be in the conversation but we don't have that right now.
- It would be good to have at least 2 tiers of hosts, perhaps even 3 (names could be improved here):
- Officially supported: test failures on these permutations should prevent a release; master and release branches should always be green on these
- Aspirationally supported: aiming for always-green but releases shouldn't be held up and collaborators should attempt to get to green on master and release branches but excessive yak shaving to get support should not be a holdup (e.g. getting musl features working for alpine builds?)
- Experimental: mostly would be the Build WG playing with new platforms, no requirement for collaborators to even pay attention to these if they don't care
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.
Activity
rvagg commentedon Sep 7, 2016
Initial list might be worth taking from libuv: libuv/libuv@be0e24c (/h1 @cjihrig).
Also note FTR that this needs to go back on
ctc-agendawhen we have something, the CTC is waiting on us here.claudiorodriguez commentedon Sep 7, 2016
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.
rvagg commentedon Sep 7, 2016
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.
geek commentedon Sep 7, 2016
@rvagg looks good.
The list should include SmartOS as an officially supported tier 1 platform with @misterdjules and myself supporting it.
misterdjules commentedon Sep 7, 2016
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.
bnoordhuis commentedon Sep 7, 2016
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.)
mhdawson commentedon Sep 7, 2016
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.
misterdjules commentedon Sep 7, 2016
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.
mhdawson commentedon Sep 7, 2016
I think that only AIX has more flaky tests (which we are working on). PPC and linuxOne run consistently clean.
jbergstroem commentedon Sep 20, 2016
Here's a initial stab at a "supported platform" document: https://gist.github.com/jbergstroem/8a4a5b6a602aacc96eb8a171698c324c
Trott commentedon Sep 20, 2016
jbergstroem commentedon Sep 20, 2016
No one from the build group has compiled or tested Node.js on Smartos 15 and 16.
Trott commentedon Sep 20, 2016
Ah! I see. Never mind. Makes sense to me.
jbergstroem commentedon Sep 20, 2016
The idea is to have a document on the table for next weeks (Week of September 26th) CTC meeting.
17 remaining items
jbergstroem commentedon Sep 28, 2016
Posting it here in its current form:
Supported platforms
A 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.
Input
We 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.
Strategy
Support will be divided into three Tiers:
Supported platforms
Supported toolchains
Depending on your host platform, the selection of toolchains may vary.
Unix
Windows
1: For backporting to Node v4.x: Visual Studio 2013
Shared libraries/dependencies
Node.js intends to support building against shared representations of
what can be found in
deps/as long as the version of the sharedlibrary is at least equal or newer to the one found in
deps. Seeinghow we've floated patches in the past, we're yet to officially support it.
Fishrock123 commentedon Sep 28, 2016
Is
Linux (musl)Alpine Linux?jbergstroem commentedon Sep 28, 2016
@Fishrock123 not necessarily but Alpine definitely the more important distribution representing musl.
Fishrock123 commentedon Sep 28, 2016
I will note that we may want to have "experimental" support for the
mipsarchitecture, issues pop up here and there and we usually try to fix them for it. I understand getting testing hardware could be difficult though. I was hoping we'd be able to solve that via Tessel 2... :/jbergstroem commentedon Sep 28, 2016
@saghul: have you had a chance to test libuv on mips?
bnoordhuis commentedon Sep 28, 2016
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. :-)
saghul commentedon Sep 29, 2016
@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.
saghul commentedon Sep 29, 2016
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).
saghul commentedon Sep 29, 2016
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, ...."
jbergstroem commentedon Sep 29, 2016
@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? :)
rvagg commentedon Oct 4, 2016
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?
jbergstroem commentedon Oct 11, 2016
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.
isodnc commentedon Sep 2, 2021
isodnc commentedon Sep 2, 2021
İsodnc/deps/#488