Commit 932c9a53 authored by Thorsten Leemhuis's avatar Thorsten Leemhuis Committed by Jonathan Corbet
Browse files

docs: verify/bisect: add and fetch stable branches ahead of time 



Add and fetch all required stable branches ahead of time. This fixes a
bug, as readers that wanted to bisect a regression within a stable or
longterm series otherwise did not have them available at the right time.
This way also matches the flow somewhat better and avoids some "if you
haven't already added it" phrases that otherwise become necessary in
future changes.

Signed-off-by: default avatarThorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/57dcf312959476abe6151bf3d35eb79e3e9a83d1.1712647788.git.linux@leemhuis.info
parent abbb9930

Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst

+18 −13
Original line number Diff line number Diff line
@@ -136,8 +136,7 @@ will be considered the 'good' release and used to prepare the .config file. 


* **Segment 3**: perform and validate the bisection.



  a) In case your 'broken' version is a stable/longterm release, add the Git

     branch holding it::

  a) Retrieve the sources for your 'bad' version::



       git remote set-branches --add stable linux-6.1.y

       git fetch stable
@@ -371,6 +370,21 @@ Preparations: set up everything to build your own kernels 


  [:ref:`details<sources_bisref>`]



.. _stablesources_bissbs:



* Retrieve the sources for any stable or longterm series you might need.



  Is the version you earlier established as 'bad' a stable or longterm release?

  Then download the code for the series it belongs to ('linux-6.1.y' in this

  example)::



    git remote set-branches --add stable linux-6.1.y

    git fetch stable



  If the version earlier established as 'good' is from a different stable or

  longterm series (say 6.0.13), repeat the previous step, but this time for the

  branch holding the series the 'good' version belongs to (e.g. linux-6.0.y).



.. _oldconfig_bissbs:



* Start preparing a kernel build configuration (the '.config' file).
@@ -620,12 +634,10 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`] 
  reproduce it with the mainline kernel you just built? One that according to

  the `front page of kernel.org <https://kernel.org/>`_ is still supported? Then

  check if the latest codebase for the particular series might already fix the

  problem. To do so, add the stable series Git branch for your 'good' kernel

  (again, this here is assumed to be 6.0) and check out the latest version::

  problem. To do so, check out that series latest version (again, this here is

  assumed to be 6.0)::



    cd ~/linux/

    git remote set-branches --add stable linux-6.0.y

    git fetch stable

    git switch --discard-changes --detach linux-6.0.y



  Now use the checked out code to build and install another kernel using the
@@ -717,13 +729,6 @@ configuration created earlier this works a lot faster than many people assume: 
overall on average it will often just take about 10 to 15 minutes to compile

each kernel on commodity x86 machines.



* In case your 'bad' version is a stable/longterm release (say 6.1.5), add its

  stable branch, unless you already did so earlier::



    cd ~/linux/

    git remote set-branches --add stable linux-6.1.y

    git fetch stable



.. _bisectstart_bissbs:



* Start the bisection and tell Git about the versions earlier established as