+
+Audit everything for dealing with out-of-memory (and drop xutil.c).
+
+Write a test suite.
+
+Achieve 100% test coverage with the test suite.
+
+Think about this race condition:
+
+ A client executes "notmuch search"
+ Then executes "notmuch show" on a thread
+ While user is reading, new mail is added to database for the thread
+ Client asks for the thread to be archived.
+
+ The bug here is that email that was never read will be
+ archived. That's bad. The fix for the above is for the client to
+ archive the individual messages already retrieved and shown, not
+ the thread. (And in fact, we don't even have functions for removing
+ tags on threads.)
+
+ But this one is harder to fix:
+
+ A client executes "notmuch search"
+ While user is reading, new mail is added to database for the thread
+ Client asks for a thread to be archived.
+
+ To support this operation, (archiving a thread without even seeing
+ the individual messages), we might need to provide a command to
+ archive a thread as a whole. The problem is actually easy to fix
+ for a persistent client. It can onto the originally retrieved
+ thread objects which can hold onto the originally retrieved
+ messages. So archiving those thread objects, (and not newly created
+ thread objects), will be safe.
+
+ It's harder to fix the non-persistent "notmuch" client. One
+ approach is to simply tell the user to not run "notmuch new"
+ between reading the results of "notmuch search" and executing
+ "notmuch archive-thread" (or whatever we name it).