mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <linux@leemhuis.info>
To: Joe Perches <joe@perches.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Kai Wasserbäch" <kai@dev.carbon-project.org>
Subject: Re: Fw: [PATCH 0/2] feat: checkpatch: prohibit Buglink: and warn about missing Link:
Date: Tue, 6 Dec 2022 08:17:35 +0100	[thread overview]
Message-ID: <d64338a1-e708-dd1f-4d9c-3b793754a8fa@leemhuis.info> (raw)
In-Reply-To: <bba95554-19a0-d548-d63c-811b229cbca0@leemhuis.info>

On 06.12.22 07:27, Thorsten Leemhuis wrote:
> On 06.12.22 06:54, Joe Perches wrote:
>> On Tue, 2022-12-06 at 05:55 +0100, Thorsten Leemhuis wrote:
>>> On 06.12.22 02:02, Joe Perches wrote:
>>>> On Mon, 2022-12-05 at 13:14 -0800, Andrew Morton wrote:
>>>>> Begin forwarded message:
>>>>>
>>>>> Date: Sun,  4 Dec 2022 12:33:37 +0100
>>>>> From: Kai Wasserbäch <kai@dev.carbon-project.org>
>>>>> To: linux-kernel@vger.kernel.org
>>>>> Cc: Andrew Morton <akpm@linux-foundation.org>, Thorsten Leemhuis <linux@leemhuis.info>
>>>>> Subject: [PATCH 0/2] feat: checkpatch: prohibit Buglink: and warn about missing Link:
>>>>>
>>>>> Thorsten Leemhuis suggested the following two changes to checkpatch, which
>>>>> I hereby humbly submit for review. Please let me know if any changes
>>>>> would be required for acceptance.
>>>> [...]
>>>>> Suggested-by: Thorsten Leemhuis <linux@leemhuis.info>
>>>>> Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
>>>>>
>>>>> Kai Wasserbäch (2):
>>>>>   feat: checkpatch: error on usage of a Buglink tag in the commit log
>>>>
>>>> Why, what's wrong with a buglink reference?
>>>
>>> Long story short: Linus doesn't like it:
>>
>> [...]
>>
>>> All of that obviously should have been in patch description. Let me
>>> resubmit that patch with all of that in there, or are you dead against
>>> this idea now?
>>
>> No, better commit description would be useful
> 
> I'll prepare something.
> 
>> and perhaps a more
>> generic, "is the thing in front of a URI/URL" a known/supported entry,
>> instead of using an known invalid test would be a better mechanism.
> 
> Are you sure about that? It's not that I disagree completely, but it
> sounds overly restrictive to me and makes it harder for new tags to
> evolve in case we might want them.
> 
> And what tags would be on this allow-list? Anything else then "Link" and
> "Patchwork"? Those are the ones that looked common and valid to me when
> I ran
> 
> git log --grep='http' v4.0.. | grep http | grep -v '    Link: ' | less
> 
> and skimmed the output. Maybe "Datasheet" should be allowed, too -- not
> sure.
> 
> But I found a few others that likely should be on the disallow list:
> "Closes:", "Bug:", "Gitlab issue:", "References:", "Ref:", "Bugzilla:",
> "RHBZ:", and "link", as "Link" should be used instead in all of these
> cases afaics.
> 
>>>>>   feat: checkpatch: Warn about Reported-by: not being followed by a
>>>>>     Link:
>>>>
>>>> I think this is unnecessary.
>>>
>>> I expect this to cause more discussion, which is why this should be in a
>>> separate submission. But in the end the reasons are similar as above:
>>> (1) Linus really want to see those links to make things easier for
>>> future code archeologists. (2) My regression tracking efforts heavily
>>> rely on those Links, as they allow to automatically connect reports with
>>> patches and commits to fix the reported regression; without those the
>>> tracking is a PITA and doesn't scale.
>>>
>>> Together that IMHO is strong enough reason to warn in this case.
>>
>> Maybe, I think there might be some value in not intermixing signature
>> tags and other tags though.
> 
> Hmm, sorry, not sure if I understood you here. Why do you consider
> "Reported-by:" a signature tag? Isn't it more of an "appreciation" tag,
> IOW, a kind of 'thank you' hat tip to the reporter?

Sorry, now I understand[1]: you consider "Reported-by:" a signature tag
as it's used in the area where the Signed-off-by resist.

Well, yeah, maybe it shouldn't be like that[2]. But it's quite normal
afaics to use Reported-by: (with and without Link:) in that area
currently. Changing that would break habits of many kernel developers.
And having the Reported-by: and the Link: next to each other IMHO is
important, as it makes it obvious what the Link is about; that's afaics
also why Linus wants it that way, as can be seen from the quotes I
provided earlier. See also commit 0ba09b173387 from a few days ago[3],
where he afaics added the Link tags to reports of that regression himself.

Ciao, Thorsten

[1] Kai (many thx!) explained and pointed me to the area in the
checkpatch.pl code that made it obvious:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl#n611

[2] in an ideal world things like that and tags like Tested-by: would
resist in git notes or something, as then they could be extended after a
change was committed...

[3] https://git.kernel.org/torvalds/c/0ba09b173387

  reply	other threads:[~2022-12-06  7:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20221205131424.36909375d90d5a40cd028bc0@linux-foundation.org>
2022-12-06  1:02 ` Joe Perches
2022-12-06  1:19   ` Joe Perches
2022-12-06  4:55   ` Thorsten Leemhuis
2022-12-06  5:54     ` Joe Perches
2022-12-06  6:27       ` Thorsten Leemhuis
2022-12-06  7:17         ` Thorsten Leemhuis [this message]
2022-12-06  7:44           ` Joe Perches
2022-12-06  8:50             ` Thorsten Leemhuis
2022-12-06  9:21               ` Joe Perches
2022-12-06 10:06                 ` Thorsten Leemhuis
2022-12-06 10:58                   ` Joe Perches
2022-12-08 13:18                 ` Thorsten Leemhuis
2022-12-08 17:22                   ` Joe Perches

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=d64338a1-e708-dd1f-4d9c-3b793754a8fa@leemhuis.info \
    --to=linux@leemhuis.info \
    --cc=akpm@linux-foundation.org \
    --cc=joe@perches.com \
    --cc=kai@dev.carbon-project.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®