doc: use consistent new lines

PR-URL: https://github.com/nodejs/node/pull/17722
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
This commit is contained in:
Ruben Bridgewater 2017-12-17 20:32:28 -03:00
parent 5c2901391a
commit 6924dac6ce
No known key found for this signature in database
GPG Key ID: F07496B3EB3C1762
5 changed files with 9 additions and 4 deletions

View File

@ -275,6 +275,7 @@ Original commit message:
Refs: https://github.com/v8/v8/commit/a51f429772d1e796744244128c9feeab4c26a854 Refs: https://github.com/v8/v8/commit/a51f429772d1e796744244128c9feeab4c26a854
PR-URL: https://github.com/nodejs/node/pull/7833 PR-URL: https://github.com/nodejs/node/pull/7833
``` ```
* Open a PR against the `v6.x-staging` branch in the Node.js repo. Launch the * Open a PR against the `v6.x-staging` branch in the Node.js repo. Launch the
normal and [V8 CI] using the Node.js CI system. We only needed to backport to 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. `v6.x` as the other LTS branches weren't affected by this bug.

View File

@ -144,6 +144,7 @@ arrays/zero-int.js n=25 type=Buffer: 90.49906662339653
``` ```
It is possible to execute more groups by adding extra process arguments. It is possible to execute more groups by adding extra process arguments.
```console ```console
$ node benchmark/run.js arrays buffers $ node benchmark/run.js arrays buffers
``` ```
@ -439,6 +440,7 @@ function main(conf) {
``` ```
Supported options keys are: Supported options keys are:
* `port` - defaults to `common.PORT` * `port` - defaults to `common.PORT`
* `path` - defaults to `/` * `path` - defaults to `/`
* `connections` - number of concurrent connections to use, defaults to 100 * `connections` - number of concurrent connections to use, defaults to 100

View File

@ -306,12 +306,14 @@ the upstream project, send another PR here to update Node.js accordingly.
Be sure to update the hash in the URL following `WPT Refs:`. Be sure to update the hash in the URL following `WPT Refs:`.
## C++ Unit test ## C++ Unit test
C++ code can be tested using [Google Test][]. Most features in Node.js can be C++ code can be tested using [Google Test][]. Most features in Node.js can be
tested using the methods described previously in this document. But there are tested using the methods described previously in this document. But there are
cases where these might not be enough, for example writing code for Node.js cases where these might not be enough, for example writing code for Node.js
that will only be called when Node.js is embedded. that will only be called when Node.js is embedded.
### Adding a new test ### Adding a new test
The unit test should be placed in `test/cctest` and be named with the prefix The unit test should be placed in `test/cctest` and be named with the prefix
`test` followed by the name of unit being tested. For example, the code below `test` followed by the name of unit being tested. For example, the code below
would be placed in `test/cctest/test_env.cc`: would be placed in `test/cctest/test_env.cc`:
@ -345,18 +347,21 @@ static void at_exit_callback(void* arg) {
``` ```
Next add the test to the `sources` in the `cctest` target in node.gyp: Next add the test to the `sources` in the `cctest` target in node.gyp:
```console ```console
'sources': [ 'sources': [
'test/cctest/test_env.cc', 'test/cctest/test_env.cc',
... ...
], ],
``` ```
Note that the only sources that should be included in the cctest target are Note that the only sources that should be included in the cctest target are
actual test or helper source files. There might be a need to include specific actual test or helper source files. There might be a need to include specific
object files that are compiled by the `node` target and this can be done by object files that are compiled by the `node` target and this can be done by
adding them to the `libraries` section in the cctest target. adding them to the `libraries` section in the cctest target.
The test can be executed by running the `cctest` target: The test can be executed by running the `cctest` target:
```console ```console
$ make cctest $ make cctest
``` ```

View File

@ -47,7 +47,6 @@ When things need extra attention, are controversial, or `semver-major`:
If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help. If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help.
## Labels ## Labels
### By Subsystem ### By Subsystem
@ -64,7 +63,6 @@ part(s) of the codebase it touches.
There may be more than one subsystem valid for any particular issue / PR. There may be more than one subsystem valid for any particular issue / PR.
### General ### General
Please use these when possible / appropriate Please use these when possible / appropriate
@ -136,7 +134,6 @@ need to be attached anymore, as only important bugfixes will be included.
* `arm`, `mips`, `s390`, `ppc` * `arm`, `mips`, `s390`, `ppc`
* No x86{_64}, since that is the implied default * No x86{_64}, since that is the implied default
## Updating Node.js from Upstream ## Updating Node.js from Upstream
* `git remote add upstream git://github.com/nodejs/node.git` * `git remote add upstream git://github.com/nodejs/node.git`
@ -147,7 +144,6 @@ to update from nodejs/node:
* `git remote update -p` OR `git fetch --all` (I prefer the former) * `git remote update -p` OR `git fetch --all` (I prefer the former)
* `git merge --ff-only upstream/master` (or `REMOTENAME/BRANCH`) * `git merge --ff-only upstream/master` (or `REMOTENAME/BRANCH`)
## best practices ## best practices
* commit often, out to your github fork (origin), open a PR * commit often, out to your github fork (origin), open a PR

View File

@ -107,6 +107,7 @@ onboarding session.
[here](https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md). [here](https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md).
## Reviewing PRs ## Reviewing PRs
* The primary goal is for the codebase to improve. * The primary goal is for the codebase to improve.
* Secondary (but not far off) is for the person submitting code to succeed. A * Secondary (but not far off) is for the person submitting code to succeed. A
pull request from a new contributor is an opportunity to grow the community. pull request from a new contributor is an opportunity to grow the community.