9c/7a2f6c70f63c4ba1d71db3ab2e3a7d39bada9c

   1 Return-Path: <amdragon@mit.edu>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id AE1DE431FAF\r
   6         for <notmuch@notmuchmail.org>; Thu, 10 Jul 2014 19:58:10 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id kObUhyMx1zbp for <notmuch@notmuchmail.org>;\r
  16         Thu, 10 Jul 2014 19:58:04 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu\r
  18         [18.9.25.13])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 60D67431FAE\r
  22         for <notmuch@notmuchmail.org>; Thu, 10 Jul 2014 19:58:04 -0700 (PDT)\r
  23 X-AuditID: 1209190d-f79c06d000002f07-c7-53bf52bb490b\r
  24 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
  25         (using TLS with cipher AES256-SHA (256/256 bits))\r
  26         (Client did not present a certificate)\r
  27         by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP\r
  28         id B0.50.12039.BB25FB35; Thu, 10 Jul 2014 22:58:03 -0400 (EDT)\r
  29 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
  30         by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s6B2w2eR030201; \r
  31         Thu, 10 Jul 2014 22:58:02 -0400\r
  32 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  33         (authenticated bits=0)\r
  34         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  35         by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6B2w0HB014386\r
  36         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
  37         Thu, 10 Jul 2014 22:58:01 -0400\r
  38 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
  39         (envelope-from <amdragon@mit.edu>)\r
  40         id 1X5R28-00061m-0b; Thu, 10 Jul 2014 22:58:00 -0400\r
  41 From: Austin Clements <amdragon@MIT.EDU>\r
  42 To: notmuch@notmuchmail.org\r
  43 Subject: Proposal: Features instead of versions\r
  44 User-Agent: Notmuch/0.18+42~gfea7a41 (http://notmuchmail.org) Emacs/23.4.1\r
  45         (i486-pc-linux-gnu)\r
  46 Date: Thu, 10 Jul 2014 22:57:59 -0400\r
  47 Message-ID: <87sim8ob48.fsf@awakening.csail.mit.edu>\r
  48 MIME-Version: 1.0\r
  49 Content-Type: text/plain; charset=us-ascii\r
  50 X-Brightmail-Tracker:\r
  51  H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUixCmqrbs7aH+wwafbOhZN050trt+cyezA\r
  52         5HHr/mt2j2erbjEHMEVx2aSk5mSWpRbp2yVwZcxa95SlYC9/xZoDGg2Ml3i6GDk5JARMJCa+\r
  53         6WCGsMUkLtxbz9bFyMUhJDCbSWLtw13MEM5GRok5S18yQTinmSTm7DwEVbaEUWLN1Ltg/WwC\r
  54         GhLb9i9nBLFFBKQldt6dzQpiMwsoS7xYM4Wli5GDQ1hAX2L3rQwQU1QgTuLtbRuQChYBVYk3\r
  55         s/6BdfICXfT65g4oW1Di5MwnLBBTtCRu/HvJNIGRfxaS1CwkqQWMTKsYZVNyq3RzEzNzilOT\r
  56         dYuTE/PyUot0jfRyM0v0UlNKNzGCg06Sdwfju4NKhxgFOBiVeHhPrNkXLMSaWFZcmXuIUZKD\r
  57         SUmU19Zif7AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4Z3EA53pTEyqrUonyYlDQHi5I471tr\r
  58         q2AhgfTEktTs1NSC1CKYrAwHh5IE75ZAoEbBotT01Iq0zJwShDQTByfIcB6g4ZkgNbzFBYm5\r
  59         xZnpEPlTjIpS4rxhAUAJAZBERmkeXC8sKbxiFAd6RZh3Jkg7DzChwHW/AhrMBDTY2mIPyOCS\r
  60         RISUVANjsdYTkTmM50W/rNrB1Vrdaxp3hmV5Y/DM0im9Rsna15fGqMep3uhIl39srcN7Y+ou\r
  61         6873ZruTz6sv+PL6vO4H0/5JZ1IfPmu8cGeucP0B7k+i3q7R233/zPJ/cWOx6ZcpNxPDq92q\r
  62         934s6V4WbXo5xURk66YHay2+xtcauuzgstn3892ioLBDSizFGYmGWsxFxYkA6mPP2+UCAAA=\r
  63 X-BeenThere: notmuch@notmuchmail.org\r
  64 X-Mailman-Version: 2.1.13\r
  65 Precedence: list\r
  66 List-Id: "Use and development of the notmuch mail system."\r
  67         <notmuch.notmuchmail.org>\r
  68 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  69         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  70 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  71 List-Post: <mailto:notmuch@notmuchmail.org>\r
  72 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  73 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  74         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  75 X-List-Received-Date: Fri, 11 Jul 2014 02:58:11 -0000\r
  76 \r
  77 I believe our current approach to database schema changes is\r
  78 inhibiting the evolution of Notmuch's features and would like to\r
  79 propose what I think is lighter-weight solution.\r
  80 \r
  81 Currently, our database schema is versioned and each database schema\r
  82 change must occur "atomically" in Notmuch's development history:\r
  83 before some commit, Notmuch uses version N, after that commit, it uses\r
  84 version N+1.  Hence, each new schema version can introduce only one\r
  85 change, the task of developing a schema change falls on a single\r
  86 person, and it must all happen and be perfect in a single commit\r
  87 series.  This makes introducing a new schema version hard.  We've seen\r
  88 only two schema changes in the history of Notmuch.\r
  89 \r
  90 I'd like to propose that we switch to a "feature set", recorded in a\r
  91 database field.  The recent introduction of boolean folder terms would\r
  92 be a "feature" (and the lack of that feature would imply probabilistic\r
  93 folder terms).  Likewise, the file terms added in version 1 would be a\r
  94 "feature".\r
  95 \r
  96 The upgrade process would be structured around the delta between the\r
  97 database's feature set and the desired feature set.  For many things,\r
  98 it would be easy to support databases both with and without a feature,\r
  99 which would enable "unstable" features that can be developed and\r
 100 tested over time, and different features could be under development in\r
 101 parallel.  We can also mark features as required or optional for\r
 102 opening the database in read mode and replace our current unknown\r
 103 version warning (which the user can't act on in any useful way) with\r
 104 either no warning or a straight failure.\r
 105 \r
 106 I've done some of this for my ghost messages support (restructuring\r
 107 upgrade, unstable features, and supporting both the current schema and\r
 108 the new schema), and it was simple and worked nicely.  This is also very\r
 109 similar to how ext4 works [1].\r
 110 \r
 111 Thoughts?\r
 112 \r
 113 \r
 114 [1] https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block\r
 115 fields 0x5C through 0x64.\r