All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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: Wed, 11 May 2022 02:22:58 -0400	[thread overview]
Message-ID: <20220511021608-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAHk-=wjPR+bj7P1O=MAQWXp0Mx2hHuNQ1acn6gS+mRo_kbo5Lg@mail.gmail.com>

On Tue, May 10, 2022 at 11:23:11AM -0700, Linus Torvalds wrote:
> On Tue, May 10, 2022 at 5:24 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > A last minute fixup of the transitional ID numbers.
> > Important to get these right - if users start to depend on the
> > wrong ones they are very hard to fix.
> 
> Hmm. I've pulled this, but those numbers aren't exactly "new".
> 
> They've been that way since 5.14, so what makes you think people
> haven't already started depending on them?

Yes they have been in the header but they are not used by *Linux* yet.
My worry is for when we start using them and then someone backports
the patches without backporting the macro fix.
Maybe we should just drop these until there's a user, but I am
a bit wary of a step like this so late in the cycle.

> And - once again - I want to complain about the "Link:" in that commit.
> 
> It points to a completely useless patch submission. It doesn't point
> to anything useful at all.
> 
> I think it's a disease that likely comes from "b4", and people decided
> that "hey, I can use the -l parameter to add that Link: field", and it
> looks better that way.
> 
> And then they add it all the time, whether it makes any sense or not.
> 
> I've mainly noticed it with the -tip tree, but maybe that's just
> because I've happened to look at it.
> 
> I really hate those worthless links that basically add zero actual
> information to the commit.
> 
> The "Link" field is for _useful_ links. Not "let's add a link just
> because we can".
> 
>                            Linus


OK I will stop doing this.
I thought they are handy for when there are several versions of the
patch. It helps me make sure I applied the latest one. Saving the
message ID of the original mail in some other way would also be ok.
Any suggestions for a better way to do this?

-- 
MST


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: KVM list <kvm@vger.kernel.org>, 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: Wed, 11 May 2022 02:22:58 -0400	[thread overview]
Message-ID: <20220511021608-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAHk-=wjPR+bj7P1O=MAQWXp0Mx2hHuNQ1acn6gS+mRo_kbo5Lg@mail.gmail.com>

On Tue, May 10, 2022 at 11:23:11AM -0700, Linus Torvalds wrote:
> On Tue, May 10, 2022 at 5:24 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > A last minute fixup of the transitional ID numbers.
> > Important to get these right - if users start to depend on the
> > wrong ones they are very hard to fix.
> 
> Hmm. I've pulled this, but those numbers aren't exactly "new".
> 
> They've been that way since 5.14, so what makes you think people
> haven't already started depending on them?

Yes they have been in the header but they are not used by *Linux* yet.
My worry is for when we start using them and then someone backports
the patches without backporting the macro fix.
Maybe we should just drop these until there's a user, but I am
a bit wary of a step like this so late in the cycle.

> And - once again - I want to complain about the "Link:" in that commit.
> 
> It points to a completely useless patch submission. It doesn't point
> to anything useful at all.
> 
> I think it's a disease that likely comes from "b4", and people decided
> that "hey, I can use the -l parameter to add that Link: field", and it
> looks better that way.
> 
> And then they add it all the time, whether it makes any sense or not.
> 
> I've mainly noticed it with the -tip tree, but maybe that's just
> because I've happened to look at it.
> 
> I really hate those worthless links that basically add zero actual
> information to the commit.
> 
> The "Link" field is for _useful_ links. Not "let's add a link just
> because we can".
> 
>                            Linus


OK I will stop doing this.
I thought they are handy for when there are several versions of the
patch. It helps me make sure I applied the latest one. Saving the
message ID of the original mail in some other way would also be ok.
Any suggestions for a better way to do this?

-- 
MST

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

  parent reply	other threads:[~2022-05-11  6:23 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 [this message]
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
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=20220511021608-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mie@igel.co.jp \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.