[MAINTAINERS SUMMIT] The amount of -stable emails

[MAINTAINERS SUMMIT] The amount of -stable emails

[Jiri Kosina]

This proposal is coming as a followup to the brief IRC discussion that 
happened a few months back.

The amount of e-mails that are coming (with maintainers directly CCed) as 
a result of patches being merged to -stable is so overwhelming that I am 
not sure that people are making any productive use of it whatsoever.

I am personally pretty much ignoring most of it, as (a) I wouldn't have 
time to do anything else otherwise (b) I don't have a sufficient 
motivation / time to invest effort into stable in the fist place.

I feel it'd be beneficial to discuss this, and (depending on the outcome) 
perhaps make it opt-in (or opt-out) at least, with people/subsystems 
having means how to be excluded from all that ... ?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Tue, Aug 05, 2025 at 05:38:55PM +0200, Jiri Kosina wrote:

> This proposal is coming as a followup to the brief IRC discussion that 
> happened a few months back.

> The amount of e-mails that are coming (with maintainers directly CCed) as 
> a result of patches being merged to -stable is so overwhelming that I am 
> not sure that people are making any productive use of it whatsoever.

> I am personally pretty much ignoring most of it, as (a) I wouldn't have 
> time to do anything else otherwise (b) I don't have a sufficient 
> motivation / time to invest effort into stable in the fist place.

> I feel it'd be beneficial to discuss this, and (depending on the outcome) 
> perhaps make it opt-in (or opt-out) at least, with people/subsystems 
> having means how to be excluded from all that ... ?

One thing I'd really like to see there would be to avoid sending each
patch separately for every stable version, that just blows up the mail
volume hugely especially for those of us with subsystems that carry a
lot of quirks.  I'm sure the range of versions something is being pulled
back to could be expressed in a single mail instead, it's always some
range of versions being processed en masse rather than just a single
version.  The per version cover letter is more useful for replying with
test results but that doesn't need the whole series.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Steven Rostedt]

On Tue, 5 Aug 2025 17:08:44 +0100
Mark Brown <broonie@kernel.org> wrote:

> On Tue, Aug 05, 2025 at 05:38:55PM +0200, Jiri Kosina wrote:
> 
> > This proposal is coming as a followup to the brief IRC discussion that 
> > happened a few months back.  
> 
> > The amount of e-mails that are coming (with maintainers directly CCed) as 
> > a result of patches being merged to -stable is so overwhelming that I am 
> > not sure that people are making any productive use of it whatsoever.  
> 
> > I am personally pretty much ignoring most of it, as (a) I wouldn't have 
> > time to do anything else otherwise (b) I don't have a sufficient 
> > motivation / time to invest effort into stable in the fist place.  
> 
> > I feel it'd be beneficial to discuss this, and (depending on the outcome) 
> > perhaps make it opt-in (or opt-out) at least, with people/subsystems 
> > having means how to be excluded from all that ... ?  

I have a love hate relationship with these stable emails.

I like to see what is happening but I just don't have the time to review
them. But every so often, one catches my attention where I think a patch
shouldn't be added. But that's very few and far between.

Now, if something is marked for stable, I really don't want to be bothered
that it made it to a stable tree. If I marked something for stable, sending
me an email that it was applied is rather redundant.

I do care about the patches that are marked but fail to apply. I like
getting those emails. Although I still don't have the time to fix them :-p

> 
> One thing I'd really like to see there would be to avoid sending each
> patch separately for every stable version, that just blows up the mail
> volume hugely especially for those of us with subsystems that carry a
> lot of quirks.  I'm sure the range of versions something is being pulled
> back to could be expressed in a single mail instead, it's always some
> range of versions being processed en masse rather than just a single
> version.  The per version cover letter is more useful for replying with
> test results but that doesn't need the whole series.

Yes, I agree that a digest of all the autoselects would be good.

Possibly even a link to the stable git tree of the commit each was added to
would work.

-- Steve

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

On Tue, Aug 05, 2025 at 12:28:28PM -0400, Steven Rostedt wrote:

> I do care about the patches that are marked but fail to apply. I like
> getting those emails. Although I still don't have the time to fix them :-p

Indeed, and those are infrequent enough that they're noticable.

> Mark Brown <broonie@kernel.org> wrote:

> > One thing I'd really like to see there would be to avoid sending each
> > patch separately for every stable version, that just blows up the mail
> > volume hugely especially for those of us with subsystems that carry a
> > lot of quirks.  I'm sure the range of versions something is being pulled
> > back to could be expressed in a single mail instead, it's always some
> > range of versions being processed en masse rather than just a single
> > version.  The per version cover letter is more useful for replying with
> > test results but that doesn't need the whole series.

> Yes, I agree that a digest of all the autoselects would be good.

> Possibly even a link to the stable git tree of the commit each was added to
> would work.

It's not just the autoselects, you get one batch of mails for AUTOSEL if
the patches were picked up that way, then another batch of mails when
the patches are added to a queue then yet another when the stable -rc
goes out for testing.  Possibly more that I'm forgetting, and each of
those is per version.  Now you mention it there's some redundancy there
too...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Geert Uytterhoeven]

On Tue, 5 Aug 2025 at 18:41, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Aug 05, 2025 at 12:28:28PM -0400, Steven Rostedt wrote:
> > > One thing I'd really like to see there would be to avoid sending each
> > > patch separately for every stable version, that just blows up the mail
> > > volume hugely especially for those of us with subsystems that carry a
> > > lot of quirks.  I'm sure the range of versions something is being pulled
> > > back to could be expressed in a single mail instead, it's always some
> > > range of versions being processed en masse rather than just a single
> > > version.  The per version cover letter is more useful for replying with
> > > test results but that doesn't need the whole series.
>
> > Yes, I agree that a digest of all the autoselects would be good.

Commits are not always backported to all stable trees.  Sometimes I
receive an email about a backport, and wonder "has that still not
been backported?", only to discover it was backported, but not to
a very old stable tree.

> > Possibly even a link to the stable git tree of the commit each was added to
> > would work.
>
> It's not just the autoselects, you get one batch of mails for AUTOSEL if
> the patches were picked up that way, then another batch of mails when
> the patches are added to a queue then yet another when the stable -rc
> goes out for testing.  Possibly more that I'm forgetting, and each of
> those is per version.  Now you mention it there's some redundancy there
> too...

Speaking about the stable rc emails: can we please get the
"Pseudo-Shortlog of commits": sorted by author, just like the final
shortlog? It would save me a tiny bit of time.
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On Wed, Aug 06, 2025 at 10:04:11AM +0200, Geert Uytterhoeven wrote:
> On Tue, 5 Aug 2025 at 18:41, Mark Brown <broonie@kernel.org> wrote:
> > On Tue, Aug 05, 2025 at 12:28:28PM -0400, Steven Rostedt wrote:

> > > > One thing I'd really like to see there would be to avoid sending each
> > > > patch separately for every stable version, that just blows up the mail
> > > > volume hugely especially for those of us with subsystems that carry a
> > > > lot of quirks.  I'm sure the range of versions something is being pulled
> > > > back to could be expressed in a single mail instead, it's always some
> > > > range of versions being processed en masse rather than just a single
> > > > version.  The per version cover letter is more useful for replying with
> > > > test results but that doesn't need the whole series.

> > > Yes, I agree that a digest of all the autoselects would be good.

> Commits are not always backported to all stable trees.  Sometimes I
> receive an email about a backport, and wonder "has that still not
> been backported?", only to discover it was backported, but not to
> a very old stable tree.

TBH I think a summary would help there - currently you're looking at six
threads for all the different stables and have to check every patch in
each, if we were instead getting a summary that says that patch A has
been backported to stables X-Y then it'd highlight more clearly if
something wasn't pulled far enough back.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Sasha Levin]

On Wed, Aug 06, 2025 at 11:42:03AM +0100, Mark Brown wrote:
>On Wed, Aug 06, 2025 at 10:04:11AM +0200, Geert Uytterhoeven wrote:
>> On Tue, 5 Aug 2025 at 18:41, Mark Brown <broonie@kernel.org> wrote:
>> > On Tue, Aug 05, 2025 at 12:28:28PM -0400, Steven Rostedt wrote:
>
>> > > > One thing I'd really like to see there would be to avoid sending each
>> > > > patch separately for every stable version, that just blows up the mail
>> > > > volume hugely especially for those of us with subsystems that carry a
>> > > > lot of quirks.  I'm sure the range of versions something is being pulled
>> > > > back to could be expressed in a single mail instead, it's always some
>> > > > range of versions being processed en masse rather than just a single
>> > > > version.  The per version cover letter is more useful for replying with
>> > > > test results but that doesn't need the whole series.
>
>> > > Yes, I agree that a digest of all the autoselects would be good.
>
>> Commits are not always backported to all stable trees.  Sometimes I
>> receive an email about a backport, and wonder "has that still not
>> been backported?", only to discover it was backported, but not to
>> a very old stable tree.
>
>TBH I think a summary would help there - currently you're looking at six
>threads for all the different stables and have to check every patch in
>each, if we were instead getting a summary that says that patch A has
>been backported to stables X-Y then it'd highlight more clearly if
>something wasn't pulled far enough back.

Something along the lines of
https://lore.kernel.org/all/20250805130945.471732-1-sashal@kernel.org/ ?

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

On Wed, Aug 06, 2025 at 08:20:02AM -0400, Sasha Levin wrote:
> On Wed, Aug 06, 2025 at 11:42:03AM +0100, Mark Brown wrote:

> > TBH I think a summary would help there - currently you're looking at six
> > threads for all the different stables and have to check every patch in
> > each, if we were instead getting a summary that says that patch A has
> > been backported to stables X-Y then it'd highlight more clearly if
> > something wasn't pulled far enough back.

> Something along the lines of
> https://lore.kernel.org/all/20250805130945.471732-1-sashal@kernel.org/ ?

Yes.  Possibly also putting the range in the body in case people find
that more visible when reading the thread?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Theodore Ts'o]

On Wed, Aug 06, 2025 at 01:24:47PM +0100, Mark Brown wrote:
> On Wed, Aug 06, 2025 at 08:20:02AM -0400, Sasha Levin wrote:
> > On Wed, Aug 06, 2025 at 11:42:03AM +0100, Mark Brown wrote:
> 
> > > TBH I think a summary would help there - currently you're looking at six
> > > threads for all the different stables and have to check every patch in
> > > each, if we were instead getting a summary that says that patch A has
> > > been backported to stables X-Y then it'd highlight more clearly if
> > > something wasn't pulled far enough back.
> 
> > Something along the lines of
> > https://lore.kernel.org/all/20250805130945.471732-1-sashal@kernel.org/ ?
> 
> Yes.  Possibly also putting the range in the body in case people find
> that more visible when reading the thread?

This is a bit of a tangent, but something that I think would be
*really* cool is if there was a web dashboard which displayed commits
that were either (a) tagged with a Fixes: or cc: stable, (b)
explicitly requested by a maintainer / developer, (c) backported
because it was a dependency needed for (a) or (b), and showed links to
commits to the LTS links where it was a backported, and optionally a
link to the "couldn't backport automatically" e-mail if it couldn't be
backported.  It would also be useful if dashboard reported whether
there was a CVE associated with the commit.

The dashboard should be searchable by subsystem, and/or by date or
kernel version range.  And it would be nice if maintainers could
subscribe to periodic update e-mails on a per-subsystem basis.

If we think this would be useful, perhaps we could try to see if we
could get LF funding/support to create such a developer tool?

      	     		     	       	    - Ted

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Sasha Levin]

On Wed, Aug 06, 2025 at 10:57:43AM -0400, Theodore Ts'o wrote:
>On Wed, Aug 06, 2025 at 01:24:47PM +0100, Mark Brown wrote:
>> On Wed, Aug 06, 2025 at 08:20:02AM -0400, Sasha Levin wrote:
>> > On Wed, Aug 06, 2025 at 11:42:03AM +0100, Mark Brown wrote:
>>
>> > > TBH I think a summary would help there - currently you're looking at six
>> > > threads for all the different stables and have to check every patch in
>> > > each, if we were instead getting a summary that says that patch A has
>> > > been backported to stables X-Y then it'd highlight more clearly if
>> > > something wasn't pulled far enough back.
>>
>> > Something along the lines of
>> > https://lore.kernel.org/all/20250805130945.471732-1-sashal@kernel.org/ ?
>>
>> Yes.  Possibly also putting the range in the body in case people find
>> that more visible when reading the thread?
>
>This is a bit of a tangent, but something that I think would be
>*really* cool is if there was a web dashboard which displayed commits
>that were either (a) tagged with a Fixes: or cc: stable, (b)
>explicitly requested by a maintainer / developer, (c) backported
>because it was a dependency needed for (a) or (b), and showed links to
>commits to the LTS links where it was a backported, and optionally a
>link to the "couldn't backport automatically" e-mail if it couldn't be
>backported.  It would also be useful if dashboard reported whether
>there was a CVE associated with the commit.
>
>The dashboard should be searchable by subsystem, and/or by date or
>kernel version range.  And it would be nice if maintainers could
>subscribe to periodic update e-mails on a per-subsystem basis.
>
>If we think this would be useful, perhaps we could try to see if we
>could get LF funding/support to create such a developer tool?

I had a similar idea about two months ago, and came up with
https://sashalevin.github.io/ . This is very much work in progress and I
wouldn't rely on the data currently in the dashboard.

Due to travel in the last couple of weeks progress was blocked, but I'm
hoping to have this in a good state for LPC to showcase it and get some
feedback in person. I wrote down your ideas around subsystem filtering,
CVE integration, and date filtering. Thanks! :)

This is one of the things AI has enabled me to do. I really don't think
that we need to go to the LF to get funding for this, at least not for
the 90% of the benefit that the dashboard will provide.

Sasha Levin, web developer, at your service :)

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Sasha Levin]

On Tue, Aug 05, 2025 at 12:28:28PM -0400, Steven Rostedt wrote:
>On Tue, 5 Aug 2025 17:08:44 +0100
>Mark Brown <broonie@kernel.org> wrote:

[snip]

>Now, if something is marked for stable, I really don't want to be bothered
>that it made it to a stable tree. If I marked something for stable, sending
>me an email that it was applied is rather redundant.

So I'd love to cancel the "Added to the stable tree" mails. I honestly
don't even know why they go out: my understanding that it was for
historical reasons where someone asked for those in the past, but I
really feel bad about sending those out because to me they are pure
spam.

>> One thing I'd really like to see there would be to avoid sending each
>> patch separately for every stable version, that just blows up the mail
>> volume hugely especially for those of us with subsystems that carry a
>> lot of quirks.  I'm sure the range of versions something is being pulled
>> back to could be expressed in a single mail instead, it's always some
>> range of versions being processed en masse rather than just a single
>> version.  The per version cover letter is more useful for replying with
>> test results but that doesn't need the whole series.
>
>Yes, I agree that a digest of all the autoselects would be good.

I actually did that earlier today!

See the latest batch of AUTOSELs: https://lore.kernel.org/stable/20250805130945.471732-1-sashal@kernel.org/T/#t

Instead of one mail per tree, the subject line contains the range of
trees it applies to.

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Konstantin Ryabitsev]

On Tue, Aug 05, 2025 at 01:14:24PM -0400, Sasha Levin wrote:
> > Now, if something is marked for stable, I really don't want to be bothered
> > that it made it to a stable tree. If I marked something for stable, sending
> > me an email that it was applied is rather redundant.
> 
> So I'd love to cancel the "Added to the stable tree" mails. I honestly
> don't even know why they go out: my understanding that it was for
> historical reasons where someone asked for those in the past, but I
> really feel bad about sending those out because to me they are pure
> spam.

I can suggest that you write them to a public-inbox feed instead. We can then
pull that into lore so they still show up for people performing context
queries, but we don't ever deliver them via SMTP.

-K

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Sasha Levin]

On Tue, Aug 05, 2025 at 01:59:10PM -0400, Konstantin Ryabitsev wrote:
>On Tue, Aug 05, 2025 at 01:14:24PM -0400, Sasha Levin wrote:
>> > Now, if something is marked for stable, I really don't want to be bothered
>> > that it made it to a stable tree. If I marked something for stable, sending
>> > me an email that it was applied is rather redundant.
>>
>> So I'd love to cancel the "Added to the stable tree" mails. I honestly
>> don't even know why they go out: my understanding that it was for
>> historical reasons where someone asked for those in the past, but I
>> really feel bad about sending those out because to me they are pure
>> spam.
>
>I can suggest that you write them to a public-inbox feed instead. We can then
>pull that into lore so they still show up for people performing context
>queries, but we don't ever deliver them via SMTP.

I wish I knew who actually uses it, so maybe we could just drop it
altogether :/

This predates the lei/lore days, so I'm a git concerned about making a
change like that if anyone is actually relying on those mails.

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Chuck Wolber]

On Tue, Aug 5, 2025 at 4:28 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
>
> I like to see what is happening but I just don't have the time to review
> them. But every so often, one catches my attention where I think a patch
> shouldn't be added. But that's very few and far between

OBRequirementsPlug: Documenting low level design expectations
[1][2][3] should provide a
foundation for semantic filtering. It is one thing to be faced with a
"big wall of patch" that looks
like a "big pile of work". It is a completely different game when you
can readily identify what
parts of the design that patch affects.

There is no panacea, but a stepwise improvement is definitely within reach.

..Ch:W..

[1] https://sched.co/1zfhU
[2] https://www.youtube.com/watch?v=_N3l_EEV8uM
[3] https://lpc.events/event/18/contributions/1894/

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[James Bottomley]

On Tue, 2025-08-05 at 17:38 +0200, Jiri Kosina wrote:
> This proposal is coming as a followup to the brief IRC discussion
> that happened a few months back.
> 
> The amount of e-mails that are coming (with maintainers directly
> CCed) as a result of patches being merged to -stable is so
> overwhelming that I am not sure that people are making any productive
> use of it whatsoever.
> 
> I am personally pretty much ignoring most of it, as (a) I wouldn't
> have time to do anything else otherwise (b) I don't have a sufficient
> motivation / time to invest effort into stable in the fist place.
> 
> I feel it'd be beneficial to discuss this, and (depending on the
> outcome)perhaps make it opt-in (or opt-out) at least, with
> people/subsystems  having means how to be excluded from all that ...
> ?

Actually, if stable emails just had a header tag, it would be easy for
procmail to sort them out ... which is what I've been asking for for
years.  X-Stable-Base: and X-Stable: seem to be reasonably common and
catch most of it, but codifying the use in the kernel documentation and
using them consistently would really help.

Regards,

James

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Sasha Levin]

On Tue, Aug 05, 2025 at 12:49:02PM -0400, James Bottomley wrote:
>On Tue, 2025-08-05 at 17:38 +0200, Jiri Kosina wrote:
>> This proposal is coming as a followup to the brief IRC discussion
>> that happened a few months back.
>>
>> The amount of e-mails that are coming (with maintainers directly
>> CCed) as a result of patches being merged to -stable is so
>> overwhelming that I am not sure that people are making any productive
>> use of it whatsoever.
>>
>> I am personally pretty much ignoring most of it, as (a) I wouldn't
>> have time to do anything else otherwise (b) I don't have a sufficient
>> motivation / time to invest effort into stable in the fist place.
>>
>> I feel it'd be beneficial to discuss this, and (depending on the
>> outcome)perhaps make it opt-in (or opt-out) at least, with
>> people/subsystems  having means how to be excluded from all that ...
>> ?
>
>Actually, if stable emails just had a header tag, it would be easy for
>procmail to sort them out ... which is what I've been asking for for
>years.  X-Stable-Base: and X-Stable: seem to be reasonably common and
>catch most of it, but codifying the use in the kernel documentation and
>using them consistently would really help.

Do we have any stable-related mails that don't have an X-Stable: header?

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[James Bottomley]

On Tue, 2025-08-05 at 13:26 -0400, Sasha Levin wrote:
> On Tue, Aug 05, 2025 at 12:49:02PM -0400, James Bottomley wrote:
[...]
> > Actually, if stable emails just had a header tag, it would be easy
> > for procmail to sort them out ... which is what I've been asking
> > for for years.  X-Stable-Base: and X-Stable: seem to be reasonably
> > common and catch most of it, but codifying the use in the kernel
> > documentation and using them consistently would really help.
> 
> Do we have any stable-related mails that don't have an X-Stable:
> header?

It seems to be mostly working for now, but what I often find is the
header changes on a whim and the filter stops working.  And, since
nothing is written down, we all have to guess again what it means.  If
you're confident this one's not going to change, why not document it
and commit to using it in the stable process docs?

Regards,

James

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Sasha Levin]

On Tue, Aug 05, 2025 at 01:33:39PM -0400, James Bottomley wrote:
>On Tue, 2025-08-05 at 13:26 -0400, Sasha Levin wrote:
>> On Tue, Aug 05, 2025 at 12:49:02PM -0400, James Bottomley wrote:
>[...]
>> > Actually, if stable emails just had a header tag, it would be easy
>> > for procmail to sort them out ... which is what I've been asking
>> > for for years.  X-Stable-Base: and X-Stable: seem to be reasonably
>> > common and catch most of it, but codifying the use in the kernel
>> > documentation and using them consistently would really help.
>>
>> Do we have any stable-related mails that don't have an X-Stable:
>> header?
>
>It seems to be mostly working for now, but what I often find is the
>header changes on a whim and the filter stops working.  And, since
>nothing is written down, we all have to guess again what it means.  If
>you're confident this one's not going to change, why not document it
>and commit to using it in the stable process docs?

It will probably need to be bigger than that: we'd need to document the
overall expectations and process before we document some of the nits in
it.

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Greg KH]

On Tue, Aug 05, 2025 at 01:33:39PM -0400, James Bottomley wrote:
> On Tue, 2025-08-05 at 13:26 -0400, Sasha Levin wrote:
> > On Tue, Aug 05, 2025 at 12:49:02PM -0400, James Bottomley wrote:
> [...]
> > > Actually, if stable emails just had a header tag, it would be easy
> > > for procmail to sort them out ... which is what I've been asking
> > > for for years.  X-Stable-Base: and X-Stable: seem to be reasonably
> > > common and catch most of it, but codifying the use in the kernel
> > > documentation and using them consistently would really help.
> > 
> > Do we have any stable-related mails that don't have an X-Stable:
> > header?
> 
> It seems to be mostly working for now, but what I often find is the
> header changes on a whim and the filter stops working.

When has it changed?  If it does, always let us know as odds are it is
not intentional.

> And, since nothing is written down, we all have to guess again what it
> means.  If you're confident this one's not going to change, why not
> document it and commit to using it in the stable process docs?

Sure, I can do that.

But also, if these emails really aren't needed/wanted, we can easily
just not send them out.  I have done so since the start of the stable
kernel process, just over 20 years ago, as I thought they were
informative.  But if not, and people are just treating them as spam to
file away, I can gladly ONLY email them to the stable-commits mailing
list so that lore can properly archive them.

thanks,

greg k-h

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Greg KH]

On Tue, Aug 05, 2025 at 12:49:02PM -0400, James Bottomley wrote:
> On Tue, 2025-08-05 at 17:38 +0200, Jiri Kosina wrote:
> > This proposal is coming as a followup to the brief IRC discussion
> > that happened a few months back.
> > 
> > The amount of e-mails that are coming (with maintainers directly
> > CCed) as a result of patches being merged to -stable is so
> > overwhelming that I am not sure that people are making any productive
> > use of it whatsoever.
> > 
> > I am personally pretty much ignoring most of it, as (a) I wouldn't
> > have time to do anything else otherwise (b) I don't have a sufficient
> > motivation / time to invest effort into stable in the fist place.
> > 
> > I feel it'd be beneficial to discuss this, and (depending on the
> > outcome)perhaps make it opt-in (or opt-out) at least, with
> > people/subsystems  having means how to be excluded from all that ...
> > ?
> 
> Actually, if stable emails just had a header tag, it would be easy for
> procmail to sort them out ... which is what I've been asking for for
> years.  X-Stable-Base: and X-Stable: seem to be reasonably common and
> catch most of it, but codifying the use in the kernel documentation and
> using them consistently would really help.

These "a patch has been added to the stable queue" has had the following
X- tags on them since August 2023:

	X-stable: commit
	X-Patchwork-Hint: ignore

and I'm sure I only added that because you, or someone else, asked :)

You can also filter on stable-commits@vger.kernel.org, which is what I
do locally.

So filter away!

thanks,

greg k-h

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Jiri Kosina]

On Tue, 5 Aug 2025, Greg KH wrote:

> > > This proposal is coming as a followup to the brief IRC discussion
> > > that happened a few months back.
> > > 
> > > The amount of e-mails that are coming (with maintainers directly
> > > CCed) as a result of patches being merged to -stable is so
> > > overwhelming that I am not sure that people are making any productive
> > > use of it whatsoever.
> > > 
> > > I am personally pretty much ignoring most of it, as (a) I wouldn't
> > > have time to do anything else otherwise (b) I don't have a sufficient
> > > motivation / time to invest effort into stable in the fist place.
> > > 
> > > I feel it'd be beneficial to discuss this, and (depending on the
> > > outcome)perhaps make it opt-in (or opt-out) at least, with
> > > people/subsystems  having means how to be excluded from all that ...
> > > ?
> > 
> > Actually, if stable emails just had a header tag, it would be easy for
> > procmail to sort them out ... which is what I've been asking for for
> > years.  X-Stable-Base: and X-Stable: seem to be reasonably common and
> > catch most of it, but codifying the use in the kernel documentation and
> > using them consistently would really help.
> 
> These "a patch has been added to the stable queue" has had the following
> X- tags on them since August 2023:
> 
> 	X-stable: commit
> 	X-Patchwork-Hint: ignore
> 
> and I'm sure I only added that because you, or someone else, asked :)
> 
> You can also filter on stable-commits@vger.kernel.org, which is what I
> do locally.
> 
> So filter away!

The question is whether it's really worth all the e-mail traffic this is 
generating, if people are just filtering those away.

For context searches if some particular information regarding stable 
patch history is needed, we can still do lore/lei queries nicely and 
easily.
Is there any other usecase (that people are actually actively using) for 
it?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Martin K. Petersen]

Jiri,

>> You can also filter on stable-commits@vger.kernel.org, which is what I
>> do locally.
>> 
>> So filter away!
>
> The question is whether it's really worth all the e-mail traffic this is 
> generating, if people are just filtering those away.

If I explicitly tagged a commit for stable and it applies without any
problems, I would prefer not to hear about it.

When I am micromanaging a particular patch (critical bug or security
fix), I am much more likely to be poking around in git instead of
relying on email notifications to determine whether it has been applied
or not.

I do have interest in failures, however. Obviously the patch author
should be the first point of contact. But I do like to get copied on
backport failure notifications. While I may not act on these, I do like
having insight into what is going on...

-- 
Martin K. Petersen

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Tomasz Figa]

2025年8月6日(水) 7:34 Martin K. Petersen <martin.petersen@oracle.com>:
>
>
> Jiri,
>
> >> You can also filter on stable-commits@vger.kernel.org, which is what I
> >> do locally.
> >>
> >> So filter away!
> >
> > The question is whether it's really worth all the e-mail traffic this is
> > generating, if people are just filtering those away.
>
> If I explicitly tagged a commit for stable and it applies without any
> problems, I would prefer not to hear about it.
>
> When I am micromanaging a particular patch (critical bug or security
> fix), I am much more likely to be poking around in git instead of
> relying on email notifications to determine whether it has been applied
> or not.
>
> I do have interest in failures, however. Obviously the patch author
> should be the first point of contact. But I do like to get copied on
> backport failure notifications. While I may not act on these, I do like
> having insight into what is going on...

Let's not forget about the autosel patches. Sometimes the selection
doesn't work very well and ends up picking patches that shouldn't go
to stable, so for those we should definitely have a way to learn
about.

Agreed, though, on explicitly tagged commits.

Best,
Tomasz

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Takashi Iwai]

On Tue, 05 Aug 2025 23:39:58 +0200,
Jiri Kosina wrote:
> 
> On Tue, 5 Aug 2025, Greg KH wrote:
> 
> > > > This proposal is coming as a followup to the brief IRC discussion
> > > > that happened a few months back.
> > > > 
> > > > The amount of e-mails that are coming (with maintainers directly
> > > > CCed) as a result of patches being merged to -stable is so
> > > > overwhelming that I am not sure that people are making any productive
> > > > use of it whatsoever.
> > > > 
> > > > I am personally pretty much ignoring most of it, as (a) I wouldn't
> > > > have time to do anything else otherwise (b) I don't have a sufficient
> > > > motivation / time to invest effort into stable in the fist place.
> > > > 
> > > > I feel it'd be beneficial to discuss this, and (depending on the
> > > > outcome)perhaps make it opt-in (or opt-out) at least, with
> > > > people/subsystems  having means how to be excluded from all that ...
> > > > ?
> > > 
> > > Actually, if stable emails just had a header tag, it would be easy for
> > > procmail to sort them out ... which is what I've been asking for for
> > > years.  X-Stable-Base: and X-Stable: seem to be reasonably common and
> > > catch most of it, but codifying the use in the kernel documentation and
> > > using them consistently would really help.
> > 
> > These "a patch has been added to the stable queue" has had the following
> > X- tags on them since August 2023:
> > 
> > 	X-stable: commit
> > 	X-Patchwork-Hint: ignore
> > 
> > and I'm sure I only added that because you, or someone else, asked :)
> > 
> > You can also filter on stable-commits@vger.kernel.org, which is what I
> > do locally.
> > 
> > So filter away!
> 
> The question is whether it's really worth all the e-mail traffic this is 
> generating, if people are just filtering those away.
> 
> For context searches if some particular information regarding stable 
> patch history is needed, we can still do lore/lei queries nicely and 
> easily.
> Is there any other usecase (that people are actually actively using) for 
> it?

In rare cases, patches are incorrectly applied.  That can't be
verified without the actual patch.

Usually it happens with a cherry-pick with fuzz, so we might be able
to catch suspected ones, but the inspection of the patch is still
needed.


Takashi

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Jiri Kosina]

On Wed, 6 Aug 2025, Takashi Iwai wrote:

> > The question is whether it's really worth all the e-mail traffic this 
> > is generating, if people are just filtering those away.
> > 
> > For context searches if some particular information regarding stable 
> > patch history is needed, we can still do lore/lei queries nicely and 
> > easily. Is there any other usecase (that people are actually actively 
> > using) for it?
> 
> In rare cases, patches are incorrectly applied.  That can't be
> verified without the actual patch.
> 
> Usually it happens with a cherry-pick with fuzz, so we might be able
> to catch suspected ones, but the inspection of the patch is still
> needed.

Sure, but you have to do that pro-actively (in case you care in the first 
place, of course). Doesn't then lore/lei provide you with the equal 
functionality?

-- 
Jiri Kosina
SUSE Labs

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Takashi Iwai]

On Wed, 06 Aug 2025 09:00:49 +0200,
Jiri Kosina wrote:
> 
> On Wed, 6 Aug 2025, Takashi Iwai wrote:
> 
> > > The question is whether it's really worth all the e-mail traffic this 
> > > is generating, if people are just filtering those away.
> > > 
> > > For context searches if some particular information regarding stable 
> > > patch history is needed, we can still do lore/lei queries nicely and 
> > > easily. Is there any other usecase (that people are actually actively 
> > > using) for it?
> > 
> > In rare cases, patches are incorrectly applied.  That can't be
> > verified without the actual patch.
> > 
> > Usually it happens with a cherry-pick with fuzz, so we might be able
> > to catch suspected ones, but the inspection of the patch is still
> > needed.
> 
> Sure, but you have to do that pro-actively (in case you care in the first 
> place, of course). Doesn't then lore/lei provide you with the equal 
> functionality?

Yeah, that's possible.  It'll become a question of tooling, after
all.  The digest mail could list up the commits that couldn't be
applied without fuzz, then one can fetch and verify, too.


Takashi

Re: [MAINTAINERS SUMMIT] The amount of -stable emails

[Steven Rostedt]

On Wed, 06 Aug 2025 08:27:03 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> > For context searches if some particular information regarding stable 
> > patch history is needed, we can still do lore/lei queries nicely and 
> > easily.
> > Is there any other usecase (that people are actually actively using) for 
> > it?  
> 
> In rare cases, patches are incorrectly applied.  That can't be
> verified without the actual patch.
> 
> Usually it happens with a cherry-pick with fuzz, so we might be able
> to catch suspected ones, but the inspection of the patch is still
> needed.

As you state this is rare. Who actually checks this? I don't. I pretty much
ignore any patch that I marked as stable and it was accepted into the
stable tree. If there was a merge mistake, I would never see it.

If people are checking for these, then I suggest they use some sort of
digest and look. But I really could do without the email that it was
applied cleanly.

-- Steve