Message-ID: <244ed3fd-c989-497a-853b-b8894911df9e@leemhuis.info>
Date: Thu, 19 Dec 2024 12:40:08 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Kees Cook <kees@...nel.org>, Jonathan Corbet <corbet@....net>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 Geert Uytterhoeven <geert+renesas@...der.be>, regressions@...ts.linux.dev,
 workflows@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] docs: git SHA prefixes are for humans

Hi! Thx for picking this up!

On 16.12.24 02:27, Kees Cook wrote:
> Clarify that the preferred git SHA abbreviation length for the Fixes
> tag is 12 characters[1], as the tag is intended for humans (though, yes,
> it is parsed by machines too). Collision resolution needs to be performed
> using the parenthetical patch Subject that follows the abbreviated hash.
> [...] 
> diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst
> index 1f5ab49c48a4..a0e8715c6cd3 100644
> --- a/Documentation/process/handling-regressions.rst
> +++ b/Documentation/process/handling-regressions.rst
> @@ -29,9 +29,9 @@ The important bits (aka "The TL;DR")
>      * For mailed reports, check if the reporter included a line like ``#regzbot
>        introduced: v5.13..v5.14-rc1``. If not, send a reply (with the regressions
>        list in CC) containing a paragraph like the following, which tells regzbot
> -      when the issue started to happen::
> +      when the issue started to happen, preferably with a full git SHA::

How about "when the issue started to happen using an unique identifier
understood by git like the commit-id::"?

Regzbot handles tags, too. And I guess the term "commit-id" is more
common and easier to understand for non-developers than "SHA". And in
case we ever start using SHA256 sums in the kernel that maybe can just
stay as it is.

> [...]

> diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst
> index e374b67b3277..658b489705be 100644
> --- a/Documentation/process/maintainer-tip.rst
> +++ b/Documentation/process/maintainer-tip.rst
> @@ -284,7 +284,7 @@ following tag ordering scheme:
>  
>       Commit
>  
> -       abcdef012345678 ("x86/xxx: Replace foo with bar")
> +       ab0123456789 ("x86/xxx: Replace foo with bar")

Ignore the following side note, I just need to get this off my chest:

Why does that file even mention this and a lot of other stuff how to
create a proper patch description at all? We already have two documents
that explain this; a third just for one subsystem seems somewhat wrong.

But whatever. :-D

> [...]
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 1518bd57adab..efd4fb1109e9 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -163,6 +163,12 @@ An example call::
>  	$ git log -1 --pretty=fixes 54a4f0239f2e
>  	Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
>  
> +Note that the "Fixes" tag, while it does get parsed by machines, is intended
> +for humans (hence the Subject portion). It is preferred that hashes remain at
> +12 characters even in the face of prefix collisions. When encountering hash
> +prefix collisions, tools (and humans) need to resolve such collisions using
> +the parenthetical patch Subject.
> +

submitting-patches.rst to my understanding and the header of that file
is the shorter of two approaches documenting how to contribute patches.
So this text should likely go to the longer one, which is
Documentation/process/5.Posting.rst. Or both, if we consider this
important enough -- but I'd say it's not.

Ciao, Thorsten

Powered by blists - more mailing lists