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

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

[Manuel Ebner]

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

Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
---
[v2]
 + one more 'your' -> 'you'
 - 'it'
 + incorporate Randy's suggestions
    https://lore.kernel.org/all/0475c09c-e165-41a5-b654-5c6aefeaab0b@infradead.org/
 + Reviewed-by: Randy Dunlap

[v1]
 https://lore.kernel.org/all/20260829055501.581856-2-manuelebnerli@mailbox.org/

Wouldn't it make sense to add how to skip pure documentation and formating
commits? Commits like this one. Or is it better to keep the document short
and simple - which it already isn't anymore.
---
 .../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.
 
 * **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
-- 
2.54.0

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@mailbox.org>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> [v2]
>  + one more 'your' -> 'you'
>  - 'it'
>  + incorporate Randy's suggestions
>     https://lore.kernel.org/all/0475c09c-e165-41a5-b654-5c6aefeaab0b@infradead.org/
>  + Reviewed-by: Randy Dunlap
> 
> [v1]
>  https://lore.kernel.org/all/20260829055501.581856-2-manuelebnerli@mailbox.org/
> 
> 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

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

[Manuel Ebner]

On Wed, 2026-09-02 at 18:30 +0200, Thorsten Leemhuis wrote:
> 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).

That's true, I got this a couple times as feedback.

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

That's a good idea. I did only find slightly more verbose than mine, eg:
> Fix 'hay attention' -> 'pay attention' in file.rst
or
> Replace "an a few" with "and a few" in
> Documentation/driver-api/media/drivers/zoran.rst.

> > Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org>
> > Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> > ---
> > [v2]
> >  + one more 'your' -> 'you'
> >  - 'it'
> >  + incorporate Randy's suggestions
> >     https://lore.kernel.org/all/0475c09c-e165-41a5-b654-5c6aefeaab0b@infradead.org/
> >  + Reviewed-by: Randy Dunlap
> > 
> > [v1]
> >  https://lore.kernel.org/all/20260829055501.581856-2-manuelebnerli@mailbox.org/
> > 
> > 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.

Ok.

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

I'll add it to my list, but it's pretty difficult.

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

That´s a feature.

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

I'd do the same, prior feedback taught me otherwise. I'll do it.

The remaining suggestions are good, will incorporate them.

Thanks
 Manuel 

> >  ...
> ...
> Ciao, Thorsten

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

[Thorsten Leemhuis]

On 9/3/26 10:22, Manuel Ebner wrote:
> On Wed, 2026-09-02 at 18:30 +0200, Thorsten Leemhuis wrote:
>> On 9/2/26 13:51, Manuel Ebner wrote:

>> 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.
> 
> That's a good idea. I did only find slightly more verbose than mine, eg:
>> Fix 'hay attention' -> 'pay attention' in file.rst
> or
>> Replace "an a few" with "and a few" in
>> Documentation/driver-api/media/drivers/zoran.rst.

Yeah, maybe that slipped thought; and if it's just one or two fixes
okayish, but after that a vague "Fix a few typos/mistakes/grammer
issues" becomes better I'd say, unless there is something more to tell.
Hopefully Jonathan agrees with this.
>>> @@ -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).
> 
> I'd do the same, prior feedback taught me otherwise. I'll do it.

Yeah, that's somewhat a matter of personal preference and for me also a
case by case decision. In this case I think it's fine to change, as the
line break makes the para look somewhat odd. Also it's just one more
line that is changed -- if it were ten, I would have left it as it is.

Ciao, Thorsten

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

[Jonathan Corbet]

Thorsten Leemhuis <linux@leemhuis.info> writes:

> On 9/3/26 10:22, Manuel Ebner wrote:
>> On Wed, 2026-09-02 at 18:30 +0200, Thorsten Leemhuis wrote:
>>> On 9/2/26 13:51, Manuel Ebner wrote:
>
>>> 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.
>> 
>> That's a good idea. I did only find slightly more verbose than mine, eg:
>>> Fix 'hay attention' -> 'pay attention' in file.rst
>> or
>>> Replace "an a few" with "and a few" in
>>> Documentation/driver-api/media/drivers/zoran.rst.
>
> Yeah, maybe that slipped thought; and if it's just one or two fixes
> okayish, but after that a vague "Fix a few typos/mistakes/grammer
> issues" becomes better I'd say, unless there is something more to tell.
> Hopefully Jonathan agrees with this.

I do; repeating the specific typo fixes in the changelog is just
redundant.  As always, the changelog should focus on the *why* of the
change.

jon