stable_kernel_rules: reorganize and update submission options
PATCH 1/1 stable_kernel_rules: reorganize and update submission options
The current organization of Documentation/stable_kernel_rules.txt doesn't clearly differentiate the mutually exclusive options for submission to the -stable review process. As I understand it, patches are not actually required to be mailed directly to [email protected], but the instructions do not make this clear.
Also, there are some established processes that are not listed -- specifically, what I call Option 2 below.
This patch updates and reorganizes a bit, to make things clearer.
---
This patch brough to you as a follow-up of:
https://lkml.org/lkml/2014/9/5/757
I don't profess to know your mind, Greg, but this is my attempt at codifying what I've observed.
Documentation/stable_kernel_rules.txt | 42 ++++++++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 10 deletions(-)
Documentation/stable_kernel_rules.txt +32 -10
@@ -32,18 +32,40 @@ Procedure for submitting patches to the -stable tree: - If the patch covers files in net/ or drivers/net please follow netdev stable submission guidelines as described in Documentation/networking/netdev-FAQ.txt - - Send the patch, after verifying that it follows the above rules, to - [email protected]. You must note the upstream commit ID in the - changelog of your submission, as well as the kernel version you wish - it to be applied to. - - To have the patch automatically included in the stable tree, add the tag + - Security patches should not be handled (solely) by the -stable review + process but should follow the procedures in Documentation/SecurityBugs. + +For all other submissions, choose one of the following procedures: + + --- Option 1 --- + + To have the patch automatically included in the stable tree, add the tag Cc: [email protected] in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer. - - If the patch requires other patches as prerequisites which can be - cherry-picked, then this can be specified in the following format in - the sign-off area: + + --- Option 2 --- + + Send an email to [email protected] that just contains the commit ID + of the patch -- after it has been merged to Linus' tree, of course. + + --- Option 3 --- + + Send the patch, after verifying that it follows the above rules, to + [email protected]. You must note the upstream commit ID in the + 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). + +Additionally, some patches submitted via Option 1 may have additional patch +prerequisites which can be cherry-picked. This can be specified in the following +format in the sign-off area: Cc: <[email protected]> # 3.3.x: a1f84a3: sched: Check for idle Cc: <[email protected]> # 3.3.x: 1b9508f: sched: Rate-limit newidle
@@ -57,13 +79,13 @@ Procedure for submitting patches to the -stable tree: git cherry-pick fd21073 git cherry-pick <this commit> +Following the submission: + - The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer's schedules. - If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer. - - Security patches should not be sent to this alias, but instead to the - documented [email protected] address. Review cycle:
Signature · 1 line
1.9.1
Quoted 46 lines · Brian Norris
The current organization of
Documentation/stable_kernel_rules.txtdoesn't clearly differentiate the mutually exclusive options for submission to the -stable review process. As I understand it, patches are not actually required to be mailed directly to [email protected], but the instructions do not make this clear.Also, there are some established processes that are not listed -- specifically, what I call Option 2 below.
This patch updates and reorganizes a bit, to make things clearer.
Signed-off-by Brian Norris <[email protected]>---
This patch brough to you as a follow-up of:https://lkml.org/lkml/2014/9/5/757
I don't profess to know your mind, Greg, but this is my attempt at codifying what I've observed.
Documentation/stable_kernel_rules.txt | 42 ++++++++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 10 deletions(-)Documentation/stable_kernel_rules.txt +8
-5@@ -32,18 +32,40 @@ Procedure for submitting patches to the -stable tree: - If the patch covers files in net/ or drivers/net please follow netdev stable submission guidelines as described in Documentation/networking/netdev-FAQ.txt - - Send the patch, after verifying that it follows the above rules, to - [email protected]. You must note the upstream commit ID in the - changelog of your submission, as well as the kernel version you wish - it to be applied to. - - To have the patch automatically included in the stable tree, add the tag + - Security patches should not be handled (solely) by the -stable review + process but should follow the procedures in Documentation/SecurityBugs. + +For all other submissions, choose one of the following procedures: + + --- Option 1 --- + + To have the patch automatically included in the stable tree, add the tag Cc: [email protected] in the sign-off area. Once the patch is merged it will be applied to
Documentation/stable_kernel_rules.txt Procedure for submitting patches to the -stable tree: · line 51
Quoted 10 lines
Documentation/stable_kernel_rules.txt +5
-3the stable tree without anything else needing to be done by the author or subsystem maintainer. - - If the patch requires other patches as prerequisites which can be - cherry-picked, then this can be specified in the following format in - the sign-off area: + + --- Option 2 --- + + Send an email to [email protected] that just contains the commit ID + of the patch -- after it has been merged to Linus' tree, of course.
"just" should also have at least the subject of the patch, why you think it should be applied, and what kernel version you wish it to be applied to.
Quoted 23 lines
Documentation/stable_kernel_rules.txt +17
-0+ + --- Option 3 --- + + Send the patch, after verifying that it follows the above rules, to + [email protected]. You must note the upstream commit ID in the + 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). + +Additionally, some patches submitted via Option 1 may have additional patch +prerequisites which can be cherry-picked. This can be specified in the following +format in the sign-off area: Cc: <[email protected]> # 3.3.x: a1f84a3: sched: Check for idle Cc: <[email protected]> # 3.3.x: 1b9508f: sched: Rate-limit newidle@@ -57,13 +79,13 @@ Procedure for submitting patches to the -stable tree: git cherry-pick fd21073 git cherry-pick <this commit>
Documentation/stable_kernel_rules.txt Procedure for submitting patches to the -stable tree: · line 66
Quoted 10 lines
Documentation/stable_kernel_rules.txt +2
-2+Following the submission: + - The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer's schedules. - If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer. - - Security patches should not be sent to this alias, but instead to the - documented [email protected] address.
Other than the above comments, this looks good, care to redo it?
thanks,
greg k-h
Quoted 1 line · Greg Kroah-Hartman
Other than the above comments, this looks good, care to redo it?
Sure thing!
PATCH v2 1/1 stable_kernel_rules: reorganize and update submission options
In reply to Brian NorrisThe current organization of Documentation/stable_kernel_rules.txt doesn't clearly differentiate the mutually exclusive options for submission to the -stable review process. As I understand it, patches are not actually required to be mailed directly to [email protected], but the instructions do not make this clear.
Also, there are some established processes that are not listed -- specifically, what I call Option 2 below.
This patch updates and reorganizes a bit, to make things clearer.
---
v2: add some more items to Option 2 to suit Greg's liking
Documentation/stable_kernel_rules.txt | 44 +++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 10 deletions(-)
Documentation/stable_kernel_rules.txt +34 -10
@@ -32,18 +32,42 @@ Procedure for submitting patches to the -stable tree: - If the patch covers files in net/ or drivers/net please follow netdev stable submission guidelines as described in Documentation/networking/netdev-FAQ.txt - - Send the patch, after verifying that it follows the above rules, to - [email protected]. You must note the upstream commit ID in the - changelog of your submission, as well as the kernel version you wish - it to be applied to. - - To have the patch automatically included in the stable tree, add the tag + - Security patches should not be handled (solely) by the -stable review + process but should follow the procedures in Documentation/SecurityBugs. + +For all other submissions, choose one of the following procedures: + + --- Option 1 --- + + To have the patch automatically included in the stable tree, add the tag Cc: [email protected] in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer. - - If the patch requires other patches as prerequisites which can be - cherry-picked, then this can be specified in the following format in - the sign-off area: + + --- Option 2 --- + + After the patch has been merged to Linus' tree, send an email to + [email protected] containing the subject of the patch, the commit ID, + why you think it should be applied, and what kernel version you wish it to + be applied to. + + --- Option 3 --- + + Send the patch, after verifying that it follows the above rules, to + [email protected]. You must note the upstream commit ID in the + 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). + +Additionally, some patches submitted via Option 1 may have additional patch +prerequisites which can be cherry-picked. This can be specified in the following +format in the sign-off area: Cc: <[email protected]> # 3.3.x: a1f84a3: sched: Check for idle Cc: <[email protected]> # 3.3.x: 1b9508f: sched: Rate-limit newidle
@@ -57,13 +81,13 @@ Procedure for submitting patches to the -stable tree: git cherry-pick fd21073 git cherry-pick <this commit> +Following the submission: + - The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer's schedules. - If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer. - - Security patches should not be sent to this alias, but instead to the - documented [email protected] address. Review cycle:
Signature · 1 line
1.9.1
Quoted 9 lines · Brian Norris
The current organization of
Documentation/stable_kernel_rules.txtdoesn't clearly differentiate the mutually exclusive options for submission to the -stable review process. As I understand it, patches are not actually required to be mailed directly to [email protected], but the instructions do not make this clear.Also, there are some established processes that are not listed -- specifically, what I call Option 2 below.
Quoted 8 lines
This patch updates and reorganizes a bit, to make things clearer.
Signed-off-by Brian Norris <[email protected]>---
v2: add some more items to Option 2 to suit Greg's likingDocumentation/stable_kernel_rules.txt | 44 +++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 10 deletions(-)
Looks good, I'll queue this up after 3.19-rc1 is out.
thanks,
greg k-h