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

Comments

Projects
None yet
9 participants
@bnoordhuis
Member

bnoordhuis commented Apr 18, 2017

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

@jbergstroem

This comment has been minimized.

Show comment
Hide comment
@jbergstroem

jbergstroem Apr 18, 2017

Member

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

Member

jbergstroem commented Apr 18, 2017

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

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Apr 18, 2017

Member

SGTM

Member

gibfahn commented Apr 18, 2017

SGTM

@gibfahn gibfahn added the infra label Apr 18, 2017

@mhdawson

This comment has been minimized.

Show comment
Hide comment
@mhdawson

mhdawson Apr 21, 2017

Member

+1 from me

Member

mhdawson commented Apr 21, 2017

+1 from me

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Apr 25, 2017

Member
Member

MylesBorins commented Apr 25, 2017

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Apr 26, 2017

Member

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.

Member

bnoordhuis commented Apr 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 26, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Apr 26, 2017

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Apr 26, 2017

Member

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/.

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/.

@gibfahn gibfahn referenced this issue Apr 26, 2017

Merged

doc: note that EoL platforms are not supported #12672

2 of 2 tasks complete
@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Apr 26, 2017

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

ljharb commented Apr 26, 2017

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

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Apr 26, 2017

Member

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

Unless you specify otherwise right?

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb 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.

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

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Apr 26, 2017

Member

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.

Member

bnoordhuis commented Apr 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@refack

refack Apr 26, 2017

Member

@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)

Member

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb 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?".

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

This comment has been minimized.

Show comment
Hide comment
@targos

targos May 22, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@refack

refack May 22, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn May 22, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis May 22, 2017

Member

So, anyone going to put it out to pasture?

Member

bnoordhuis commented May 22, 2017

So, anyone going to put it out to pasture?

@mhdawson

This comment has been minimized.

Show comment
Hide comment
@mhdawson

mhdawson May 23, 2017

Member

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

Member

mhdawson 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 ?

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn May 23, 2017

Member

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).

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

This comment has been minimized.

Show comment
Hide comment
@refack

refack May 23, 2017

Member

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

Member

refack commented May 23, 2017

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

@mhdawson

This comment has been minimized.

Show comment
Hide comment
@mhdawson

mhdawson May 23, 2017

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.

Member

mhdawson commented May 23, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn May 23, 2017

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@mhdawson

mhdawson May 24, 2017

Member

Thanks that is what I originally had in mind.

Member

mhdawson commented May 24, 2017

Thanks that is what I originally had in mind.

gibfahn added a commit to gibfahn/node that referenced this issue Jun 14, 2017

doc: note that EoL platforms are not supported
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 added a commit to nodejs/node that referenced this issue Jun 17, 2017

doc: note that EoL platforms are not supported
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 added a commit to nodejs/node that referenced this issue Jun 17, 2017

doc: note that EoL platforms are not supported
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 added a commit to nodejs/node that referenced this issue Jun 21, 2017

doc: note that EoL platforms are not supported
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 added a commit to nodejs/node that referenced this issue Jul 17, 2017

doc: note that EoL platforms are not supported
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

setup: remove fedora22
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

setup: remove fedora22
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

setup: remove fedora22
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

setup: remove fedora22
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