[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87czgk8jjo.fsf@mpe.ellerman.id.au>
Date: Wed, 11 May 2022 20:12:27 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
"Michael S. Tsirkin" <mst@...hat.com>,
Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Cc: KVM list <kvm@...r.kernel.org>,
virtualization@...ts.linux-foundation.org,
Netdev <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
mie@...l.co.jp
Subject: Re: [GIT PULL] virtio: last minute fixup
Linus Torvalds <torvalds@...ux-foundation.org> writes:
> On Tue, May 10, 2022 at 5:24 AM Michael S. Tsirkin <mst@...hat.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?
>
> 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.
Some folks have been doing it since the early 2010s.
But I think it really took off after the Change-Id discussion a few
years back:
https://lore.kernel.org/all/CAHk-=whFbgy4RXG11c_=S7O-248oWmwB_aZOcWzWMVh3w7=RCw@mail.gmail.com/
Which I read as you endorsing Link: tags :)
> And then they add it all the time, whether it makes any sense or not.
For me it always makes sense, because it means I can easily go from a
commit back to the original submission. That's useful for automating
various things like replies and patchwork status updates.
It allows me to find the exact patch I applied, even if what I committed
is slightly different (due to fuzz or editing), which would be harder
with a search based approach.
It gives us a way to essentially augment the change log after the fact,
by replying to the original patch with things we didn't know at the time
of commit - eg. this patch was reverted because it caused a bug, etc.
If you follow the Link: and there's nothing useful there explaining
what motivated the change then that's a bug in the patch submission, not
the Link: tag.
Really important information should be in the change log itself, but the
space below the "---" is perfect for added context that would be too
verbose for the committed change log. And anyone can reply to the
original submission to add even more useful information.
cheers
Powered by blists - more mailing lists