All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Thu, 25 Jan 2024 11:36:38 +0200	[thread overview]
Message-ID: <87fryllpp5.fsf@intel.com> (raw)
In-Reply-To: <c763e15e-e82e-49f8-a540-d211d18768a3@leemhuis.info>

On Wed, 24 Jan 2024, Thorsten Leemhuis <linux@leemhuis.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.

The one thing I find problematic is the use of shallow clones by default
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

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


BR,
Jani.


-- 
Jani Nikula, Intel

  reply	other threads:[~2024-01-25  9:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24 12:19 More detailed text about bisecting Linux kernel regression -- request for comments and help Thorsten Leemhuis
2024-01-25  9:36 ` Jani Nikula [this message]
2024-01-25 10:28   ` Thorsten Leemhuis
2024-01-25 12:54     ` Jani Nikula
2024-01-28  2:18 ` Bagas Sanjaya
2024-01-28  5:28   ` Thorsten Leemhuis
2024-01-28 12:27     ` Bagas Sanjaya
2024-02-05  8:32 ` Linux regression tracking (Thorsten Leemhuis)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fryllpp5.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=bagasdotme@gmail.com \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.