From: David Bremner <david@tethera.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
 Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: [PATCH v3 16/16] add "notmuch reindex" subcommand
In-Reply-To: <1454272801-23623-17-git-send-email-dkg@fifthhorseman.net>
References: <1454272801-23623-1-git-send-email-dkg@fifthhorseman.net>
 <1454272801-23623-17-git-send-email-dkg@fifthhorseman.net>
User-Agent: Notmuch/0.21+26~g9404723 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Sun, 28 Feb 2016 11:05:37 -0400
Message-ID: <87h9gs50zi.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> This new subcommand takes a set of search terms, and re-indexes the
> list of matching messages using the supplied options.
>
> This can be used to index the cleartext of encrypted messages with
> something like:
>
>  notmuch reindex --try-decrypt \
>     tag:encrypted and not tag:index-decrypted

I haven't reviewed this patch yet.  Before I do I'd like to discuss the
issue of the apparent existing bug in thread handling that it exposes[1].

Assuming that analysis is correct (and I have no reason not to believe
so), the bug is in existing notmuch code and not related to this
change. On the other hand, currently users have to work a bit to expose
this bug, while this command would be inherently buggy (through no fault
of it's own) from introduction.  With my release manager hat on, I'm not
very happy with the hypothetical announcement "We have this new command,
but it will break your threads". So what I'd like to understand is to
what extent the reindex command, with the current notmuch codebase
(i.e. no new ghost message code), is "suitable for release".

One option would be to merge a version of most of the proposed changes
(with some minor updates), and leave the re-index (and maybe python
bindings changes) for a second series.


[1]: id:871t8ko50r.fsf@alice.fifthhorseman.net