From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Linus Torvalds <torvalds@linuxfoundation.org>,
tools@linux.kernel.org, users@linux.kernel.org
Subject: Re: b4-0.9.0 available
Date: Tue, 21 Jun 2022 21:50:18 +0200 [thread overview]
Message-ID: <YrIg+vV8YMVrhHME@zx2c4.com> (raw)
In-Reply-To: <CAMuHMdU1EZ9vwyOec6EKGaW=Ghy_p5D0dbcun24BqoSok6maLQ@mail.gmail.com>
Hi Geert,
On Tue, Jun 21, 2022 at 09:43:41PM +0200, Geert Uytterhoeven wrote:
> I disagree: when bisecting a bug, I can just follow the Link: tag,
> and check if anyone already replied there with a newer review or
> bug report (and hopefully with a fix, too).
> Without the Link: tag, it's sometimes surprisingly difficult to find
> out where the patch has been posted and discussed before.
Linus spelled this out pretty clearly last week I thought:
https://lore.kernel.org/all/CAHk-=wgzRUT1fBpuz3xcN+YdsX0SxqOzHWRtj0ReHpUBb5TKbA@mail.gmail.com/
> Honestly, I still think that patch submission link should probably
> just not exist at all.
>
> Are there other links that might be worthwhilte?
>
> Yes: if people want to make patch submission give more information,
> then I think b4 should encourage taking the *COVER*LETTER* and make it
> into a merge commit, and at that point it's probably worth having the
> link to the patch series in that merge commit.
>
> Because then maybe you get discussion about the whole series, which is
> more likely to be interesting and worthwhile.
>
> There really is a big difference between "data" and "information". I
> think some per-patch link to a random patch submission that is just
> the same thing as the commit is worthless ("data"), but something
> higher-level may actually give you something useful ("information").
This seems spot on. So much so, that it used to be that when there was a
link in kernel commits, I'd middle click and read. But now it's usually
just crap that doesn't add anything, and so it wastes time and obscures
the good information when it actually is there, since I grow wary of
clicking. I spend a lot of time reading random commits, and this is an
annoyance.
On the contrary, the thing you want is a service where you paste a
commit and you get a LKML thread. That sounds like something lore could
grow, or any other service that has that database handy. And it could do
it *better* too, since it could show multiple matches sorted by
relevance and matching distance to the actual git patch. This will be so
much better than polluting the human-written git commit log with
automated stuff.
Jason
next prev parent reply other threads:[~2022-06-21 19:50 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 19:01 b4-0.9.0 available Konstantin Ryabitsev
2022-06-20 8:40 ` Geert Uytterhoeven
2022-06-21 23:38 ` Linus Walleij
2022-06-22 5:49 ` Vinod Koul
2022-06-21 15:20 ` Geert Uytterhoeven
2022-06-21 15:29 ` Konstantin Ryabitsev
2022-06-21 15:41 ` Geert Uytterhoeven
2022-06-21 15:55 ` Linus Torvalds
2022-06-21 16:03 ` Jason A. Donenfeld
2022-06-21 16:59 ` Konstantin Ryabitsev
2022-06-21 17:49 ` Jason A. Donenfeld
2022-06-21 18:29 ` Konstantin Ryabitsev
2022-06-21 18:45 ` Jason A. Donenfeld
2022-06-21 19:27 ` Konstantin Ryabitsev
2022-06-21 19:42 ` Jason A. Donenfeld
2022-06-21 19:43 ` Geert Uytterhoeven
2022-06-21 19:50 ` Jason A. Donenfeld [this message]
2022-06-21 20:06 ` Konstantin Ryabitsev
2022-06-21 20:29 ` Jason A. Donenfeld
2022-06-21 21:25 ` Bjorn Andersson
2022-06-23 23:33 ` Theodore Ts'o
2022-06-24 13:51 ` Jason Gunthorpe
2022-06-24 15:29 ` Theodore Ts'o
2022-06-24 15:34 ` Mark Brown
2022-06-24 16:05 ` Theodore Ts'o
2022-06-24 15:52 ` Konstantin Ryabitsev
2022-06-24 16:05 ` James Bottomley
2022-06-24 16:16 ` Konstantin Ryabitsev
2022-06-24 16:29 ` James Bottomley
2022-06-24 16:06 ` Jason Gunthorpe
2022-06-24 16:16 ` Mark Brown
2022-06-24 17:51 ` Chuck Lever
2022-06-24 8:34 ` Nicolas Ferre
2022-06-21 15:53 ` Jason A. Donenfeld
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=YrIg+vV8YMVrhHME@zx2c4.com \
--to=jason@zx2c4.com \
--cc=geert@linux-m68k.org \
--cc=konstantin@linuxfoundation.org \
--cc=tools@linux.kernel.org \
--cc=torvalds@linuxfoundation.org \
--cc=users@linux.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.