[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <680ab492-8ffb-46a6-ab76-06605954308d@leemhuis.info>
Date: Mon, 5 Feb 2024 09:32:34 +0100
From: "Linux regression tracking (Thorsten Leemhuis)"
<regressions@...mhuis.info>
To: Linux kernel regressions list <regressions@...ts.linux.dev>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Jonathan Corbet <corbet@....net>,
Bagas Sanjaya <bagasdotme@...il.com>, Greg KH <gregkh@...uxfoundation.org>,
Jani Nikula <jani.nikula@...ux.intel.com>
Subject: Re: More detailed text about bisecting Linux kernel regression --
request for comments and help
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
Powered by blists - more mailing lists