All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Submitting Co-Author <sub@coauthor.example.org>
Subject: Re: [PATCH] docs: submitting-patches: Introduce Test: tag
Date: Sat, 07 Oct 2023 06:57:03 -0600	[thread overview]
Message-ID: <8734ymvbds.fsf@meer.lwn.net> (raw)
In-Reply-To: <20231007-topic-test_tag-v1-1-513cd9e577ed@linaro.org>

Konrad Dybcio <konrad.dybcio@linaro.org> writes:

> Currently, we blindly trust the submitters that they both compiled their
> code at all, tested it on a relevant device, and have done so in a manner
> that made sense for a given changeset.
>
> If at least two of these three things were always true, the review
> workflow would be much more exciting.
>
> Introduce a new Test: tag to help submitters express the way the patch
> was tested, making it easier to understand for reviewers and maintainers
> whether it was tested, and if so, whether that test was sufficient.
>
> I originally found something like this on Google's Android kernel repos
> and loved the concept.
>
> Test: make htmldocs and manual examination
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
>  Documentation/process/submitting-patches.rst | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)

Do we really want to do this?  To me, it almost seems like it codifies
the idea that sending *untested* patches is OK as long as you leave out
the tag.

Others may disagree, but I don't think we need yet another tag for this.
Testing of patches before sending them should be the norm; if special
notes about testing are needed, they can go in or below the changelog,
as appropriate.

Thanks,

jon

  reply	other threads:[~2023-10-07 12:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-07  0:43 [PATCH] docs: submitting-patches: Introduce Test: tag Konrad Dybcio
2023-10-07 12:57 ` Jonathan Corbet [this message]
2023-10-08 17:18   ` Geert Uytterhoeven
2023-10-09 10:14     ` Konrad Dybcio

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=8734ymvbds.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=andersson@kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=sub@coauthor.example.org \
    --cc=workflows@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.