]> git.cworth.org Git - obsolete/notmuch-wiki/blobdiff - contributing.mdwn
Update news & manpages to notmuch version 0.16
[obsolete/notmuch-wiki] / contributing.mdwn
index 98dd62955e315284effbd766d625365ef19233bc..3729a766cbbc9948401b3c149a15d8c6131227aa 100644 (file)
@@ -18,7 +18,7 @@ situations; use common sense.
 The Notmuch source code is maintained in [git](http://git-scm.com/). Get the
 source code using:
 
-       git clone git://notmuchmail.org/git/notmuch
+        git clone git://notmuchmail.org/git/notmuch
 
 This guide assumes a working knowledge of git. There are plenty of resources
 available on git, such as [Pro Git](http://git-scm.com/book) and the git man
@@ -30,11 +30,11 @@ The changes you submit should almost always be based on the current
 Notmuch git master. There are plenty of ways to work in git, and this
 is not your git guide, but a typical workflow might start with:
 
-       git fetch origin
-       git checkout -b my-local-branch origin/master
-       # make changes
-       git add ...
-       git commit
+        git fetch origin
+        git checkout -b my-local-branch origin/master
+        # make changes
+        git add ...
+        git commit
 
 If you're planning big changes, it may be advisable to __not__ polish
 the patch series according to all the details described below at
@@ -58,7 +58,7 @@ Each commit should contain one logical change only. The code should
 build and the tests should pass after each commit. Changes to lib,
 cli, emacs, tests, man pages, or news are usually best kept
 separate. Also separate cleanups from functional changes. See the
-Notmuch source history (`git log`) for examples.
+Notmuch source history (**`git log`**) for examples.
 
 For in-depth discussion on the subject, see
 [Software Release Practice HOWTO](http://tldp.org/HOWTO/Software-Release-Practice-HOWTO/) by Eric S. Raymond.
@@ -74,8 +74,8 @@ See also
 on commit guidelines, including commit messages.
 
 It is customary to prefix the subject line with "lib:", "cli:", "emacs:",
-etc. depending on which part of Notmuch the commit is changing. See `git log`
-for examples.
+etc. depending on which part of Notmuch the commit is changing. See
+**`git log`** for examples.
 
 Wrap the lines to about 72 characters.
 
@@ -87,7 +87,7 @@ at the end, after a line containing "---".
 
 Notmuch has a test suite with fairly good coverage. At the very least, `make
 test` must pass after your changes. Therefore you must amend the tests if you
-make functional changes that have existing test coverage. Preferrably, you
+make functional changes that have existing test coverage. Preferably, you
 should add new tests for any new functionality, and it helps in getting your
 changes accepted.
 
@@ -116,6 +116,14 @@ update the Emacs documentation.
 If you make user visible changes, you should add an entry to the
 [`NEWS`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/NEWS) file.
 
+## Update command-line completion
+
+If you modify or add new features to the Notmuch command-line tools, it
+would be a nice bonus if you also updated the Notmuch command-line
+completion scripts under the `completion` directory of the Notmuch
+source. Not required, but nice to have, and definitely can be done
+afterwards.
+
 ## Subscribe to the Notmuch mailing list
 
 While strictly not required, it is advisable to subscribe to the
@@ -130,14 +138,14 @@ Once you have your changes ready in your local repository, you need to
 send them to the Notmuch mailing list. The simplest way is to use `git
 send-email` to send the patches directly from your repository:
 
-       git send-email --to notmuch@notmuchmail.org origin/master
+        git send-email --to notmuch@notmuchmail.org origin/master
 
 An alternative is to do this in two steps; first generating patch
 files (using `git format-patch`), and then sending the patch files to
 the mailing list (using `git send-email` or a mail client):
 
-       git format-patch origin/master
-       git send-email --to notmuch@notmuchmail.org *.patch
+        git format-patch origin/master
+        git send-email --to notmuch@notmuchmail.org *.patch
 
 Either way, using `git send-email` to actually send the patches is
 recommended. It may be distributed separately from git, typically in a
@@ -207,13 +215,19 @@ people to review your patches if you review theirs.
 
 ## Report bugs
 
-Send bug reports to the Notmuch mailing list. Preferrably prefix the
+Send bug reports to the Notmuch mailing list. Preferably prefix the
 subject line with "BUG:" or similar. Tag the message as a bug in
 [nmbug](http://notmuchmail.org/nmbug/).
 
 Even better, send a patch adding a "known broken" test to the test suite
 highlighting the issue.
 
+## Update the Notmuch website
+
+Update the Notmuch website, especially if you've landed a commit that
+changes or obsoletes information on the site. It's a wiki; see the
+[[instructions on how to edit the wiki|wikiwriteaccess]].
+
 ## Join the Notmuch IRC channel
 
 Patch review happens on the Notmuch mailing list, but there is plenty of