1 Return-Path: <beheerder@tekenbeetziekten.nl>
\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 2DE56431FB6
\r
6 for <notmuch@notmuchmail.org>; Sun, 3 Feb 2013 07:26:53 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
\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 ohp7oDa+ul51 for <notmuch@notmuchmail.org>;
\r
16 Sun, 3 Feb 2013 07:26:50 -0800 (PST)
\r
17 Received: from srv047132.webreus.nl (srv047132.webreus.nl [46.235.47.132])
\r
18 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
\r
19 (No client certificate requested)
\r
20 by olra.theworths.org (Postfix) with ESMTPS id 0E279431FAE
\r
21 for <notmuch@notmuchmail.org>; Sun, 3 Feb 2013 07:26:49 -0800 (PST)
\r
22 Received: (qmail 28155 invoked from network); 3 Feb 2013 16:26:45 +0100
\r
23 Received: from ip73-109-210-87.adsl2.static.versatel.nl (HELO PCvangebruike)
\r
25 by srv047132.webreus.nl with SMTP; 3 Feb 2013 16:26:43 +0100
\r
26 From: "Robert Mast" <beheerder@tekenbeetziekten.nl>
\r
27 To: "'David Bremner'" <david@tethera.net>
\r
28 References: <000001cdfcd9$82500f00$86f02d00$@nl>
\r
29 <CA+pa1O0mTxkj_FMQH_jXWajmUAKHWbMsB4Yhp_4UX7hnhwgBrg@mail.gmail.com>
\r
30 <000001ce0161$5da40990$18ec1cb0$@nl>
\r
31 <87a9rml9pm.fsf@zancas.localnet>
\r
32 In-Reply-To: <87a9rml9pm.fsf@zancas.localnet>
\r
33 Subject: RE: Reply all - issue
\r
34 Date: Sun, 3 Feb 2013 16:26:27 +0100
\r
35 Message-ID: <000001ce0222$d5f30420$81d90c60$@nl>
\r
37 Content-Type: text/plain;
\r
39 Content-Transfer-Encoding: quoted-printable
\r
40 X-Mailer: Microsoft Office Outlook 12.0
\r
41 Thread-Index: Ac4Bh0PMAEUftH8lRH6w+fV5DvJa7QAm1Gtg
\r
42 Content-Language: nl
\r
43 Cc: notmuch@notmuchmail.org
\r
44 X-BeenThere: notmuch@notmuchmail.org
\r
45 X-Mailman-Version: 2.1.13
\r
47 List-Id: "Use and development of the notmuch mail system."
\r
48 <notmuch.notmuchmail.org>
\r
49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
50 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
52 List-Post: <mailto:notmuch@notmuchmail.org>
\r
53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
55 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
56 X-List-Received-Date: Sun, 03 Feb 2013 15:26:53 -0000
\r
58 I committed a little patch on a memory-issue I found.
\r
60 Can someone look whether I used git the right way, or should I study git =
\r
61 send-email some further?
\r
63 -----Oorspronkelijk bericht-----
\r
64 Van: David Bremner [mailto:david@tethera.net]=20
\r
65 Verzonden: zaterdag 2 februari 2013 21:53
\r
67 CC: notmuch@notmuchmail.org
\r
68 Onderwerp: [Spam-verdenking][english 100%] RE: Reply all - issue
\r
70 Robert Mast <beheerder@tekenbeetziekten.nl> writes:
\r
73 > Anyone interested in me patching Notmuch, or shall I keep the changes=20
\r
79 If you have patches, and you want feedback on them, then you are of =
\r
80 course welcome to send them to the list. Previous experience suggests =
\r
81 us that it is often faster in the long run (in terms of actually getting =
\r
82 code into notmuch) to take time to work out the design issues before =
\r
83 starting coding. Some suggestions/comments:
\r
85 1) See http://notmuchmail.org/contributing/ for some general hints on
\r
86 contributing code to notmuch.
\r
88 2) Make sure whatever threading heuristic you use is deterministic, and
\r
89 robust in the face of messages arriving in different orders, and
\r
90 munging of headers by mailing lists (subjects in particular get
\r
91 munged fairly often). =20
\r
93 3) In particular, it seems important that "notmuch dump" followed by
\r
94 "notmuch restore" (possibly followed by notmuch new?) yields =
\r
96 or equivalent thread structure
\r
98 4) Since threading heuristics are a matter of taste (i.e. not everyone
\r
99 is convinced that the way Gmail does it is the way notmuch should),
\r
100 you'll need to make this configurable. One constraint is that the
\r
101 library itself (under ./lib) is should not read configuration files
\r
102 (or environment variables, although it violates this for debugging).
\r
103 This just means you will have to change the API to pass configuration
\r
104 information in to certain routines.
\r
106 5) I'd say it's more important that you can shut off the heuristic
\r
107 completely than have special handling for git (or other version
\r
108 control system) patch series. If you do decide to add some special
\r
109 handling for patch series, I'd suggest making it as generic as
\r
110 possible, perhaps a configurable list of (header, regex) values that
\r
111 disable the thread splitting heuristics.
\r
113 6) Decide how, if at all your design will support manually joining
\r
114 threads together. I think an acceptable answer would probably be
\r
115 "disable all thread splitting heuristics and rebuild the
\r
116 database". I'm not sure if it's feasible to do anything nicer than
\r
projects / notmuch-archives.git / blob