Re: [PATCH v4] docs: verify/bisect: fix typos, formating and punctuation

[Thorsten Leemhuis]

On 9/4/26 13:46, Manuel Ebner wrote:
> Improve readability.

YMMV, but for me this is a bit too short and vague; I'd prefer a proper
sentence along the lines of "Fix a few typos and some grammar and
formatting issues." Yes, basically the same as the subject (side note:
needs s/formating/formatting/ apparently), but there is not much more to
say here. Apart from that:

Acked-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx>

And again: thx for doing this!

Ciao, Thorsten


> Signed-off-by: Manuel Ebner <manuelebnerli@xxxxxxxxxxx>
> CC: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
> ---
> 
> [v4]
>  - remove 'Reviewed-by: Randy Dunlap'
> 
> [v3]
>  + incorporate Thorsten's suggestions
> 
> [v2]
>  https://lore.kernel.org/all/20260902115121.687986-2-manuelebnerli@xxxxxxxxxxx/
>  + one more 'your' -> 'you'
>  + 'it'
>  + incorporate Randy's suggestions
>     https://lore.kernel.org/all/0475c09c-e165-41a5-b654-5c6aefeaab0b@xxxxxxxxxxxxx/
>  + Reviewed-by: Randy Dunlap (added by mistake)
> 
> [v1]
>  https://lore.kernel.org/all/20260829055501.581856-2-manuelebnerli@xxxxxxxxxxx/
> ---
>  .../verify-bugs-and-bisect-regressions.rst    | 26 +++++++++----------
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
> index 7d38393f3..91ebb631a 100644
> --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
> +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
> @@ -163,7 +163,7 @@ will be considered the 'good' release and used to prepare the .config file.
>       section 'Complementary tasks: cleanup during and after the process'
>       below.
>  
> -  d) Once your finished the bisection, put a few things away::
> +  d) Once you have finished the bisection, put a few things away::
>  
>         cd ~/linux/
>         git bisect log > ~/bisect-log
> @@ -178,9 +178,9 @@ will be considered the 'good' release and used to prepare the .config file.
>         ./scripts/config --set-str CONFIG_LOCALVERSION '-local-cafec0cacaca0-reverted'
>  
>      This is optional, as some commits are impossible to revert. But if the
> -    second command worked flawlessly, build, install, and boot one more kernel
> -    kernel; just this time skip the first command copying the base .config file
> -    over, as that already has been taken care off.
> +    second command worked flawlessly, build, install, and boot one more kernel;
> +    just this time skip the first command copying the base .config file over,
> +    as that already has been taken care off.
>  
>  * **Complementary tasks**: cleanup during and after the process.
>  
> @@ -229,10 +229,10 @@ depends on your issue:
>  Execute all steps till the end of *segment 1* to **verify if your kernel problem
>  is present in code supported by Linux kernel developers**. If it is, you are all
>  set to report the bug -- unless it did not happen with earlier kernel versions,
> -as then your want to at least continue with *segment 2* to **check if the issue
> +as then you want to at least continue with *segment 2* to **check if the issue
>  qualifies as regression** which receive priority treatment. Depending on the
>  outcome you then are ready to report a bug or submit a preliminary regression
> -report; instead of the latter your could also head straight on and follow
> +report; instead of the latter you could also head straight on and follow
>  *segment 3* to **perform a bisection** for a full-fledged regression report
>  developers are obliged to act upon.
>  
> @@ -550,7 +550,7 @@ be a waste of time. [:ref:`details <introlatestcheck_bisref>`]
>        cd ~/linux/
>        git switch --discard-changes --detach stable/linux-6.1.y
>  
> -    Your series is unsupported, if is not listed or carrying a 'end of life'
> +    Your series is unsupported if it is not listed or it is carrying a 'end of life'
>      tag. In that case you might want to check if a successor series (say
>      linux-6.2.y) or mainline (see next point) fix the bug.
>  
> @@ -1183,9 +1183,9 @@ Space requirements
>  The numbers mentioned are rough estimates with a big extra charge to be on the
>  safe side, so often you will need less.
>  
> -If you have space constraints, be sure to hay attention to the :ref:`step about
> -debug symbols' <debugsymbols_bissbs>` and its :ref:`accompanying reference
> -section' <debugsymbols_bisref>`, as disabling then will reduce the consumed disk
> +If you have space constraints, be sure to pay attention to the :ref:`step about
> +debug symbols <debugsymbols_bissbs>` and its :ref:`accompanying reference
> +section <debugsymbols_bisref>`, as disabling them will reduce the consumed disk
>  space by quite a few gigabytes.
>  
>  [:ref:`back to step-by-step guide <diskspace_bissbs>`]
> @@ -1254,8 +1254,8 @@ distributions:
>        kernel-install-tools libelf-devel make modutils openssl openssl-devel \
>        perl-base zlib-devel rpm-build ncurses-devel qt6-base-devel
>  
> -These commands install a few packages that are often, but not always needed. You
> -for example might want to skip installing the development headers for ncurses,
> +These commands install a few packages that are often, but not always needed. For
> +example, you might want to skip installing the development headers for ncurses,
>  which you will only need in case you later might want to adjust the kernel build
>  configuration using make the targets 'menuconfig' or 'nconfig'; likewise omit
>  the headers of Qt6 if you do not plan to adjust the .config using 'xconfig'.
> @@ -1407,7 +1407,7 @@ Occasionally odd things happen when trying to use a config file prepared for one
>  kernel (say 6.1) on an older mainline release -- especially if it is much older
>  (say 5.15). That's one of the reasons why the previous step in the guide told
>  you to boot the kernel where everything works. If you manually add a .config
> -file you thus want to ensure it's from the working kernel and not from a one
> +file you thus want to ensure it's from the working kernel and not from one
>  that shows the regression.
>  
>  In case you want to build kernels for another machine, locate its kernel build