From: Jonathan Corbet <corbet@lwn.net>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] docs: submitting-patches: describe preserving review/test tags
Date: Fri, 9 Oct 2020 09:38:04 -0600 [thread overview]
Message-ID: <20201009093804.7a130063@lwn.net> (raw)
In-Reply-To: <20201007084306.12591-1-krzk@kernel.org>
On Wed, 7 Oct 2020 10:43:06 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> From time to time, the novice kernel contributors do not add Reviewed-by
> or Tested-by tags to the next versions of the patches. Mostly because
> they are unaware that responsibility of adding these tags in next
> version is on submitter, not maintainer.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> Documentation/process/submitting-patches.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 58586ffe2808..9752b6311674 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -527,6 +527,13 @@ done on the patch. Reviewed-by: tags, when supplied by reviewers known to
> understand the subject area and to perform thorough reviews, will normally
> increase the likelihood of your patch getting into the kernel.
>
> +Both Tested-by and Reviewed-by tags, once received on mailing list from tester
> +or reviewer, should be added by author to the applicable patches when sending
> +next versions. However if the patch is changed in following version, these
> +tags might not be applicable anymore and thus should be removed. Usually
> +removal of someone's Tested-by or Reviewed-by tags should be mentioned
> +in the patch changelog (after '---' separator).
after *the* "---" separator
This is a bit ambiguous, though, since the point of sending a new version
of a patch is usually that it has changed. I'm not quite sure how to best
articulate when a patch has changed enough that reviews and such are no
longer applicable... If nothing else, "if the patch *has changed
substantially*" or something like that?
Thanks,
jon
next prev parent reply other threads:[~2020-10-09 15:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 8:43 [PATCH] docs: submitting-patches: describe preserving review/test tags Krzysztof Kozlowski
2020-10-09 15:38 ` Jonathan Corbet [this message]
2020-10-12 17:18 ` Krzysztof Kozlowski
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=20201009093804.7a130063@lwn.net \
--to=corbet@lwn.net \
--cc=krzk@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+huawei@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