summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--HACKING20
1 files changed, 12 insertions, 8 deletions
diff --git a/HACKING b/HACKING
index ca3ad52e..55c03435 100644
--- a/HACKING
+++ b/HACKING
@@ -17,6 +17,7 @@ Contents:
* STABLE PLATFORMS AND DAEMONS
* IMPORT OR UPDATE VENDOR SPECIFIC ROUTING PROTOCOLS
+
GUIDELINES FOR HACKING ON QUAGGA
[this is a draft in progress]
@@ -98,6 +99,7 @@ release.
See also below regarding SHARED LIBRARY VERSIONING.
+
COMPILE-TIME CONDITIONAL CODE
Please think very carefully before making code conditional at compile time,
@@ -121,6 +123,7 @@ rather than:
Note that the former approach requires ensuring that SOME_SYMBOL will be
defined (watch your AC_DEFINEs).
+
COMMIT MESSAGES
The commit message should provide:
@@ -141,14 +144,14 @@ The commit message should provide:
to provide a short description of the general intent of the patch, in terms
of the problem it solves and how it achieves it, to help reviewers
-understand.
+understand.
The one-line summary must be limited to 54 characters, and all other
lines to 72 characters.
The reason for such itemised commit messages is to encourage the author to
self-review every line of the patch, as well as provide reviewers an index
-of which changes are intended, along with a short description for each.
+of which changes are intended, along with a short description for each.
Some discretion is obviously required. A C-to-english description is not
desireable. For short patches, a per-function/file break-down may be
redundant. For longer patches, such a break-down may be essential.
@@ -159,7 +162,7 @@ given the one-line summary):
zebra: Enhance frob FSM to detect loss of frob
* (general) Add a new DOWN state to the frob state machine
- to allow the barinator to detect loss of frob.
+ to allow the barinator to detect loss of frob.
* frob.h: (struct frob) Add DOWN state flag.
* frob.c: (frob_change) set/clear DOWN appropriately on state change.
* bar.c: (barinate) Check frob for DOWN state.
@@ -174,13 +177,14 @@ etc.), try to check that the following things still work:
- make dist
- resulting dist tarball builds
- - out-of-tree builds
+ - out-of-tree builds
The quagga.net site relies on make dist to work to generate snapshots. It
must work. Common problems are to forget to have some additional file
included in the dist, or to have a make rule refer to a source file without
using the srcdir variable.
+
RELEASE PROCEDURE
* Tag the apppropriate commit with a release tag (follow existing
@@ -203,7 +207,7 @@ RELEASE PROCEDURE
The tarball which 'make dist' creates is the tarball to be released! The
git-archive step ensures you're working with code corresponding to that in
the official repository, and also carries out keyword expansion. If any
-errors occur, move tags as needed and start over from the fresh checkouts.
+errors occur, move tags as needed and start over from the fresh checkouts.
Do not append to tarballs, as this has produced non-standards-conforming
tarballs in the past.
@@ -246,9 +250,9 @@ installed together.
PATCH SUBMISSION
* Send a clean diff against the 'master' branch of the quagga.git
- repository, in unified diff format, preferably with the '-p' argument to
+ repository, in unified diff format, preferably with the '-p' argument to
show C function affected by any chunk, and with the -w and -b arguments to
- minimise changes. E.g:
+ minimise changes. E.g:
git diff -up mybranch..remotes/quagga.net/master
@@ -256,7 +260,7 @@ PATCH SUBMISSION
* Not doing so is a definite hindrance to patch application.
-* Include NEWS entries as appropriate.
+* Include NEWS entries as appropriate.
* Please, please include an appropriate commit message with any emailed
patches. Doing so makes it easier to review a patch, and apply it.