Re: WARNING: database upgrade coming
authorJameson Graef Rollins <jrollins@finestructure.net>
Mon, 17 Mar 2014 21:29:34 +0000 (14:29 +1700)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 18:00:48 +0000 (10:00 -0800)
fe/89f35efffe5d92a3c28763d754b97264d646d8 [new file with mode: 0644]

diff --git a/fe/89f35efffe5d92a3c28763d754b97264d646d8 b/fe/89f35efffe5d92a3c28763d754b97264d646d8
new file mode 100644 (file)
index 0000000..03d3e1d
--- /dev/null
@@ -0,0 +1,102 @@
+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 18582431FC0\r
+       for <notmuch@notmuchmail.org>; Mon, 17 Mar 2014 14:29:49 -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 wdoKtvfOk6Oa for <notmuch@notmuchmail.org>;\r
+       Mon, 17 Mar 2014 14:29:41 -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 3BA8A431FBD\r
+       for <notmuch@notmuchmail.org>; Mon, 17 Mar 2014 14:29:41 -0700 (PDT)\r
+Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
+       by fire-doxen-postvirus (Postfix) with ESMTP id 9B1EF3282FC;\r
+       Mon, 17 Mar 2014 14:29:38 -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 C22A3328306;\r
+       Mon, 17 Mar 2014 14:29:37 -0700 (PDT)\r
+Received: by finestructure.net (Postfix, from userid 1000)\r
+       id 405B5600C2; Mon, 17 Mar 2014 14:29:37 -0700 (PDT)\r
+From: Jameson Graef Rollins <jrollins@finestructure.net>\r
+To: David Bremner <david@tethera.net>, Jani Nikula <jani@nikula.org>,\r
+       Notmuch list <notmuch@notmuchmail.org>\r
+Subject: Re: WARNING: database upgrade coming\r
+In-Reply-To: <87eh20v7zc.fsf@zancas.localnet>\r
+References: <874n37a017.fsf@zancas.localnet>\r
+       <87txawkam3.fsf@servo.finestructure.net>\r
+       <87a9cood0l.fsf@nikula.org> <87eh20v7zc.fsf@zancas.localnet>\r
+User-Agent: Notmuch/0.17+134~g31849a1 (http://notmuchmail.org) Emacs/24.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Mon, 17 Mar 2014 14:29:34 -0700\r
+Message-ID: <87bnx4jyyp.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: Mon, 17 Mar 2014 21:29:49 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+\r
+On Mon, Mar 17 2014, David Bremner <david@tethera.net> wrote:\r
+> Jani Nikula <jani@nikula.org> writes:\r
+>> FWIW it should always be safe to interrupt the upgrade; I know we don't\r
+>> inform the user about this.\r
+>\r
+> With that in mind, would it be reasonable/worthwhile to print a 5 second (or so)\r
+> countdown before running the upgrade? But then people who run it\r
+> non-interactively would still automagically get the upgrade, just 5\r
+> seconds later.\r
+\r
+My vote would be that anything invasive like this should be done with an\r
+explicit "OK" from the user.  In otherwords, when a database upgrade is\r
+due, non-interactive usage of notmuch new should fail until the user has\r
+run notmuch new interactively and acknowledged that a db upgrade will be\r
+happening and that they're ok with it.\r
+\r
+jamie.\r
+\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1\r
+\r
+iQIcBAEBCAAGBQJTJ2k+AAoJEO00zqvie6q8XSkQAJFY150Zx7Xz5vtxjd7GP4xy\r
+EbslorO+qp3WaGEkOxDuweLTGSHsXEpT5O4z4lEd7MPNwXbnBqxeMllOUjYv0C5j\r
++2kHljTZKOoaZKAZG1hxfdPQvVBv+O467i2FXWVUDlmSSbKJ5e/cFhFiLJygzfJx\r
+t47MAgWcb+901QVZE86z+Zv71GLGwTJstDl0YEe4IiBbuvYI7ne4FyUWQLQj3BjD\r
+lRTfiBgoOo8nmIulr3cascz7Rl4J+wkWKKEDrtyDhOrharts7Wp7vWI+egHWeoTy\r
+IuoRBy65PQVUVFLOfmsxbUnXgawFhmVmY/QPZsvY67bkjECBHiygW+j56fUufQoA\r
+GaOZmn5Hq4RiVLlEBFz1TSz279gI5CWUlLDbO/6dLJeNQ4eJq1AGbZsa9IQE62KG\r
+D88QHwGgdmDhhUNOFDFh9eI0yI+zmEItTpdnie77nUik23x0jPIpgdYOEuobItk8\r
+dKiKFBSa1DsraozwOiiwLa/Jpim7H9HU3qGuPvKBZicpVKB2dwBqskMJsVcquhNU\r
+pUUExRagrJ7LxhIveLfcpGDN5bo1bIWPftjrVSYLQUG9Ha1knjfZW5vv3ywru1ED\r
+zJRhgvAkbGG7H/6/iadHoeu+oadAsoA89onho3zYksECXy5UlxKq/8PsSdPdMvTY\r
+m4Ro97bQf3T2IWw24jyg\r
+=ODmf\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r