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]

Date: Thu, 29 Feb 2024 22:55:15 +0100
From: Vegard Nossum <vegard.nossum@...cle.com>
To: Jonathan Corbet <corbet@....net>, 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

On 19/02/2024 23:07, Jonathan Corbet wrote:
> 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.

My vote would be to include the new document "soon" (perhaps after
Petr's extensive comments have been addressed), but keep the existing,
short document around as well.

Yes, the new doc is long and perhaps overwhelming for some, but nobody
is forced to use it and its existence in the kernel documentation does
not in any way detract from the documentation as a whole.

I also think the best feedback is going to come from users attempting
to use these steps for their real regressions. Once merged, we
(Thorsten or anybody) can attempt to incorporate that feedback in
increments.

Perfect is the enemy of good, etc.

> 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.

Something I really like about the current set of books is that they are,
at least in theory, roughly divided by their target audience
(user/admin, userspace dev, kernel dev). I'd worry that "tutorials"
as a top-level book would unintentionally end up as a very mixed bag of
documents that don't have a clearly defined target audience.

So FWIW I don't think "tutorials" should be a new top-level book. Maybe
it could be its own section under admin-guide, but in that case we
should have a clear idea of what other documents we intend to move there
as well.

Also, I'm not sure if this bisection document is really even a tutorial;
I feel like tutorials aim to teach, while this document seems more like
a guide/howto or run-book. Maybe this is splitting hairs, though :-)

Vegard