Message-ID: <20250402154435.5b0aad22@gandalf.local.home>
Date: Wed, 2 Apr 2025 15:44:35 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>, Petr Mladek
 <pmladek@...e.com>, Sergey Senozhatsky <senozhatsky@...omium.org>, John
 Ogness <john.ogness@...utronix.de>, Andy Shevchenko
 <andriy.shevchenko@...ux.intel.com>, Rasmus Villemoes
 <linux@...musvillemoes.dk>, Peter Zijlstra <peterz@...radead.org>,
 linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] more printk for 6.15

On Wed, 2 Apr 2025 12:10:08 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> People sometimes argue that it's good for belated Ack's etc. But
> Christ - they are *belated*.

I would also argue that it's good for the actual ack, because it gives you
a link back to email were it was likely acked, in case you want to confirm
it was acked.

Also, it's a case to prove Cc's, as there's been times that I've seen
someone add a "Cc:" to the commit log but not actually Cc the person in the
email!

My scripts do add the link back to the submission, but I also make it a
point to separate out Link: tags that hold actual discussions that happened
outside the patch submission.

For example, my last patch post had:

    ring-buffer: Use flush_kernel_vmap_range() over flush_dcache_folio()
    
    Some architectures do not have data cache coherency between user and
    kernel space. For these architectures, the cache needs to be flushed on
    both the kernel and user addresses so that user space can see the updates
    the kernel has made.
    
    Instead of using flush_dcache_folio() and playing with virt_to_folio()
    within the call to that function, use flush_kernel_vmap_range() which
    takes the virtual address and does the work for those architectures that
    need it.
    
    This also fixes a bug where the flush of the reader page only flushed one
    page. If the sub-buffer order is 1 or more, where the sub-buffer size
    would be greater than a page, it would miss the rest of the sub-buffer
    content, as the "reader page" is not just a page, but the size of a
    sub-buffer.
    
    Link: https://lore.kernel.org/all/CAG48ez3w0my4Rwttbc5tEbNsme6tc0mrSN95thjXUFaJ3aQ6SA@mail.gmail.com/
    
    Cc: stable@...r.kernel.org
>   Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>   Cc: Masami Hiramatsu <mhiramat@...nel.org>
>   Cc: Mark Rutland <mark.rutland@....com>
>   Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
>   Cc: Andrew Morton <akpm@...ux-foundation.org>
>   Cc: Vincent Donnefort <vdonnefort@...gle.com>
>   Cc: Vlastimil Babka <vbabka@...e.cz>
>   Cc: Mike Rapoport <rppt@...nel.org>
>   Link: https://lore.kernel.org/20250402144953.920792197@goodmis.org
    Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions");
    Suggested-by: Jann Horn <jannh@...gle.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.org>

The above ">" lines are added by my scripts. The top Link: is the
discussion (which I keep separate as it is easy to see and is used for
people wanting to see the discussion that was not part of the submission)
where as the bottom Link points to the patch submission which sometimes
also includes the discussion. That is, the Link that is above the other
tags is to the discussion that was likely what was the reason for this
patch to be created.

One case where this is also useful for my work flow, is that when I do a
new version, I will use that bottom link to cut and paste it in my
submission of the second version, by changing it to:

  Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.org>
  ---
  Change since v5: https://lore.kernel.org/linux-trace-kernel/20250401225842.261475465@goodmis.org/

  - Use %pa instead of %lx for start and size sizes (Mike Rapoport)


Where I moved the bottom Link from patch v5 below the "---" and added the
Changes since v5: with that link to v5. Now, if you go from the git Link to
the submission, you also get a link to the previous version, which probably
has a discussion on why it was changed. And that link has a link to the
previous submission from that.

Hence, the Link tags hold the chain to get you to every version of the
patch. In a lot of the cases, the earlier versions have the discussions.

Note, for patch series, I sometimes do not have the individual patches
have the link back to the previous version, but I make sure the cover
letter does have the link back to the previous version.

In practice, I have found this very useful and has given me the history of
the change that landed in git.

Automating the Link tags and making sure every new version has a link to
the previous version will likely take you to the discussions to why the
patch was written the way it was written.

-- Steve

Powered by blists - more mailing lists