From: Sean Christopherson <seanjc@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] more printk for 6.15
Date: Wed, 2 Apr 2025 13:00:20 -0700 [thread overview]
Message-ID: <Z-2XVMOJXUjVYXV0@google.com> (raw)
In-Reply-To: <CAHk-=wgWT4AOFgMxSBVqYD9dVPXTr775UAwyX9cUOz=0ahf3_Q@mail.gmail.com>
On Wed, Apr 02, 2025, Linus Torvalds wrote:
> On Wed, 2 Apr 2025 at 12:07, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > The whole "link to original submission" is garbage.
>
> Just to clarify: people should link to the *problem* report. Or to the
> *debugging* thread.
>
> But linking to the final result is pointless. That's what in the tree,
> and any subsequent discussion about it is stale and late.
It's not pointless noise to everyone.
For people that come across the commit after the fact, which may be years down
the road, e.g. when doing git archaeology, having an explicit link to *something*
is extremely valuable. The final submission may not have the full context, but
more often than not there are links and references to threads that do provide
additional context. At the very least, it's a starting point for the hunt.
"just Google it" does work most of the time, but search engines won't help all
that much if the maintainer massaged the shortlog and/or changelog, especially
if the surgery done when applying is significant. And if the source patch was
never posted to a public list, lack of a source Link is a hint that trying to
find the source/context may be futile.
Linking to source of the commit also provides a paper trail that can be used to
audit the final result. As a maintainer, I've used the link to verify that I
actually applied the version I intended to apply.
E.g. with zero a priori knowledge of the situation, it was trivially easy for me
to verify that Thomas' goof[*] with the irq/msi series was due to v2 getting
applied instead of v4, thanks to the Links in the buggy commits.
I can appreciate that in your role, a Link to the source patch is a false positive
more often than not. But isn't that a problem with the tag being ambiguous? I
assume it's not the mere presense of the line in the changelog that's most
frustrating, it's the wasted time and crushing disappointment of following the
link and finding nothing useful.
So rather than trash the convention entirely and risk throwing out the baby with
the bath water, what if we tweak the convention to use a dedicated tag, a la
Closes? E.g. Source or something. If b4 implements the new tag, it shouldn't be
too hard to get maintainers to follow suit. Then you can quickly gloss over the
tag and mutter about its uselessness as you do so, and us plebs can continue
reveling in the joy of our source links.
[*] https://lkml.kernel.org/r/20250319104921.201434198%40linutronix.de
next prev parent reply other threads:[~2025-04-02 20:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 12:58 [GIT PULL] more printk for 6.15 Petr Mladek
2025-04-02 17:12 ` Linus Torvalds
2025-04-02 18:39 ` Andy Shevchenko
2025-04-02 19:06 ` Linus Torvalds
2025-04-02 19:25 ` Andy Shevchenko
2025-04-02 20:34 ` Nathan Chancellor
2025-04-03 12:07 ` Andy Shevchenko
2025-04-04 8:19 ` Petr Mladek
2025-04-04 21:02 ` Nathan Chancellor
2025-04-03 16:14 ` Kees Cook
2025-04-02 19:07 ` Linus Torvalds
2025-04-02 19:10 ` Linus Torvalds
2025-04-02 19:44 ` Steven Rostedt
2025-04-02 19:52 ` Linus Torvalds
2025-04-02 20:25 ` Andy Shevchenko
2025-04-02 20:00 ` Sean Christopherson [this message]
2025-04-02 20:11 ` Steven Rostedt
2025-04-03 9:34 ` Petr Mladek
2025-04-02 17:48 ` pr-tracker-bot
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=Z-2XVMOJXUjVYXV0@google.com \
--to=seanjc@google.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=torvalds@linux-foundation.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