]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/blame - releases/3.19.2/stable_kernel_rules-reorganize-and-update-submission-options.patch
4.14-stable patches
[thirdparty/kernel/stable-queue.git] / releases / 3.19.2 / stable_kernel_rules-reorganize-and-update-submission-options.patch
CommitLineData
58fbfec9
GKH
1From 5de61e7aa1ba9ac3c7edbea375da2bc8eb1a89ae Mon Sep 17 00:00:00 2001
2From: Brian Norris <computersforpeace@gmail.com>
3Date: Thu, 18 Dec 2014 14:55:53 -0800
4Subject: stable_kernel_rules: reorganize and update submission options
5
6From: Brian Norris <computersforpeace@gmail.com>
7
8commit 5de61e7aa1ba9ac3c7edbea375da2bc8eb1a89ae upstream.
9
10The current organization of Documentation/stable_kernel_rules.txt
11doesn't clearly differentiate the mutually exclusive options for
12submission to the -stable review process. As I understand it, patches
13are not actually required to be mailed directly to
14stable@vger.kernel.org, but the instructions do not make this clear.
15
16Also, there are some established processes that are not listed --
17specifically, what I call Option 2 below.
18
19This patch updates and reorganizes a bit, to make things clearer.
20
21Signed-off-by: Brian Norris <computersforpeace@gmail.com>
22Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
23
24---
25 Documentation/stable_kernel_rules.txt | 44 ++++++++++++++++++++++++++--------
26 1 file changed, 34 insertions(+), 10 deletions(-)
27
28--- a/Documentation/stable_kernel_rules.txt
29+++ b/Documentation/stable_kernel_rules.txt
30@@ -32,18 +32,42 @@ Procedure for submitting patches to the
31 - If the patch covers files in net/ or drivers/net please follow netdev stable
32 submission guidelines as described in
33 Documentation/networking/netdev-FAQ.txt
34- - Send the patch, after verifying that it follows the above rules, to
35- stable@vger.kernel.org. You must note the upstream commit ID in the
36- changelog of your submission, as well as the kernel version you wish
37- it to be applied to.
38- - To have the patch automatically included in the stable tree, add the tag
39+ - Security patches should not be handled (solely) by the -stable review
40+ process but should follow the procedures in Documentation/SecurityBugs.
41+
42+For all other submissions, choose one of the following procedures:
43+
44+ --- Option 1 ---
45+
46+ To have the patch automatically included in the stable tree, add the tag
47 Cc: stable@vger.kernel.org
48 in the sign-off area. Once the patch is merged it will be applied to
49 the stable tree without anything else needing to be done by the author
50 or subsystem maintainer.
51- - If the patch requires other patches as prerequisites which can be
52- cherry-picked, then this can be specified in the following format in
53- the sign-off area:
54+
55+ --- Option 2 ---
56+
57+ After the patch has been merged to Linus' tree, send an email to
58+ stable@vger.kernel.org containing the subject of the patch, the commit ID,
59+ why you think it should be applied, and what kernel version you wish it to
60+ be applied to.
61+
62+ --- Option 3 ---
63+
64+ Send the patch, after verifying that it follows the above rules, to
65+ stable@vger.kernel.org. You must note the upstream commit ID in the
66+ changelog of your submission, as well as the kernel version you wish
67+ it to be applied to.
68+
69+Option 1 is probably the easiest and most common. Options 2 and 3 are more
70+useful if the patch isn't deemed worthy at the time it is applied to a public
71+git tree (for instance, because it deserves more regression testing first).
72+Option 3 is especially useful if the patch needs some special handling to apply
73+to an older kernel (e.g., if API's have changed in the meantime).
74+
75+Additionally, some patches submitted via Option 1 may have additional patch
76+prerequisites which can be cherry-picked. This can be specified in the following
77+format in the sign-off area:
78
79 Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
80 Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
81@@ -57,13 +81,13 @@ Procedure for submitting patches to the
82 git cherry-pick fd21073
83 git cherry-pick <this commit>
84
85+Following the submission:
86+
87 - The sender will receive an ACK when the patch has been accepted into the
88 queue, or a NAK if the patch is rejected. This response might take a few
89 days, according to the developer's schedules.
90 - If accepted, the patch will be added to the -stable queue, for review by
91 other developers and by the relevant subsystem maintainer.
92- - Security patches should not be sent to this alias, but instead to the
93- documented security@kernel.org address.
94
95
96 Review cycle: