Skip to content

Commit

Permalink
doc: CONTRIBUTING.md updates (will squash)
Browse files Browse the repository at this point in the history
  • Loading branch information
Stewart X Addison committed Jan 19, 2017
1 parent 9728136 commit f9bc1e9
Showing 1 changed file with 17 additions and 15 deletions.
32 changes: 17 additions & 15 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ $ git remote add upstream git://github.com/nodejs/node.git
For developing new features and bug fixes, the `master` branch should be
pulled and built upon. See the section on
[backporting](#backporting-to-current-and-lts-branches) if you would like
the fix to be backported.
the fix to be backported to other releases.

#### Respect the stability index

Expand Down Expand Up @@ -327,34 +327,36 @@ widely used, so don't be discouraged!
### Backporting to Current and LTS Branches

Before backporting or contributing to the LTS releases make sure you are
familiar with the LTS information and schedules at
https://github.com/nodejs/LTS#lts-schedule
familiar with the [LTS information and schedules](https://github.com/nodejs/LTS#lts-schedule)

Items which have already made it from master will be candidates for the
Commits which have already landed on master will be candidates for the
"current" release branch(es) and can then also become candidates for
inclusion into the "Active LTS" branch(es), especially if they are bug
fixes. Any change can be considered for LTS by applying the appropriate
lts-watch-vX.x label for the branch you would like it backported to. If a
commit is not to be considered for backporting please apply the
dont-land-on-vX.x label. If it can be cherry-picked cleanly it will be done
by someone from the release team. Generally any changes should have landed
in the current release for at least two weeks before considering backporting
to the LTS releases.
fixes. Any change can be considered for LTS by requesting @nodejs/lts apply
the appropriate `lts-watch-vX.x` label for the branch you would like it
backported to. If a commit is not to be considered for backporting please
ask for it to be labelled with `dont-land-on-vX.x`. If it is to be backported
and can be cherry-picked cleanly it will be done by someone from the release
team. Generally all changes should have landed in the current release for
at least two weeks before considering backporting to the LTS releases.

If a manual backport is required when porting your change to the current or
LTS branches you may be asked to submit a PR against the staging branch of
the release line the backport is targetting (vX.x-staging). The easiest way
to do this is to use git cherry-pick to pull across the commit hash from
master and manually resolve the conflicts using these commands:
the release line the backport is targetting `vX.x-staging`. The easiest way
to do the backport this is to use git cherry-pick to pull across the commit
hash from master and manually resolve the conflicts using these commands:

```
$ git cherry-pick HASH
// fix all conflicts that are reported
$ git cherry-pick --continue
```

When you submit it, please include "vX.x backport" in the PR title.

If you need to reference other relevant pull requests regarding the
conflicts, list them as "Ref:" links in the PR message.
conflicts, list them as "Refs:" links in the PR message.


### Check Out the Collaborator's Guide

Expand Down

0 comments on commit f9bc1e9

Please sign in to comment.