Message-ID: <5cfc34c7-8298-4639-bb81-8b95392279ba@leemhuis.info>
Date: Thu, 25 Jan 2024 11:28:30 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Jani Nikula <jani.nikula@...ux.intel.com>,
 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>
Subject: Re: More detailed text about bisecting Linux kernel regression --
 request for comments and help

On 25.01.24 10:36, Jani Nikula wrote:
> On Wed, 24 Jan 2024, Thorsten Leemhuis <linux@...mhuis.info> 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
> 
> Hi Thorsten, first of all, thanks for doing this. I think it'll be good
> to have a document on kernel bisection to point people at.

Thx for saying that and also thx for taking a look and providing feedback!

> The one thing I find problematic is the use of shallow clones by default

FWIW, some of what is in that text is a result of similar discussion
that happened when
Documentation/admin-guide/quickly-build-trimmed-linux.rst was submitted
about a year ago, which also uses shallow clones by default.

Further a quick reminder, as it's easy to forget: most of us live in
areas where downloading a lot of data is not something that bothers us
or will take a lot of time. But it is different for some people that
will need this document.

Out of curiosity I just gave it a rough try with my 100 MBit (aka
neither-slow-nor-fast) connection.

Shallow clone:
 246.67 MiB, 0m48,015s

Deepening the shallow clone to v5.18 while adding linux-6.1.y:
 171.79 MiB, 1m47,510s

Full torvalds clone (just for completeness):
 2.77 GiB, 7m36,892s

Full stable clone:
 4.82 GiB, 12m12,093s

(reminder, those are just rough numbers, nothing else that was using the
connection much was going on, but this was not a lab setup!)

> and, well, the use of git in ways that I myself can't figure out without
> resorting to the man pages. I think it's a lot of dark corners of git
> that's overwhelming and really unrelated to the bisection itself.
> 
> If I point people at that, and they have problems, I'm just going to
> tell them to:
> 
>   git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>   cd linux
>   git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>   git fetch stable

This could be simplified, as linux-stable.git includes mainline, it's
just sometimes a few hours behind.

> And I can tell them to 'git checkout v<GOOD>' and 'git checkout v<BAD>'
> and proceed from there.
> 
> To me, that's the TL;DR.

FWIW, I earlier today considered changing this myself. But then I
noticed the bundle clone instructions (more on that below) are complex
as well. :-/

Hmmm. Maybe switching to "do a full clone of linus' repo (without using
bundles) and just telling users to add the stable branches they might
need" by default would be a good middle ground for this document. Guess
then I'd switch quickly-build-trimmed-linux.rst over myself.

> And then you can have a section on "what if I
> really can't do full clones" and various options to save bandwidth.
> 
>> Downloading the sources using a full git clone
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> If downloading and storing a lot of data (~4,4 Gigabyte as of early
>> 2023) is nothing that bothers you, instead of a shallow clone perform a
>> full git clone instead. You then will avoid the specialties mentioned
>> above and will have all versions and individual commits at hand at any
>> time::
>>
>>   curl -L \
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle
>> \
>>     -o linux-stable.git.bundle
>>   git clone linux-stable.git.bundle ~/linux/
>>   rm linux-stable.git.bundle
>>   cd ~/linux/
>>   git remote set-url origin \
>>     https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
>>   git fetch origin
>>   git checkout --detach origin/master
> 
> I mean seriously, even the full clone instructions use curl, without
> rationale. Why?

That was the result of the discussion back then, can't remember all the
details and all the places where that happened. Part of it was reducing
the server load, but that IIRC is mainly a concern for CI systems and
something this document can ignore. Unstable internet connection might
have been the main reason -- in combination with the redirection thing
kernel.org does, which *IIRC* prevents us from using "git clone
--bundle-uri=".

Ciao, Thorsten

Powered by blists - more mailing lists