Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6955844rwb; Mon, 5 Dec 2022 21:56:39 -0800 (PST) X-Google-Smtp-Source: AA0mqf5BIKDAB8PYWAVAdO52i9AAtq6h8CknizexDD4UlbdwYAf+9J2kobuWGe2uJrp6puncVHti X-Received: by 2002:a05:6a00:2883:b0:572:7b49:4f47 with SMTP id ch3-20020a056a00288300b005727b494f47mr70344106pfb.16.1670306198897; Mon, 05 Dec 2022 21:56:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670306198; cv=none; d=google.com; s=arc-20160816; b=Grr078aDHSBXAq1SDUTKZmSFwyGhxdCNVVFhwfCupyxtOB/Wn7fTj3m2kRwujp9CA5 khwnUVLbmq+9+vwhEf3h/auaHoussGjj/NRqsXOqYMqtID15VcKmFF1y4gFNdqRilvII v+tghE9ZuI4FkgViVB0TG34THCsJbzQuZHuNsjvd8LsEiy9JYyQpK0IaGnl9tOF/ZXvM n9pMCSoml/CoeUP9qcRzWTLFc+ANl0G3r0nBbw92sIlUde0nqZEgviesOPK1gJ1UGetU lM4Zj6cJRB9zp1vghVfv4FNrhIPkGJmpugQoGFpT8aLtLMO4RyK1jq0cu6yPuF3ll+55 Au+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id; bh=U5i15t53q4dESQViTdTm9m8WQcXb8gdCTIsH1RRVJbU=; b=AueRyP63URvMjiSl4Wk4xISOkzVP33QU1/iwBS8/CFKGJxvNveMj5nSPAnwObydtlG rUNjGIZKglie8nSBZUspYM2owUPc5LeWMcLEKO2zlfBmAoR2KsdkNxnHNFkBo2T+g/Kf NysGCVxUgWxn+kEPUsbPSG2GF+jn2EtzWY/VvHOxk5viZQX4knoxVoOAVO3BVFsMt+vG dB0ulYrZBRlNxsMNqCuYfxwo0FCTtLxPyCSrnSETxMX28H4kW951nmJmf1vfV40NYbJC O3YyUDzmCAl84uls2m14bCW5+7GKN42MdAED2a0aPMrdk5JCocq5Pb/Gibcq0h5A270k 0OKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b7-20020a656687000000b004789976b13csi9046339pgw.254.2022.12.05.21.56.28; Mon, 05 Dec 2022 21:56:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233844AbiLFFyi convert rfc822-to-8bit (ORCPT + 79 others); Tue, 6 Dec 2022 00:54:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233849AbiLFFyU (ORCPT ); Tue, 6 Dec 2022 00:54:20 -0500 Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B653275C1 for ; Mon, 5 Dec 2022 21:54:16 -0800 (PST) Received: from omf12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DCDACC09FE; Tue, 6 Dec 2022 05:54:15 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf12.hostedemail.com (Postfix) with ESMTPA id DEEBF18; Tue, 6 Dec 2022 05:54:13 +0000 (UTC) Message-ID: <23a61dd072ee1d2cc5b54281b0a9dc13e01aa0b8.camel@perches.com> Subject: Re: Fw: [PATCH 0/2] feat: checkpatch: prohibit Buglink: and warn about missing Link: From: Joe Perches To: Thorsten Leemhuis Cc: LKML , Andrew Morton , Kai =?ISO-8859-1?Q?Wasserb=E4ch?= Date: Mon, 05 Dec 2022 21:54:13 -0800 In-Reply-To: <25f4838b-208a-cf8c-914c-b2092665d56f@leemhuis.info> References: <20221205131424.36909375d90d5a40cd028bc0@linux-foundation.org> <11a9fe60f5333a931b8d75f67808b6d923c16dfa.camel@perches.com> <25f4838b-208a-cf8c-914c-b2092665d56f@leemhuis.info> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 X-Rspamd-Queue-Id: DEEBF18 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_SPF_HELO, KHOP_HELO_FCRDNS,SPF_HELO_PASS,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Rspamd-Server: rspamout01 X-Stat-Signature: mjsx31x6rtq6pujqnyhaqkf4yee5oiag X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX19rKO3gGkxEMRatNNSkA9mA1lYurhuvi8g= X-HE-Tag: 1670306053-807855 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2022-12-06 at 05:55 +0100, Thorsten Leemhuis wrote: > Hi Joe! Many thx for looking into this. > > 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 > > > To: linux-kernel@vger.kernel.org > > > Cc: Andrew Morton , Thorsten Leemhuis > > > 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 > > > Signed-off-by: Kai Wasserb?ch > > > > > > 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: > > ``` > > > BugLink: https://lore.kernel.org/r/20220610205038.GA3050413@paulmck-ThinkPad-P17-Gen-1 > > > BugLink: https://lore.kernel.org/r/CAMdYzYpF4FNTBPZsEFeWRuEwSies36QM_As8osPWZSr2q-viEA@mail.gmail.com > > [...] > > please stop making up random tags that make no sense. > > > > Just use "Link:" > > [...] > > > > It's extra context to the commit, in case somebody wants to know the > > history. The "bug" part is (and always should be) already explained in > > the commit message, there's absolutely no point in adding soem extra > > noise to the "Link:" tag.> > ``` > That's a quote from > https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/ > > In that message he also links to another mail from him, where he wrote: > ``` > > I think "BugLink:" is silly, because that's just a regular link. > > What's the upside of saying "Bug" in there? If you're fixing a bug, > > and are linking to reports and discussions by people, what does that > > "bug" buy you apart from another ugly CamelCase thing? > > > > In other words, in "BugLink:", neither "Bug" nor "Link" is actually meaningful. > > > > The current "Link:" tag exists AS A GENERIC WAY TO SAY "look, here's > > more information". That's the point. The word "Link" has no other > > meaning, and trying to then combine it with other things is worthless. > ``` > https://lore.kernel.org/all/CAHk-=wgzRUT1fBpuz3xcN+YdsX0SxqOzHWRtj0ReHpUBb5TKbA@mail.gmail.com/ > > Our docs say to use Link in this case, too; see > Documentation/process/submitting-patches.rst > (http://docs.kernel.org/process/submitting-patches.html) and > Documentation/process/5.Posting.rst > (https://docs.kernel.org/process/5.Posting.html) > > And using various tags for the same thing makes it also harder for > external scripts that look at commits to take further action -- like the > regression tracking bot I write and use for my work. > > 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 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. > > > 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.