On 04/16/2012 07:32 AM, Jiri Kosina wrote:
>
> [ adding linux-doc@, once I get their Ack, I'll apply it ]
Let's see...
Commit b5d1b4e72e60c2f04bf1ee5d858ab15a0bbdc670
Docs (trivial): README: Use `X' and `x' consistently
This patch is utterly pointless. I suppose there's no more reason
_not_ to do it than there is to do it...
Commit b6c5289fd48a92ba1d4192eac9339091c2987c39
Docs (trivial): README: Grammar: `me has' -> `I have'
Ok.
Commit d5ea7be2bb5fe0ed68ae5992705f743af907831d
Docs (trivial): README: Better comma usage
Actually worse comma usage. Please no.
Ahem:
Actually, worse comma usage. Please, no.
commit a429779237e2a74b0671a741feb1e9b821c9c46e
Docs (trivial): README: `Alternately' -> `Alternatively'
Ah, the defense of archaic forms dropping out of the language.
Always good fun while the rest of us decide to boldly split
infinitives while finding prepositions perfectly good words to end a
sentence with. Still, it's not quite 5 to 1 on the net for the older
version:
"alternate values": 28,200 google hits
"alternative values": 129,000 google hits.
*shrug* Ok...
commit 0452fff25f3d120819942234413a1b9a782e9c7a
Docs (trivial): README: More consistent and readable white space
This is a style change. It is neither an improvement nor regression
in readability, it's just somebody imposing their sense of taste.
commit 71a0867235bb5ac9c5e665ebea19ebbf5874b5ad
Pull the Microsoft Outlook trick of capitalizing other people's words.
According to git annotate, the lines you're capitalizing have
remained unchanged since Linux 1.0, March 12 1994. I.E. nobody's
asked for clarification of this for 18 years. These lines are
older than all three of Linus's daughters, and are old enough
to vote.
It's difficult to consider this change a _priority_, is what I'm saying.
commit 2dcb758d3d636a8e38d059a4cf1c7243b1305138
Docs (trivial): README: Consolidate discussions of -stable patches
There's a bullet point on upgrading between development releases via
patch, and a bullet point on upgrading between -stable releases via
patch. The first bullet point has a warning that -stable patches
don't work that way. The second bullet point is an explanation of how
-stable releases work.
It was probably that way to provide more surface area to reduce the
"why didn't this patch apply" emails to the list. With your change,
all discussion of -stable patches is paragraph 3 of 5 in the
"upgrading via patches" bullet point, instead of having its own
bullet point _and_ a warning like it does now. I'm not sure that's
functionally an improvement as documentation.
To be honest, this sounds like a design issue (-stable and development
patches should probably have worked the same way), but at this point
changing it would just cause more confusion...
commit 86e1d222688102d99ceb20ffcf857868c983020e
Docs (trivial): README: Replace tabs with spaces
I honestly do not care one way or the other.
Net I consider this entire series to be pointless churn, and I say that
with an english minor. None of it actually clarified the meaning of any
documentation. The _strongest_ patch in the series does this:
--- a/README
+++ b/README
@@ -89,7 +89,7 @@ INSTALLING the kernel source:
source tree, _in_order_, and you should be ok. You may want to remove
the backup files (some-file-name~ or some-file-name.orig), and make sure
that there are no failed patches (some-file-name# or some-file-name.rej).
- If there are, either you or me has made a mistake.
+ If there are, either you or I have made a mistake.
Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
I.E. this series contains seven patches _less_ compelling than that one.
Honestly, I'd rather not have the churn.
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
