[wwwdocs] [PATCH 0/4] Fix various typos

[wwwdocs] [PATCH 0/4] Fix various typos

[Pokechu22]

While working on a separate patch, I found several typos on the website.
I have only looked within the htdocs directory, not its subdirectories.

These are individual patches per file, since that seemed reasonable to me.

I believe this is a small enough change that I do not need to go through
copyright assignment or DCO certification (if I had supplied a list of
files and line numbers, I suspect anyone else would have made the same
patches).  I would rather remain pseudonymous.

I've sent these patches using gmail's web interface since I have had
bad experiences setting up command-line mailing.  Hopefully they have
not been mangled by it.

--Poke

[wwwdocs] [PATCH 1/4] branch-closing: Fix various typos

[Pokechu22]

---
 htdocs/branch-closing.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/branch-closing.html b/htdocs/branch-closing.html
index c36ad1ab..15fb90e3 100644
--- a/htdocs/branch-closing.html
+++ b/htdocs/branch-closing.html
@@ -54,7 +54,7 @@ is listed in "Known to work" or "Known to fail" as
applicable.</li>
 <li>If the bug is a regression that is not fixed on all subsequent
 release branches and on trunk then it needs to remain open.  Remove
 the version number of the branch being closed from the summary (for
-example, change "[7/8 Regression]" to "[8 Regression]".  If the
+example, change "[7/8 Regression]" to "[8 Regression]").  If the
 milestone is not set, or is set to a version from the branch being
 closed, set it to the version number of the next release from the next
 oldest release branch.
-- 
2.25.1

[wwwdocs] [PATCH 2/4] codingconventions: Fix various typos

[Pokechu22]

---
 htdocs/codingconventions.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index e4d30510..86b63b89 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -141,7 +141,7 @@ a large batch of changes.</p>
         supported formats: <code>a/b/c/ChangeLog</code>,
<code>a/b/c/ChangeLog:</code>, <code>a/b/c/</code> (where ChangeLog
file lives in the folder), <code>\ta/b/c/</code> and
<code>a/b/c</code></li>
     <li><code>pr_entry</code> - bug report reference <br>
         example: <code>\tPR component/12345</code></li>
-    <li><code>changelog_file</code> - a modified file mentined in a ChangeLog:
+    <li><code>changelog_file</code> - a modified file mentioned in a ChangeLog:
         supported formats: <code>\t* a/b/c/file.c:</code>, <code>\t*
a/b/c/file.c (function):</code>, <code>\t* a/b/c/file1.c,
a/b/c/file2.c:</code></li>
     <li><code>changelog_file_comment</code> - line that follows a
<code>changelog_file</code> with description of changes in the file;
         must start with <code>\t</code></li>
@@ -153,7 +153,7 @@ a large batch of changes.</p>
 <h3>Format rules</h3>

 <ul>
-    <li><code>git_description</code> - optional; ends right before
one of the other compoments is found</li>
+    <li><code>git_description</code> - optional; ends right before
one of the other components is found</li>
     <li><code>committer_timestamp</code> - optional; when found
before a <code>changelog_file</code>, then it is added
     to each changelog entry</li>
     <li><code>additional_author</code> - optional</li>
@@ -1022,7 +1022,7 @@ intended to last a long time.
 <p>
 Complex hierarchies are to be avoided.
 Take special care with multiple inheritance.
-On the rare occasion that using mulitple inheritance is indeed useful,
+On the rare occasion that using multiple inheritance is indeed useful,
 prepare design rationales in advance,
 and take special care to make documentation of the entire hierarchy clear.
 (In particular, multiple inheritance can be an acceptable way of combining
-- 
2.25.1

[wwwdocs] [PATCH 3/4] codingrationale: Fix various typos

[Pokechu22]

---
 htdocs/codingrationale.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index 0b44f1da..f523f3e2 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -18,7 +18,7 @@

 <p>
 Inlining functions has a potential cost in object size,
-working set size, compile time, and debuggablity.
+working set size, compile time, and debuggability.
 These costs should not be borne without some evidence
 that the inlining pays for itself.
 </p>
@@ -155,7 +155,7 @@ Wide use of implicit conversion can cause some
very surprising results.

 <p>
 C++03 has no explicit conversion operators,
-and hence using them cannot avoid suprises.
+and hence using them cannot avoid surprises.
 Wait for C++11.
 </p>

-- 
2.25.1

[wwwdocs] [PATCH 4/4] contribute: Fix various typos

[Pokechu22]

---
 htdocs/contribute.html | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index c0223738..2d04b1f0 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -267,7 +267,7 @@ characters.</p>

 <p>The classifier identifies the type of contribution, for example a
 patch, an RFC (request for comments) or a committed patch (where
-approval is not necessary.  The classifier should be written in upper
+approval is not necessary).  The classifier should be written in upper
 case and surrounded with square brackets.  This is the only component
 of the e-mail subject line that will not appear in the commit itself.
 The classifier may optionally contain a version number (v<i>N</i>) and
@@ -297,7 +297,7 @@ followed by a colon.  For example,</p>
 </ul>

 <p>Some large components may be subdivided into sub-components.  If
-the subcomponent name is not disctinct in its own right, you can use the
+the subcomponent name is not distinct in its own right, you can use the
 form <i>component/sub-component:</i>.</p>

 <h4>Series identifier</h4>
@@ -327,7 +327,7 @@ the commit message so that Bugzilla will correctly
notice the
 commit.  If your patch relates to two bugs, then write
 <code>[PR<i>nnnnn</i>, PR<i>mmmmm</i>]</code>.  For multiple
 bugs, just cite the most relevant one in the summary and use an
-elipsis instead of the second, or subsequent PR numbers; list all the
+ellipsis instead of the second, or subsequent PR numbers; list all the
 related PRs in the body of the commit message in the normal way.</p>

 <p>It is not necessary to cite bugs that are closed as duplicates of
@@ -352,7 +352,7 @@ together.</p>
 <p>If you submit a new version of a patch series, then you should
 start a new email thread (don't reply to the original patch series).
 This avoids email threads becoming confused between discussions of the
-first and subsequent revisions of the patch set.  Your cover leter
+first and subsequent revisions of the patch set.  Your cover letter
 (0/<i>nnn</i>) should explain clearly what has been changed between
 the two patch series.  Also state if some of the patches are unchanged
 between revisions; this saves maintainers having to re-review the
-- 
2.25.1

Re: [wwwdocs] [PATCH 0/4] Fix various typos

[Pokechu22]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

In case it's helpful, I've included copies of the patches as
attachments (as well as a single patch that is all of these changes
merged together).

--Poke

On Tue, Mar 22, 2022 at 12:50 PM Pokechu22 <pokechu022@gmail.com> wrote:
>
> While working on a separate patch, I found several typos on the website.
> I have only looked within the htdocs directory, not its subdirectories.
>
> These are individual patches per file, since that seemed reasonable to me.
>
> I believe this is a small enough change that I do not need to go through
> copyright assignment or DCO certification (if I had supplied a list of
> files and line numbers, I suspect anyone else would have made the same
> patches).  I would rather remain pseudonymous.
>
> I've sent these patches using gmail's web interface since I have had
> bad experiences setting up command-line mailing.  Hopefully they have
> not been mangled by it.
>
> --Poke

[-- Attachment #2: 0001-branch-closing-Fix-various-typos.patch --]
[-- Type: application/octet-stream, Size: 1057 bytes --]

From 9eba9216fe24e2a693f4c7da3a509d729ec428b5 Mon Sep 17 00:00:00 2001
From: Pokechu22 <Pokechu022@gmail.com>
Date: Tue, 22 Mar 2022 12:34:17 -0700
Subject: [PATCH 1/4] branch-closing: Fix various typos

---
 htdocs/branch-closing.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/branch-closing.html b/htdocs/branch-closing.html
index c36ad1ab..15fb90e3 100644
--- a/htdocs/branch-closing.html
+++ b/htdocs/branch-closing.html
@@ -54,7 +54,7 @@ is listed in "Known to work" or "Known to fail" as applicable.</li>
 <li>If the bug is a regression that is not fixed on all subsequent
 release branches and on trunk then it needs to remain open.  Remove
 the version number of the branch being closed from the summary (for
-example, change "[7/8 Regression]" to "[8 Regression]".  If the
+example, change "[7/8 Regression]" to "[8 Regression]").  If the
 milestone is not set, or is set to a version from the branch being
 closed, set it to the version number of the next release from the next
 oldest release branch.
-- 
2.25.1


[-- Attachment #3: 0002-codingconventions-Fix-various-typos.patch --]
[-- Type: application/octet-stream, Size: 2350 bytes --]

From a3f45b11b7edb6db6712c403df39bd60992ac00f Mon Sep 17 00:00:00 2001
From: Pokechu22 <Pokechu022@gmail.com>
Date: Tue, 22 Mar 2022 12:34:42 -0700
Subject: [PATCH 2/4] codingconventions: Fix various typos

---
 htdocs/codingconventions.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index e4d30510..86b63b89 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -141,7 +141,7 @@ a large batch of changes.</p>
         supported formats: <code>a/b/c/ChangeLog</code>, <code>a/b/c/ChangeLog:</code>, <code>a/b/c/</code> (where ChangeLog file lives in the folder), <code>\ta/b/c/</code> and <code>a/b/c</code></li>
     <li><code>pr_entry</code> - bug report reference <br>
         example: <code>\tPR component/12345</code></li>
-    <li><code>changelog_file</code> - a modified file mentined in a ChangeLog:
+    <li><code>changelog_file</code> - a modified file mentioned in a ChangeLog:
         supported formats: <code>\t* a/b/c/file.c:</code>, <code>\t* a/b/c/file.c (function):</code>, <code>\t* a/b/c/file1.c, a/b/c/file2.c:</code></li>
     <li><code>changelog_file_comment</code> - line that follows a <code>changelog_file</code> with description of changes in the file;
         must start with <code>\t</code></li>
@@ -153,7 +153,7 @@ a large batch of changes.</p>
 <h3>Format rules</h3>
 
 <ul>
-    <li><code>git_description</code> - optional; ends right before one of the other compoments is found</li>
+    <li><code>git_description</code> - optional; ends right before one of the other components is found</li>
     <li><code>committer_timestamp</code> - optional; when found before a <code>changelog_file</code>, then it is added
     to each changelog entry</li>
     <li><code>additional_author</code> - optional</li>
@@ -1022,7 +1022,7 @@ intended to last a long time.
 <p>
 Complex hierarchies are to be avoided.
 Take special care with multiple inheritance.
-On the rare occasion that using mulitple inheritance is indeed useful,
+On the rare occasion that using multiple inheritance is indeed useful,
 prepare design rationales in advance,
 and take special care to make documentation of the entire hierarchy clear.
 (In particular, multiple inheritance can be an acceptable way of combining
-- 
2.25.1


[-- Attachment #4: 0004-contribute-Fix-various-typos.patch --]
[-- Type: application/octet-stream, Size: 2480 bytes --]

From 8962ff9795a4ac77e844c56f9301f197b7154a62 Mon Sep 17 00:00:00 2001
From: Pokechu22 <Pokechu022@gmail.com>
Date: Tue, 22 Mar 2022 12:35:11 -0700
Subject: [PATCH 4/4] contribute: Fix various typos

---
 htdocs/contribute.html | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index c0223738..2d04b1f0 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -267,7 +267,7 @@ characters.</p>
 
 <p>The classifier identifies the type of contribution, for example a
 patch, an RFC (request for comments) or a committed patch (where
-approval is not necessary.  The classifier should be written in upper
+approval is not necessary).  The classifier should be written in upper
 case and surrounded with square brackets.  This is the only component
 of the e-mail subject line that will not appear in the commit itself.
 The classifier may optionally contain a version number (v<i>N</i>) and
@@ -297,7 +297,7 @@ followed by a colon.  For example,</p>
 </ul>
 
 <p>Some large components may be subdivided into sub-components.  If
-the subcomponent name is not disctinct in its own right, you can use the
+the subcomponent name is not distinct in its own right, you can use the
 form <i>component/sub-component:</i>.</p>
 
 <h4>Series identifier</h4>
@@ -327,7 +327,7 @@ the commit message so that Bugzilla will correctly notice the
 commit.  If your patch relates to two bugs, then write
 <code>[PR<i>nnnnn</i>, PR<i>mmmmm</i>]</code>.  For multiple
 bugs, just cite the most relevant one in the summary and use an
-elipsis instead of the second, or subsequent PR numbers; list all the
+ellipsis instead of the second, or subsequent PR numbers; list all the
 related PRs in the body of the commit message in the normal way.</p>
 
 <p>It is not necessary to cite bugs that are closed as duplicates of
@@ -352,7 +352,7 @@ together.</p>
 <p>If you submit a new version of a patch series, then you should
 start a new email thread (don't reply to the original patch series).
 This avoids email threads becoming confused between discussions of the
-first and subsequent revisions of the patch set.  Your cover leter
+first and subsequent revisions of the patch set.  Your cover letter
 (0/<i>nnn</i>) should explain clearly what has been changed between
 the two patch series.  Also state if some of the patches are unchanged
 between revisions; this saves maintainers having to re-review the
-- 
2.25.1


[-- Attachment #5: 0003-codingrationale-Fix-various-typos.patch --]
[-- Type: application/octet-stream, Size: 1022 bytes --]

From 19d25f47214e0965b113184e283e05990b446a2e Mon Sep 17 00:00:00 2001
From: Pokechu22 <Pokechu022@gmail.com>
Date: Tue, 22 Mar 2022 12:35:01 -0700
Subject: [PATCH 3/4] codingrationale: Fix various typos

---
 htdocs/codingrationale.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index 0b44f1da..f523f3e2 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -18,7 +18,7 @@
 
 <p>
 Inlining functions has a potential cost in object size,
-working set size, compile time, and debuggablity.
+working set size, compile time, and debuggability.
 These costs should not be borne without some evidence
 that the inlining pays for itself.
 </p>
@@ -155,7 +155,7 @@ Wide use of implicit conversion can cause some very surprising results.
 
 <p>
 C++03 has no explicit conversion operators,
-and hence using them cannot avoid suprises.
+and hence using them cannot avoid surprises.
 Wait for C++11.
 </p>
 
-- 
2.25.1


[-- Attachment #6: 0001-Fix-various-typos.patch --]
[-- Type: application/octet-stream, Size: 6096 bytes --]

From d2380da3485c74e403c61037b469ec3cb6d8dff0 Mon Sep 17 00:00:00 2001
From: Pokechu22 <Pokechu022@gmail.com>
Date: Tue, 22 Mar 2022 12:34:17 -0700
Subject: [PATCH] Fix various typos

---
 htdocs/branch-closing.html    | 2 +-
 htdocs/codingconventions.html | 6 +++---
 htdocs/codingrationale.html   | 4 ++--
 htdocs/contribute.html        | 8 ++++----
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/htdocs/branch-closing.html b/htdocs/branch-closing.html
index c36ad1ab..15fb90e3 100644
--- a/htdocs/branch-closing.html
+++ b/htdocs/branch-closing.html
@@ -54,7 +54,7 @@ is listed in "Known to work" or "Known to fail" as applicable.</li>
 <li>If the bug is a regression that is not fixed on all subsequent
 release branches and on trunk then it needs to remain open.  Remove
 the version number of the branch being closed from the summary (for
-example, change "[7/8 Regression]" to "[8 Regression]".  If the
+example, change "[7/8 Regression]" to "[8 Regression]").  If the
 milestone is not set, or is set to a version from the branch being
 closed, set it to the version number of the next release from the next
 oldest release branch.
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index e4d30510..86b63b89 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -141,7 +141,7 @@ a large batch of changes.</p>
         supported formats: <code>a/b/c/ChangeLog</code>, <code>a/b/c/ChangeLog:</code>, <code>a/b/c/</code> (where ChangeLog file lives in the folder), <code>\ta/b/c/</code> and <code>a/b/c</code></li>
     <li><code>pr_entry</code> - bug report reference <br>
         example: <code>\tPR component/12345</code></li>
-    <li><code>changelog_file</code> - a modified file mentined in a ChangeLog:
+    <li><code>changelog_file</code> - a modified file mentioned in a ChangeLog:
         supported formats: <code>\t* a/b/c/file.c:</code>, <code>\t* a/b/c/file.c (function):</code>, <code>\t* a/b/c/file1.c, a/b/c/file2.c:</code></li>
     <li><code>changelog_file_comment</code> - line that follows a <code>changelog_file</code> with description of changes in the file;
         must start with <code>\t</code></li>
@@ -153,7 +153,7 @@ a large batch of changes.</p>
 <h3>Format rules</h3>
 
 <ul>
-    <li><code>git_description</code> - optional; ends right before one of the other compoments is found</li>
+    <li><code>git_description</code> - optional; ends right before one of the other components is found</li>
     <li><code>committer_timestamp</code> - optional; when found before a <code>changelog_file</code>, then it is added
     to each changelog entry</li>
     <li><code>additional_author</code> - optional</li>
@@ -1022,7 +1022,7 @@ intended to last a long time.
 <p>
 Complex hierarchies are to be avoided.
 Take special care with multiple inheritance.
-On the rare occasion that using mulitple inheritance is indeed useful,
+On the rare occasion that using multiple inheritance is indeed useful,
 prepare design rationales in advance,
 and take special care to make documentation of the entire hierarchy clear.
 (In particular, multiple inheritance can be an acceptable way of combining
diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index 0b44f1da..f523f3e2 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -18,7 +18,7 @@
 
 <p>
 Inlining functions has a potential cost in object size,
-working set size, compile time, and debuggablity.
+working set size, compile time, and debuggability.
 These costs should not be borne without some evidence
 that the inlining pays for itself.
 </p>
@@ -155,7 +155,7 @@ Wide use of implicit conversion can cause some very surprising results.
 
 <p>
 C++03 has no explicit conversion operators,
-and hence using them cannot avoid suprises.
+and hence using them cannot avoid surprises.
 Wait for C++11.
 </p>
 
diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index c0223738..2d04b1f0 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -267,7 +267,7 @@ characters.</p>
 
 <p>The classifier identifies the type of contribution, for example a
 patch, an RFC (request for comments) or a committed patch (where
-approval is not necessary.  The classifier should be written in upper
+approval is not necessary).  The classifier should be written in upper
 case and surrounded with square brackets.  This is the only component
 of the e-mail subject line that will not appear in the commit itself.
 The classifier may optionally contain a version number (v<i>N</i>) and
@@ -297,7 +297,7 @@ followed by a colon.  For example,</p>
 </ul>
 
 <p>Some large components may be subdivided into sub-components.  If
-the subcomponent name is not disctinct in its own right, you can use the
+the subcomponent name is not distinct in its own right, you can use the
 form <i>component/sub-component:</i>.</p>
 
 <h4>Series identifier</h4>
@@ -327,7 +327,7 @@ the commit message so that Bugzilla will correctly notice the
 commit.  If your patch relates to two bugs, then write
 <code>[PR<i>nnnnn</i>, PR<i>mmmmm</i>]</code>.  For multiple
 bugs, just cite the most relevant one in the summary and use an
-elipsis instead of the second, or subsequent PR numbers; list all the
+ellipsis instead of the second, or subsequent PR numbers; list all the
 related PRs in the body of the commit message in the normal way.</p>
 
 <p>It is not necessary to cite bugs that are closed as duplicates of
@@ -352,7 +352,7 @@ together.</p>
 <p>If you submit a new version of a patch series, then you should
 start a new email thread (don't reply to the original patch series).
 This avoids email threads becoming confused between discussions of the
-first and subsequent revisions of the patch set.  Your cover leter
+first and subsequent revisions of the patch set.  Your cover letter
 (0/<i>nnn</i>) should explain clearly what has been changed between
 the two patch series.  Also state if some of the patches are unchanged
 between revisions; this saves maintainers having to re-review the
-- 
2.25.1