ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Jiri Kosina <jikos@kernel.org>
Cc: Takashi Iwai <tiwai@suse.de>,
	Greg KH <gregkh@linuxfoundation.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] The amount of -stable emails
Date: Wed, 06 Aug 2025 09:08:08 +0200	[thread overview]
Message-ID: <878qjxrkpz.wl-tiwai@suse.de> (raw)
In-Reply-To: <234rn3r2-qss4-s6s4-8o69-81o79rqp9s54@xreary.bet>

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

  reply	other threads:[~2025-08-06  7:08 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
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 [this message]
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=878qjxrkpz.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jikos@kernel.org \
    --cc=ksummit@lists.linux.dev \
    /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