On Tue, May 10, 2022 at 5:24 AM Michael S. Tsirkin <mst at 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? 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
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 at 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". > > LinusOK 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
Linus Torvalds <torvalds at linux-foundation.org> writes:> On Tue, May 10, 2022 at 5:24 AM Michael S. Tsirkin <mst at 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? > > 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 at 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
On Tue, May 10, 2022 at 11:23:11AM -0700, Linus Torvalds wrote:> And - once again - I want to complain about the "Link:" in that commit.I have to say that for me (probably for others as well) those Link tags pointing to the patch submission have quite some value: 1) First of all it is an easy proof that the patch was actually submitted somewhere for public review before it went into a maintainers tree. 2) The patch submission is often the entry point to the discussion which lead to this patch. From that email I can see what was discussed and often there is even a link to previous versions and the discussions that happened there. It helps to better understand how a patch came to be the way it is. I know this should ideally be part of the commit message, but in reality this is what I also use the link tag for. 3) When backporting a patch to a downstream kernel it often helps a lot to see the whole patch-set the change was submitted in, especially when it comes to fixes. With the Link: tag the whole submission thread is easy to find. I can stop adding them to patches if you want, but as I said, I think there is some value in them which make me want to keep them. Regards, Joerg