Skip to content
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

Retire fedora22 buildbot? #688

Closed
bnoordhuis opened this issue Apr 18, 2017 · 24 comments
Closed

Retire fedora22 buildbot? #688

bnoordhuis opened this issue Apr 18, 2017 · 24 comments
Labels

Comments

@bnoordhuis
Copy link
Member

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

@jbergstroem
Copy link
Member

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

@gibfahn
Copy link
Member

gibfahn commented Apr 18, 2017

SGTM

@gibfahn gibfahn added the infra label Apr 18, 2017
@mhdawson
Copy link
Member

+1 from me

@MylesBorins
Copy link
Contributor

MylesBorins commented Apr 25, 2017 via email

@bnoordhuis
Copy link
Member Author

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
Copy link
Member

jasnell commented Apr 26, 2017

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
Copy link
Member

gibfahn commented Apr 26, 2017

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
Copy link
Member

gibfahn commented Apr 26, 2017

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
Copy link
Member

ljharb commented Apr 26, 2017

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

@gibfahn
Copy link
Member

gibfahn commented Apr 26, 2017

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

Unless you specify otherwise right?

@ljharb
Copy link
Member

ljharb commented Apr 26, 2017

@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
Copy link
Member Author

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
Copy link
Contributor

refack commented Apr 26, 2017

@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
Copy link
Member

ljharb commented Apr 26, 2017

@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
Copy link
Member

targos commented May 22, 2017

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
Copy link
Contributor

refack commented May 22, 2017

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

@gibfahn
Copy link
Member

gibfahn commented May 22, 2017

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
Copy link
Member Author

So, anyone going to put it out to pasture?

@mhdawson
Copy link
Member

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

@gibfahn
Copy link
Member

gibfahn commented May 23, 2017

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
Copy link
Contributor

refack commented May 23, 2017

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

@mhdawson
Copy link
Member

@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
Copy link
Member

gibfahn commented May 23, 2017

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
Copy link
Member

Thanks that is what I originally had in mind.

gibfahn added a commit to gibfahn/node that referenced this issue Jun 14, 2017
Add a note to clarify that any platform that is EoL will not be
supported by Node.js.

PR-URL: nodejs#12672
Fixes: nodejs/build#688
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
addaleax pushed a commit to nodejs/node that referenced this issue Jun 17, 2017
Add a note to clarify that any platform that is EoL will not be
supported by Node.js.

PR-URL: #12672
Fixes: nodejs/build#688
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
addaleax pushed a commit to nodejs/node that referenced this issue Jun 21, 2017
Add a note to clarify that any platform that is EoL will not be
supported by Node.js.

PR-URL: #12672
Fixes: nodejs/build#688
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
MylesBorins pushed a commit to nodejs/node that referenced this issue Jul 17, 2017
Add a note to clarify that any platform that is EoL will not be
supported by Node.js.

PR-URL: #12672
Fixes: nodejs/build#688
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
maclover7 added a commit to maclover7/build that referenced this issue Jan 2, 2018
Machines do not appear in https://ci.nodejs.org/computer, or in
`ansible/inventory.yml`.

Refs: nodejs#579
Refs: nodejs#688
maclover7 added a commit to maclover7/build that referenced this issue Jan 3, 2018
Machines do not appear in https://ci.nodejs.org/computer, or in
`ansible/inventory.yml`.

Refs: nodejs#579
Refs: nodejs#688
maclover7 added a commit to maclover7/build that referenced this issue Jan 3, 2018
Machines do not appear in https://ci.nodejs.org/computer, or in
`ansible/inventory.yml`.

Refs: nodejs#579
Refs: nodejs#688
maclover7 added a commit that referenced this issue Jan 3, 2018
Machines do not appear in https://ci.nodejs.org/computer, or in
`ansible/inventory.yml`.

PR-URL: #1063
Reviewed-By: Rod Vagg <rod@vagg.org>
Refs: #579
Refs: #688
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants