linux-kernel - Re: [PATCH v1] docs: new text on bisecting which also covers bug validation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87edd8m7l0.fsf@meer.lwn.net>
Date: Mon, 19 Feb 2024 15:07:23 -0700
From: Jonathan Corbet <corbet@....net>
To: Thorsten Leemhuis <linux@...mhuis.info>
Cc: regressions@...ts.linux.dev, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, Bagas Sanjaya <bagasdotme@...il.com>, Nathan
 Chancellor <nathan@...nel.org>
Subject: Re: [PATCH v1] docs: new text on bisecting which also covers bug
 validation

Thorsten Leemhuis <linux@...mhuis.info> writes:

> Replace the existing brief explanation on bisecting regressions with a
> text describing the whole process from beginning to end -- while also
> describing how to validate if a problem is still present in mainline.
> This "two in one" approach is possible, as checking whenever a bug is in
> mainline is one of the first steps before performing a bisection anyway
> and thus described. Due to this approach the text also works quite
> nicely in conjunction with
> Documentation/admin-guide/reporting-issues.rst, as it covers all typical
> cases where users will need to build a kernel in exactly the same order.

I have scanned over this; don't really have a time to do a detailed
reading at this point.  My overall impression is: it's useful
information, but I think we're going to overwhelm people.  I worry that
we're replacing a one-page file on how to do a bisect with a 1,900-line
beast.  I suspect there are whole classes of readers who want the new
stuff, but there are others who would be better served by something much
more terse.

I'll repeat a question I've asked before: should we create a separate
"tutorials" book for this kind of material?  I honestly think that the
readers for this kind of documentation will be a different crowd, and
everybody might be better off if we put the tutorial material in one
place where they can find it easily.

Regardless, thanks for doing this,

jon