Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id F1CC34196F3 for ; Mon, 29 Mar 2010 00:49:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1d2X+SKzMMC for ; Mon, 29 Mar 2010 00:49:20 -0700 (PDT) Received: from homiemail-a12.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by olra.theworths.org (Postfix) with ESMTP id 405D64196F2 for ; Mon, 29 Mar 2010 00:49:20 -0700 (PDT) Received: from sspaeth.de (mtec-hg-docking-1-dhcp-204.ethz.ch [129.132.133.204]) by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 39009714060; Mon, 29 Mar 2010 00:49:18 -0700 (PDT) Received: by sspaeth.de (sSMTP sendmail emulation); Mon, 29 Mar 2010 09:49:16 +0200 From: "Sebastian Spaeth" To: Michal Sojka , David Edmondson , notmuch@notmuchmail.org In-Reply-To: <87y6hdgfr3.fsf@steelpick.2x.cz> References: <87iq8o76r8.fsf@uf.hh.sledj.net> <87aatt2pf7.fsf@SSpaeth.de> <87y6hdgfr3.fsf@steelpick.2x.cz> Date: Mon, 29 Mar 2010 09:49:16 +0200 Message-ID: <87pr2n1sar.fsf@SSpaeth.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [notmuch] JSON based emacs UI X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 07:49:21 -0000 On Sun, 28 Mar 2010 07:46:40 +0200, Michal Sojka wrote: > I don't think this can be solved only in Makefile. From my look at dme's > repo, he adds a new subcomand 'part', which is used by the UI. So if you > want to use the new UI and your other features, you need to merge the > things together. I agree that notmuch and notmuch.el need to be developed deployed in close cooperation. However, this bundling makes things a bit more complex to untangle. I am willing to e.g. add the -part improvement to my own branch of notmuch, but I want to follow dme's frontend closely. > To build my version of notmuch, I use an ugly script > (http://rtime.felk.cvut.cz/gitweb/notmuch.git/blob/refs/heads/debian-wsh:/wsh-buildpackage) > which first does a big octopus merge to combine several features to one > branch and then I build notmuch from there. The current state of my > integration can be seen at > http://rtime.felk.cvut.cz/gitweb/notmuch.git/shortlog/refs/heads/integration/features. Interesting, but a bit more complicated that I was originally thinking off. > This approach has a disadvantage that integration/features branch is > often rewritten (whenever I add, remove or change a patch) so that > others cannot track the branch. On the other side, the advantage is that > others can easily see which patches I have applied on top of master. If > Carl updates master, I just rerun the script and the updated integration > branch is ready (unless there is a merge conflict). Very nice. Sebastian