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