Received-SPF: pass (google.com: domain of linux-kernel+bounces-38596-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Thorsten Leemhuis <linux@leemhuis.info>, Linux kernel regressions list
 <regressions@lists.linux.dev>, Linux Doc Mailing List
 <linux-doc@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Jonathan Corbet <corbet@lwn.net>,
 Bagas Sanjaya <bagasdotme@gmail.com>, Greg KH <gregkh@linuxfoundation.org>
Subject: Re: More detailed text about bisecting Linux kernel regression --
 request for comments and help
In-Reply-To: <5cfc34c7-8298-4639-bb81-8b95392279ba@leemhuis.info>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
References: <c763e15e-e82e-49f8-a540-d211d18768a3@leemhuis.info>
 <87fryllpp5.fsf@intel.com>
 <5cfc34c7-8298-4639-bb81-8b95392279ba@leemhuis.info>
Date: Thu, 25 Jan 2024 14:54:06 +0200
Message-ID: <874jf1lgk1.fsf@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

On Thu, 25 Jan 2024, Thorsten Leemhuis <linux@leemhuis.info> wrote:
> On 25.01.24 10:36, Jani Nikula wrote:
>> 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.

I'm not suggesting to ignore or forget the people for whom full clones
might be slow or costly. I'm suggesting to first describe the basic
principles in as simple ways as possible, and then expand on pitfalls
and corner cases in separate sections.

I think even the simplest and most basic kernel bisect can be
intimidating for anyone doing it for the first time - and that's the
target audience here - so I'd like to not scare people with all the
difficulties with shallow clones right off the bat. Lure them in first!
;)

Also not suggesting to throw out all the things you've written, just to
structure it different.

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

It's perhaps a personal preference more than anything to have origin
always point at Linus' tree, and all the other repos as additional
remotes. Then I can ask people to add remotes e.g. for drm subsystem to
try out new stuff. YMMV.

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

Perhaps server load should not be a consideration in *this* particular
case?

To me, all of this is just saying "git is difficult", and that's kind of
the wrong message here. :/


BR,
Jani.


-- 
Jani Nikula, Intel