Re: [PATCH 2/2] notmuch-new: block database upgrades in default configuration.

diff --git a/c2/7f7bcfdc534499fb9589f4893fe5bc8ed9d17a b/c2/7f7bcfdc534499fb9589f4893fe5bc8ed9d17a
new file mode 100644 (file)
index 0000000..3644924
--- /dev/null
+++ b/c2/7f7bcfdc534499fb9589f4893fe5bc8ed9d17a
@@ -0,0 +1,110 @@
+Return-Path: <jrollins@finestructure.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 0EF21431FBD\r
+       for <notmuch@notmuchmail.org>; Sun, 23 Mar 2014 16:54:55 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.3\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id iA7mxs8RTtK9 for <notmuch@notmuchmail.org>;\r
+       Sun, 23 Mar 2014 16:54:51 -0700 (PDT)\r
+Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
+       [131.215.239.19])\r
+       by olra.theworths.org (Postfix) with ESMTP id 0DF84431FB6\r
+       for <notmuch@notmuchmail.org>; Sun, 23 Mar 2014 16:54:51 -0700 (PDT)\r
+Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
+       by fire-doxen-postvirus (Postfix) with ESMTP id 9C5162E50E08;\r
+       Sun, 23 Mar 2014 16:54:50 -0700 (PDT)\r
+X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new\r
+Received: from finestructure.net (unknown [198.129.209.100])\r
+       (Authenticated sender: jrollins)\r
+       by fire-doxen-submit (Postfix) with ESMTP id DFEE22E50B36;\r
+       Sun, 23 Mar 2014 16:54:49 -0700 (PDT)\r
+Received: by finestructure.net (Postfix, from userid 1000)\r
+       id 6B5CE600D3; Sun, 23 Mar 2014 16:54:49 -0700 (PDT)\r
+From: Jameson Graef Rollins <jrollins@finestructure.net>\r
+To: Jani Nikula <jani@nikula.org>, David Bremner <david@tethera.net>,\r
+       notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 2/2] notmuch-new: block database upgrades in default\r
+       configuration.\r
+In-Reply-To: <87ppldrocd.fsf@nikula.org>\r
+References: <87bnx4jyyp.fsf@servo.finestructure.net>\r
+       <1395541573-2417-1-git-send-email-david@tethera.net>\r
+       <1395541573-2417-3-git-send-email-david@tethera.net>\r
+       <87ppldrocd.fsf@nikula.org>\r
+User-Agent: Notmuch/0.17+134~g31849a1 (http://notmuchmail.org) Emacs/24.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Sun, 23 Mar 2014 16:54:47 -0700\r
+Message-ID: <8738i8eaig.fsf@servo.finestructure.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha256; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 23 Mar 2014 23:54:55 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+\r
+On Sun, Mar 23 2014, Jani Nikula <jani@nikula.org> wrote:\r
+> We really have very few configuration options, and so far none of them\r
+> are such that we could make the decision for the user. I think in this\r
+> case pushing the responsibility to the user would be just *us* being\r
+> paranoid. What does that tell our users?\r
+>\r
+> I also think the user should consider doing backups before upgrading\r
+> notmuch in the first place. I am generally more concerned about the user\r
+> doing a database dump of the old database version using the new notmuch\r
+> than doing the upgrade. (Although in this case I think we're fine unless\r
+> the user decides 'notmuch dump folder:important' is enough.)\r
+\r
+Sorry for the delay responding to this.\r
+\r
+I really think the right way to handle a database upgrade is:\r
+\r
+* fail notmuch new (with appropriate message) if run in quiet mode\r
+* prompt user yes/no to upgrade database otherwise\r
+\r
+This will allow all users to acknowledge the upgrade and do the\r
+appropriate thing, regardless of configuration, without adding a new\r
+config option.\r
+\r
+jamie.\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1\r
+\r
+iQIcBAEBCAAGBQJTL3RHAAoJEO00zqvie6q8jjAP/i3572zTTmCNCNattzg5B9m3\r
+AdeJPSFEEmLasQRVooqkigQpwiTGGGe8X2GaJpku+WXe9r9G4clW/CyNWFKOUQUJ\r
+2zcAwaBNfIoDEM4B8xs/yDi8ZeCRugCdFhih1NdV3jmsSYcBS+iAwsMFtlNTuk6P\r
+UYcWi8t75VLKTktTke0WHS6L+AYQFiT8fU86kLnyiUqcMCafycCpqlykPmiiSbaf\r
+kkwzIVHJyRyiMn1+HL1+rOBbBX5Equ0P3Lpesqc6O2/73ouRxsUKCSeiosWQdFaB\r
+uqE6le+/mhQQPB1SL4SPQjc2ZKOsidoMQ1l6o6UZS7wepzNKuaonIyzBG5RvF7VO\r
+8UQAjBn7nE2jIFW/RmcxxOEQj8lEMax93MjNFJ5YBP7dVUO7BCOFiFo1BzyQF9qZ\r
+C0o426s+YCTB5nKrSuP9l0uPVIrYh9P+ItWc5oiYp/S3kc8Ah6EioxqMe0LnTEwj\r
+sf0s1nKDUudGo9dIGKeNSsi3DgzCObNViaK80WtIMI4xZCQyC00HQeZYo5nZSmFg\r
+hf4kU13hy4/Sm9XmuhxD4v9Q0cazTNpGeQPHn5HZ3YSUUu1qYLAex4Rw3cgxjahL\r
+3lAJPNfLsuy6nJrI5lP6e8+WtzC+0q+Ultb9v/7ntIuSwIXk7OuSULWDfjc7ynee\r
+Kp26AARtkW4Mc8/ZDQDc\r
+=ybEH\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r