Re: Fw: [PATCH 0/2] feat: checkpatch: prohibit Buglink: and warn about missing Link:

[Joe Perches]

On Tue, 2022-12-06 at 09:50 +0100, Thorsten Leemhuis wrote:
> On 06.12.22 08:44, Joe Perches wrote:
> > On Tue, 2022-12-06 at 08:17 +0100, Thorsten Leemhuis wrote:
> > > On 06.12.22 07:27, Thorsten Leemhuis wrote:
> > > > On 06.12.22 06:54, Joe Perches wrote:
> > []
> > > > > 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.
> > 
> > It's easy to add newly supported values to a list.
> > 
> > > > 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.
> > 
> > Do understand please that checkpatch will never be perfect.
> > At best, it's just a guidance tool.
> 
> Of course -- and that's actually a reason why I prefer a disallow list
> over an allow list, as that gives guidance in the way of "don't use this
> tag, use Link instead" instead of enforcing "always use Link: when
> linking somewhere" (now that I've written it like that it feels even
> more odd, because it's obvious that it's a link, so why bother with a
> tag; but whatever).
> 
> I also think the approach with a disallow list will not bother
> developers much, while the other forces them a bit to much into a scheme.
> 
> > To me most of these are in the noise level, but perhaps all should just
> > use Link:
> > 
> > $ git log -100000 --format=email -P --grep='^\w+:[ \t]*http' | \
> >   grep -Poh '^\w+:[ \t]*http' | \
> >   sort | uniq -c | sort -rn
> >  103889 Link: http
> >     415 BugLink: http
> >     372 Patchwork: http
> >     270 Closes: http
> >     221 Bug: http
> >     121 References: http
> > [...]
> 
> Ha, I considered doing something like that when I wrote my earlier mail,
> but was to lazy. :-D thx!
> 
> Yeah, they are not that often, but I grew tired arguing about that,
> that's why I think checkpatch is the better place and in the better
> position to handle that.

I'm not sure that "Patchwork:" is a reasonable prefix.
Is that documented anywhere?

> Anyway, so how to move forward now? Do you insist on a allow list (IOW:
> a Link: or Patchwork: before every http...)? Or is a disallow list with
> the most common unwanted tags for links (that you thankfully compiled)
> fine for you as well?

Maybe
---
 scripts/checkpatch.pl | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 1c3d13e65c2d0..a526a354cdfbc 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3250,6 +3250,13 @@ sub process {
 			$commit_log_possible_stack_dump = 0;
 		}
 
+# Check for odd prefixes before a URI/URL
+		if ($in_commit_log &&
+		    $line =~ /^\s*(\w+):\s*http/ && $1 !~ /^(?:Link|Patchwork)/) {
+			WARN("PREFER_LINK",
+			     "Unusual link reference '$1:', prefer 'Link:'\n" . $herecurr);
+		}
+
 # Check for lines starting with a #
 		if ($in_commit_log && $line =~ /^#/) {
 			if (WARN("COMMIT_COMMENT_SYMBOL",