SubmittingPatches-backports.rst: clarify where to explain

The prevailing consensus is that rationales of direct fixes need
not be included in the commit messages. The matter must be
made clear to the reviewers, but it's not important how this is
accomplished.

(Perusers of the git history interested in finding out this information
are free to search for it by linking the commit in question to the PR it
originated from, and possibly from there to the related tracker issues.)

Signed-off-by: Nathan Cutler <[email protected]>

SubmittingPatches-backports.rst

@@ -42,8 +42,9 @@ over years of backporting, apply to the actual backport implementation:
 * all fixes should land in master first
 * commits to stable branches should be cherry-picked from master
 * before starting to cherry-pick a set of commits from master, grep the master git history for the SHA1 of each master commit (using ``git log --grep``) to check for follow-up fixes. Include any follow-up fixes found in the set of commits to be cherry-picked.
+* when backporting a master PR to a stable branch, double-check that the backport PR contains cherry-picks of all of the master PR's commits. If any commit needs to be omitted, declare and explain this in the PR.
 * cherry-picks must be done using ``git cherry-pick -x``
-* if a commit could not be cherry-picked from master, the commit message must explain why that was not possible
+* if a cherry-pick from master is not feasible and a direct fix is being undertaken, this must be explained
 * the commit message generated by ``git cherry-pick -x`` must not be modified, except to add a "Conflicts" section below the "cherry picked from commit ..." line added by git
 * the "Conflicts" section must mention all files where changes had to be made manually (not just conflicts flagged by git)
 * the "Conflicts" section should also describe the manual changes that were made