From 561139f14cb4ab0fdfce7f9505b61baec48ab91d Mon Sep 17 00:00:00 2001 From: Stewart Addison Date: Tue, 29 Nov 2016 13:17:03 +0000 Subject: [PATCH 1/3] doc: Update CONTRIBUTING.md with backport info Add information on getting fixes into the LTS releases, and also some information on what is needed for getting fixes to dependencies back into the Node.js codebase. doc: Separate out current release from LTS in CONTRIBUTING.md doc: Add info on bumping V8 path level --- CONTRIBUTING.md | 62 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 60 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6d419aa4954fde..2889f39629e074 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -43,8 +43,10 @@ $ git remote add upstream git://github.com/nodejs/node.git #### Which branch? -For developing new features and bug fixes, the `master` branch should be pulled -and built upon. +For developing new features and bug fixes, the `master` branch should be +pulled and built upon. See the section on +[LTS contributions](#lts-contributions) if you would like the fix to be +backported. #### Respect the stability index @@ -354,3 +356,59 @@ By making a contribution to this project, I certify that: personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. + +#### LTS contributions + +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 + +Items may be selected as candidates for inclusion into the "active LTS" +branch(es), especially if they are bug fixes. This will be at the +discretion of the person releasing that new version by default, but anyone +can request a backport by adding the label "lts-watch-vX.x" (e.g +lts-watch-v6.x) and adding a suitable comment. If the changes can just be +cherry picked across without merge conflicts this will often be done by a +member of the release team, but if not then they may request a manual merge, +for which a pull request will be required. Also related to the lts-watch- +labels, if you want to ensure something is not backported, label it with +dont-land-on-vX.x (e.g. dont-land-on-v6.x) + +Generally any changes should have landed in the current release for at least +two weeks before considering backporting to the other releases. + +### Current release + +The "Current" release - as opposed to LTS - changes every six months and is +the shown on the front of the nodejs.org download page along with the LTS +one. It will typically have more frequent releases than LTS and is for +those for whom having the latest features is more important than stability. +Even numbered versions will become LTS releases and the odd numbered ones +will be supported only for nine months from when they are released - the +details of each are on the LTS schedule page. Once Pull Requests have +landed in master they will often automatically become candidates for the +next version of the "current" release, in which case the process mentioned +above regarding cherry picking and potentially pull requests will apply. + +### Merge conflicts on LTS branches + +If a fix is selected for inclusion in a current or LTS releases but cannot +be merged directly, a member of the release team may request that someone +performs a manual backport. This will involve someone (potentially the +person who submitted the original pull request) doing the backport by +submitting another pull request into the appropriate staging branch (e.g. +v6.x-staging). + +If you need to submit a new pull request to a branch other than master to do +a manual backport then you should include the same set of commits that went +into master along with the associated metadata. The easiest way to do this +is to use git cherry-pick to pull across the commit hash from master: + +``` + $ git cherry-pick HASH + // fix all conflicts that are reported + $ git cherry-pick --continue +``` + +Any other relevant links to pull requests can be included as "Ref:" links in +the PR message From 97281362e95b5c3f5d4d0ad3abefcca25c1bdd7d Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Wed, 28 Dec 2016 13:58:10 +0000 Subject: [PATCH 2/3] doc: More updates to CONTRIBUTING.md following review Updating to remove some information based on changes I'm submitting into the LTS README.md --- CONTRIBUTING.md | 91 ++++++++++++++++++------------------------------- 1 file changed, 34 insertions(+), 57 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2889f39629e074..a6d26b7aaed0a3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -45,8 +45,8 @@ $ 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 -[LTS contributions](#lts-contributions) if you would like the fix to be -backported. +[backporting](#backporting-to-current-and-lts-branches) if you would like +the fix to be backported. #### Respect the stability index @@ -324,6 +324,38 @@ doesn't need to wait. A Pull Request may well take longer to be merged in. All these precautions are important because Node.js is 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 + +Items which have already made it from 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. + +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: + +``` + $ git cherry-pick HASH + // fix all conflicts that are reported + $ git cherry-pick --continue +``` + +If you need to reference other relevant pull requests regarding the +conflicts, list them as "Ref:" links in the PR message. + ### Check Out the Collaborator's Guide If you want to know more about the code review and the landing process, @@ -357,58 +389,3 @@ By making a contribution to this project, I certify that: maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -#### LTS contributions - -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 - -Items may be selected as candidates for inclusion into the "active LTS" -branch(es), especially if they are bug fixes. This will be at the -discretion of the person releasing that new version by default, but anyone -can request a backport by adding the label "lts-watch-vX.x" (e.g -lts-watch-v6.x) and adding a suitable comment. If the changes can just be -cherry picked across without merge conflicts this will often be done by a -member of the release team, but if not then they may request a manual merge, -for which a pull request will be required. Also related to the lts-watch- -labels, if you want to ensure something is not backported, label it with -dont-land-on-vX.x (e.g. dont-land-on-v6.x) - -Generally any changes should have landed in the current release for at least -two weeks before considering backporting to the other releases. - -### Current release - -The "Current" release - as opposed to LTS - changes every six months and is -the shown on the front of the nodejs.org download page along with the LTS -one. It will typically have more frequent releases than LTS and is for -those for whom having the latest features is more important than stability. -Even numbered versions will become LTS releases and the odd numbered ones -will be supported only for nine months from when they are released - the -details of each are on the LTS schedule page. Once Pull Requests have -landed in master they will often automatically become candidates for the -next version of the "current" release, in which case the process mentioned -above regarding cherry picking and potentially pull requests will apply. - -### Merge conflicts on LTS branches - -If a fix is selected for inclusion in a current or LTS releases but cannot -be merged directly, a member of the release team may request that someone -performs a manual backport. This will involve someone (potentially the -person who submitted the original pull request) doing the backport by -submitting another pull request into the appropriate staging branch (e.g. -v6.x-staging). - -If you need to submit a new pull request to a branch other than master to do -a manual backport then you should include the same set of commits that went -into master along with the associated metadata. The easiest way to do this -is to use git cherry-pick to pull across the commit hash from master: - -``` - $ git cherry-pick HASH - // fix all conflicts that are reported - $ git cherry-pick --continue -``` - -Any other relevant links to pull requests can be included as "Ref:" links in -the PR message From f9bc1e9da981319f738af8af880d393801851c3d Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Fri, 30 Dec 2016 13:45:57 +0000 Subject: [PATCH 3/3] doc: CONTRIBUTING.md updates (will squash) --- CONTRIBUTING.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a6d26b7aaed0a3..58f205594f81e3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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 @@ -327,25 +327,24 @@ 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 @@ -353,8 +352,11 @@ master and manually resolve the conflicts using these commands: $ 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