Message-Id: <20161205072154.8177-1-mhocko@kernel.org>
Date:   Mon,  5 Dec 2016 08:21:54 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     LKML <linux-kernel@...r.kernel.org>,
        Stable tree <stable@...r.kernel.org>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     Andy Lutomirski <luto@...capital.net>, Willy Tarreau <w@....eu>,
        Jiri Kosina <jkosina@...e.cz>, Michal Hocko <mhocko@...e.com>
Subject: [RFC PATCH] doc: change the way how the stable backport is requested

From: Michal Hocko <mhocko@...e.com>

Currently if a patch should aim a stable tree backport one should add

Cc: stable@...r.kernel.org # $version

to the s-o-b block. This has two major disadvantages a) it spams the
stable mailing list with patches which are just discussed and not merged
yet and b) it is easy to make a mistake and disclose a patch via
git-send-email while it is still discussed under security embargo.

In fact it is not necessary to have the stable mailing list address in
the Cc until it hits the Linus tree and all we need is to have a
grepable marker for automatic identification of such a patch. Let's
use

stable-request: $version[s]

instead. Where $version would tell which stable trees might be
interested in the backport. This will make the process much less error
prone without any actual downsides.

Signed-off-by: Michal Hocko <mhocko@...e.com>
---

Hi,
this is mostly motivated by the "recent" leak when a security related
patch made it to the stable tree before the embargo was lifted while it
has been discussed on the security mailing list because of careless git
send-email usage. It's not been the first time AFAIR.

This is not the only reason to change this workflow though. I also think
that CCing stable on the patch submission just adds a lot of noise to the
stable mailing list. I personally stopped following the list because the
email volume was just too high. IMHO the mailing list should only
contain patches that are currently aiming the stable tree to be useful.

Thoughts/Comments?

 Documentation/stable_kernel_rules.txt | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index 4d82e31b7958..a9f2ca460ec7 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -54,11 +54,13 @@ To have the patch automatically included in the stable tree, add the tag
 
 .. code-block:: none
 
-     Cc: stable@...r.kernel.org
+     stable-request: $version[s]
 
 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.
+the stable tree[s] without anything else needing to be done by the author
+or subsystem maintainer. In exceptional cases when the $version is not
+known to the patch submitter "any" can be used and the final version will
+get resolved at the time of backporting.
 
 .. _option_2:
 
@@ -104,10 +106,10 @@ prerequisites which can be cherry-picked. This can be specified in the following
 
 .. code-block:: none
 
-     Cc: <stable@...r.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
-     Cc: <stable@...r.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
-     Cc: <stable@...r.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
-     Cc: <stable@...r.kernel.org> # 3.3.x
+     stable-request: depends on a1f84a3: sched: Check for idle
+     stable-request: depends on 1b9508f: sched: Rate-limit newidle
+     stable-request: depends on fd21073: sched: Fix affinity logic
+     stable-request: 3.3.x
      Signed-off-by: Ingo Molnar <mingo@...e.hu>
 
 The tag sequence has the meaning of:
@@ -119,13 +121,6 @@ prerequisites which can be cherry-picked. This can be specified in the following
      git cherry-pick fd21073
      git cherry-pick <this commit>
 
-Also, some patches may have kernel version prerequisites.  This can be
-specified in the following format in the sign-off area:
-
-.. code-block:: none
-
-     Cc: <stable@...r.kernel.org> # 3.3.x-
-
 The tag has the meaning of:
 
 .. code-block:: none
-- 
2.10.2

Powered by blists - more mailing lists