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

doc: add guide for maintaining V8 #9777

Closed
wants to merge 1 commit into from

Conversation

ofrobots
Copy link
Contributor

Checklist
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

doc

Description of change

This document attempts to describe the processes for maintaining the V8 brances in Node.js LTS and Current releases.

Previously: nodejs/Release#137

@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Nov 24, 2016
@mscdex mscdex added the v8 engine Issues and PRs related to the V8 dependency. label Nov 24, 2016
Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with nit


# Proposal: Dealing with the need to float patches to a stable/beta

Sometimes upstream V8 may not want to merge a fix to their stable branches, but we might. An example of this would be a fix for a performance regression that only affects Node.js and now the broweser. At the moment we don't have a mechanism to deal with this situation. If we float a patch and bump the V8 version, we might run into a problem if upstream releases a fix with the same version number.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"now the broweser" should be "not the browser"

@@ -0,0 +1,281 @@
# Maintaining V8 in Node

[ofrobots@google.com](mailto:ofrobots@google.com), [hablich@chromium.org](mailto:hablich@chromium.org), 2016-08-05
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

authors? people to ask for help? something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was authors, but I have removed that line.


Once a bug in Node.js has been identified to be caused by V8, the first step is to identify the versions of Node and V8 affected. The bug may be present in multiple different locations, each of which follows a slightly different process.

* Unfixed bugs. If the bug exists in the V8 master branch.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"If the" -> "The"?

* Fixed, but needs backport. The bug may need porting to one or more branches.
* Backporting to active branches.
* Backporting to abandoned branches.
* Backports identified by the V8 team.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this different from backporting to active branches? doesn't v8 backport to active?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have tried to clarify this a bit further. The idea was that there are three classes of bugs, Node.js bugs that have (1) or have not (2) been fixed upstream, and bugs that have not been encountered by Node.js yet but upstream has identified as potentially interesting to Node (3).


## Unfixed Upstream Bugs

If the bug can be reproduced on the `vee-eight-lkgr` branch, Chromium canary, or V8 tip-of-tree, and the test case is valid, then the bug needs to be fixed upstream first.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where is this branch? I don't see it in nodejs/node.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Added link. FYI, it is at https://github.com/v8/node/tree/vee-eight-lkgr but we can bring this over to nodejs/node too if it is helpful.

* In some cases the patch may require extra effort to merge in case V8 has changed substantially. For important issues we may be able to lean on the V8 team to get help with reimplementing the patch.
* Run Node's [V8-CI](https://ci.nodejs.org/job/node-test-commit-v8-linux/) in addition to the [Node CI](https://ci.nodejs.org/job/node-test-pull-request/).

An example for workflow how to cherry-pick consider the following bug: https://crbug.com/v8/5199. From the bug we can see that it was merged by V8 into 5.2 and 5.3, and not in V8 5.1 (since it was already abandoned). Since Node.js `v6.x` uses V8 5.1, the fix needed to cherry-picked. To cherry-pick, here's an example workflow:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"into V8 5.1"


PR-URL: <pr link>
```
* Open a PR against the `v6.x-staging` branch in the Node.js repo. Launch the normal and [V8-CI](https://ci.nodejs.org/job/node-test-commit-v8-linux/) using the Node.js CI system.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

v6.x-staging is just an example, right? because backports might be necessary to any LTS staging branch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarified.

Upgrading major versions would be much harder to do with the patch mechanism above. A better strategy is to

1. Audit the current master branch and look at the patches that have been floated since the last major V8 update.
1. Replace the copy of V8 in Node.js with a fresh checkout of the latest stable V8 branch. Special care must be taken to recursively update the DEPS that V8 has a compile time dependency on (at the moment of this writing, these are only trace_event and gtest_prod.h)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trace_event, or trace_event.h?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trace event is a component. gtest_prod.h is just a file.

For example, at the time of this writing:

* **Stable**: V8 5.4 is currently shipping as part of Chromium stable. This branch was created approx. 6 weeks before from when V8 5.3 shipped as stable.
* **Beta**: V8 5.5 is currently in beta. It will be promoted to stable next; approximately 6 weeks after V8 5.3 shipped as stable.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after V8 5.4 shipped as stable.

@ofrobots
Copy link
Contributor Author

I will land this later today.

@ofrobots
Copy link
Contributor Author

Thanks. Landed as 11b0872.

@ofrobots ofrobots closed this Nov 29, 2016
@ofrobots ofrobots deleted the maintaining-v8 branch November 29, 2016 00:19
ofrobots added a commit that referenced this pull request Nov 29, 2016
Ref: nodejs/Release#137
PR-URL: #9777
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
addaleax pushed a commit that referenced this pull request Dec 5, 2016
Ref: nodejs/Release#137
PR-URL: #9777
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
@Fishrock123 Fishrock123 mentioned this pull request Dec 5, 2016
2 tasks
MylesBorins pushed a commit that referenced this pull request Dec 13, 2016
Ref: nodejs/Release#137
PR-URL: #9777
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
MylesBorins pushed a commit that referenced this pull request Dec 13, 2016
Ref: nodejs/Release#137
PR-URL: #9777
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
MylesBorins pushed a commit that referenced this pull request Dec 21, 2016
Ref: nodejs/Release#137
PR-URL: #9777
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
MylesBorins pushed a commit that referenced this pull request Dec 21, 2016
Ref: nodejs/Release#137
PR-URL: #9777
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
This was referenced Dec 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants