Skip to content

Commit

Permalink
doc: apply sentence case to guides headers
Browse files Browse the repository at this point in the history
PR-URL: #37497
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Pooja D P <Pooja.D.P@ibm.com>
  • Loading branch information
marsonya authored and aduh95 committed Feb 26, 2021
1 parent 7837d3f commit 5c3bc21
Show file tree
Hide file tree
Showing 2 changed files with 15 additions and 15 deletions.
22 changes: 11 additions & 11 deletions doc/guides/maintaining-V8.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ This document attempts to outline the current maintenance processes, proposes
a workflow for maintaining the V8 branches in both Node.js LTS and current
releases, and discusses how the Node.js and V8 teams at Google can help.

## V8 Release Schedule
## V8 release schedule

V8 and Chromium follow a
[roughly 6-week release cadence][ChromiumReleaseCalendar]. At any given time
Expand All @@ -30,7 +30,7 @@ For example, at the time of this writing:

All older branches are abandoned and are not maintained by the V8 team.

### V8 Merge Process Overview
### V8 merge process overview

The process for backporting bug fixes to active branches is officially
documented [on the V8 wiki][V8MergingPatching]. The summary of the process is:
Expand All @@ -48,7 +48,7 @@ documented [on the V8 wiki][V8MergingPatching]. The summary of the process is:
* Merge requests to an abandoned branch will be rejected.
* Only bug fixes are accepted for backporting.

## Node.js Support Requirements
## Node.js support requirements

At any given time Node.js needs to be maintaining a few different V8 branches
for the various Current, LTS, and nightly releases. At present this list
Expand Down Expand Up @@ -146,7 +146,7 @@ abandoned by upstream V8. However, Node.js needs to continue supporting
these branches for many months (Current branches) or several
years (LTS branches).

## Maintenance Process
## Maintenance process

Once a bug in Node.js has been identified to be caused by V8, the first step is
to identify the versions of Node.js and V8 affected. The bug may be present in
Expand All @@ -160,7 +160,7 @@ process.
* Backports identified by the V8 team. Bugs identified by upstream V8 that we
haven't encountered in Node.js yet.

### Unfixed Upstream Bugs
### Unfixed upstream bugs

If the bug can be reproduced on the [Node.js `canary` branch][], Chromium
canary, or V8 tip-of-tree, and the test case is valid, then the bug needs to be
Expand All @@ -176,7 +176,7 @@ fixed upstream first.
branches that are still active or are branches that Node.js cares about.
Follow the process for backporting below.

### Backporting to Active Branches
### Backporting to active branches

If the bug exists in any of the active V8 branches, we may need to get the fix
backported. At any given time there are [two active branches][V8ActiveBranches]
Expand Down Expand Up @@ -205,7 +205,7 @@ backport the fix:
* Once the fix has been merged upstream, it can be picked up during an update of
the V8 branch (see below).

### Backporting to Abandoned Branches
### Backporting to abandoned branches

Abandoned V8 branches are supported in the Node.js repository. The fix needs
to be cherry-picked in the Node.js repository and V8-CI must test the change.
Expand Down Expand Up @@ -278,7 +278,7 @@ PR-URL: https://github.com/nodejs/node/pull/7833
normal and [V8 CI][] using the Node.js CI system. We only needed to backport
to `v6.x` as the other LTS branches weren't affected by this bug.

### Backports Identified by the V8 Team
### 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
Expand Down Expand Up @@ -317,7 +317,7 @@ V8 builds against the version of ICU supplied by Node.js,
see [maintaining-icu.md](./maintaining-icu.md) for special considerations.
Specifically, a V8 update may necessitate an ICU update.

### Minor Updates (Patch Level)
### 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
Expand Down Expand Up @@ -347,7 +347,7 @@ Revision* from the 5.4 branch that can be useful in the update process above.
The [`git-node`][] tool can be used to simplify this task. Run `git node v8 minor`
to apply a minor update.

### Major Updates
### 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.
Expand Down Expand Up @@ -382,7 +382,7 @@ git node v8 major --branch=5.1-lkgr

This should be followed up with manual refloating of all relevant patches.

## Proposal: Using a Fork Repo to Track Upstream V8
## Proposal: using a fork repo to track upstream V8

The fact that Node.js keeps a vendored, potentially edited copy of V8 in deps/
makes the above processes a bit complicated. An alternative proposal would be to
Expand Down
8 changes: 4 additions & 4 deletions doc/guides/node-postmortem-support.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
# Postmortem Support
# Postmortem support

Postmortem metadata are constants present in the final build which can be used
by debuggers and other tools to navigate through internal structures of software
when analyzing its memory (either on a running process or a core dump). Node.js
provides this metadata in its builds for V8 and Node.js internal structures.

## V8 Postmortem metadata
## V8 postmortem metadata

V8 prefixes all postmortem constants with `v8dbg_`, and they allow inspection of
objects on the heap as well as object properties and references. V8 generates
those symbols with a script (`deps/v8/tools/gen-postmortem-metadata.py`), and
Node.js always includes these constants in the final build.

## Node.js Debug Symbols
## Node.js debug symbols

Node.js prefixes all postmortem constants with `nodedbg_`, and they complement
V8 constants by providing ways to inspect Node.js-specific structures, like
Expand Down Expand Up @@ -64,7 +64,7 @@ class ReqWrap : public AsyncWrap {
There are also tests on `test/cctest/test_node_postmortem_metadata.cc` to make
sure all Node.js postmortem metadata are calculated correctly.

## Tools and References
## Tools and references

* [llnode](https://github.com/nodejs/llnode): LLDB plugin
* [`mdb_v8`](https://github.com/joyent/mdb_v8): mdb plugin
Expand Down

0 comments on commit 5c3bc21

Please sign in to comment.