Retire fedora22 buildbot?

[bnoordhuis]

Continuing from #579 (comment), FC22 has been EOL for the better part of a year now. Time to retire it?

[jbergstroem]

No objections. I can pull the plug if others agree.

[gibfahn]

SGTM

[mhdawson]

+1 from me

[MylesBorins]

+1 This does raise a question for @nodejs/LTS. Should we continue to build / test for platforms that go eol during lts?

…

On Apr 21, 2017 12:21 PM, "Michael Dawson" ***@***.***> wrote: +1 from me — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#688 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV_-9VJqrq68j3Iy9Cf_lpgzUrk2Pks5ryNdugaJpZM4NAzwr> .

[bnoordhuis]

Good question. CentOS / RHEL 5 is another example, it's officially EOL as of last month. Windows XP we stopped supporting when MS did so it probably makes sense to do the same for other platforms.

[jasnell]

I agree. When a platform goes EOL, we should simply drop support and do any more releases for it past that point, even in LTS.

Considering that we shorten the lifetime of LTS for OpenSSL EOL, this would be consistent, I think.

[gibfahn]

If you specify the supported platforms for a version, then dropping support within a release line is arguably semver-major. I think we could be explicit about this by simply adding a sentence to BUILDING.md to say something like:

The below platforms are only under support while the upstream Platform or OS is supported by its maintainers.

or

Node.js is not supported on Platforms or OSs that are EoL.

EDIT: See nodejs/node#12672

[gibfahn]

From #699

@shigeki

The Ubuntu 12.04 LTS (Long Term Support) period will end on Friday, April 28, 2017.

https://insights.ubuntu.com/2017/03/14/introducing-ubuntu-12-04-esm-extended-security-maintenance/

Although it has an extended commercial support by Canonical, I would be happy if it is retied because it has an old gas version of 2.22 that needs deps/openssl/asm_obsolete/.

[ljharb]

Supported platforms are absolutely part of the API; dropping one that works is absolutely semver-major.

[gibfahn]

Supported platforms are absolutely part of the API; dropping one that works is absolutely semver-major.

Unless you specify otherwise right?

[ljharb]

@gibfahn that would be the debate; personally I believe that documentation doesn't invalidate what code does at runtime, and that what code does at runtime is the API.

If the documentation takes precedence over the code, then adding such specification is also semver-major.

[bnoordhuis]

Supported platforms are absolutely part of the API; dropping one that works is absolutely semver-major.

Says who? First time I've heard anyone make this claim w.r.t. semver.

[refack]

@gibfahn that would be the debate; personally I believe that documentation doesn't invalidate what code does at runtime, and that what code does at runtime is the API.

IMHO these cases should be judgment calls (for fear of breaking) Ref: nodejs/node#12293 (comment)

[ljharb]

@bnoordhuis to be more precise; it's the act of shipping a change in a non-major that doesn't work, on a platform where the code previously worked, that's semver-major - simply declaring that you drop support for a platform isn't the important part, but effectively it ends up being the same thing over time.

Semver fails to precisely specify a number of things; one of these is "backwards compatible" - i believe the common definition is "did i upgrade from a version that works to this one, and something broke? it's semver-major" - which doesn't special-case "and something broke on a supported platform?".

[targos]

There is an issue on Ubuntu 12.04 with V8 5.9 and 6.0: nodejs/node-v8#2
I am +1 for retiring or disabling this buildbot before the 8.0.0 release.

[refack]

Cross-ref: #730
There is only one fedora22 worker, and it gets clogged (>6hr wait) a few times a week.

[gibfahn]

There is only one fedora22 worker, and it gets clogged (>6hr wait) a few times a week.

There are actually two machines, but I agree that the lack of redundancy is an issue.

[bnoordhuis]

So, anyone going to put it out to pasture?

[mhdawson]

How about we update the main regression job so that in master it skips fedora22, at least until we come to agreement here ?

[gibfahn]

How about we update the main regression job so that in master it skips fedora22, at least until we come to agreement here ?

Done (I just removed it from the labels dropdown in node-test-commit-linux, I don't think that will break anything, if it does we can just add it back).

[refack]

☺️
Could you take it out of the CITGM jobs as well.

[mhdawson]

@gibfahn I think that will remove it for all versions (4.x, 6.x etc) as well ?
I was thinking we'd need to tweak the job to not run if the node version was 8 or higher and instead simply "pass".

That would not remove coverage for older streams while taking the pressure off since most runs are on master.

[gibfahn]

I was thinking we'd need to tweak the job to not run if the node version was 8 or higher and instead simply "pass".

Seems reasonable, added this to the job instead:

# fedora22 is not supported in Node 8 and above
if [[ "$nodes" = fedora22 && ${MAJOR_VERSION} -gt 7 ]]; then
  RUN_TESTS=DONT_RUN
fi

confirmed that fedora22 is skipped on master but not on 6.x.

We can revisit what we're doing for older releases later.

[mhdawson]

Thanks that is what I originally had in mind.