From: Linus Torvalds <torvalds@linux-foundation.org>
To: Michael Ellerman <mpe@ellerman.id.au>,
"Michael S. Tsirkin" <mst@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Takashi Iwai <tiwai@suse.de>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Jan Kara <jack@suse.cz>, Thorsten Leemhuis <linux@leemhuis.info>,
"ksummit@lists.linux.dev" <ksummit@lists.linux.dev>
Subject: Re: [MAINTAINERS SUMMIT] [4/4] Discuss how to better prevent backports of commits that turn out to cause regressions
Date: Sat, 15 Jun 2024 18:13:57 -0700 [thread overview]
Message-ID: <CAHk-=wiD9du3fBHuLYzwUSdNgY+hxMZEWNZpqJXy-=wD2wafdg@mail.gmail.com> (raw)
In-Reply-To: <87plsjoax6.fsf@mail.lhotse>
On Fri, 14 Jun 2024 at 07:29, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Message-Id: sucks, I want a link I can open with a single click.
!00% agreed.
There is no way in hell I will endorse adding more of those completely
*idiotic* "Message-ID" things.
Yes, people use them. It's a damn shame.
There is no excuse for that completely broken model. It's objectively
and unquestionably worse than having a "link".
Here's the thing: if that message-ID isn't public, then that line
SHOULD NOT EXIST and is an actual real problem. I personally look at
those, and go "is that actually available on lore?"
And if that message-id _is_ public, then it has a link, and it's much
easier for people to check.
Ergo: there is absolutely zero reason to ever use Message-ID.
People need to stop advocating that sh*t.
And no, I'm not at all happy with the fact that apparently vhost and
kvm has made it their thing.
Paolo, Michael, Takashi, please put useful links, not those braindead
message id's in your commit messages.
Linus
next prev parent reply other threads:[~2024-06-16 1:14 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 8:22 [MAINTAINERS SUMMIT] [0/4] Common scenario for four proposals regarding regressions Thorsten Leemhuis
2024-06-13 8:26 ` [MAINTAINERS SUMMIT] [1/4] Create written down guidelines for handling regressions Thorsten Leemhuis
2024-09-12 13:33 ` Thorsten Leemhuis
2024-06-13 8:32 ` [MAINTAINERS SUMMIT] [2/4] Ensure recent mainline regression are fixed in latest stable series Thorsten Leemhuis
2024-06-13 11:02 ` Johannes Berg
2024-06-13 11:21 ` Greg KH
2024-06-13 13:18 ` Sasha Levin
2024-06-13 11:17 ` Jiri Kosina
2024-06-13 11:28 ` Laurent Pinchart
2024-06-14 0:50 ` Steven Rostedt
2024-06-14 14:01 ` Mark Brown
2024-06-14 14:32 ` Rafael J. Wysocki
2024-06-13 8:34 ` [MAINTAINERS SUMMIT] [3/4] Elevate handling of regressions that made it to releases deemed for end users Thorsten Leemhuis
2024-06-13 11:34 ` Laurent Pinchart
2024-06-13 11:39 ` Jiri Kosina
2024-06-14 14:10 ` Mark Brown
2024-06-18 12:58 ` Thorsten Leemhuis
2024-06-19 20:25 ` Laurent Pinchart
2024-06-20 10:47 ` Thorsten Leemhuis
2024-06-13 15:56 ` Liam R. Howlett
2024-06-18 12:24 ` Thorsten Leemhuis
2024-06-20 13:20 ` Jani Nikula
2024-06-20 13:35 ` Thorsten Leemhuis
2024-06-20 14:16 ` Mark Brown
2024-06-21 6:47 ` Jiri Kosina
2024-06-21 10:19 ` Thorsten Leemhuis
2024-06-13 8:42 ` [MAINTAINERS SUMMIT] [4/4] Discuss how to better prevent backports of commits that turn out to cause regressions Thorsten Leemhuis
2024-06-13 9:59 ` Jan Kara
2024-06-13 10:18 ` Thorsten Leemhuis
2024-06-13 14:08 ` Konstantin Ryabitsev
2024-06-14 9:19 ` Lee Jones
2024-06-14 9:24 ` Lee Jones
2024-06-14 12:27 ` Konstantin Ryabitsev
2024-06-14 14:26 ` Konstantin Ryabitsev
2024-06-14 14:36 ` Lee Jones
2024-06-14 14:29 ` Michael Ellerman
2024-06-14 14:38 ` Konstantin Ryabitsev
2024-06-14 14:44 ` Rafael J. Wysocki
2024-06-14 15:08 ` Geert Uytterhoeven
2024-06-15 11:29 ` Michael Ellerman
2024-06-17 10:15 ` Jani Nikula
2024-06-17 12:42 ` Geert Uytterhoeven
2024-06-14 15:45 ` Mark Brown
2024-06-14 14:43 ` Mark Brown
2024-06-14 14:51 ` Konstantin Ryabitsev
2024-06-14 15:42 ` Mark Brown
2024-06-14 14:43 ` Steven Rostedt
2024-06-14 14:57 ` Laurent Pinchart
2024-06-16 1:13 ` Linus Torvalds [this message]
2024-06-16 3:28 ` Steven Rostedt
2024-06-16 4:59 ` Linus Torvalds
2024-06-16 8:22 ` Paolo Bonzini
2024-06-16 9:05 ` Geert Uytterhoeven
2024-06-16 15:07 ` Steven Rostedt
2024-06-17 13:48 ` Dan Carpenter
2024-06-17 15:23 ` Dan Carpenter
2024-06-17 14:39 ` Konstantin Ryabitsev
2024-06-17 16:04 ` Paul E. McKenney
2024-06-17 16:06 ` Konstantin Ryabitsev
2024-06-17 16:14 ` Paolo Bonzini
2024-06-17 16:18 ` Konstantin Ryabitsev
2024-06-17 17:11 ` Geert Uytterhoeven
2024-06-18 12:05 ` Michael Ellerman
2024-06-16 7:26 ` Takashi Iwai
2024-06-16 8:10 ` Paolo Bonzini
2024-06-16 11:31 ` Laurent Pinchart
2024-06-16 11:39 ` Takashi Iwai
2024-06-16 16:40 ` Linus Torvalds
2024-06-16 8:31 ` Jiri Kosina
2024-06-16 8:54 ` Geert Uytterhoeven
2024-06-13 19:39 ` Dan Carpenter
2024-06-14 1:00 ` Steven Rostedt
2024-06-13 11:58 ` James Bottomley
2024-06-13 13:06 ` Sasha Levin
2024-06-13 13:56 ` James Bottomley
2024-06-13 14:02 ` Greg KH
2024-06-13 15:11 ` James Bottomley
2024-06-13 16:27 ` Greg KH
2024-06-14 18:47 ` Sasha Levin
2024-06-17 10:59 ` Vlastimil Babka
2024-06-13 18:08 ` Sasha Levin
2024-06-13 13:45 ` Greg KH
2024-06-13 13:40 ` Sasha Levin
2024-06-18 13:12 ` Thorsten Leemhuis
2024-06-13 14:28 ` Andrew Lunn
2024-06-13 18:14 ` Sasha Levin
2024-06-14 14:41 ` Jan Kara
2024-06-14 15:03 ` Rafael J. Wysocki
2024-06-14 17:46 ` Sasha Levin
2024-06-18 14:43 ` [MAINTAINERS SUMMIT] [0/4] Common scenario for four proposals regarding regressions James Bottomley
2024-06-18 15:50 ` Mark Brown
2024-06-20 10:32 ` Thorsten Leemhuis
2024-06-20 12:57 ` James Bottomley
2024-06-20 13:55 ` Mark Brown
2024-06-20 14:01 ` James Bottomley
2024-06-20 14:42 ` Mark Brown
2024-06-20 16:02 ` James Bottomley
2024-06-20 17:15 ` Mark Brown
2024-06-20 23:25 ` Sasha Levin
2024-06-21 6:33 ` Thorsten Leemhuis
[not found] ` <20240625175131.672d14a4@rorschach.local.home>
2024-06-26 7:36 ` Greg KH
2024-06-26 18:32 ` Steven Rostedt
2024-06-26 19:05 ` James Bottomley
2024-07-25 10:14 ` Thorsten Leemhuis
2024-07-25 13:14 ` Greg KH
2024-06-20 16:59 ` Thorsten Leemhuis
2024-06-20 23:18 ` Sasha Levin
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='CAHk-=wiD9du3fBHuLYzwUSdNgY+hxMZEWNZpqJXy-=wD2wafdg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=jack@suse.cz \
--cc=konstantin@linuxfoundation.org \
--cc=ksummit@lists.linux.dev \
--cc=linux@leemhuis.info \
--cc=mpe@ellerman.id.au \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tiwai@suse.de \
/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