patch queue

patch queue

[Jameson Rollins]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

Hey, Carl.  I've noticed that you've been applying some patches that
were recently sent to the list, out of order from the chronological
queue of patches that were sent to the list.  I'm a fan of the recently
applied patches, but I'm curious about what your plans are for the older
patches in the quene.  Are you still planning on processing them?
Should the older patches be rebased against the current master and
resent?

I'm not at all trying to be pushy; there's just some older stuff in the
queue that I would really like to see applied, such as folder-based
tagging, json output, and some of the emacs UI improvements.

Thanks so much for the info.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: patch queue

[Michal Sojka]

On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins <jrollins@finestructure.net> wrote:
> I'm not at all trying to be pushy; there's just some older stuff in the
> queue that I would really like to see applied, such as folder-based
> tagging

Hi,

as for the folder-based tagging patch sent by myself, it needs some
improvement. I'm waiting for merge of testing ifrastructure in order to
write tests for the patch. The testing infrastructure is GPLv2 and we
would like to use it under GPLv3 and changing this takes some time. I
guess, Carl waits for this as well.

Michal

Re: patch queue

[Sebastian Spaeth]

On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins <jrollins@finestructure.net> wrote:
> Hey, Carl.  I've noticed that you've been applying some patches that
> were recently sent to the list, out of order from the chronological
> queue of patches that were sent to the list.  I'm a fan of the recently
> applied patches, but I'm curious about what your plans are for the older
> patches in the quene.  Are you still planning on processing them?
> Should the older patches be rebased against the current master and
> resent?

Just my snippet of info from IRC:
<cworth> bremner: OK. So my plan: 1) Commit stash stuff. 2) Make emacs directory. 3) Find and apply all obvious notmuch.el patches
<cworth> And bremner can help me stay focused.
<cworth> After that: 1) Modularize test suite 2) Add testing of emacs stuff
<cworth> Then: 1) Add folder: search 2) Don't index data redundantly
<cworth> And: 1) Add --format (JSON) 2) Add --output
<cworth> There. Now I've published a plan at least.
<bremner> luckily there are no public logs .

hehe, wrong ;-)

Sebastian

Re: patch queue

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins <jrollins@finestructure.net> wrote:
> Hey, Carl.  I've noticed that you've been applying some patches that
> were recently sent to the list, out of order from the chronological
> queue of patches that were sent to the list.  I'm a fan of the recently
> applied patches, but I'm curious about what your plans are for the older
> patches in the quene.  Are you still planning on processing them?
> Should the older patches be rebased against the current master and
> resent?

Thanks for asking, Jamie.

I'm still planning on processing the entire queue, (and chronologically),
but I'm definitely capable of being influenced to grab stuff from the
"future"

> I'm not at all trying to be pushy; there's just some older stuff in the
> queue that I would really like to see applied, such as folder-based
> tagging, json output, and some of the emacs UI improvements.

You're not being pushy at all. Please feel free to let me know what you
think is most important.

I totally agree on the things mentioned above as being priority. I want
folder-based tagging myself, and there are a *lot* of interesting things
that are blocking on json output. Meanwhile, shortcomings in the emacs
UI are causing me problems on a constant basis, (the latest thing
driving me crazy is the regression that refreshing search results makes
the current position in the search results get lost).

For folder-based tagging, that will cause an increment in the
database-format version, so I'd like to do a couple of other things at
the same time. One is to enable indexing of additional headers, (spam
flags, and mailing-list headers), and the other is to stop doing
redundant indexing of data under multiple prefixes[*].

For the emacs UI improvements, I do plan on making an early sweep of the
patch queue and applying them, (if only because I have some improvements
I need to make myself, and I want to avoid doing anything that's already
been done).

Thanks for your input, and please feel free to let me know your thoughts
at any time.

-Carl

[*] This idea came from an equivalent fix recently made to sup. We are
currently indexing the subject, for example, with a "subject:" prefix
and also with no prefix, (to match search terms with no prefix). The fix
is to just index it with the "subject:" prefix, but then at search time
to take any un-prefixed terms and match them against a whole list of
prefixes, (subject:, from:, to:, etc.). This should be a nice savings on
our database size with no appreciable performance cost.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]