f2/be907067b6e5e634cb1a7ee597bb2c0ba17619

   1 Return-Path: <prvs=jrosenthal=73207fb16@jhu.edu>\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 6160E4196F0\r
   6         for <notmuch@notmuchmail.org>; Mon,  3 May 2010 12:44:32 -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: -4.2\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 HtWnl+R6N0pU for <notmuch@notmuchmail.org>;\r
  16         Mon,  3 May 2010 12:44:31 -0700 (PDT)\r
  17 Received: from ipex4.johnshopkins.edu (ipex4.johnshopkins.edu\r
  18         [128.220.161.141])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 346D1431FC1\r
  20         for <notmuch@notmuchmail.org>; Mon,  3 May 2010 12:44:31 -0700 (PDT)\r
  21 X-IronPort-Anti-Spam-Filtered: true\r
  22 X-IronPort-Anti-Spam-Result: AvsEABLF3kuA3DZF/2dsb2JhbACdJXG1AYhehRIE\r
  23 X-IronPort-AV: E=Sophos;i="4.52,320,1270440000"; d="scan'208";a="361791712"\r
  24 Received: from watt.gilman.jhu.edu ([128.220.54.69])\r
  25         by ipex4.johnshopkins.edu with ESMTP/TLS/ADH-AES256-SHA;\r
  26         03 May 2010 15:44:25 -0400\r
  27 Received: by watt.gilman.jhu.edu (Postfix, from userid 502)\r
  28         id C5A81502B0D; Mon,  3 May 2010 15:44:24 -0400 (EDT)\r
  29 From: Jesse Rosenthal <jrosenthal@jhu.edu>\r
  30 To: Mark Anderson <MarkR.Anderson@amd.com>,\r
  31         Servilio Afre Puentes <servilio@gmail.com>, David Bremner <bremner@unb.ca>\r
  32 Subject: Re: bug tracking\r
  33 In-Reply-To: <3wd633at4co.fsf@testarossa.amd.com>\r
  34 References: <87d3xr8p6m.fsf@servo.finestructure.net>\r
  35         <87wrvz2xt5.fsf@convex-new.cs.unb.ca>\r
  36         <87sk6icbh2.fsf@yoom.home.cworth.org>\r
  37         <87wrvrzqca.fsf@servo.finestructure.net>\r
  38         <87k4rrve6x.fsf@rocinante.cs.unb.ca>\r
  39         <o2tb22065d01004291048vf347c019rb8c22d69aa06fa0c@mail.gmail.com>\r
  40         <3wd633at4co.fsf@testarossa.amd.com>\r
  41 User-Agent: Notmuch/0.3.1-18-g688e1e7 (http://notmuchmail.org) Emacs/23.1.1\r
  42         (i386-apple-darwin9.7.0)\r
  43 Date: Mon, 03 May 2010 15:44:24 -0400\r
  44 Message-ID: <m1hbmokbxj.fsf@watt.gilman.jhu.edu>\r
  45 MIME-Version: 1.0\r
  46 Content-Type: text/plain; charset=us-ascii\r
  47 Cc: "notmuch@notmuchmail.org" <notmuch@notmuchmail.org>\r
  48 X-BeenThere: notmuch@notmuchmail.org\r
  49 X-Mailman-Version: 2.1.13\r
  50 Precedence: list\r
  51 List-Id: "Use and development of the notmuch mail system."\r
  52         <notmuch.notmuchmail.org>\r
  53 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  55 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  56 List-Post: <mailto:notmuch@notmuchmail.org>\r
  57 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  58 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  59         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  60 X-List-Received-Date: Mon, 03 May 2010 19:44:32 -0000\r
  61 \r
  62 Just a response to some of Mark's points, re. the very rough prototype I\r
  63 mentioned in another email in this thread:\r
  64 \r
  65 id:m1k4rkkchy.fsf@watt.gilman.jhu.edu\r
  66 \r
  67 All of my answers are based on my current implementation, and don't\r
  68 necessarily reflect the best possible way to address these problems.\r
  69 \r
  70 On Thu, 29 Apr 2010 14:01:59 -0600, Mark Anderson <MarkR.Anderson@amd.com> wrote\r
  71 > Wouldn't it be good to have a timestamp associated with the application\r
  72 > of a tag, especially if you're going to manage a bug workflow with\r
  73 > tags?\r
  74 \r
  75 I sort of fake this by having timestamps come with pushing. Of course\r
  76 then it doesn't reflect the time of the tagging, but the time of the\r
  77 pushing. But if there were an internal db timestamp on the tag, that\r
  78 might be even better.\r
  79 \r
  80 > You'll be going cross geography, so UTC sounds nice.\r
  81 \r
  82 Yeah, I should change it to that.\r
  83 \r
  84 > But what happens if a bug goes from OPEN->CLOSED->REOPENED->CLOSED->...,\r
  85 > can you track that state with a simple tag cloud?\r
  86 \r
  87 Depends if you push in intermediate states. It will be recorded as\r
  88 prefaced with a + or - depending. See the link I give to a sample public\r
  89 log in the announcement email. The file that you push to/pull from will\r
  90 thus have a whole history for each tag in the namespace. Note that it\r
  91 will be "reduced" before being applied to your current db, when you\r
  92 pull.\r
  93 \r
  94 > How would you handle conflicts for the bug tracker?  Suppose two people\r
  95 > close the bug in different ways, and one fix goes through several state\r
  96 > switches before being committed to a globally visible repository.\r
  97 \r
  98 The tag would only be in your inbox in its latest state. (See above\r
  99 about "reducing" before applying.) But you can see the history for any\r
 100 msg-id.\r
 101 \r
 102 > Does this really work with distributed development?\r
 103 \r
 104 No idea. Worth a try.\r
 105 \r
 106 Best,\r
 107 Jesse\r
 108 \r
 109 \r