Re: [PATCH v2] docs: verify/bisect: fix typos

[Thorsten Leemhuis]

Thx for doing this, much appreciated.

On 9/2/26 13:51, Manuel Ebner wrote:
> 'your' -> 'you have'
> 'kernel kernel' -> 'kernel'
> 'your' -> 'you' twice
> 'if is not listed' -> 'if it is not listed'
> 'hay attention' -> 'pay attention'
> remove needless "'" in sphinx link
> 'as disabling then will reduce the consumed disk space'
>               vvvv
> 'as disabling them will reduce the consumed disk space'
> 'You for example might' -> 'For example you might'
> 'and not from a one that' -> 'and not from one that'

Pretty sure the above won't fly as a patch description, as it should
describe the changes, not list each of them, as that is visible from the
diff already (even if that's slightly hard for text-only files).

For typos and grammar fixes there is not much to say, so maybe just
state that; but you might want to look at a few recent changes in
Documentation/ to see how other developers approach a situation like this.
> Signed-off-by: Manuel Ebner <manuelebnerli@xxxxxxxxxxx>
> Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
> ---
> [v2]
>  + one more 'your' -> 'you'
>  - 'it'
>  + incorporate Randy's suggestions
>     https://lore.kernel.org/all/0475c09c-e165-41a5-b654-5c6aefeaab0b@xxxxxxxxxxxxx/
>  + Reviewed-by: Randy Dunlap
> 
> [v1]
>  https://lore.kernel.org/all/20260829055501.581856-2-manuelebnerli@xxxxxxxxxxx/
> 
> Wouldn't it make sense to add how to skip pure documentation and formating
> commits?

YMMV, but I don't think that's worth it. It is easy to get wrong,
doesn't matter much at the early steps of a bisection, and means one
more instruction to describe for people that do that for the first time.

> Commits like this one. Or is it better to keep the document short
> and simple - which it already isn't anymore.

Feel free to suggest something to remove or rewrite parts with less
words -- in separate patches of course. I know my writing is pretty
verbose, sorry; partly that's my style, partly it might be because I'm
not a native speaker, and partly it's like that because I know about too
many corner cases that I try to prevent users running into.

> ---
>  .../verify-bugs-and-bisect-regressions.rst    | 24 +++++++++----------
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
> index 7d38393f31f..9296e3f5410 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,8 +178,8 @@ 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
> +    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.

I'd move the "over, " to the previous line, as the formatting otherwise
looks odd. Not strictly required and makes the patch slightly more
complex (so might not be the best idea, but I think it's worth when it's
just one line).
>  * **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'

Correct me if I'm wrong, but isn't the comma before the "if" wrong (not
your fault, it was like that before your change already; but would be
good to fix while at it)?

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

I think there needs to be a comma after the "For example" (also a
earlier error).

>  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

Ciao, Thorsten