Improve readability.

Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
---

[v3]
 + incorporate Thorsten's suggestions

[v2]
 https://lore.kernel.org/all/20260902115121.687986-2-manuelebnerli@mailbox.org/
 + 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/

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

Hi Manual,

On 9/3/26 8:43 AM, Manuel Ebner wrote:
> Improve readability.
> 
> Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>

It looks like you might be misusing the Reviewed-by: tag here.
My only reply (to v1 of this patch) was:
  https://lore.kernel.org/linux-doc/0475c09c-e165-41a5-b654-5c6aefeaab0b@infradead.org/

and in that email I did not write "Reviewed-by: /me".
Just because I commented on it does not mean that it merits
a Reviewed-by: tag.
I.e., a Reviewed-by: tag must be explicitly written by the reviewer
for it to be included in a patch.

Please see Documentation/process/submitting-patches.rst for more info,
or ask if you still have questions.

> ---
> 
> [v3]
>  + incorporate Thorsten's suggestions
> 
> [v2]
>  https://lore.kernel.org/all/20260902115121.687986-2-manuelebnerli@mailbox.org/
>  + 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/
> 
> ---
>  .../verify-bugs-and-bisect-regressions.rst    | 26 +++++++++----------
>  1 file changed, 13 insertions(+), 13 deletions(-)

thanks.
-- 
~Randy

On Thu, 2026-09-03 at 09:59 -0700, Randy Dunlap wrote:
> Hi Manual,
> 
> On 9/3/26 8:43 AM, Manuel Ebner wrote:
> > Improve readability.
> > 
> > Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org>
> > Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> 
> It looks like you might be misusing the Reviewed-by: tag here.
> My only reply (to v1 of this patch) was:
>   https://lore.kernel.org/linux-doc/0475c09c-e165-41a5-b654-5c6aefeaab0b@infradead.org/

My thought process was: when I include all you suggestions and your message ends with
> All of the other changes LGTM.

you are good with the result. Thus Reviewed.

I probably did this a couple more times with you and others.

I'm sorry and I'll pay more attention to this.

> and in that email I did not write "Reviewed-by: /me".
> Just because I commented on it does not mean that it merits
> a Reviewed-by: tag.
> I.e., a Reviewed-by: tag must be explicitly written by the reviewer
> for it to be included in a patch.
> 
> Please see Documentation/process/submitting-patches.rst for more info,

I'll reread it.

Thanks for the feedback,
 Manuel 

> or ask if you still have questions.
> 
> > ---
> > 
> > [v3]
> >  + incorporate Thorsten's suggestions
> > 
> > [v2]
> >  https://lore.kernel.org/all/20260902115121.687986-2-manuelebnerli@mailbox.org/
> >  + 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/
> > 
> > ---
> >  .../verify-bugs-and-bisect-regressions.rst    | 26 +++++++++----------
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> thanks.

Manuel Ebner <manuelebnerli@mailbox.org> writes:

> On Thu, 2026-09-03 at 09:59 -0700, Randy Dunlap wrote:
>> Hi Manual,
>> 
>> On 9/3/26 8:43 AM, Manuel Ebner wrote:
>> > Improve readability.
>> > 
>> > Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org>
>> > Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>> 
>> It looks like you might be misusing the Reviewed-by: tag here.
>> My only reply (to v1 of this patch) was:
>>   https://lore.kernel.org/linux-doc/0475c09c-e165-41a5-b654-5c6aefeaab0b@infradead.org/
>
> My thought process was: when I include all you suggestions and your message ends with
>> All of the other changes LGTM.
>
> you are good with the result. Thus Reviewed.

Just to emphasize this: you do *not* get to make up Reviewed-by tags; if
it is not explicitly given to you by the person involved, it does not
exist.

jon

On Fri, 2026-09-04 at 07:59 -0600, Jonathan Corbet wrote:
> Manuel Ebner <manuelebnerli@mailbox.org> writes:
> 
> > On Thu, 2026-09-03 at 09:59 -0700, Randy Dunlap wrote:
> > > Hi Manual,
> > > 
> > > On 9/3/26 8:43 AM, Manuel Ebner wrote:
> > > > Improve readability.
> > > > 
> > > > Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org>
> > > > Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> > > 
> > > It looks like you might be misusing the Reviewed-by: tag here.
> > > My only reply (to v1 of this patch) was:
> > >   https://lore.kernel.org/linux-doc/0475c09c-e165-41a5-b654-5c6aefeaab0b@infradead.org/
> > 
> > My thought process was: when I include all you suggestions and your message ends with
> > > All of the other changes LGTM.
> > 
> > you are good with the result. Thus Reviewed.
> 
> Just to emphasize this: you do *not* get to make up Reviewed-by tags; if
> it is not explicitly given to you by the person involved, it does not
> exist.

Understood.
 Manuel

> jon

On 9/3/26 10:18 PM, Manuel Ebner wrote:
> On Thu, 2026-09-03 at 09:59 -0700, Randy Dunlap wrote:
>> Hi Manual,
>>
>> On 9/3/26 8:43 AM, Manuel Ebner wrote:
>>> Improve readability.
>>>
>>> Signed-off-by: Manuel Ebner <manuelebnerli@mailbox.org>
>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
>>
>> It looks like you might be misusing the Reviewed-by: tag here.
>> My only reply (to v1 of this patch) was:
>>   https://lore.kernel.org/linux-doc/0475c09c-e165-41a5-b654-5c6aefeaab0b@infradead.org/
> 
> My thought process was: when I include all you suggestions and your message ends with
>> All of the other changes LGTM.
> 
> you are good with the result. Thus Reviewed.

I understand, but still, it should be explicit (or you could ask).

> I probably did this a couple more times with you and others.
> 
> I'm sorry and I'll pay more attention to this.
> 
>> and in that email I did not write "Reviewed-by: /me".
>> Just because I commented on it does not mean that it merits
>> a Reviewed-by: tag.
>> I.e., a Reviewed-by: tag must be explicitly written by the reviewer
>> for it to be included in a patch.
>>
>> Please see Documentation/process/submitting-patches.rst for more info,
> 
> I'll reread it.

Thanks.
-- 
~Randy