Re: More detailed text about bisecting Linux kernel regression -- request for comments and help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24.01.24 13:19, Thorsten Leemhuis wrote:
> Hi! Find below a WIP text on bisecting Linux kernel regressions I plan
> to submit for inclusion in the Linux kernel documentation in a month or
> two. I could do so now, but chose to write this mail instead, as the
> text would really benefit from a few people actually testing the given
> instructions. Hence if you notice somebody that faces a regression that
> needs bisecting, consider poiting them them to this text, asking them to
> play through this and provide feedback to me.
> 
> Ideally point users to the following rendered version:
> https://www.leemhuis.info/files/misc/How%20to%20bisect%20a%20Linux%20kernel%20regression%20%e2%80%94%20The%20Linux%20Kernel%20documentation.html
> 
> It is (a) a lot easier to read (b) has no odd or broken line breaks,
> like the text below has a few (sorry!) (c) is updated when I improve
> something.
> 
> Anyone who might be willing to provide feedback can do so in a reply
> here or by modifying the following document (which for copyright reasons
> is just a copy of the document I use to prepared the text for the actual
> submission):
> https://docs.google.com/document/d/1Im7SPK0j6PUGQTSGZyCTSQv8h3S51EYsZuRRdyhfzto/edit?usp=sharing

TWIMC, I changed a few important things since I wrote above mail. The
most important parts:

* I switched the default flow from "use a shallow clone of linux-stable"
 to "use a full clone of linux-mainline with stable added as remote";
the instructions for shallow clones are now in the reference section, as
it seems that was was some people prefer. Not really happy with that, as
I think the shallow clone stuff was worth it and not that much more
complicated. But whatever, not really unhappy either (maybe I like it a
bit better myself that way, not sure yet). :-D

* I changed a few aspects to make the text properly cover the "verify a
bug is present in mainline" aspect as well, as that's basically the
preparation and segment 1 of the whole process anyway. Not totally sure
if that was a good idea. Maybe having that in a separate copy might have
been better (basically a copy with the segment 2 and 3 removed and a few
small changes), not sure. But that should be easy to realize later.

See above links for details.

Ciao, Thorsten




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux