[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjcYW9Kf6Yrua_+RqB32RB9aVnvwzzXEC_6sdWinA1AoQ@mail.gmail.com>
Date: Wed, 2 Apr 2025 12:52:12 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>, Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <senozhatsky@...omium.org>, John Ogness <john.ogness@...utronix.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>, Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] more printk for 6.15
On Wed, 2 Apr 2025 at 12:43, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> I would also argue that it's good for the actual ack, because it gives you
> a link back to email were it was likely acked, in case you want to confirm
> it was acked.
Let's make the rule that you can have your useless Link: tags for the
pointless patch source if you want.
IF YOU ALSO PUT THE ACTUALLY USEFUL LINKS IN THERE!
In other words - don't make me go look at the patch submission and be
disappointed.
Make the *first* link be something useful, like the *reason* for the
patch in the first place.
Then you can add your pointless noise afterwards.
Because no, "it has an actual ack" is not a good reason. Nobody cares
about the ack. The *reason* people look at the link is because
something went wrong, and you want some serious explanation for why
the patch exists.
Seeing extra "Acks" is not a reason.
Linus
Linus
Powered by blists - more mailing lists