you get there. DON'T PANIC.
The headlines below act as a checklist. Not all of them apply in all
-situations; use common sense.
+situations. Use your best judgment, and the Notmuch community will
+help out as needed.
[[!toc levels=2]]
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 https://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
The Notmuch code base follows a fairly uniform coding style. See the existing
code around your changes, and read
-[`devel/STYLE`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/devel/STYLE)
+[`devel/STYLE`](https://git.notmuchmail.org/git/notmuch/blob/HEAD:/devel/STYLE)
in the Notmuch source. It's not difficult to get it right, and may save you an
extra review round.
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.
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.
approach also for adding new features.
See
-[`test/README`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/test/README)
+[`test/README`](https://git.notmuchmail.org/git/notmuch/blob/HEAD:/test/README)
in the Notmuch source for further information.
## Update the documentation
If you modify or add new features to the Notmuch Emacs UI, you should
update the Emacs documentation.
+If you add a new keybinding, update `devel/emacs-keybindings.org`. As
+much as possible, try to be consistent between modes.
+
## Update NEWS
If you make user visible changes, you should add an entry to the
-[`NEWS`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/NEWS) file.
+[`NEWS`](https://git.notmuchmail.org/git/notmuch/blob/HEAD:/NEWS) file.
+
+In practice adding NEWS items can be done later during the release
+process, but then you typically get a one line mention, if at all.
## Update command-line completion
## Subscribe to the Notmuch mailing list
While strictly not required, it is advisable to subscribe to the
-[Notmuch mailing list](http://notmuchmail.org/mailman/listinfo/notmuch)
+[Notmuch mailing list](https://nmbug.notmuchmail.org/list/)
before submitting patches.
## Send your patches to the mailing list
Changes to Notmuch are contributed as [emailed
-patches](http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Public-Large-Project).
+patches](http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Public-Project-over-Email).
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:
extra information you want to share that is not really part of the
commit messages, it is advisable to write a cover letter to give an
overview of your work. See the
-[Notmuch mailing list archives](http://notmuchmail.org/pipermail/notmuch/)
+[Notmuch mailing list archives](https://nmbug.notmuchmail.org/nmweb/)
for examples. Use the `--cover-letter` option of `git format-patch`,
or `--compose` option of `git send-email`.
When you're developing an email tool, all the problems start looking
like email. This applies to patch and bug tracking as well. The
-Notmuch project uses [nmbug](http://notmuchmail.org/nmbug/) for
+Notmuch project uses [nmbug](https://notmuchmail.org/nmbug/) for
tracking. The Notmuch developers will tag your patches too, making
them show up in the
-[nmbug status page](http://nmbug.tethera.net/status/), but requesting
+[nmbug status page](https://nmbug.notmuchmail.org/status/), but requesting
access and tagging your patches yourself will be helpful in the long
run.
changes. You are expected to follow up on the review comments you
receive, either by discussing the comments and the code, or modifying
your patches. Again, see the [Notmuch mailing list
-archives](http://notmuchmail.org/pipermail/notmuch/) for examples.
+archives](https://nmbug.notmuchmail.org/nmweb) for examples.
## Send another round addressing review comments
there are no hard rules. Usually the message-id reference to the
previous version is sufficient and preferred.
-Tag the old patches obsolete in [nmbug](http://notmuchmail.org/nmbug/)
+Tag the old patches obsolete in [nmbug](https://notmuchmail.org/nmbug/)
if you have access.
## Review other people's work
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/).
+[nmbug](https://notmuchmail.org/nmbug/).
Even better, send a patch adding a "known broken" test to the test suite
highlighting the issue.
## Join the Notmuch IRC channel
Patch review happens on the Notmuch mailing list, but there is plenty of
-discussion going on in the freenode #notmuch IRC channel. See
-[freenode.net/irc_servers.shtml](http://freenode.net/irc_servers.shtml)
+discussion going on in the libera #notmuch IRC channel. See
+[libera.chat/guides/connect](https://libera.chat/guides/connect)
for information how to get there.
projects / notmuch-wiki / blobdiff