--- /dev/null
+Return-Path: <MarkR.Anderson@amd.com>\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 B93244196F0\r
+ for <notmuch@notmuchmail.org>; Thu, 29 Apr 2010 13:02:25 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.1\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,\r
+ RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham\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 3AKUlP9tc6Kt for <notmuch@notmuchmail.org>;\r
+ Thu, 29 Apr 2010 13:02:23 -0700 (PDT)\r
+Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com\r
+ [65.55.88.11])\r
+ by olra.theworths.org (Postfix) with ESMTP id EC36E431FC1\r
+ for <notmuch@notmuchmail.org>; Thu, 29 Apr 2010 13:02:22 -0700 (PDT)\r
+Received: from mail87-tx2-R.bigfish.com (10.9.14.253) by\r
+ TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id\r
+ 8.1.340.0; Thu, 29 Apr 2010 20:02:22 +0000\r
+Received: from mail87-tx2 (localhost.localdomain [127.0.0.1]) by\r
+ mail87-tx2-R.bigfish.com (Postfix) with ESMTP id 35E78C0835B;\r
+ Thu, 29 Apr 2010 20:02:22 +0000 (UTC)\r
+X-SpamScore: -16\r
+X-BigFish: VPS-16(zz1432P98dNa2dbKzz1202hzz6ff19h6d525hz32i2a8h43h61h)\r
+X-Spam-TCS-SCL: 0:0\r
+Received: from mail87-tx2 (localhost.localdomain [127.0.0.1]) by mail87-tx2\r
+ (MessageSwitch) id 1272571341499100_21101;\r
+ Thu, 29 Apr 2010 20:02:21 +0000 (UTC)\r
+Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.241]) by\r
+ mail87-tx2.bigfish.com (Postfix) with ESMTP id 76A27980050;\r
+ Thu, 29 Apr 2010 20:02:21 +0000 (UTC)\r
+Received: from ausb3extmailp01.amd.com (163.181.251.8) by\r
+ TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS)\r
+ id 14.0.482.44; Thu, 29 Apr 2010 20:02:19 +0000\r
+Received: from ausb3twp02.amd.com ([163.181.250.38]) by\r
+ ausb3extmailp01.amd.com (Switch-3.2.7/Switch-3.2.7) with SMTP id\r
+ o3TJsUEf009356; Thu, 29 Apr 2010 14:54:33 -0500\r
+X-WSS-ID: 0L1NMBI-02-HIN-02\r
+X-M-MSG: \r
+Received: from sausexhtp02.amd.com (sausexhtp02.amd.com [163.181.3.152])\r
+ (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate\r
+ requested) by ausb3twp02.amd.com (Tumbleweed MailGate 3.7.2) with ESMTP\r
+ id 22097C85B1; Thu, 29 Apr 2010 15:02:06 -0500 (CDT)\r
+Received: from optimon.amd.com (163.181.34.104) by sausexhtp02.amd.com\r
+ (163.181.3.152) with Microsoft SMTP Server (TLS) id 8.2.234.1;\r
+ Thu, 29 Apr 2010 15:02:15 -0500\r
+Received: from mhdc-ns01.amd.com (mhdc-ns01.amd.com [165.204.35.147]) by\r
+ optimon.amd.com (8.12.10/8.12.10) with ESMTP id o3TK2Flg010624;\r
+ Thu, 29 Apr 2010 15:02:15 -0500\r
+Received: from testarossa.amd.com (testarossa.amd.com [165.204.147.44]) by\r
+ mhdc-ns01.amd.com (8.13.8+Sun/8.13.8) with ESMTP id o3TK1xME016711;\r
+ Thu, 29 Apr 2010 14:01:59 -0600 (MDT)\r
+Received: (from manderso@localhost) by testarossa.amd.com\r
+ (8.13.1/8.13.1/Submit) id o3TK1xv6020241;\r
+ Thu, 29 Apr 2010 14:01:59 -0600\r
+X-Authentication-Warning: testarossa.amd.com: manderso set sender to\r
+ MarkR.Anderson@amd.com using -f\r
+From: Mark Anderson <MarkR.Anderson@amd.com>\r
+To: Servilio Afre Puentes <servilio@gmail.com>, David Bremner <bremner@unb.ca>\r
+Subject: Re: bug tracking\r
+In-Reply-To: <o2tb22065d01004291048vf347c019rb8c22d69aa06fa0c@mail.gmail.com>\r
+References: <87d3xr8p6m.fsf@servo.finestructure.net>\r
+ <87wrvz2xt5.fsf@convex-new.cs.unb.ca>\r
+ <87sk6icbh2.fsf@yoom.home.cworth.org>\r
+ <87wrvrzqca.fsf@servo.finestructure.net>\r
+ <87k4rrve6x.fsf@rocinante.cs.unb.ca>\r
+ <o2tb22065d01004291048vf347c019rb8c22d69aa06fa0c@mail.gmail.com>\r
+Date: Thu, 29 Apr 2010 14:01:59 -0600\r
+Message-ID: <3wd633at4co.fsf@testarossa.amd.com>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset="utf-8"\r
+Content-Transfer-Encoding: quoted-printable\r
+X-Reverse-DNS: unknown\r
+Cc: "notmuch@notmuchmail.org" <notmuch@notmuchmail.org>\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: Thu, 29 Apr 2010 20:02:25 -0000\r
+\r
+On Thu, 29 Apr 2010 12:48:38 -0500, Servilio Afre Puentes <servilio@gmail.c=\r
+om> wrote:\r
+> On 28 April 2010 16:34, David Bremner <bremner@unb.ca> wrote:\r
+> [...]\r
+> > Meanwhile Jesse Rosenthal and I started chatting about, and Jesse\r
+> > started implementing, some tools for grabbing remote collections of tags\r
+> > and merging them into their own namespace. =C2=A0This may give us a\r
+> > notmuch-oriented way of managing the mailing list a bit better as a kind\r
+> > of bug tracker. I don't want to promise things on Jesse's behalf, but I\r
+> > personally am holding off on further bug tracker experiments until I see\r
+> > how this works out.\r
+>=20\r
+> I have been playing in my head with the idea of using notmuch to track\r
+> bugs, thinking of ways it could be done. Using tags and searches this\r
+> should be fine, and even (if not right now, I am sure in the future we\r
+> will) easily see what bugs have patches/pull requests proposed[1].\r
+>=20\r
+> While reading your message, David, I think I've found and idea might\r
+> enable this: enabling the dump command to accept a search term. With\r
+> this in place, our bug database can be composed of the mail archive +\r
+> a dump of the tags used for bug management.\r
+>=20\r
+> There another wrinkle with this approach, but a solvable one I think:\r
+> the current implementation of the restore command will wipe all local\r
+> state for the related messages. This is really bad for people tracking\r
+> individually bugs/features in their local notmuch databases, e.g.:\r
+> using tags such as TODO, REVIEW, etc.\r
+>=20\r
+> But with a way of non-destructively applying a set of tags to a\r
+> messages we could have a distributed issue/feature/etc tracking system\r
+> that is 100% notmuch-based and message driven (PR for the feature, we\r
+> have to think forward!).\r
+>=20\r
+> IMHO this will allow for totally awesome workflows.\r
+>=20\r
+> And we should name it "notmuch issues" or "notmuch bugs".\r
+>=20\r
+> Servilio\r
+\r
+Wouldn't it be good to have a timestamp associated with the application\r
+of a tag, especially if you're going to manage a bug workflow with tags?\r
+\r
+You'll be going cross geography, so UTC sounds nice.\r
+\r
+But what happens if a bug goes from OPEN->CLOSED->REOPENED->CLOSED->...,\r
+can you track that state with a simple tag cloud?\r
+\r
+How would you handle conflicts for the bug tracker? Suppose two people\r
+close the bug in different ways, and one fix goes through several state\r
+switches before being committed to a globally visible repository.\r
+\r
+Does this really work with distributed development?\r
+\r
+Although a permutation of that question might be:\r
+\r
+What does a distributed bug tracker look like?\r
+\r
+You will have multiple bug DB's in different states, so do we default to\r
+having a tie-breaker "master" DB designated by the community?\r
+\r
+Distributed bug tracking - I'm certain it means different things to\r
+different people, perhaps we ought to specify what it means with a bit\r
+more clarity before jumping off and developing it.=20\r
+\r
+Nah, too much central control, just develop what you want, we'll bend it\r
+and the conversation about what it means until they fit. ;}\r
+\r
+Enjoy,\r
+-Mark\r
+\r
projects / notmuch-archives.git / commitdiff