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 11E6F4196F0 for ; Thu, 29 Apr 2010 10:48:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001] 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 6+48ylRDKboD for ; Thu, 29 Apr 2010 10:48:39 -0700 (PDT) Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com [74.125.82.53]) by olra.theworths.org (Postfix) with ESMTP id 25D82431FC1 for ; Thu, 29 Apr 2010 10:48:39 -0700 (PDT) Received: by wwe15 with SMTP id 15so936757wwe.26 for ; Thu, 29 Apr 2010 10:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mOlEqICcS+je1pdipNJ7OCyyLH4BcuDzeiArfA08XVs=; b=oSiCbEc+wbEST0rIvxkUT2GWwKmMOgHYa0srxyhdT2qW6nNb2o6r44/VqFmOpNeEVD cdUeU6QPV8ARhKBbJdowUzTH+Zpugr984DhiDVZ10JISHLuG57j5JqVClZ7EGp5Lld/v cAhpuXVo++6c9HfFLk9J8wiDdUdBk5Z5pIqR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nPuAqkCWuLilWexE2ojpZXhZupReHSsxTRWF3/c+eF5vlak/dM/DT+kPnWOqpbjTHi HUHK8S7uO4jOjSl9ExqR9G/UGluvWj0rkWMR8/DqSZitYSr5eXy+50YlAyQWxIiQwObE /KZU1K1vz9XZvoX5oHDTEfJ7lXLdyuC8WLlK8= MIME-Version: 1.0 Received: by 10.216.89.202 with SMTP id c52mr967447wef.84.1272563318066; Thu, 29 Apr 2010 10:48:38 -0700 (PDT) Received: by 10.216.133.155 with HTTP; Thu, 29 Apr 2010 10:48:37 -0700 (PDT) In-Reply-To: <87k4rrve6x.fsf@rocinante.cs.unb.ca> References: <87d3xr8p6m.fsf@servo.finestructure.net> <87wrvz2xt5.fsf@convex-new.cs.unb.ca> <87sk6icbh2.fsf@yoom.home.cworth.org> <87wrvrzqca.fsf@servo.finestructure.net> <87k4rrve6x.fsf@rocinante.cs.unb.ca> Date: Thu, 29 Apr 2010 19:48:38 +0200 Message-ID: Subject: Re: bug tracking From: Servilio Afre Puentes To: David Bremner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: notmuch@notmuchmail.org 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: Thu, 29 Apr 2010 17:48:40 -0000 On 28 April 2010 16:34, David Bremner wrote: [...] > Meanwhile Jesse Rosenthal and I started chatting about, and Jesse > started implementing, some tools for grabbing remote collections of tags > and merging them into their own namespace. =A0This may give us a > notmuch-oriented way of managing the mailing list a bit better as a kind > of bug tracker. I don't want to promise things on Jesse's behalf, but I > personally am holding off on further bug tracker experiments until I see > how this works out. I have been playing in my head with the idea of using notmuch to track bugs, thinking of ways it could be done. Using tags and searches this should be fine, and even (if not right now, I am sure in the future we will) easily see what bugs have patches/pull requests proposed[1]. While reading your message, David, I think I've found and idea might enable this: enabling the dump command to accept a search term. With this in place, our bug database can be composed of the mail archive + a dump of the tags used for bug management. There another wrinkle with this approach, but a solvable one I think: the current implementation of the restore command will wipe all local state for the related messages. This is really bad for people tracking individually bugs/features in their local notmuch databases, e.g.: using tags such as TODO, REVIEW, etc. But with a way of non-destructively applying a set of tags to a messages we could have a distributed issue/feature/etc tracking system that is 100% notmuch-based and message driven (PR for the feature, we have to think forward!). IMHO this will allow for totally awesome workflows. And we should name it "notmuch issues" or "notmuch bugs". Servilio [1] I like pull request because they are easier to manage: you don't need to resend the patch series when you need to update your work.