HACKING: Fix spelling mistakes
Acked-by: Vincent Jardin <vincent.jardin@6wind.com>
diff --git a/HACKING.tex b/HACKING.tex
index 6b27ebf..57235b1 100644
--- a/HACKING.tex
+++ b/HACKING.tex
@@ -57,7 +57,7 @@
See line 2 of HACKING.tex, the source for this document, for an example.
This placeholder string will be expanded out by the `git archive' commands,
-wihch is used to generate the tar archives for snapshots and releases.
+which is used to generate the tar archives for snapshots and releases.
Please document fully the proper use of a new function in the header file
in which it is declared. And please consult existing headers for
@@ -73,7 +73,7 @@
an orderly manner. If at all possible, try to retain the old deprecated
interface as is, or functionally equivalent. Make a note of when the
interface was deprecated and guard the deprecated interface definitions in
-the header file, ie:
+the header file, i.e.:
\begin{verbatim}
/* Deprecated: 20050406 */
@@ -172,9 +172,9 @@
Please think very carefully before making code conditional at compile time,
as it increases maintenance burdens and user confusion. In particular,
-please avoid gratuitious --enable-\ldots switches to the configure script -
+please avoid gratuitous --enable-\ldots switches to the configure script -
typically code should be good enough to be in Quagga, or it shouldn't be
-there at all.
+there at all.
When code must be compile-time conditional, try have the compiler make it
conditional rather than the C pre-processor - so that it will still be
@@ -256,7 +256,7 @@
This itemised commit messages allows reviewers to have confidence that the
author has self-reviewed every line of the patch, as well as providing
reviewers a clear index of which changes are intended, and descriptions for
-them (C-to-english descriptions are not desireable - some discretion is
+them (C-to-english descriptions are not desirable - some discretion is
useful). For short patches, a per-function/file break-down may be
redundant. For longer patches, such a break-down may be essential. A
contrived example (where the general discussion is obviously somewhat
@@ -299,7 +299,7 @@
\section{RELEASE PROCEDURE}
\begin{itemize}
-\item Tag the apppropriate commit with a release tag (follow existing
+\item Tag the appropriate commit with a release tag (follow existing
conventions).
[This enables recreating the release, and is just good CM practice.]
@@ -388,7 +388,7 @@
\label{sec:git-submission}
The preferred method for submitting changes is to provide git commits via a
-publically-accessible git repository, which the maintainers can easily pull.
+publicly-accessible git repository, which the maintainers can easily pull.
The commits should be in a branch based off the Quagga.net master - a
"feature branch". Ideally there should be no commits to this branch other
@@ -440,8 +440,8 @@
\item Do not make gratuitous changes to whitespace. See the w and b arguments
to diff.
-\item Changes should be arranged so that the least contraversial and most
- trivial are first, and the most complex or more contraversial are
+\item Changes should be arranged so that the least controversial and most
+ trivial are first, and the most complex or more controversial are
last. This will maximise how many the Quagga maintainers can merge,
even if some other commits need further work.
@@ -473,7 +473,7 @@
\item Only apply patches that meet the submission guidelines.
\item If the patch might break something, issue a call for testing on the
- mailinglist.
+ mailing-list.
\item Give an appropriate commit message (see above), and use the --author
argument to git-commit, if required, to ensure proper attribution (you