[RFC PATCH] doc: change the way how the stable backport is requested

[RFC PATCH] doc: change the way how the stable backport is requested

[Michal Hocko]

From: Michal Hocko <mhocko@suse.com>

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

Cc: stable@vger.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@suse.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@vger.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@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
-     Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
-     Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
-     Cc: <stable@vger.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@elte.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@vger.kernel.org> # 3.3.x-
-
 The tag has the meaning of:
 
 .. code-block:: none
-- 
2.10.2

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Greg KH]

On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> Currently if a patch should aim a stable tree backport one should add
> 
> Cc: stable@vger.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

That's not a problem in that I know I like to see them to give me a
"heads up" that something is coming down the pipeline soon.  I don't
think anyone has ever complained of this before, do you?

> 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.

Having this happen only once (maybe twice) in a over a decade really
isn't that bad of odds.  We have loads of embargoed security patches
that properly include the cc: stable tag, yet don't leak the patch to
the public mailing list.  So this really is a rare thing to have happen.
(also when it did happen, no one except me seemed to notice it, which
was pretty funny in itself...)

> 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.

We still have whole subsystems that have yet to learn about how to put
proper "cc: stable@..." in their patches, why do we want to change the
muscle memory of those that are doing the right thing to now have to do
something else?

So I don't think we need this change, let's just keep things as they
are.  If more and more people get sloppy and mess up, we can revisit it
then.

thanks,

greg k-h

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Michal Hocko]

On Mon 05-12-16 13:52:36, Greg KH wrote:
> On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.com>
> > 
> > Currently if a patch should aim a stable tree backport one should add
> > 
> > Cc: stable@vger.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
> 
> That's not a problem in that I know I like to see them to give me a
> "heads up" that something is coming down the pipeline soon.

Are you really tracking all those discussion to catch resulting patches
in the Linus' tree? I simply fail to see a point having N versions of
the patch on the stable mailing list before it gets picked up from the
_Linus'_ anyayw.

> I don't think anyone has ever complained of this before, do you?

This is the reason I have stopped following the stable mailing list.
The noise level is just too high.

> > 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.
> 
> Having this happen only once (maybe twice) in a over a decade really
> isn't that bad of odds.  We have loads of embargoed security patches
> that properly include the cc: stable tag, yet don't leak the patch to
> the public mailing list.  So this really is a rare thing to have happen.

Rare, still annoying and unnecessarily error prone. Btw. even git
send-email will not cope with Cc: stable # version properly... Here is
what I get when not using --suppress-cc=body on this particular patch
:From: Michal Hocko <mhocko@kernel.org>
:To: LKML <linux-kernel@vger.kernel.org>
:Cc: Michal Hocko <mhocko@suse.com>,
:        stable@vger.kernel.org,
:        #,
:        $version
:Subject: [RFC PATCH] doc: change the way how the stable backport is requested

> (also when it did happen, no one except me seemed to notice it, which
> was pretty funny in itself...)

You can be pretty sure people have noticed even when not pointing that
out as a response to the particular email...
 
> > 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.
> 
> We still have whole subsystems that have yet to learn about how to put
> proper "cc: stable@..." in their patches, why do we want to change the
> muscle memory of those that are doing the right thing to now have to do
> something else?

I completely see this argument. It will take some time for people to
adapt any changes in the workflow. No question about that. I just
believe that a less error prone process would be more comfortable long
term. Making stable ML being only about stable related patches and the
follow up discussions sounds like an improvemnt to me as well.

-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Willy Tarreau]

Hi Michal,

On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> > That's not a problem in that I know I like to see them to give me a
> > "heads up" that something is coming down the pipeline soon.
> 
> Are you really tracking all those discussion to catch resulting patches
> in the Linus' tree? I simply fail to see a point having N versions of
> the patch on the stable mailing list before it gets picked up from the
> _Linus'_ anyayw.
> 
> > I don't think anyone has ever complained of this before, do you?
> 
> This is the reason I have stopped following the stable mailing list.
> The noise level is just too high.

I personally have mixed opinion on this. I agree that there's too much
"noise" on the list, but at the same time I would probably be even more
clueless about patches I receive if I didn't have this noise. As Greg
says, these emails tell you something is coming. For sure I don't keep
track of the discussions nor the threads but sometimes I'm interested
in reading them and that makes my later job easier.

So in the end, I just press ",st" in mutt and all stable mails are moved
away from my mbox and archived into the stable box. My only risk at the
moment is to accidently miss something that people expected me to merge
by sending it to stable only, but that doesn't happen often.

So I think I'm fine with not changing anything as well.

cheers,
Willy

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Michal Hocko]

On Mon 05-12-16 14:15:57, Willy Tarreau wrote:
> Hi Michal,
> 
> On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> > > That's not a problem in that I know I like to see them to give me a
> > > "heads up" that something is coming down the pipeline soon.
> > 
> > Are you really tracking all those discussion to catch resulting patches
> > in the Linus' tree? I simply fail to see a point having N versions of
> > the patch on the stable mailing list before it gets picked up from the
> > _Linus'_ anyayw.
> > 
> > > I don't think anyone has ever complained of this before, do you?
> > 
> > This is the reason I have stopped following the stable mailing list.
> > The noise level is just too high.
> 
> I personally have mixed opinion on this. I agree that there's too much
> "noise" on the list, but at the same time I would probably be even more
> clueless about patches I receive if I didn't have this noise.

Is this because patches that you are receiving do not have the full
context?
-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Willy Tarreau]

On Mon, Dec 05, 2016 at 02:24:00PM +0100, Michal Hocko wrote:
> On Mon 05-12-16 14:15:57, Willy Tarreau wrote:
> > Hi Michal,
> > 
> > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> > > > That's not a problem in that I know I like to see them to give me a
> > > > "heads up" that something is coming down the pipeline soon.
> > > 
> > > Are you really tracking all those discussion to catch resulting patches
> > > in the Linus' tree? I simply fail to see a point having N versions of
> > > the patch on the stable mailing list before it gets picked up from the
> > > _Linus'_ anyayw.
> > > 
> > > > I don't think anyone has ever complained of this before, do you?
> > > 
> > > This is the reason I have stopped following the stable mailing list.
> > > The noise level is just too high.
> > 
> > I personally have mixed opinion on this. I agree that there's too much
> > "noise" on the list, but at the same time I would probably be even more
> > clueless about patches I receive if I didn't have this noise.
> 
> Is this because patches that you are receiving do not have the full
> context?

No, not at all, it's because when you're only working on old kernels,
you tend to cultivate a wide gap with modern features. And actually seeing
some activity related to some new features prepares you to deal with them,
sometimes simply by testing them on spare time. In my case t's not
exclusively a matter of applying patches, it's also about using the
kernels I emit (ie eating my own food). Normally lkml is made for this
but it's far too much verbose, and stable provides a resonable excerpt
of things I'm supposed to visit soon.

Cheers,
Willy

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Greg KH]

On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> On Mon 05-12-16 13:52:36, Greg KH wrote:
> > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> > > From: Michal Hocko <mhocko@suse.com>
> > > 
> > > Currently if a patch should aim a stable tree backport one should add
> > > 
> > > Cc: stable@vger.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
> > 
> > That's not a problem in that I know I like to see them to give me a
> > "heads up" that something is coming down the pipeline soon.
> 
> Are you really tracking all those discussion to catch resulting patches
> in the Linus' tree? I simply fail to see a point having N versions of
> the patch on the stable mailing list before it gets picked up from the
> _Linus'_ anyayw.

I do scan them, sometimes I even find problems with them (like a zram
"fix" that went by this weekend.)  So yes, it is always good to have
more reviewers on patches, don't you think?

> > I don't think anyone has ever complained of this before, do you?
> 
> This is the reason I have stopped following the stable mailing list.
> The noise level is just too high.

What "noise"?  It's all patches that are being addressed to the stable
kernels, how is that off-topic?  What do you expect to be posted to this
list?

> > > 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.
> > 
> > Having this happen only once (maybe twice) in a over a decade really
> > isn't that bad of odds.  We have loads of embargoed security patches
> > that properly include the cc: stable tag, yet don't leak the patch to
> > the public mailing list.  So this really is a rare thing to have happen.
> 
> Rare, still annoying and unnecessarily error prone. Btw. even git
> send-email will not cope with Cc: stable # version properly... Here is
> what I get when not using --suppress-cc=body on this particular patch
> :From: Michal Hocko <mhocko@kernel.org>
> :To: LKML <linux-kernel@vger.kernel.org>
> :Cc: Michal Hocko <mhocko@suse.com>,
> :        stable@vger.kernel.org,
> :        #,
> :        $version
> :Subject: [RFC PATCH] doc: change the way how the stable backport is requested

People are working on the "# 4.4+" issue in git right now, there was a
thread about it last week.

> > > 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.
> > 
> > We still have whole subsystems that have yet to learn about how to put
> > proper "cc: stable@..." in their patches, why do we want to change the
> > muscle memory of those that are doing the right thing to now have to do
> > something else?
> 
> I completely see this argument. It will take some time for people to
> adapt any changes in the workflow. No question about that. I just
> believe that a less error prone process would be more comfortable long
> term. Making stable ML being only about stable related patches and the
> follow up discussions sounds like an improvemnt to me as well.

But the stable ML is only about stable related patches today, how would
that change?

thanks,

greg k-h

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Michal Hocko]

On Mon 05-12-16 14:58:24, Greg KH wrote:
> On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> > On Mon 05-12-16 13:52:36, Greg KH wrote:
> > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> > > > From: Michal Hocko <mhocko@suse.com>
> > > > 
> > > > Currently if a patch should aim a stable tree backport one should add
> > > > 
> > > > Cc: stable@vger.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
> > > 
> > > That's not a problem in that I know I like to see them to give me a
> > > "heads up" that something is coming down the pipeline soon.
> > 
> > Are you really tracking all those discussion to catch resulting patches
> > in the Linus' tree? I simply fail to see a point having N versions of
> > the patch on the stable mailing list before it gets picked up from the
> > _Linus'_ anyayw.
> 
> I do scan them, sometimes I even find problems with them (like a zram
> "fix" that went by this weekend.)  So yes, it is always good to have
> more reviewers on patches, don't you think?

Yes I do agree that more review is better. But then the stable mailing
list is a complete failure in that resopect - at least for me. Why?
Simply because it doesn't contain discussion for the stable inclusion
but rather something that eventually might happen to become stable
material. This what I call noise and the reason why I've stopped
following the stable ML.

> > > I don't think anyone has ever complained of this before, do you?
> > 
> > This is the reason I have stopped following the stable mailing list.
> > The noise level is just too high.
> 
> What "noise"?  It's all patches that are being addressed to the stable
> kernels, how is that off-topic?  What do you expect to be posted to this
> list?

Patches which are final and target the stable tree. I do not have to see
N versions of patchesets which evolve in the time just to see that
something completely different has been merged to the Linus tree. 

-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Greg KH]

On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote:
> On Mon 05-12-16 14:58:24, Greg KH wrote:
> > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> > > On Mon 05-12-16 13:52:36, Greg KH wrote:
> > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> > > > > From: Michal Hocko <mhocko@suse.com>
> > > > > 
> > > > > Currently if a patch should aim a stable tree backport one should add
> > > > > 
> > > > > Cc: stable@vger.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
> > > > 
> > > > That's not a problem in that I know I like to see them to give me a
> > > > "heads up" that something is coming down the pipeline soon.
> > > 
> > > Are you really tracking all those discussion to catch resulting patches
> > > in the Linus' tree? I simply fail to see a point having N versions of
> > > the patch on the stable mailing list before it gets picked up from the
> > > _Linus'_ anyayw.
> > 
> > I do scan them, sometimes I even find problems with them (like a zram
> > "fix" that went by this weekend.)  So yes, it is always good to have
> > more reviewers on patches, don't you think?
> 
> Yes I do agree that more review is better. But then the stable mailing
> list is a complete failure in that resopect - at least for me. Why?
> Simply because it doesn't contain discussion for the stable inclusion
> but rather something that eventually might happen to become stable
> material. This what I call noise and the reason why I've stopped
> following the stable ML.

That doesn't make sense, I want to see patches that are being proposed
for the stable kernels _before_ they get into the maintainers and
Linus's tree, as then, it is almost always too late.

I will point out the zram patch this weekend as an example of that,
where if the original had gone in, it would be a while before the
"fixup" would have then gone in, and the abi deprecation would probably
have missed 4.11 entirely.

Don't you want to catch things earlier rather than later?

thanks,

greg k-h

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Michal Hocko]

On Mon 05-12-16 15:21:37, Greg KH wrote:
> On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote:
> > On Mon 05-12-16 14:58:24, Greg KH wrote:
> > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> > > > On Mon 05-12-16 13:52:36, Greg KH wrote:
> > > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> > > > > > From: Michal Hocko <mhocko@suse.com>
> > > > > > 
> > > > > > Currently if a patch should aim a stable tree backport one should add
> > > > > > 
> > > > > > Cc: stable@vger.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
> > > > > 
> > > > > That's not a problem in that I know I like to see them to give me a
> > > > > "heads up" that something is coming down the pipeline soon.
> > > > 
> > > > Are you really tracking all those discussion to catch resulting patches
> > > > in the Linus' tree? I simply fail to see a point having N versions of
> > > > the patch on the stable mailing list before it gets picked up from the
> > > > _Linus'_ anyayw.
> > > 
> > > I do scan them, sometimes I even find problems with them (like a zram
> > > "fix" that went by this weekend.)  So yes, it is always good to have
> > > more reviewers on patches, don't you think?
> > 
> > Yes I do agree that more review is better. But then the stable mailing
> > list is a complete failure in that resopect - at least for me. Why?
> > Simply because it doesn't contain discussion for the stable inclusion
> > but rather something that eventually might happen to become stable
> > material. This what I call noise and the reason why I've stopped
> > following the stable ML.
> 
> That doesn't make sense, I want to see patches that are being proposed
> for the stable kernels _before_ they get into the maintainers and
> Linus's tree, as then, it is almost always too late.

Too late for what? I am still not sure I see your point. Are you
suggesting that a review from the stable mailing list, which wouldn't
be a part of a standard review process normally, has helped to identify
issues?

> I will point out the zram patch this weekend as an example of that,
> where if the original had gone in, it would be a while before the
> "fixup" would have then gone in, and the abi deprecation would probably
> have missed 4.11 entirely.

I do not have a full context here. Do you have a pointer please?

> Don't you want to catch things earlier rather than later?

Sure, but I fail to see the role of the stable ML in this area. I might
be underastimating its role of course.
-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Greg KH]

On Mon, Dec 05, 2016 at 03:39:15PM +0100, Michal Hocko wrote:
> On Mon 05-12-16 15:21:37, Greg KH wrote:
> > On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote:
> > > On Mon 05-12-16 14:58:24, Greg KH wrote:
> > > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> > > > > On Mon 05-12-16 13:52:36, Greg KH wrote:
> > > > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> > > > > > > From: Michal Hocko <mhocko@suse.com>
> > > > > > > 
> > > > > > > Currently if a patch should aim a stable tree backport one should add
> > > > > > > 
> > > > > > > Cc: stable@vger.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
> > > > > > 
> > > > > > That's not a problem in that I know I like to see them to give me a
> > > > > > "heads up" that something is coming down the pipeline soon.
> > > > > 
> > > > > Are you really tracking all those discussion to catch resulting patches
> > > > > in the Linus' tree? I simply fail to see a point having N versions of
> > > > > the patch on the stable mailing list before it gets picked up from the
> > > > > _Linus'_ anyayw.
> > > > 
> > > > I do scan them, sometimes I even find problems with them (like a zram
> > > > "fix" that went by this weekend.)  So yes, it is always good to have
> > > > more reviewers on patches, don't you think?
> > > 
> > > Yes I do agree that more review is better. But then the stable mailing
> > > list is a complete failure in that resopect - at least for me. Why?
> > > Simply because it doesn't contain discussion for the stable inclusion
> > > but rather something that eventually might happen to become stable
> > > material. This what I call noise and the reason why I've stopped
> > > following the stable ML.
> > 
> > That doesn't make sense, I want to see patches that are being proposed
> > for the stable kernels _before_ they get into the maintainers and
> > Linus's tree, as then, it is almost always too late.
> 
> Too late for what? I am still not sure I see your point. Are you
> suggesting that a review from the stable mailing list, which wouldn't
> be a part of a standard review process normally, has helped to identify
> issues?

Sometimes, yes, this happens.

> > I will point out the zram patch this weekend as an example of that,
> > where if the original had gone in, it would be a while before the
> > "fixup" would have then gone in, and the abi deprecation would probably
> > have missed 4.11 entirely.
> 
> I do not have a full context here. Do you have a pointer please?

A patch for the zram subsystem was cc: stable this weekend and I pointed
out problems with it and the user/kernel api that it was modifying.  I
would have never seen this patch otherwise.

> > Don't you want to catch things earlier rather than later?
> 
> Sure, but I fail to see the role of the stable ML in this area. I might
> be underastimating its role of course.

I think you are :)

Seeing the patches sent to the list _before_ they end up in a
maintainers tree, or Linus's tree, helps some issues to be resolved.
Most of the time it just lets me know what to watch out for, and what
areas of the kernel are having lots of issues.

Given that the current maintainers of the stable kernels don't seem to
be objecting to the current setup of this list, I find it odd that you
wish to change it :)

thanks,

greg k-h

Re: [RFC PATCH] doc: change the way how the stable backport is requested

[Michal Hocko]

On Mon 05-12-16 15:43:59, Greg KH wrote:
> On Mon, Dec 05, 2016 at 03:39:15PM +0100, Michal Hocko wrote:
> > On Mon 05-12-16 15:21:37, Greg KH wrote:
> > > On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote:
> > > > On Mon 05-12-16 14:58:24, Greg KH wrote:
> > > > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote:
> > > > > > On Mon 05-12-16 13:52:36, Greg KH wrote:
> > > > > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote:
> > > > > > > > From: Michal Hocko <mhocko@suse.com>
> > > > > > > > 
> > > > > > > > Currently if a patch should aim a stable tree backport one should add
> > > > > > > > 
> > > > > > > > Cc: stable@vger.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
> > > > > > > 
> > > > > > > That's not a problem in that I know I like to see them to give me a
> > > > > > > "heads up" that something is coming down the pipeline soon.
> > > > > > 
> > > > > > Are you really tracking all those discussion to catch resulting patches
> > > > > > in the Linus' tree? I simply fail to see a point having N versions of
> > > > > > the patch on the stable mailing list before it gets picked up from the
> > > > > > _Linus'_ anyayw.
> > > > > 
> > > > > I do scan them, sometimes I even find problems with them (like a zram
> > > > > "fix" that went by this weekend.)  So yes, it is always good to have
> > > > > more reviewers on patches, don't you think?
> > > > 
> > > > Yes I do agree that more review is better. But then the stable mailing
> > > > list is a complete failure in that resopect - at least for me. Why?
> > > > Simply because it doesn't contain discussion for the stable inclusion
> > > > but rather something that eventually might happen to become stable
> > > > material. This what I call noise and the reason why I've stopped
> > > > following the stable ML.
> > > 
> > > That doesn't make sense, I want to see patches that are being proposed
> > > for the stable kernels _before_ they get into the maintainers and
> > > Linus's tree, as then, it is almost always too late.
> > 
> > Too late for what? I am still not sure I see your point. Are you
> > suggesting that a review from the stable mailing list, which wouldn't
> > be a part of a standard review process normally, has helped to identify
> > issues?
> 
> Sometimes, yes, this happens.

It is really hard to argue here... But effectivelly something is really
broken when wrong/unsuitable patches marked for stable pass the maintainer.
 
> > > I will point out the zram patch this weekend as an example of that,
> > > where if the original had gone in, it would be a while before the
> > > "fixup" would have then gone in, and the abi deprecation would probably
> > > have missed 4.11 entirely.
> > 
> > I do not have a full context here. Do you have a pointer please?
> 
> A patch for the zram subsystem was cc: stable this weekend and I pointed
> out problems with it and the user/kernel api that it was modifying.  I
> would have never seen this patch otherwise.

I guess you are talking about  https://lkml.org/lkml/2016/12/3/257? If
yes then the patch hasn't even been taken by Andrew so I am wondering
why do mention it as a hand break coming from the stable tree.

> > > Don't you want to catch things earlier rather than later?
> > 
> > Sure, but I fail to see the role of the stable ML in this area. I might
> > be underastimating its role of course.
> 
> I think you are :)
> 
> Seeing the patches sent to the list _before_ they end up in a
> maintainers tree, or Linus's tree, helps some issues to be resolved.
> Most of the time it just lets me know what to watch out for, and what
> areas of the kernel are having lots of issues.
> 
> Given that the current maintainers of the stable kernels don't seem to
> be objecting to the current setup of this list, I find it odd that you
> wish to change it :)

The reason I came up with this is simple and I have mentioned that in
the changelog. I just thought we might improve the process a bit, if
there is no demand for that then I will not push for it. This is an RFC
after all.
-- 
Michal Hocko
SUSE Labs