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: made grammar more consistent and correct #33081

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions doc/guides/backporting-to-release-lines.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,9 +31,9 @@ release line. All commands will use the `v10.x-staging` branch as the target
branch. In order to submit a backport pull request to another branch, simply
replace that with the staging branch for the targeted release line.

1. Checkout the staging branch for the targeted release line
2. Make sure that the local staging branch is up to date with the remote
3. Create a new branch off of the staging branch
1. Checkout the staging branch for the targeted release line.
Copy link
Member

Choose a reason for hiding this comment

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

While we're in here, maybe this too?

Suggested change
1. Checkout the staging branch for the targeted release line.
1. Check out the staging branch for the targeted release line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are we sure we'd want to change this considering it's in reference to the git checkout command?

Copy link
Member

Choose a reason for hiding this comment

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

I’ll go ahead with landing this as this PR hasn’t modified that part.

2. Make sure that the local staging branch is up to date with the remote.
3. Create a new branch off of the staging branch, as shown below.

```shell
# Assuming your fork of Node.js is checked out in $NODE_DIR,
Expand Down Expand Up @@ -68,26 +68,26 @@ replace that with the staging branch for the targeted release line.
using `git add`, and then commit the changes. That can be done with
`git cherry-pick --continue`.
6. Leave the commit message as is. If you think it should be modified, comment
in the Pull Request. The `Backport-PR-URL` metadata does need to be added to
in the pull request. The `Backport-PR-URL` metadata does need to be added to
the commit, but this will be done later.
7. Make sure `make -j4 test` passes.
8. Push the changes to your fork
8. Push the changes to your fork.
9. Open a pull request:
1. Be sure to target the `v10.x-staging` branch in the pull request.
1. Include the backport target in the pull request title in the following
format: `[v10.x backport] <commit title>`.
Example: `[v10.x backport] process: improve performance of nextTick`
1. Check the checkbox labeled "Allow edits from maintainers".
1. In the description add a reference to the original PR.
1. In the description add a reference to the original pull request.
1. Amend the commit message and include a `Backport-PR-URL:` metadata and
re-push the change to your fork.
1. Run a [`node-test-pull-request`][] CI job (with `REBASE_ONTO` set to the
default `<pr base branch>`)
10. If during the review process conflicts arise, use the following to rebase:
`git pull --rebase upstream v10.x-staging`

After the PR lands replace the `backport-requested-v10.x` label on the original
PR with `backported-to-v10.x`.
After the pull request lands, replace the `backport-requested-v10.x` label
on the original pull request with `backported-to-v10.x`.

[Release Schedule]: https://github.com/nodejs/Release#release-schedule1
[Release Plan]: https://github.com/nodejs/Release#release-plan
Expand Down