Propose the backporting process

Change-Id: I0b0fddf8dfdd68fa144b28dba911352e9a4974fd
JIRA: YARDSTICK-1253
Signed-off-by: Emma Foley <emma.l.foley@intel.com>

1 files changed, 26 insertions, 0 deletions

diff --git a/docs/testing/developer/devguide/devguide.rst b/docs/testing/developer/devguide/devguide.rst
index dbe92b846..91f2c2148 100755
--- a/docs/testing/developer/devguide/devguide.rst
+++ b/docs/testing/developer/devguide/devguide.rst
@@ -540,6 +540,32 @@ The final step consists in pushing the newly modified commit to Gerrit::
 
   git review
 
+Backporting changes to stable branches
+--------------------------------------
+During the release cycle, when master and the ``stable/<release>`` branch have
+diverged, it may be necessary to backport (cherry-pick) changes top the
+``stable/<release>`` branch once they have merged to master.
+These changes should be identified by the committers reviewing the patch.
+Changes should be backported **as soon as possible** after merging of the
+original code.
+
+..note::
+  Besides the commit and review process below, the Jira tick must be updated to
+  add dual release versions and indicate that the change is to be backported.
+
+The process for backporting is as follows:
+
+* Committer A merges a change to master (process for normal changes).
+* Committer A cherry-picks the change to ``stable/<release>`` branch (if the
+  bug has been identified for backporting).
+* The original author should review the code and verify that it still works
+  (and give a ``+1``).
+* Committer B reviews the change, gives a ``+2`` and merges to
+  ``stable/<release>``.
+
+A backported change needs a ``+1`` and a ``+2`` from a committer who didn’t
+propose the change (i.e. minimum 3 people involved).
+
 
 Plugins
 -------