Re: bug tracking

diff --git a/f2/be907067b6e5e634cb1a7ee597bb2c0ba17619 b/f2/be907067b6e5e634cb1a7ee597bb2c0ba17619
new file mode 100644 (file)
index 0000000..839c459
--- /dev/null
+++ b/f2/be907067b6e5e634cb1a7ee597bb2c0ba17619
@@ -0,0 +1,109 @@
+Return-Path: <prvs=jrosenthal=73207fb16@jhu.edu>\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 6160E4196F0\r
+       for <notmuch@notmuchmail.org>; Mon,  3 May 2010 12:44:32 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -4.2\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5\r
+       tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 HtWnl+R6N0pU for <notmuch@notmuchmail.org>;\r
+       Mon,  3 May 2010 12:44:31 -0700 (PDT)\r
+Received: from ipex4.johnshopkins.edu (ipex4.johnshopkins.edu\r
+       [128.220.161.141])\r
+       by olra.theworths.org (Postfix) with ESMTP id 346D1431FC1\r
+       for <notmuch@notmuchmail.org>; Mon,  3 May 2010 12:44:31 -0700 (PDT)\r
+X-IronPort-Anti-Spam-Filtered: true\r
+X-IronPort-Anti-Spam-Result: AvsEABLF3kuA3DZF/2dsb2JhbACdJXG1AYhehRIE\r
+X-IronPort-AV: E=Sophos;i="4.52,320,1270440000"; d="scan'208";a="361791712"\r
+Received: from watt.gilman.jhu.edu ([128.220.54.69])\r
+       by ipex4.johnshopkins.edu with ESMTP/TLS/ADH-AES256-SHA;\r
+       03 May 2010 15:44:25 -0400\r
+Received: by watt.gilman.jhu.edu (Postfix, from userid 502)\r
+       id C5A81502B0D; Mon,  3 May 2010 15:44:24 -0400 (EDT)\r
+From: Jesse Rosenthal <jrosenthal@jhu.edu>\r
+To: Mark Anderson <MarkR.Anderson@amd.com>,\r
+       Servilio Afre Puentes <servilio@gmail.com>, David Bremner <bremner@unb.ca>\r
+Subject: Re: bug tracking\r
+In-Reply-To: <3wd633at4co.fsf@testarossa.amd.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
+       <3wd633at4co.fsf@testarossa.amd.com>\r
+User-Agent: Notmuch/0.3.1-18-g688e1e7 (http://notmuchmail.org) Emacs/23.1.1\r
+       (i386-apple-darwin9.7.0)\r
+Date: Mon, 03 May 2010 15:44:24 -0400\r
+Message-ID: <m1hbmokbxj.fsf@watt.gilman.jhu.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\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: Mon, 03 May 2010 19:44:32 -0000\r
+\r
+Just a response to some of Mark's points, re. the very rough prototype I\r
+mentioned in another email in this thread:\r
+\r
+id:m1k4rkkchy.fsf@watt.gilman.jhu.edu\r
+\r
+All of my answers are based on my current implementation, and don't\r
+necessarily reflect the best possible way to address these problems.\r
+\r
+On Thu, 29 Apr 2010 14:01:59 -0600, Mark Anderson <MarkR.Anderson@amd.com> wrote\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\r
+> tags?\r
+\r
+I sort of fake this by having timestamps come with pushing. Of course\r
+then it doesn't reflect the time of the tagging, but the time of the\r
+pushing. But if there were an internal db timestamp on the tag, that\r
+might be even better.\r
+\r
+> You'll be going cross geography, so UTC sounds nice.\r
+\r
+Yeah, I should change it to that.\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
+Depends if you push in intermediate states. It will be recorded as\r
+prefaced with a + or - depending. See the link I give to a sample public\r
+log in the announcement email. The file that you push to/pull from will\r
+thus have a whole history for each tag in the namespace. Note that it\r
+will be "reduced" before being applied to your current db, when you\r
+pull.\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
+The tag would only be in your inbox in its latest state. (See above\r
+about "reducing" before applying.) But you can see the history for any\r
+msg-id.\r
+\r
+> Does this really work with distributed development?\r
+\r
+No idea. Worth a try.\r
+\r
+Best,\r
+Jesse\r
+\r
+\r