* [PATCH 1/1] docs: Fix minor grammatical error
@ 2026-06-05 5:38 Brigham Campbell
2026-06-06 19:10 ` Randy Dunlap
0 siblings, 1 reply; 4+ messages in thread
From: Brigham Campbell @ 2026-06-05 5:38 UTC (permalink / raw)
To: Thorsten Leemhuis, Jonathan Corbet, Shuah Khan,
open list:DOCUMENTATION REPORTING ISSUES, open list
Cc: Brigham Campbell
Fix minor grammatical error in the admin guide docs.
Signed-off-by: Brigham Campbell <me@brighamcampbell.com>
---
I happened across this minor mistake while investigating techniques to
use a partial kernel config to generate a complete config. If
maintainers that I don't send out minor fixes like this, please let me
know and I'll remember that for the future.
Documentation/admin-guide/quickly-build-trimmed-linux.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
index cb178e0a6208..194d22f56449 100644
--- a/Documentation/admin-guide/quickly-build-trimmed-linux.rst
+++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
@@ -217,10 +217,10 @@ again.
There is a catch: 'localmodconfig' is likely to disable kernel features you
did not use since you booted your Linux -- like drivers for currently
- disconnected peripherals or a virtualization software not haven't used yet.
- You can reduce or nearly eliminate that risk with tricks the reference
- section outlines; but when building a kernel just for quick testing purposes
- it is often negligible if such features are missing. But you should keep that
+ disconnected peripherals or virtualization software not currently in use. You
+ can reduce or nearly eliminate that risk with tricks the reference section
+ outlines; but when building a kernel just for quick testing purposes it is
+ often negligible if such features are missing. But you should keep that
aspect in mind when using a kernel built with this make target, as it might
be the reason why something you only use occasionally stopped working.
--
2.54.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH 1/1] docs: Fix minor grammatical error
2026-06-05 5:38 [PATCH 1/1] docs: Fix minor grammatical error Brigham Campbell
@ 2026-06-06 19:10 ` Randy Dunlap
2026-06-09 5:50 ` Brigham Campbell
0 siblings, 1 reply; 4+ messages in thread
From: Randy Dunlap @ 2026-06-06 19:10 UTC (permalink / raw)
To: Brigham Campbell, Thorsten Leemhuis, Jonathan Corbet, Shuah Khan,
open list:DOCUMENTATION REPORTING ISSUES, open list
On 6/4/26 10:38 PM, Brigham Campbell wrote:
> Fix minor grammatical error in the admin guide docs.
>
> Signed-off-by: Brigham Campbell <me@brighamcampbell.com>
> ---
>
> I happened across this minor mistake while investigating techniques to
> use a partial kernel config to generate a complete config. If
> maintainers that I don't send out minor fixes like this, please let me
> know and I'll remember that for the future.
>
> Documentation/admin-guide/quickly-build-trimmed-linux.rst | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> index cb178e0a6208..194d22f56449 100644
> --- a/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> +++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> @@ -217,10 +217,10 @@ again.
>
> There is a catch: 'localmodconfig' is likely to disable kernel features you
> did not use since you booted your Linux -- like drivers for currently
> - disconnected peripherals or a virtualization software not haven't used yet.
> - You can reduce or nearly eliminate that risk with tricks the reference
> - section outlines; but when building a kernel just for quick testing purposes
> - it is often negligible if such features are missing. But you should keep that
> + disconnected peripherals or virtualization software not currently in use. You
> + can reduce or nearly eliminate that risk with tricks the reference section
> + outlines; but when building a kernel just for quick testing purposes it is
> + often negligible if such features are missing. But you should keep that
> aspect in mind when using a kernel built with this make target, as it might
> be the reason why something you only use occasionally stopped working.
>
Can't you just modify the first line only and leave the other 3 changed lines
intact?
--
~Randy
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 1/1] docs: Fix minor grammatical error
2026-06-06 19:10 ` Randy Dunlap
@ 2026-06-09 5:50 ` Brigham Campbell
2026-06-09 6:15 ` Thorsten Leemhuis
0 siblings, 1 reply; 4+ messages in thread
From: Brigham Campbell @ 2026-06-09 5:50 UTC (permalink / raw)
To: Randy Dunlap, Brigham Campbell, Thorsten Leemhuis,
Jonathan Corbet, Shuah Khan,
open list:DOCUMENTATION REPORTING ISSUES, open list
On Sat Jun 6, 2026 at 1:10 PM MDT, Randy Dunlap wrote:
> Can't you just modify the first line only and leave the other 3 changed lines
> intact?
I'm not as familiar with the kernel documentation project as I am with
the code itself. I figured that it's generally preferred to maintain
80-character hard wrapping consistently across all documentation. Is it
actually preferable to _not_ reflow text after editing in order to avoid
munging the git history?
Thanks for your time, Randy,
Brigham
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 1/1] docs: Fix minor grammatical error
2026-06-09 5:50 ` Brigham Campbell
@ 2026-06-09 6:15 ` Thorsten Leemhuis
0 siblings, 0 replies; 4+ messages in thread
From: Thorsten Leemhuis @ 2026-06-09 6:15 UTC (permalink / raw)
To: Brigham Campbell, Randy Dunlap, Jonathan Corbet, Shuah Khan,
open list:DOCUMENTATION REPORTING ISSUES, open list
On 6/9/26 07:50, Brigham Campbell wrote:
> On Sat Jun 6, 2026 at 1:10 PM MDT, Randy Dunlap wrote:
>> Can't you just modify the first line only and leave the other 3 changed lines
>> intact?
>
> I'm not as familiar with the kernel documentation project as I am with
> the code itself. I figured that it's generally preferred to maintain
> 80-character hard wrapping consistently across all documentation. Is it
> actually preferable to _not_ reflow text after editing in order to avoid
> munging the git history?
It's a "80-character wrapping" vs "keep patches small/simple/obvious"
situation where one has to weighting things up against each other.
If you'd change one thing in a line that would make the line say only
something like 60 characters or less long, then reflowing becomes the
right thing, as the para otherwise would look odd.
But in this case it won't matter much, so it's likely better to not
reflow to keep the patch smaller.
In the end it's a judgement call that the maintainer has to make. I
don't care much, but if I'd be forced to decide for one way or the other
I'd go with what Randy suggested.
BTW, thx for fixing this!
Ciao, Thorsten
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-06-09 6:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-05 5:38 [PATCH 1/1] docs: Fix minor grammatical error Brigham Campbell
2026-06-06 19:10 ` Randy Dunlap
2026-06-09 5:50 ` Brigham Campbell
2026-06-09 6:15 ` Thorsten Leemhuis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox