Message ID | 20230314-doc-checkpatch-closes-tag-v3-0-d1bdcf31c71c@tessares.net |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp58695vqo; Thu, 30 Mar 2023 11:37:59 -0700 (PDT) X-Google-Smtp-Source: AKy350bfiIiLD3na1fa7muk3sXKiGeIrMH6kEVS9IFsj5po9EwUXcXVD/UvKXroqVrKJg4oUCmtc X-Received: by 2002:a17:907:72c8:b0:946:fa69:cb0 with SMTP id du8-20020a17090772c800b00946fa690cb0mr8981552ejc.29.1680201479238; Thu, 30 Mar 2023 11:37:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680201479; cv=none; d=google.com; s=arc-20160816; b=JCGP/1//EEeQr6Eos10KzkpelWS7RXzR8DSlHc2OUspPF7pYr4m+MpHRIoIPoQBfcx etgB+WzqloFinGWeTV+VlKxDKuESYWd8Bs7kWIAfWhDYF+u7U0TMRW5EJQRzp2nmP/TD A5vIFYLYZo8q0FmPPusy5e8ocNLn8mNXlJeiCPmoWC8dSxTt55sSR0Qu7k9JcfeOKezE mOwFid1EuLbZe1zo8I7WE0ttvg+m3nyO4Kck9Q0Oxrl76WF8cYYPXBfnOvheS5vbpTA8 Z3ppC6hIs3cdOyInUchP7zf3cFWdwJ5ybNFRC1eL9obmURDAmBxyCjfLeoP+VG4k68AY trbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:content-transfer-encoding:mime-version :message-id:date:subject:from:dkim-signature; bh=8rBDKsgZ0c2Ea0fhfHATR3kgGwH9tv06KM69SIB7yXs=; b=ga09n7z9f5+XxIus7/Z0Xi5b+2JIjN1Hp5vHjcaqgWX39n+VBcpTeit8/IdKR/xpDq qsBQfdXjCBrex2ogFx9thR8f/21vw9ZK07z0uv1iutT+vU6nj9io6jkZQRah5Cwf454X P9PGM33muABgQcXUE0iowkQCf5SeuuvIug1Tjx2gLNAcvLk2it4d8fdk0w+wXxgZegQt CVqnmZXE7rEncf9Cgu60JFtM4NjMNtDIujpFAy5sIB34C4QcTbdxx7NBBO5PvkaiSkXH y3zb0m1ePm6s5VqOhztogoJhj9KAEEkh1BNPV5BoIZsnAWCjjPMEkcFuRC4uVpVyMeDC oEcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tessares.net header.s=google header.b=bBsrNAMN; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=tessares.net Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n25-20020a170906b31900b008dd40fa813esi203274ejz.546.2023.03.30.11.37.33; Thu, 30 Mar 2023 11:37:59 -0700 (PDT) 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; dkim=pass header.i=@tessares.net header.s=google header.b=bBsrNAMN; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=tessares.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229898AbjC3SNt (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Thu, 30 Mar 2023 14:13:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229379AbjC3SNr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 30 Mar 2023 14:13:47 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7EA2DD314 for <linux-kernel@vger.kernel.org>; Thu, 30 Mar 2023 11:13:45 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id r29so19960385wra.13 for <linux-kernel@vger.kernel.org>; Thu, 30 Mar 2023 11:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; t=1680200024; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:from:to:cc:subject:date:message-id:reply-to; bh=8rBDKsgZ0c2Ea0fhfHATR3kgGwH9tv06KM69SIB7yXs=; b=bBsrNAMNDg2hmM1g5ZjEmgb4OtN2iPjzRQAn2q9/9UE+XsxVYH+8x3ewcsS2i1Cqqs tddFU2LH+8uz4LEejwQv6lqh2kRwiKseLyLPvzhScAjC1bntXWJijgiHsMAmNYXQ52lt yMpwvxwgZABQthiThFH0dG3QB8/iWbxFNFhhHUP/PJ6qqbI30R4RSMjVGT6dT/6YkeGs vLxjOlIgEioRIZ/9rNzkjMm4rXpjv215vNUhXMZsxXcw/Z4UPSaJ4Ofkqo5hvz5vZ1V0 ZExrnBlTPNyJrSV3TjJYMc7BLf4K1Pj+ydhxizIWYG8n7DjsyMFKRgq0vjBpEhYnhnPJ 0bIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680200024; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8rBDKsgZ0c2Ea0fhfHATR3kgGwH9tv06KM69SIB7yXs=; b=h0zz1HqyUbPlZ5pjK66kUYxWTL3RzZV278Mh0KMoCg4PHB9aixOuOa+ZpkVfSC2Jbq 6CYEPfA3woUPcH/oNjUfNhr1dDcSXW7HUboByUEUv+PWx6bKkzLp/YqIFxfciWTkXjCP VqioFCZZdWSay+VUDlfugjugIE4qpFjHOmyoUZfmTPGcRznWw8dTHkIXS1HDy4gcriaa SuhyEZ453cE2vMelQULzcWTDHrfPjXoYgYVwZ+lRLchiRJG1Dg84kp+R1+8k5cjcq9S5 od07u7hFXkeuhCgWlL/8ORof9yLopGDyR50GHmwpbq0vNniCNJtaB3VUXezQk/YMMn1w croQ== X-Gm-Message-State: AAQBX9d0Ogz1TZJH6hdex+/YQBf+ZPtuzIGawzBXhmDs+H+XpPXlrgko VxzgOc8GvSfznK6qtA7usxKbtg== X-Received: by 2002:adf:fb0d:0:b0:2e5:17a4:7d65 with SMTP id c13-20020adffb0d000000b002e517a47d65mr1582583wrr.39.1680200023887; Thu, 30 Mar 2023 11:13:43 -0700 (PDT) Received: from vdi08.nix.tessares.net (static.219.156.76.144.clients.your-server.de. [144.76.156.219]) by smtp.gmail.com with ESMTPSA id e18-20020a056000121200b002d24a188b64sm33459741wrx.112.2023.03.30.11.13.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 11:13:43 -0700 (PDT) From: Matthieu Baerts <matthieu.baerts@tessares.net> Subject: [PATCH v3 0/4] docs & checkpatch: allow Closes tags with links Date: Thu, 30 Mar 2023 20:13:22 +0200 Message-Id: <20230314-doc-checkpatch-closes-tag-v3-0-d1bdcf31c71c@tessares.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAELRJWQC/42OS67CMAxFt4IyxlAn/cAbsQ/EwEldEsFLURwqE OreSRkyYnh85XPvSwmnwKL+Vi+VeAoSxljArFfKeYpnhtAXVrrSpjJYQz86cJ7d5UbZeXDXUVg g0xmwM2ibrmlai6r8WxIGmyg6vxiuId5l+0+SOS3xLfEQHp/q46mwD5LH9PwsmXC5/lI6IVSAd meqTvOe9nTILEKJZRM5q0U86Z9lusiGmmrsdi0Obf8lm+f5DeOHyqExAQAA To: Jonathan Corbet <corbet@lwn.net>, Andy Whitcroft <apw@canonical.com>, Joe Perches <joe@perches.com>, Dwaipayan Ray <dwaipayanray1@gmail.com>, Lukas Bulwahn <lukas.bulwahn@gmail.com>, =?utf-8?q?Kai_Wasserb=C3=A4ch?= <kai@dev.carbon-project.org>, Thorsten Leemhuis <linux@leemhuis.info>, Andrew Morton <akpm@linux-foundation.org>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Konstantin Ryabitsev <konstantin@linuxfoundation.org>, Bagas Sanjaya <bagasdotme@gmail.com>, Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, mptcp@lists.linux.dev, Matthieu Baerts <matthieu.baerts@tessares.net> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3054; i=matthieu.baerts@tessares.net; h=from:subject:message-id; bh=P6AoCjPKkmZgS1nv0s1/YpaDCkuDnCn+pulVbPGi3fU=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBkJdFWd6L1EDibjVLoRL8MVbW7B74nKBeqWTkWV jLorHcm6OaJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZCXRVgAKCRD2t4JPQmmg cwnXD/9PUHGS5kFofgqXyvh4xymo63lE27hUiy16eFTdsOmc5RBXX1wJRyv+p4K3iJOs1kK7t1B 6iHAQT9+YDDdwjKgMHHUM3P6RG14+PXH3taTgL8FPWeM9CCHbWhmT7t1WF102Z4sFH4FiYfoehc PyUKmGHUnkrITvb28LN5r7wdxTqiphQIS72Ed8R+C3AfahWr9poP0GiMTrWMNPKmI70VTT2Wh7N PGvQ4io348yw80+QT3KuXkxE/cgG/5SlWYkOev8Q1QpKTcO3tvtG4anudQ+J06YSEQg4DDYXzk8 tvQaQV8k+2E9f7SqbOu0nXfUIr8RPjfAOpz901UXTs6EIdcqmxqJqS1sHlO0Chrc1YbHOZYK0Al HgtoCk31vLqtyv+p983bnY5oTRaDpoU2AAY2BujS3WKs49KcN7HIBSXvkFyOpRF2PP9BzQCc6CC zDwWuLB8p/Wk8+8fe6/Dxca0/WejYdwkZAeyH/I90tBvl/qgTyCw2EeOCyG4lB8G9aZiaYxSeum R7a3LKBY64/c6YlQiO8a157JTWFsEsmComat6PC59/RzpCoHb70KlH73dGHS2le+KPPISCoVw0d xIP2thgk9hRIAuWniP/I2vE8hEGFxtEkZ7+NhVwavemfbe+a8L/70qilEcVBuEFm0fMswWWHRzY DkeoZYcleOGd2ZQ== X-Developer-Key: i=matthieu.baerts@tessares.net; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761818946675179053?= X-GMAIL-MSGID: =?utf-8?q?1761818946675179053?= |
Series |
docs & checkpatch: allow Closes tags with links
|
|
Message
Matthieu Baerts
March 30, 2023, 6:13 p.m. UTC
Since v6.3, checkpatch.pl now complains about the use of "Closes:" tags
followed by a link [1]. It also complains if a "Reported-by:" tag is
followed by a "Closes:" one [2].
As detailed in the first patch, this "Closes:" tag is used for a bit of
time, mainly by DRM and MPTCP subsystems. It is used by some bug
trackers to automate the closure of issues when a patch is accepted.
It is even planned to use this tag with bugzilla.kernel.org [3].
The first patch updates the documentation to explain what is this
"Closes:" tag and how/when to use it. The second patch modifies
checkpatch.pl to stop complaining about it.
The DRM maintainers and their mailing list have been added in Cc as they
are probably interested by these two patches as well.
[1] https://lore.kernel.org/all/3b036087d80b8c0e07a46a1dbaaf4ad0d018f8d5.1674217480.git.linux@leemhuis.info/
[2] https://lore.kernel.org/all/bb5dfd55ea2026303ab2296f4a6df3da7dd64006.1674217480.git.linux@leemhuis.info/
[3] https://lore.kernel.org/linux-doc/20230315181205.f3av7h6owqzzw64p@meerkat.local/
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
---
Note: After having re-read the comments from the v1, it is still unclear
to me if this "Closes:" can be accepted or not. But because it seems
that the future Bugzilla bot for kernel.org and regzbot would like to
use it as well, I'm sending here new versions. I'm sorry if I
misunderstood the comments from v1. Please tell me if I did.
Changes in v3:
- Patch 1/4 now allow using the "Closes" tag with any kind of bug
reports, as long as the link is public. (Thorsten)
- The former patch 2/2 has been split in two: first to use a list for
the different "link" tags (Joe). Then to allow the 'Closes' tag.
- A new patch has been added to let checkpatch.pl checking if "Closes"
and "Links" are used with a URL.
- Link to v2: https://lore.kernel.org/r/20230314-doc-checkpatch-closes-tag-v2-0-f4a417861f6d@tessares.net
Changes in v2:
- The text on patch 1/2 has been reworked thanks to Jon, Bagas and
Thorsten. See the individual changelog on the patch for more details.
- Private bug trackers and invalid URLs are clearly marked as forbidden
to avoid being misused. (Linus)
- Rebased on top of Linus' repo.
- Link to v1: https://lore.kernel.org/r/20230314-doc-checkpatch-closes-tag-v1-0-1b83072e9a9a@tessares.net
---
Matthieu Baerts (4):
docs: process: allow Closes tags with links
checkpatch: use a list of "link" tags
checkpatch: allow Closes tags with links
checkpatch: check for misuse of the link tags
Documentation/process/5.Posting.rst | 10 +++++++
Documentation/process/submitting-patches.rst | 10 +++++++
scripts/checkpatch.pl | 43 ++++++++++++++++++++++------
3 files changed, 55 insertions(+), 8 deletions(-)
---
base-commit: ffe78bbd512166e0ef1cc4858010b128c510ed7d
change-id: 20230314-doc-checkpatch-closes-tag-1731b57556b1
Best regards,
Comments
On 30.03.23 20:13, Matthieu Baerts wrote: > Since v6.3, checkpatch.pl now complains about the use of "Closes:" tags > followed by a link [1]. It also complains if a "Reported-by:" tag is > followed by a "Closes:" one [2]. > > As detailed in the first patch, this "Closes:" tag is used for a bit of > time, mainly by DRM and MPTCP subsystems. It is used by some bug > trackers to automate the closure of issues when a patch is accepted. > It is even planned to use this tag with bugzilla.kernel.org [3]. > > The first patch updates the documentation to explain what is this > "Closes:" tag and how/when to use it. The second patch modifies > checkpatch.pl to stop complaining about it. > > The DRM maintainers and their mailing list have been added in Cc as they > are probably interested by these two patches as well. > > [1] https://lore.kernel.org/all/3b036087d80b8c0e07a46a1dbaaf4ad0d018f8d5.1674217480.git.linux@leemhuis.info/ > [2] https://lore.kernel.org/all/bb5dfd55ea2026303ab2296f4a6df3da7dd64006.1674217480.git.linux@leemhuis.info/ > [3] https://lore.kernel.org/linux-doc/20230315181205.f3av7h6owqzzw64p@meerkat.local/ > > Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Maybe it's just me, but I think those changes do not make it clear enough when to use Link: and when to use Closes. Find below an alternative proposal how I'd do it for consideration that goes 'all-in' for the sake of simplicity. [untested -- and I hope thunderbird won't mangle the patch] Ciao, Thorsten diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index 7a670a075ab6..fc194b4d1674 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -207,11 +207,17 @@ the patch:: Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID") Another tag is used for linking web pages with additional backgrounds or -details, for example a report about a bug fixed by the patch or a document +details, for example earlier discussion which lead to the patch or a document with a specification implemented by the patch:: Link: https://example.com/somewhere.html optional-other-stuff +If the URL points to a report about a bug fixed by the patch, use this instead:: + + Closes: https://example.com/somewhere.html optional-other-stuff + +Ensure any such links are publicly accessible. + Many maintainers when applying a patch also add this tag to link to the latest public review posting of the patch; often this is automatically done by tools like b4 or a git hook like the one described in @@ -251,7 +257,7 @@ The tags in common use are: - Reported-by: names a user who reported a problem which is fixed by this patch; this tag is used to give credit to the (often underappreciated) people who test our code and let us know when things do not work - correctly. Note, this tag should be followed by a Link: tag pointing to the + correctly. Note, this tag should be followed by a Closes: tag pointing to the report, unless the report is not available on the web. - Cc: the named person received a copy of the patch and had the diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 69ce64e03c70..73611cf1c372 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -126,8 +126,10 @@ For example:: Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ -Please check the link to make sure that it is actually working and points -to the relevant message. +If the URL points to a bug report that is fixed by the patch, use 'Closes:' +instead. + +Ensure any such links are publicly accessible. However, try to make your explanation understandable without external resources. In addition to giving a URL to a mailing list archive or bug, @@ -498,7 +500,7 @@ Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: The Reported-by tag gives credit to people who find bugs and report them and it hopefully inspires them to help us again in the future. The tag is intended for bugs; please do not use it to credit feature requests. The tag should be -followed by a Link: tag pointing to the report, unless the report is not +followed by a Closes: tag pointing to the report, unless the report is not available on the web. Please note that if the bug was reported in private, then ask for permission first before using the Reported-by tag. diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index bd44d12965c9..f9a7c2b856ae 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -3158,14 +3158,14 @@ sub process { } } -# check if Reported-by: is followed by a Link: +# check if Reported-by: is followed by a Closes: tag if ($sign_off =~ /^reported(?:|-and-tested)-by:$/i) { if (!defined $lines[$linenr]) { WARN("BAD_REPORTED_BY_LINK", - "Reported-by: should be immediately followed by Link: to the report\n" . $herecurr . $rawlines[$linenr] . "\n"); - } elsif ($rawlines[$linenr] !~ m{^link:\s*https?://}i) { + "Reported-by: should be immediately followed by Closes: to the report\n" . $herecurr . $rawlines[$linenr] . "\n"); + } elsif ($rawlines[$linenr] !~ m{^closes:\s*https?://}i) { WARN("BAD_REPORTED_BY_LINK", - "Reported-by: should be immediately followed by Link: with a URL to the report\n" . $herecurr . $rawlines[$linenr] . "\n"); + "Reported-by: should be immediately followed by Closes: with a URL to the report\n" . $herecurr . $rawlines[$linenr] . "\n"); } } } @@ -3266,13 +3266,13 @@ sub process { # Check for odd tags before a URI/URL if ($in_commit_log && - $line =~ /^\s*(\w+):\s*http/ && $1 ne 'Link') { + $line =~ /^\s*(\w+):\s*http/ && $1 ne 'Link' && $1 ne 'Closes') { if ($1 =~ /^v(?:ersion)?\d+/i) { WARN("COMMIT_LOG_VERSIONING", "Patch version information should be after the --- line\n" . $herecurr); } else { WARN("COMMIT_LOG_USE_LINK", - "Unknown link reference '$1:', use 'Link:' instead\n" . $herecurr); + "Unknown link reference '$1:', use 'Link:' or 'Closes:' instead\n" . $herecurr); } }
On Fri, Mar 31, 2023 at 11:39:22AM +0200, Thorsten Leemhuis wrote: > -Please check the link to make sure that it is actually working and points > -to the relevant message. > +If the URL points to a bug report that is fixed by the patch, use 'Closes:' > +instead. This is not specifically a comment about your additional diff, but this sprang to mind (again) while reading it. I have been wondering if this sort of thing will lead to inconsistency. Reports sometimes report more than one issue at once. Other times a patch that is (intentionally) not a complete fix for the problem. Using Closes: in those cases is not really true, as it does not close the report. Having a series of N patches, each of which purport to close an issue, also doesn't seem quite right. The word Closes has a meaning and "forcing" the use of Closes: for reports implies meaning that may not be present. I suppose it is true that just because documentation or checkpatch says to do something, doesn't mean that you **have** to do it but I don't want to be the one on the Rx side of a rant...
Hi Thorsten, On 31/03/2023 11:39, Thorsten Leemhuis wrote: > On 30.03.23 20:13, Matthieu Baerts wrote: >> Since v6.3, checkpatch.pl now complains about the use of "Closes:" tags >> followed by a link [1]. It also complains if a "Reported-by:" tag is >> followed by a "Closes:" one [2]. >> >> As detailed in the first patch, this "Closes:" tag is used for a bit of >> time, mainly by DRM and MPTCP subsystems. It is used by some bug >> trackers to automate the closure of issues when a patch is accepted. >> It is even planned to use this tag with bugzilla.kernel.org [3]. >> >> The first patch updates the documentation to explain what is this >> "Closes:" tag and how/when to use it. The second patch modifies >> checkpatch.pl to stop complaining about it. >> >> The DRM maintainers and their mailing list have been added in Cc as they >> are probably interested by these two patches as well. >> >> [1] https://lore.kernel.org/all/3b036087d80b8c0e07a46a1dbaaf4ad0d018f8d5.1674217480.git.linux@leemhuis.info/ >> [2] https://lore.kernel.org/all/bb5dfd55ea2026303ab2296f4a6df3da7dd64006.1674217480.git.linux@leemhuis.info/ >> [3] https://lore.kernel.org/linux-doc/20230315181205.f3av7h6owqzzw64p@meerkat.local/ >> >> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> > > Maybe it's just me, but I think those changes do not make it clear > enough when to use Link: and when to use Closes. Find below an > alternative proposal how I'd do it for consideration that goes > 'all-in' for the sake of simplicity. Thank you for the new proposition. I like your approach of forcing people to use the "Closes:" tag, I didn't think it would have been OK. I will wait a bit before sending a v4 just to get more feedback about that. The good thing with this approach is that it makes things clear. The "Closes:" tag is then no longer an alternative to "Link:" but a different tag, e.g. to be used after "Reported-by" as you did in your patch. I guess as any warnings from checkpatch.pl, it needs to be interpreted, e.g. if multiple bugs are reported in the same report as Conor mentioned. Cheers, Matt
On 31.03.23 12:08, Conor Dooley wrote: > On Fri, Mar 31, 2023 at 11:39:22AM +0200, Thorsten Leemhuis wrote: > >> -Please check the link to make sure that it is actually working and points >> -to the relevant message. >> +If the URL points to a bug report that is fixed by the patch, use 'Closes:' >> +instead. > > This is not specifically a comment about your additional diff, but this > sprang to mind (again) while reading it. > I have been wondering if this sort of thing will lead to inconsistency. > Reports sometimes report more than one issue at once. Other times a > patch that is (intentionally) not a complete fix for the problem. > Using Closes: in those cases is not really true, as it does not close > the report. > > Having a series of N patches, each of which purport to close an issue, > also doesn't seem quite right. > The word Closes has a meaning and "forcing" the use of Closes: for > reports implies meaning that may not be present. > > I suppose it is true that just because documentation or checkpatch says > to do something, doesn't mean that you **have** to do it but I don't > want to be the one on the Rx side of a rant... Yeah, maybe checkpath.pl should allow a "Link" after a "Reported-by" for cases like this, then developers could save "Closes" for the patch that addresses the last of the issues the report is about. OTOH checkpatch.pl currently just prints a warning, so developers could ignore this and do the above already now, as you say. Guess it depends on how often we expect "one report with multiple issue" to happen. Maybe this is an indicator that we are on the wrong track in general and should not do any of this and just stick to "Link:". Ciao, Thorsten