From: Mark Brown <broonie@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Jiri Kosina <jkosina@suse.com>, ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] The amount of -stable emails
Date: Tue, 5 Aug 2025 17:41:40 +0100 [thread overview]
Message-ID: <09a8f276-916f-45e9-bd63-ffddecf1be9a@sirena.org.uk> (raw)
In-Reply-To: <20250805122828.68312a8d@gandalf.local.home>
[-- 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 --]
next prev parent reply other threads:[~2025-08-05 16:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 15:38 Jiri Kosina
2025-08-05 16:08 ` Mark Brown
2025-08-05 16:28 ` Steven Rostedt
2025-08-05 16:41 ` Mark Brown [this message]
2025-08-06 8:04 ` Geert Uytterhoeven
2025-08-06 10:42 ` Mark Brown
2025-08-06 12:20 ` Sasha Levin
2025-08-06 12:24 ` Mark Brown
2025-08-06 14:57 ` Theodore Ts'o
2025-08-06 21:35 ` Sasha Levin
2025-08-05 17:14 ` Sasha Levin
2025-08-05 17:59 ` Konstantin Ryabitsev
2025-08-05 21:04 ` Sasha Levin
2025-08-05 17:40 ` Chuck Wolber
2025-08-05 16:49 ` James Bottomley
2025-08-05 17:26 ` Sasha Levin
2025-08-05 17:33 ` James Bottomley
2025-08-05 18:01 ` Sasha Levin
2025-08-06 8:04 ` Greg KH
2025-08-05 17:34 ` Greg KH
2025-08-05 21:39 ` Jiri Kosina
2025-08-05 22:34 ` Martin K. Petersen
2025-08-06 5:44 ` Tomasz Figa
2025-08-06 6:27 ` Takashi Iwai
2025-08-06 7:00 ` Jiri Kosina
2025-08-06 7:08 ` Takashi Iwai
2025-08-12 17:19 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09a8f276-916f-45e9-bd63-ffddecf1be9a@sirena.org.uk \
--to=broonie@kernel.org \
--cc=jkosina@suse.com \
--cc=ksummit@lists.linux.dev \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox