b3/1d34bd6f4757aae04bd77f69dc2a89baeb3156

   1 Return-Path: <Sebastian@SSpaeth.de>\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 F1CC34196F3\r
   6         for <notmuch@notmuchmail.org>; Mon, 29 Mar 2010 00:49:20 -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: -1.9\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-1.9] autolearn=ham\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 D1d2X+SKzMMC for <notmuch@notmuchmail.org>;\r
  16         Mon, 29 Mar 2010 00:49:20 -0700 (PDT)\r
  17 Received: from homiemail-a12.g.dreamhost.com (caiajhbdcbbj.dreamhost.com\r
  18         [208.97.132.119])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 405D64196F2\r
  20         for <notmuch@notmuchmail.org>; Mon, 29 Mar 2010 00:49:20 -0700 (PDT)\r
  21 Received: from sspaeth.de (mtec-hg-docking-1-dhcp-204.ethz.ch\r
  22         [129.132.133.204])\r
  23         by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 39009714060; \r
  24         Mon, 29 Mar 2010 00:49:18 -0700 (PDT)\r
  25 Received: by sspaeth.de (sSMTP sendmail emulation);\r
  26         Mon, 29 Mar 2010 09:49:16 +0200\r
  27 From: "Sebastian Spaeth" <Sebastian@SSpaeth.de>\r
  28 To: Michal Sojka <sojkam1@fel.cvut.cz>, David Edmondson <dme@dme.org>,\r
  29         notmuch@notmuchmail.org\r
  30 In-Reply-To: <87y6hdgfr3.fsf@steelpick.2x.cz>\r
  31 References: <87iq8o76r8.fsf@uf.hh.sledj.net> <87aatt2pf7.fsf@SSpaeth.de>\r
  32         <87y6hdgfr3.fsf@steelpick.2x.cz>\r
  33 Date: Mon, 29 Mar 2010 09:49:16 +0200\r
  34 Message-ID: <87pr2n1sar.fsf@SSpaeth.de>\r
  35 MIME-Version: 1.0\r
  36 Content-Type: text/plain; charset=us-ascii\r
  37 Subject: Re: [notmuch] JSON based emacs UI\r
  38 X-BeenThere: notmuch@notmuchmail.org\r
  39 X-Mailman-Version: 2.1.13\r
  40 Precedence: list\r
  41 List-Id: "Use and development of the notmuch mail system."\r
  42         <notmuch.notmuchmail.org>\r
  43 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  45 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  46 List-Post: <mailto:notmuch@notmuchmail.org>\r
  47 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  48 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  50 X-List-Received-Date: Mon, 29 Mar 2010 07:49:21 -0000\r
  51 \r
  52 On Sun, 28 Mar 2010 07:46:40 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
  53 > I don't think this can be solved only in Makefile. From my look at dme's\r
  54 > repo, he adds a new subcomand 'part', which is used by the UI. So if you\r
  55 > want to use the new UI and your other features, you need to merge the\r
  56 > things together.\r
  57 \r
  58 I agree that notmuch and notmuch.el need to be developed deployed in\r
  59 close cooperation. However, this bundling makes things a bit more\r
  60 complex to untangle. I am willing to e.g. add the -part improvement to\r
  61 my own branch of notmuch, but I want to follow dme's frontend closely.\r
  62 \r
  63 > To build my version of notmuch, I use an ugly script\r
  64 > (http://rtime.felk.cvut.cz/gitweb/notmuch.git/blob/refs/heads/debian-wsh:/wsh-buildpackage)\r
  65 > which first does a big octopus merge to combine several features to one\r
  66 > branch and then I build notmuch from there. The current state of my\r
  67 > integration can be seen at\r
  68 > http://rtime.felk.cvut.cz/gitweb/notmuch.git/shortlog/refs/heads/integration/features.\r
  69 \r
  70 Interesting, but a bit more complicated that I was originally thinking off.\r
  71 \r
  72 > This approach has a disadvantage that integration/features branch is\r
  73 > often rewritten (whenever I add, remove or change a patch) so that\r
  74 > others cannot track the branch. On the other side, the advantage is that\r
  75 > others can easily see which patches I have applied on top of master. If\r
  76 > Carl updates master, I just rerun the script and the updated integration\r
  77 > branch is ready (unless there is a merge conflict).\r
  78 \r
  79 Very nice.\r
  80 \r
  81 Sebastian\r