All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	KVM list <kvm@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	Netdev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	mie@igel.co.jp
Subject: Re: [GIT PULL] virtio: last minute fixup
Date: Thu, 12 May 2022 10:19:24 -0700	[thread overview]
Message-ID: <CAHk-=wg=jfhgTkYBtY3LPPcUP=8A2bqH_iFezwOCDivuovE41w@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wgnYGY=10sRDzXCC2bmappjBTRNNbr8owvGLEW-xuV7Vw@mail.gmail.com>

On Thu, May 12, 2022 at 10:10 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> And most definitely not just random data that can be trivially
> auto-generated after-the-fact.

Put another way: when people asked for change ID's and I said "we have
links", I by no means meant that "you can just add random worthless
links to commits".

For example, if you have a (public-facing) Gerrit system that tracks a
patch before it gets committed, BY ALL MEANS add a link to that as the
"change ID" that you tracked in Gerrit.

That's a Link: that actually adds *information*. It shows some real
history to the commit, and shows who approved it and when, and gives
you all the Gerrit background.

But a link to the email on lkml that just contains the patch and the
same commentary that was introduced into the commit? Useless garbage.
It adds no actual information.

THAT is my argument. Why do people think I'm arguing against the Link:
tag? No. I'm arguing against adding links with no relevant new
information behind them.

I don't argue against links to lore. Not at all. If those links are
about the background that caused the patch, they are great. Maybe they
are to a long thread about the original problem and how to solve it.
Thats WONDERFUL.

But here's the deal: when I look at a commit that I wonder "why is it
doing this, it seems wrong" (possibly after there's been a bug report
about it, but possibly just because I'm reviewing it as part of doing
the pull), and I see a "Link:" tag, and it just points back to the
SAME DAMN DATA that I already have in the commit, then that Link: tag
not only wasn't helpful, it was ACTIVELY DETRIMENTAL and made me waste
time and just get irritated.

And if you waste my time with useless links, why would you expect me
to be supportive of that behavior?

                      Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: KVM list <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Netdev <netdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org, mie@igel.co.jp,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: Re: [GIT PULL] virtio: last minute fixup
Date: Thu, 12 May 2022 10:19:24 -0700	[thread overview]
Message-ID: <CAHk-=wg=jfhgTkYBtY3LPPcUP=8A2bqH_iFezwOCDivuovE41w@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wgnYGY=10sRDzXCC2bmappjBTRNNbr8owvGLEW-xuV7Vw@mail.gmail.com>

On Thu, May 12, 2022 at 10:10 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> And most definitely not just random data that can be trivially
> auto-generated after-the-fact.

Put another way: when people asked for change ID's and I said "we have
links", I by no means meant that "you can just add random worthless
links to commits".

For example, if you have a (public-facing) Gerrit system that tracks a
patch before it gets committed, BY ALL MEANS add a link to that as the
"change ID" that you tracked in Gerrit.

That's a Link: that actually adds *information*. It shows some real
history to the commit, and shows who approved it and when, and gives
you all the Gerrit background.

But a link to the email on lkml that just contains the patch and the
same commentary that was introduced into the commit? Useless garbage.
It adds no actual information.

THAT is my argument. Why do people think I'm arguing against the Link:
tag? No. I'm arguing against adding links with no relevant new
information behind them.

I don't argue against links to lore. Not at all. If those links are
about the background that caused the patch, they are great. Maybe they
are to a long thread about the original problem and how to solve it.
Thats WONDERFUL.

But here's the deal: when I look at a commit that I wonder "why is it
doing this, it seems wrong" (possibly after there's been a bug report
about it, but possibly just because I'm reviewing it as part of doing
the pull), and I see a "Link:" tag, and it just points back to the
SAME DAMN DATA that I already have in the commit, then that Link: tag
not only wasn't helpful, it was ACTIVELY DETRIMENTAL and made me waste
time and just get irritated.

And if you waste my time with useless links, why would you expect me
to be supportive of that behavior?

                      Linus
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2022-05-12 17:19 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 12:23 [GIT PULL] virtio: last minute fixup Michael S. Tsirkin
2022-05-10 12:23 ` Michael S. Tsirkin
2022-05-10 18:23 ` Linus Torvalds
2022-05-10 18:23   ` Linus Torvalds
2022-05-10 23:12   ` Nathan Chancellor
2022-05-10 23:50     ` Linus Torvalds
2022-05-10 23:50       ` Linus Torvalds
2022-05-11  7:13       ` Michael S. Tsirkin
2022-05-11  7:13         ` Michael S. Tsirkin
2022-05-11 12:51       ` Konstantin Ryabitsev
2022-05-11 13:40         ` Michael Ellerman
2022-05-11 13:40           ` Michael Ellerman
2022-05-11 16:31           ` Konstantin Ryabitsev
2022-05-12  2:07             ` Theodore Ts'o
2022-05-12  2:07               ` Theodore Ts'o
2022-05-11 17:35       ` Dave Taht
2022-05-11  6:22   ` Michael S. Tsirkin
2022-05-11  6:22     ` Michael S. Tsirkin
2022-05-11 10:12   ` Michael Ellerman
2022-05-11 10:12     ` Michael Ellerman
2022-05-11 16:20     ` Linus Torvalds
2022-05-11 16:20       ` Linus Torvalds
2022-05-12 13:30       ` Michael Ellerman
2022-05-12 13:30         ` Michael Ellerman
2022-05-12 17:10         ` Linus Torvalds
2022-05-12 17:10           ` Linus Torvalds
2022-05-12 17:19           ` Linus Torvalds [this message]
2022-05-12 17:19             ` Linus Torvalds
2022-05-13 14:14             ` Eric W. Biederman
2022-05-13 14:14               ` Eric W. Biederman
2022-05-13 17:00               ` Jakub Kicinski
2022-05-16  9:03           ` Michael S. Tsirkin
2022-05-16  9:03             ` Michael S. Tsirkin
2022-05-11 12:24   ` Jörg Rödel
2022-05-11 12:24     ` Jörg Rödel
2022-05-13 12:16     ` Michael S. Tsirkin
2022-05-13 12:16       ` Michael S. Tsirkin
2022-05-10 18:31 ` pr-tracker-bot
2022-05-10 18:31   ` 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='CAHk-=wg=jfhgTkYBtY3LPPcUP=8A2bqH_iFezwOCDivuovE41w@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mie@igel.co.jp \
    --cc=mpe@ellerman.id.au \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.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 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.