From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932900AbbCPOTa (ORCPT ); Mon, 16 Mar 2015 10:19:30 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:55353 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932790AbbCPOTZ (ORCPT ); Mon, 16 Mar 2015 10:19:25 -0400 From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Norris Subject: [PATCH 3.19 163/177] stable_kernel_rules: reorganize and update submission options Date: Mon, 16 Mar 2015 15:09:30 +0100 Message-Id: <20150316140820.522271272@linuxfoundation.org> X-Mailer: git-send-email 2.3.3 In-Reply-To: <20150316140813.085032723@linuxfoundation.org> References: <20150316140813.085032723@linuxfoundation.org> User-Agent: quilt/0.64 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.19-stable review patch. If anyone has any objections, please let me know. ------------------ From: Brian Norris commit 5de61e7aa1ba9ac3c7edbea375da2bc8eb1a89ae upstream. 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 stable@vger.kernel.org, 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 Signed-off-by: Greg Kroah-Hartman --- Documentation/stable_kernel_rules.txt | 44 ++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 10 deletions(-) --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -32,18 +32,42 @@ Procedure for submitting patches to the - 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 - stable@vger.kernel.org. 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: stable@vger.kernel.org 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 + stable@vger.kernel.org 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 + stable@vger.kernel.org. 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: # 3.3.x: a1f84a3: sched: Check for idle Cc: # 3.3.x: 1b9508f: sched: Rate-limit newidle @@ -57,13 +81,13 @@ Procedure for submitting patches to the git cherry-pick fd21073 git cherry-pick +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 security@kernel.org address. Review cycle: