Skip to content

Conversation

@MylesBorins
Copy link
ContributorAuthor

/cc @Trott@jasnell

This was referenced Jan 14, 2016
@MylesBorins
Copy link
ContributorAuthor

There was a big combination of weird things going on getting this to backport nicely. Some commits that were part of this large change landed in LTS a week ago. Other commits landed, but with conflicts, others were not tagged for LTS and were just missed.

I'd be very interested to discuss ways we can co-ordinate moving large changes like this to LTS more efficiently. As branches diverge this kind of stuff is going to get more and more difficult.

@MylesBorins
Copy link
ContributorAuthor

@Trott
Copy link
Member

Ci failure for test-cluster-disconnect-race is of concern only if #4457 and #4465 have both landed in 4.x-staging. If not, then that issue should be fixed when those land.

In terms of how to prevent this in the future, the obvious things that leap to mind are:

  • More process. I suspect this is a bad idea as it will probably just make the whole thing more confusing and error-prone. For example, we could add some more tagging to note commits/PRs that depend on other commits/PRs. I don't think that will actually work, to be honest, but there's one possibility.
  • Bundling of things into mega-commits rather than individual small commits. This is an anti-pattern.
  • Bundling things into mega-PRs (with lots of small commits) rather than individual small PRs. Makes things harder to review and would probably greatly slow velocity.
  • More automation. This seems like the best idea but probably by far the hardest to implement. Straw proposal: Everything that lands on master would be tagged semver-patch, semver-minor, or semver-major. The semver-patch stuff would be merged to v4.x-staging automatically and in the same order that it landed on master. We'd need the CI in solid shape so the automated job could depend on it. There'd still be a lot of manual work when stuff didn't land cleanly (because a semver-patch depends on a previous semver-minor, for example) but that's work we do manually today anyway.

If the automation idea is appealing, maybe we can open a discussion over in the nodejs/build repo? Although I imagine getting the node-accept-pull-request job working again would be a necessary pre-requisite. (We're close, I think.)

@Trott
Copy link
Member

(Also: Nice work, @thealphanerd!)

@mscdexmscdex added the test Issues and PRs related to the tests. label Jan 14, 2016
@MylesBorins
Copy link
ContributorAuthor

I backported #4457 and rebased against it. #4465 will likely come in next release as it only was just released in v5.4.1

CI: https://ci.nodejs.org/job/node-test-pull-request/1235/

Trott added 11 commits January 14, 2016 12:00
Many tests use require() to import modules that subsequently never gets used. This removes those imports and, in a few cases, removes other unused variables from tests. PR-URL: nodejs#4684 Reviewed-By: Myles Borins <[email protected]>
Some files in `lib` were using `require` to load modules that were subsequently not used in the file. This removes those `require` statements. PR-URL: nodejs#4683 Reviewed-By: Myles Borins <[email protected]>
Remove unused vars in tests PR-URL: nodejs#4536 Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
In addition to removing unused vars, this also fixes an instance where booleans were set presumably to check something but then never used. This now confirms that the events that were setting the booleans are fired. PR-URL: nodejs#4425 Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
Remove a handful of variables that are declared but never used in the tests for the net module. PR-URL: nodejs#4430 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
Some of the TLS tests have variables that do not get used. This removes those variables. PR-URL: nodejs#4424 Reviewed-By: Johan Bergström <[email protected]>
Debug mode slows execution speed. There is work afoot to enable Debug mode runs on the continuous integration infrastructure for the project. Some tests are timing out, such as test-net-nodejsGH-5504.js. This change doubles the timeout returned from `common.platformTimeout()` when running in Debug mode. It also removes an unused variable from the aforementioned test-net-nodejsGH-5504.js. PR-URL: nodejs#4431 Reviewed-By: Johan Bergström <[email protected]>
The http tests seem especially prone to including unused variables. This change removes them. PR-URL: nodejs#4422 Reviewed-By: Johan Bergström <[email protected]>
Remove all remaining unused variables from tests in test/parallel. PR-URL: nodejs#4511 Reviewed-By: James M Snell<[email protected]> Reviewed-By: Johan Bergström <[email protected]>
PR-URL: nodejs#4536 Reviewed-By: Rod Vagg <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
@MylesBorins
Copy link
ContributorAuthor

CI against current head
https://ci.nodejs.org/job/node-test-pull-request/1238/

@MylesBorins
Copy link
ContributorAuthor

CI Failures look unrelated. @jasnell are we good to land this?

@jasnell
Copy link
Member

LGTM

@MylesBorinsMylesBorins merged commit ef5e9ef into nodejs:v4.x-stagingJan 14, 2016
@MylesBorins
Copy link
ContributorAuthor

landed

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

testIssues and PRs related to the tests.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@MylesBorins@Trott@jasnell@mscdex