From: "Robert Mast" <beheerder@tekenbeetziekten.nl>
To: "'David Bremner'" <david@tethera.net>
References: <000001cdfcd9$82500f00$86f02d00$@nl>
	<CA+pa1O0mTxkj_FMQH_jXWajmUAKHWbMsB4Yhp_4UX7hnhwgBrg@mail.gmail.com>
	<000001ce0161$5da40990$18ec1cb0$@nl>
	<87a9rml9pm.fsf@zancas.localnet>
In-Reply-To: <87a9rml9pm.fsf@zancas.localnet>
Subject: RE: Reply all - issue
Date: Sun, 3 Feb 2013 16:26:27 +0100
Message-ID: <000001ce0222$d5f30420$81d90c60$@nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Ac4Bh0PMAEUftH8lRH6w+fV5DvJa7QAm1Gtg
Content-Language: nl
Cc: notmuch@notmuchmail.org
Precedence: list

I committed a little patch on a memory-issue I found.

Can someone look whether I used git the right way, or should I study git =
send-email some further?

-----Oorspronkelijk bericht-----
Van: David Bremner [mailto:david@tethera.net]=20
Verzonden: zaterdag 2 februari 2013 21:53
Aan: Robert Mast
CC: notmuch@notmuchmail.org
Onderwerp: [Spam-verdenking][english 100%] RE: Reply all - issue

Robert Mast <beheerder@tekenbeetziekten.nl> writes:

>
> Anyone interested in me patching Notmuch, or shall I keep the changes=20
> to myself?
>

Hi Robert;

If you have patches, and you want feedback on them, then you are of =
course welcome to send them to the list.  Previous experience suggests =
us that it is often faster in the long run (in terms of actually getting =
code into notmuch) to take time to work out the design issues before =
starting coding. Some suggestions/comments:

1) See http://notmuchmail.org/contributing/ for some general hints on
   contributing code to notmuch.
            =20
2) Make sure whatever threading heuristic you use is deterministic, and
   robust in the face of messages arriving in different orders, and
   munging of headers by mailing lists (subjects in particular get
   munged fairly often). =20

3) In particular, it seems important that "notmuch dump" followed by
   "notmuch restore" (possibly followed by notmuch new?) yields =
unchanged
   or equivalent thread structure

4) Since threading heuristics are a matter of taste (i.e. not everyone
   is convinced that the way Gmail does it is the way notmuch should),
   you'll need to make this configurable. One constraint is that the
   library itself (under ./lib) is should not read configuration files
   (or environment variables, although it violates this for debugging).
   This just means you will have to change the API to pass configuration
   information in to certain routines.

5) I'd say it's more important that you can shut off the heuristic
   completely than have special handling for git (or other version
   control system) patch series.  If you do decide to add some special
   handling for patch series, I'd suggest making it as generic as
   possible, perhaps a configurable list of (header, regex) values that
   disable the thread splitting heuristics.

6) Decide how, if at all your design will support manually joining
   threads together.  I think an acceptable answer would probably be
   "disable all thread splitting heuristics and rebuild the
   database". I'm not sure if it's feasible to do anything nicer than
   that.

d




.