Italian Translation Report: Node.js [Part 15 - 1098 words]

An example for workflow how to cherry-pick consider the bug RegExp show inconsistent result with other browsers
From the bug we can see that it was merged by V8 into 5.2 and 5.3, and not into V8 5.1 (since it was already abandoned).
Since Node.js uses V8 5.1, the fix needed to be cherry-picked.
To cherry-pick, here's an example workflow:
Download and apply the commit linked-to in the issue (in this case).
If the branches have diverged significantly, this may not apply cleanly
It may help to try to cherry-pick the merge to the oldest branch that was done upstream in V8.
In this example, this would be the patch from the merge to 5.2. The hope is that this would be closer to the V8 5.1, and has a better chance of applying cleanly. If you're stuck, feel free to ping for help.
Modify the commit message to match the format we use for V8 backports and replace yourself as the author.
You may want to add extra description if necessary to indicate the impact of the fix on Node.js. In this case the original issue was descriptive enough. Example:
cherry-pick from V8 upstream
Original commit message:
Fix case-insensitive matching for one-byte subjects.
The bug occurs because we do not canonicalize character class ranges before adding case equivalents. While adding case equivalents, we abort early for one-byte subject strings, assuming that the ranges are sorted. Which they are not.
Open a PR against the branch in the Node.js repo. Launch the normal and V8 CI using the Node.js CI system. We only needed to backport to as the other LTS branches weren't affected by this bug.
Backports Identified by the V8 team
For bugs found through the browser or other channels, the V8 team marks bugs that might be applicable to the abandoned branches in use by Node.js. This is done through manual tagging by the V8 team and through an automated process that tags any fix that gets backported to the stable branch (as it is likely candidate for backporting further).
Such fixes are tagged with the following labels in the V8 issue tracker:
to be reviewed if this is applicable to abandoned branches in use by Node.js. This list if regularly reviewed by the Node.js team at Google to determine applicability to Node.js.
marks bugs that are deemed relevant to Node.js and should be backported.
Backport for Node.js has been performed already.
Backport for Node.js is not desired.
The backlog of issues with such is regularly reviewed by the node-team at Google to shepherd through the backport process. External contributors are welcome to collaborate on the backport process as well. Note that some of the bugs may be security issues and will not be visible to external collaborators.
Updating V8
Node.js keeps a vendored copy of V8 inside of the deps/ directory. In addition, Node.js may need to float patches that do not exist upstream. This means that some care may need to be taken to update the vendored copy of V8.
Minor updates (patch level)
Because there may be floating patches on the version of V8 in Node.js, it is safest to apply the patch level updates as a patch. For example, imagine that upstream V8 is at 5.0.71.47 and Node.js is at 5.0.71.32. It would be best to compute the diff between these tags on the V8 repository, and then apply that patch on the copy of V8 in Node.js. This should preserve the patches/backports that Node.js may be floating (or else cause a merge conflict).
The rough outline of the process is:
# Assuming your fork of Node.js is checked out in
# and you want to update the Node.js master branch.
# Find the current (OLD) version in
# You may want to amend the commit message to describe the nature of the update
V8 also keeps tags of the form which point to the Last Known Good Revision from the 5.4 branch that can be useful in the update process above.
The tool can be used to simplify this task. Run minor to apply a minor update.
Major Updates
We upgrade the version of V8 in Node.js master whenever a V8 release goes stable upstream, that is, whenever a new release of Chrome comes out.
Upgrading major versions would be much harder to do with the patch mechanism above. A better strategy is to
Audit the current master branch and look at the patches that have been floated since the last major V8 update.
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 and)
Reset the variable to in
Refloat (cherry-pick) all the patches from list computed in 1) as necessary. Some of the patches may no longer be necessary.
To audit for floating patches:
To replace the copy of V8 in Node.js, use the tool. For example, if you want to replace the copy of V8 in Node.js with the branch-head for V8 5.1 branch:
This should be followed up with manual refloating of all relevant patches.
Proposal: Using a fork repo to track upstream V8
The fact that Node.js keeps a vendored, potentially edited copy of V8 in makes the above processes a bit complicated. An alternative proposal would be to create a fork of V8 at that would be used to maintain the V8 branches. This has several benefits:
The process to update the version of V8 in Node.js could be automated to track the tips of various V8 branches in
It would simplify cherry-picking and porting of fixes between branches as the version bumps in would happen as part of this update instead of on every change.
It would simplify the V8-CI and make it more automatable.
The history of the V8 branch in becomes purer and it would make it easier to pull in the V8 team for help with reviewing.
It would make it simpler to setup an automated build that tracks Node.js master + V8 lkgr integration build.
This would require some tooling to:
A script that would update the V8 in a specific Node.js branch with V8 from upstream (dependent on branch abandoned vs. active).
We need a script to bump V8 version numbers when a new version of V8 is promoted from  to
Enabled the V8-CI build in Jenkins to build from the fork.
Notes
Node.js 0.12 and older are intentionally omitted from this document as their support has ended.