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.
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(-)
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index aee73e78c7d4..a34adcb462b0 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -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:
--
1.9.1
On Wed, Dec 17, 2014 at 11:11:16PM -0800, Brian Norris wrote:
> 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.
>
> 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(-)
>
> diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
> index aee73e78c7d4..a34adcb462b0 100644
> --- a/Documentation/stable_kernel_rules.txt
> +++ b/Documentation/stable_kernel_rules.txt
> @@ -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.
"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.
> +
> + --- 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.
Other than the above comments, this looks good, care to redo it?
thanks,
greg k-h
On Thu, Dec 18, 2014 at 02:12:49PM -0800, Greg Kroah-Hartman wrote:
> Other than the above comments, this looks good, care to redo it?
Sure thing!
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.
Signed-off-by: Brian Norris <[email protected]>
---
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(-)
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index aee73e78c7d4..02f8331edb8b 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -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:
--
1.9.1
On Thu, Dec 18, 2014 at 02:55:53PM -0800, Brian Norris wrote:
> 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.
>
> Signed-off-by: Brian Norris <[email protected]>
> ---
> 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(-)
Looks good, I'll queue this up after 3.19-rc1 is out.
thanks,
greg k-h