linux-kernel - [PATCH] stable: Update documentation to clarify preferred procedure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 May 2015 22:01:07 +0200
From:	Christoffer Dall <christoffer.dall@...aro.org>
To:	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	stable@...r.kernel.org, corbet@....net, gregkh@...uxfoundation.org
Cc:	Christoffer Dall <christoffer.dall@...aro.org>
Subject: [PATCH] stable: Update documentation to clarify preferred procedure

Clearly specify that option 1 is strongly preferred so that developers
understand that option 2 or 3 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@...aro.org>
---
 Documentation/stable_kernel_rules.txt | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index 58d0ac4..54188a3 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
-- 
2.1.2.330.g565301e.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/