Thorsten Leemhuis <linux@xxxxxxxxxxxxx> 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
