Re: [PATCH 9/9] add has: query prefix to search for specific properties
[notmuch-archives.git] / 9c / d4a07ac1e8d9c5ff0dc90549d33acca30affff
1 Return-Path: <MarkR.Anderson@amd.com>\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 B93244196F0\r
6         for <notmuch@notmuchmail.org>; Thu, 29 Apr 2010 13:02:25 -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: 0.1\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,\r
12         RCVD_IN_DNSWL_LOW=-0.7] 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 3AKUlP9tc6Kt for <notmuch@notmuchmail.org>;\r
16         Thu, 29 Apr 2010 13:02:23 -0700 (PDT)\r
17 Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com\r
18         [65.55.88.11])\r
19         by olra.theworths.org (Postfix) with ESMTP id EC36E431FC1\r
20         for <notmuch@notmuchmail.org>; Thu, 29 Apr 2010 13:02:22 -0700 (PDT)\r
21 Received: from mail87-tx2-R.bigfish.com (10.9.14.253) by\r
22         TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id\r
23         8.1.340.0; Thu, 29 Apr 2010 20:02:22 +0000\r
24 Received: from mail87-tx2 (localhost.localdomain [127.0.0.1])   by\r
25         mail87-tx2-R.bigfish.com (Postfix) with ESMTP id 35E78C0835B;\r
26         Thu, 29 Apr 2010 20:02:22 +0000 (UTC)\r
27 X-SpamScore: -16\r
28 X-BigFish: VPS-16(zz1432P98dNa2dbKzz1202hzz6ff19h6d525hz32i2a8h43h61h)\r
29 X-Spam-TCS-SCL: 0:0\r
30 Received: from mail87-tx2 (localhost.localdomain [127.0.0.1]) by mail87-tx2\r
31         (MessageSwitch) id 1272571341499100_21101;\r
32         Thu, 29 Apr 2010 20:02:21 +0000 (UTC)\r
33 Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.241]) by\r
34         mail87-tx2.bigfish.com (Postfix) with ESMTP id 76A27980050;\r
35         Thu, 29 Apr 2010 20:02:21 +0000 (UTC)\r
36 Received: from ausb3extmailp01.amd.com (163.181.251.8) by\r
37         TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS)\r
38         id 14.0.482.44; Thu, 29 Apr 2010 20:02:19 +0000\r
39 Received: from ausb3twp02.amd.com ([163.181.250.38])    by\r
40         ausb3extmailp01.amd.com (Switch-3.2.7/Switch-3.2.7) with SMTP id\r
41         o3TJsUEf009356; Thu, 29 Apr 2010 14:54:33 -0500\r
42 X-WSS-ID: 0L1NMBI-02-HIN-02\r
43 X-M-MSG: \r
44 Received: from sausexhtp02.amd.com (sausexhtp02.amd.com [163.181.3.152])\r
45         (using TLSv1 with cipher RC4-MD5 (128/128 bits))        (No client certificate\r
46         requested)      by ausb3twp02.amd.com (Tumbleweed MailGate 3.7.2) with ESMTP\r
47         id 22097C85B1;  Thu, 29 Apr 2010 15:02:06 -0500 (CDT)\r
48 Received: from optimon.amd.com (163.181.34.104) by sausexhtp02.amd.com\r
49         (163.181.3.152) with Microsoft SMTP Server (TLS) id 8.2.234.1;\r
50         Thu, 29 Apr 2010 15:02:15 -0500\r
51 Received: from mhdc-ns01.amd.com (mhdc-ns01.amd.com [165.204.35.147])   by\r
52         optimon.amd.com (8.12.10/8.12.10) with ESMTP id o3TK2Flg010624;\r
53         Thu, 29 Apr 2010 15:02:15 -0500\r
54 Received: from testarossa.amd.com (testarossa.amd.com [165.204.147.44]) by\r
55         mhdc-ns01.amd.com (8.13.8+Sun/8.13.8) with ESMTP id o3TK1xME016711;\r
56         Thu, 29 Apr 2010 14:01:59 -0600 (MDT)\r
57 Received: (from manderso@localhost)     by testarossa.amd.com\r
58         (8.13.1/8.13.1/Submit) id o3TK1xv6020241;\r
59         Thu, 29 Apr 2010 14:01:59 -0600\r
60 X-Authentication-Warning: testarossa.amd.com: manderso set sender to\r
61         MarkR.Anderson@amd.com using -f\r
62 From: Mark Anderson <MarkR.Anderson@amd.com>\r
63 To: Servilio Afre Puentes <servilio@gmail.com>, David Bremner <bremner@unb.ca>\r
64 Subject: Re: bug tracking\r
65 In-Reply-To: <o2tb22065d01004291048vf347c019rb8c22d69aa06fa0c@mail.gmail.com>\r
66 References: <87d3xr8p6m.fsf@servo.finestructure.net>\r
67         <87wrvz2xt5.fsf@convex-new.cs.unb.ca>\r
68         <87sk6icbh2.fsf@yoom.home.cworth.org>\r
69         <87wrvrzqca.fsf@servo.finestructure.net>\r
70         <87k4rrve6x.fsf@rocinante.cs.unb.ca>\r
71         <o2tb22065d01004291048vf347c019rb8c22d69aa06fa0c@mail.gmail.com>\r
72 Date: Thu, 29 Apr 2010 14:01:59 -0600\r
73 Message-ID: <3wd633at4co.fsf@testarossa.amd.com>\r
74 MIME-Version: 1.0\r
75 Content-Type: text/plain; charset="utf-8"\r
76 Content-Transfer-Encoding: quoted-printable\r
77 X-Reverse-DNS: unknown\r
78 Cc: "notmuch@notmuchmail.org" <notmuch@notmuchmail.org>\r
79 X-BeenThere: notmuch@notmuchmail.org\r
80 X-Mailman-Version: 2.1.13\r
81 Precedence: list\r
82 List-Id: "Use and development of the notmuch mail system."\r
83         <notmuch.notmuchmail.org>\r
84 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
85         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
86 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
87 List-Post: <mailto:notmuch@notmuchmail.org>\r
88 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
89 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
90         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
91 X-List-Received-Date: Thu, 29 Apr 2010 20:02:25 -0000\r
92 \r
93 On Thu, 29 Apr 2010 12:48:38 -0500, Servilio Afre Puentes <servilio@gmail.c=\r
94 om> wrote:\r
95 > On 28 April 2010 16:34, David Bremner <bremner@unb.ca> wrote:\r
96 > [...]\r
97 > > Meanwhile Jesse Rosenthal and I started chatting about, and Jesse\r
98 > > started implementing, some tools for grabbing remote collections of tags\r
99 > > and merging them into their own namespace. =C2=A0This may give us a\r
100 > > notmuch-oriented way of managing the mailing list a bit better as a kind\r
101 > > of bug tracker. I don't want to promise things on Jesse's behalf, but I\r
102 > > personally am holding off on further bug tracker experiments until I see\r
103 > > how this works out.\r
104 >=20\r
105 > I have been playing in my head with the idea of using notmuch to track\r
106 > bugs, thinking of ways it could be done. Using tags and searches this\r
107 > should be fine, and even (if not right now, I am sure in the future we\r
108 > will) easily see what bugs have patches/pull requests proposed[1].\r
109 >=20\r
110 > While reading your message, David, I think I've found and idea might\r
111 > enable this: enabling the dump command to accept a search term. With\r
112 > this in place, our bug database can be composed of the mail archive +\r
113 > a dump of the tags used for bug management.\r
114 >=20\r
115 > There another wrinkle with this approach, but a solvable one I think:\r
116 > the current implementation of the restore command will wipe all local\r
117 > state for the related messages. This is really bad for people tracking\r
118 > individually bugs/features in their local notmuch databases, e.g.:\r
119 > using tags such as TODO, REVIEW, etc.\r
120 >=20\r
121 > But with a way of non-destructively applying a set of tags to a\r
122 > messages we could have a distributed issue/feature/etc tracking system\r
123 > that is 100% notmuch-based and message driven (PR for the feature, we\r
124 > have to think forward!).\r
125 >=20\r
126 > IMHO this will allow for totally awesome workflows.\r
127 >=20\r
128 > And we should name it "notmuch issues" or "notmuch bugs".\r
129 >=20\r
130 > Servilio\r
131 \r
132 Wouldn't it be good to have a timestamp associated with the application\r
133 of a tag, especially if you're going to manage a bug workflow with tags?\r
134 \r
135 You'll be going cross geography, so UTC sounds nice.\r
136 \r
137 But what happens if a bug goes from OPEN->CLOSED->REOPENED->CLOSED->...,\r
138 can you track that state with a simple tag cloud?\r
139 \r
140 How would you handle conflicts for the bug tracker?  Suppose two people\r
141 close the bug in different ways, and one fix goes through several state\r
142 switches before being committed to a globally visible repository.\r
143 \r
144 Does this really work with distributed development?\r
145 \r
146 Although a permutation of that question might be:\r
147 \r
148 What does a distributed bug tracker look like?\r
149 \r
150 You will have multiple bug DB's in different states, so do we default to\r
151 having a tie-breaker "master" DB designated by the community?\r
152 \r
153 Distributed bug tracking - I'm certain it means different things to\r
154 different people, perhaps we ought to specify what it means with a bit\r
155 more clarity before jumping off and developing it.=20\r
156 \r
157 Nah, too much central control, just develop what you want, we'll bend it\r
158 and the conversation about what it means until they fit. ;}\r
159 \r
160 Enjoy,\r
161 -Mark\r
162 \r