Should we continue to support FreeBSD?

[targos]

I'm opening this because at the moment, the update to V8 6.0 is blocked by FreeBSD 10 that cannot compile V8 because of a bug in Clang.
I opened an issue about that on May 9 and a suggestion was to upgrade Clang, so I opened another issue on the build repo for that on May 16.
Nothing really happened for about a month and then @kfarnung investigated a bit and found that we would need to update Clang to 3.8 to avoid the bug. @jbergstroem contacted the maintainers of the Node port for FreeBSD and it seems that upgrading Clang is not an option.
That leaves with having to find and apply a workaround to V8 for this bug. I already spent a few hours on this myself without success so far. The thing is, I don't think it's my responsibility (as the one who usually does the V8 upgrades) to fix platform issues.
I would like to question the presence of FreeBSD in the "Tier 2" support type because it seems to me that we don't have enough collaborators who care about it and who are ready to spend the time needed to make it green on our CI.

Refs: nodejs/node-v8#1
Refs: nodejs/build#723

/cc @nodejs/platform-freebsd @nodejs/ctc

[mcollina]

Great work @targos, we all know you tried hard on this. In the last few months I have heard only problems on how hard is to support FreeBSD 10.

We have two options: do not ship V8 6.0 in Node 8, and be at the risk of missing updates from the V8 team, or do not provide Node 8 in FreeBSD 10 for the time being.

Considering the overall community interests, I think we should go ahead and land V8 6.0, and ideally release it in Node 8.

@jbergstroem contacted the maintainers of the Node port for FreeBSD and it seems that upgrading Clang is not an option.

This means we can run builds with an upgraded Clang? If so, let's run builds and releases with the updated Clang. If there are binaries around, people can still use them, even if it couldn't be packaged.

[bnoordhuis]

We don't release binaries for freebsd. If clang 3.8 fixes the ICE, then upgrading is what needs to happen.

Shouldn't be a problem for our CI. If it's a problem for the ports packagers, well, the good news is it's their problem, not ours.

[targos]

If clang 3.8 fixes the ICE, then upgrading is what needs to happen.

Then we need to change the requirements in https://github.com/nodejs/node/blob/master/BUILDING.md#unix

@nodejs/v8 is there version range of Clang that is officially supported by V8 or it's just the latest?

Clang is what's blocking us to ship V8 6.0, but it's not the only problem we have with FreeBSD. Right now Canary is broken on FreeBSD 10 and 11 and I don't know who I can ask to look into the issue and submit a patch upstream.
I think that for each platform that we support in Tier 1 and Tier 2, we should have active collaborators who are able to fix issues quickly when they arise. It works very well with SmartOS and PPC for example.

[bnoordhuis]

is there version range of Clang that is officially supported by V8 or it's just the latest?

I don't think the V8 people make any guarantee except google's clang fork (and maybe the one version of gcc that's tested in their CI.)

[jbergstroem]

I'm ok with updating clang; the maintainers are both responsive and helpful in patching upstream. They just don't act as much on non-releases/pre-releases.

[mcollina]

@jbergstroem let's update clang so we can move forward with landing V8 6.0.

[jbergstroem]

@mcollina sure.

[emaste]

I'm not sure why it would be a problem to use a newer Clang to build node packages in FreeBSD 10 - we have many packages that depend on having a newer Clang. (And we can't update Clang in 10.x, because we want 10.x to be buildable from older FreeBSD releases which do not include a compiler that can compile C++11 software). That said, I'm not involved in packaging node on FreeBSD so I could be missing something.

One of my goals is to support upstream software projects in running on FreeBSD though so feel free to CC me on issues and I will try to find someone to help.