workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <linux@leemhuis.info>
To: Jonathan Corbet <corbet@lwn.net>
Cc: workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	regressions@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 02/30] docs: reporting-issues: tweak the reference section intro
Date: Tue, 13 Jan 2026 15:30:37 +0100	[thread overview]
Message-ID: <acf27b9d-fe11-4650-b525-4a91d1271e25@leemhuis.info> (raw)
In-Reply-To: <87qzuontlj.fsf@trenco.lwn.net>

On 10/27/25 18:27, Jonathan Corbet wrote:
> Thorsten Leemhuis <linux@leemhuis.info> writes:
> 
>> Small improvements to the intro of the reference section.
> 
> That's a bit uninformative ... what is the purpose of these
> improvements?  That information would be especially helpful in a patch
> that simply replaces that section altogether.

Sorry, yes, of course, changes that to

"""
Fine tuning to the intro of the reference section:

 * Call the step-by-step guide what it is.
 * Reorder the links to the guides on bug reporting to first mention the
  most modern one.
 * Many small changes to streamline the text and slightly shorten it
"""

>> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
>> ---
>>  .../admin-guide/reporting-issues.rst          | 67 +++++++++----------
>>  1 file changed, 31 insertions(+), 36 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst
>> index 3bc47afaf85ea0..90b50c27c0d2b6 100644
>> --- a/Documentation/admin-guide/reporting-issues.rst
>> +++ b/Documentation/admin-guide/reporting-issues.rst
>> @@ -244,42 +244,37 @@ The reference section below explains each of these steps in more detail.
> 
> [...]
> 
>> +The step-by-step guide above outlines all the major steps in brief fashion,
>> +which usually covers everything required. But even experienced users will
>> +sometimes wonder how to actually realize some of those steps or why they are
>> +needed; there are also corner cases the guide ignores for readability. That is
>> +what the entries in this reference section are for, which provide additional
>> +information for each of the steps in the detailed guide.
>> +
>> +A few words of general advice:
>> +
>> +* The Linux kernel developers are well aware that reporting bugs to them is
>> +  more complicated and demanding than in other FLOSS projects. Quite a few
>> +  would love to make it simpler. But that would require convincing a lot of
>> +  developers to change their habits; it, furthermore, would require improvements
>> +  on several technical fronts and people that constantly take care of various
>> +  things. Nobody has stepped up to do or fund that work.
> 
> This paragraph ... essentially says "we're making it hard on you because
> kernel developers can't be bothered to work on GitHub".

/me looks puzzled
/me noticed that Jonathan is right
/me looks puzzled in a different way

> I'm not sure this paragraph is needed at all but, if
> you're going to keep it, have it at least reflect that the complexity of
> problem reporting has a lot to do with the complexity of the problem
> domain rather than developers who are stuck in their habits.

Considered dropping it, but in the end decided that I think it's wort it
and changed it to:

* The Linux developers are well aware that reporting bugs to them is
more complicated and demanding than in other FLOSS projects. Some of it
is because the kernel is different, among others due to its mail-driven
development process and because it consists mostly of drivers. Some of
it is because improving things would require work in several technical
areas and people triaging bugs –– and nobody has stepped up to do or
fund that work.

Ciao, Thorsten

  reply	other threads:[~2026-01-13 14:30 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-26 12:41 [PATCH v1 00/30] docs: reporting-issues: rework Thorsten Leemhuis
2025-10-26 12:41 ` [PATCH v1 01/30] docs: reporting-issues: mention text is best viewed rendered Thorsten Leemhuis
2025-10-27 17:18   ` Jonathan Corbet
2026-01-13 14:18     ` Thorsten Leemhuis
2025-10-27 21:19   ` Randy Dunlap
2025-10-26 12:41 ` [PATCH v1 02/30] docs: reporting-issues: tweak the reference section intro Thorsten Leemhuis
2025-10-27 17:27   ` Jonathan Corbet
2026-01-13 14:30     ` Thorsten Leemhuis [this message]
2025-10-26 12:41 ` [PATCH v1 03/30] docs: reporting-issues: add conclusion to the step-by-step guide Thorsten Leemhuis
2025-10-27 17:29   ` Jonathan Corbet
2026-01-13 14:33     ` Thorsten Leemhuis
2025-10-26 12:41 ` [PATCH v1 04/30] docs: reporting-issues: add proper appendix Thorsten Leemhuis
2025-10-27 17:38   ` Jonathan Corbet
2026-01-13 14:38     ` Thorsten Leemhuis
2025-10-26 12:41 ` [PATCH v1 05/30] docs: reporting-issues: outline why reporting is complicated Thorsten Leemhuis
2025-10-27 17:44   ` Jonathan Corbet
2026-01-13 16:07     ` Thorsten Leemhuis
2026-01-14  5:02       ` Thorsten Leemhuis
2026-01-16  9:42         ` Thorsten Leemhuis
2025-10-26 12:41 ` [PATCH v1 06/30] docs: reporting-issues: replace TLDR guide with more of an into Thorsten Leemhuis
2025-10-28 21:32   ` Jonathan Corbet
2025-10-26 12:41 ` [PATCH v1 07/30] docs: reporting-issues: explain need for fresh vanilla kernel Thorsten Leemhuis
2025-10-28 21:40   ` Jonathan Corbet
2025-10-26 12:41 ` [PATCH v1 08/30] docs: reporting-issues: add step about processing issues separately Thorsten Leemhuis
2025-10-28 21:42   ` Jonathan Corbet
2025-10-26 12:42 ` [PATCH v1 09/30] docs: reporting-issues: tell users to check the kernel log Thorsten Leemhuis
2025-10-28 21:43   ` Jonathan Corbet
2025-10-26 12:42 ` [PATCH v1 10/30] docs: reporting-issues: move 'check tainted flag' upwards Thorsten Leemhuis
2025-10-28 21:47   ` Jonathan Corbet
2025-10-26 12:42 ` [PATCH v1 11/30] docs: reporting-issues: improve first tainted check Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 12/30] docs: reporting-issues: move 'check environment' upwards Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 13/30] docs: reporting-issues: improve environment check Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 14/30] docs: reporting-issues: improve text about checking for existing issues Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 15/30] docs: reporting-issues: improve text on classifying the bug Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 16/30] docs: reporting-issues: add fast-track for regressions Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 17/30] docs: reporting-issues: move text on 'check MAINTAINERS file' upwards Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 18/30] docs: reporting-issues: improve text on looking up place to report Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 19/30] docs: reporting-issues: move text on 'check other places' upwards Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 20/30] docs: reporting-issues: improve text on check other places Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 21/30] docs: reporting-issues: improve text on backup et. al Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 22/30] docs: reporting-issues: move text on 'initial write-up' upwards Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 23/30] docs: reporting-issues: improve text on initial write-up Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 24/30] docs: reporting-issues: improve text on bug verification Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 25/30] docs: reporting-issues: improve text on non-regressions in stable Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 26/30] docs: reporting-issues: improve text on second search Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 27/30] docs: reporting-issues: make collecting files a separate step Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 28/30] docs: reporting-issues: separate steps for optimizing and submitting reports Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 29/30] docs: reporting-issues: separate steps for follow-up tasks Thorsten Leemhuis
2025-10-26 12:42 ` [PATCH v1 30/30] docs: reporting-issues: fix a few line breaks Thorsten Leemhuis
2025-10-27 17:16 ` [PATCH v1 00/30] docs: reporting-issues: rework Jonathan Corbet

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=acf27b9d-fe11-4650-b525-4a91d1271e25@leemhuis.info \
    --to=linux@leemhuis.info \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox