]>
Commit | Line | Data |
---|---|---|
58fbfec9 GKH |
1 | From 5de61e7aa1ba9ac3c7edbea375da2bc8eb1a89ae Mon Sep 17 00:00:00 2001 |
2 | From: Brian Norris <computersforpeace@gmail.com> | |
3 | Date: Thu, 18 Dec 2014 14:55:53 -0800 | |
4 | Subject: stable_kernel_rules: reorganize and update submission options | |
5 | ||
6 | From: Brian Norris <computersforpeace@gmail.com> | |
7 | ||
8 | commit 5de61e7aa1ba9ac3c7edbea375da2bc8eb1a89ae upstream. | |
9 | ||
10 | The current organization of Documentation/stable_kernel_rules.txt | |
11 | doesn't clearly differentiate the mutually exclusive options for | |
12 | submission to the -stable review process. As I understand it, patches | |
13 | are not actually required to be mailed directly to | |
14 | stable@vger.kernel.org, but the instructions do not make this clear. | |
15 | ||
16 | Also, there are some established processes that are not listed -- | |
17 | specifically, what I call Option 2 below. | |
18 | ||
19 | This patch updates and reorganizes a bit, to make things clearer. | |
20 | ||
21 | Signed-off-by: Brian Norris <computersforpeace@gmail.com> | |
22 | Signed-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: |