summaryrefslogtreecommitdiff
path: root/Documentation/stable_kernel_rules.txt
diff options
context:
space:
mode:
authorChristoffer Dall <christoffer.dall@linaro.org>2015-05-13 22:01:07 +0200
committerJonathan Corbet <corbet@lwn.net>2015-05-22 09:38:56 -0600
commitbde1b29420d71a17d87332db8e20229f251d6c14 (patch)
treeb4f0940f75e7f0ff8cb4300b45c63a737c9e8055 /Documentation/stable_kernel_rules.txt
parentcbfa2c52818ada02ca3084e0c50aba8745311bc1 (diff)
stable: Update documentation to clarify preferred procedure
Clearly specify that "Cc: stable@vger.kernel.org" is strongly preferred so that developers understand that the other options should only be used when absolutely required. Also specify how upstream commit ids should be referenced in patches submitted directly to stable (I gathered this from looking at the stable archives), and specify that any modified patches for stable should be clearly documented in the patch description. Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/stable_kernel_rules.txt')
-rw-r--r--Documentation/stable_kernel_rules.txt19
1 files changed, 14 insertions, 5 deletions
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index 58d0ac4df946..3049a612291b 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -59,11 +59,20 @@ For all other submissions, choose one of the following procedures:
changelog of your submission, as well as the kernel version you wish
it to be applied to.
-Option 1 is probably the easiest and most common. Options 2 and 3 are more
-useful if the patch isn't deemed worthy at the time it is applied to a public
-git tree (for instance, because it deserves more regression testing first).
-Option 3 is especially useful if the patch needs some special handling to apply
-to an older kernel (e.g., if API's have changed in the meantime).
+Option 1 is *strongly* preferred, is the easiest and most common. Options 2 and
+3 are more useful if the patch isn't deemed worthy at the time it is applied to
+a public git tree (for instance, because it deserves more regression testing
+first). Option 3 is especially useful if the patch needs some special handling
+to apply to an older kernel (e.g., if API's have changed in the meantime).
+
+Note that for Option 3, if the patch deviates from the original upstream patch
+(for example because it had to be backported) this must be very clearly
+documented and justified in the patch description.
+
+The upstream commit ID must be specified with a separate line above the commit
+text, like this:
+
+ commit <sha1> upstream.
Additionally, some patches submitted via Option 1 may have additional patch
prerequisites which can be cherry-picked. This can be specified in the following