On Mon, Oct 11, 2010 at 10:01 PM, Jameson Rollins
wrote:
> On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras gmail.com> wrote:
>> I think many people agree notmuch mainline has been rather slow. So
>> I'm proposing to have notmuch-next branch, either on github or
>> gitorious (please vote).
I just wrote a simple script to turn rss feeds into notmuch-parsable
directories.
Script and docs available at: http://github.com/krl/sluk/
I had run into problems with both of the two other solutions for this i know
feed2imap: problems with threading consuming 100% cpu somehow (seems like a
On Mon, Oct 11, 2010 at 22:00, Jameson Rollins
wrote:
> As long as all the repos are synced, then you only need to track one.
> But notmuch already has "official" repos [0], and making another
> pseudo-"official" repo will probably just makes things more confusing.
Patches show up in a different
Hi,
I think many people agree notmuch mainline has been rather slow. So
I'm proposing to have notmuch-next branch, either on github or
gitorious (please vote).
More than one person should have write access to this repo, but some
guidelines should be in place. I propose that patches should be
> What do you think?
Good idea. github+
On Mon, 11 Oct 2010 22:10:24 +0200, Jed Brown wrote:
> Patches show up in a different order in each person's "personal, but
> 'synced'" repository. Then you need a mess of merges to actually get
> them synced (if they are published, you can't rebase).
I'd add, by way of voting for something a
tachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101011/59d54bab/attachment.pgp>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20101011/b1e06538/attachment.pgp>
On 11 October 2010 14:45, Felipe Contreras
wrote:
> Hi,
>
> I think many people agree notmuch mainline has been rather slow. So
> I'm proposing to have notmuch-next branch, either on github or
> gitorious (please vote).
+1 for gitorious, you can use OpenID and their code is available (for
me a
From: David Bremner
logging of tags is enabled by adding a stanza like
[log]
tags = /some/path/you/can/write/to
to your notmuch config.
Note that we intentionally do the logging after the database
transaction is finished.
---
notmuch-tag.c | 31
From: David Bremner
Since the function is supposed to work for any pair of strings, this
means some form of quoting seems necessary. I decided to re-use the
json quoting routines for convenience.
---
notmuch-client.h |4
notmuch-log.c| 18 ++
2
From: David Bremner
notmuch_log_open: open a log file; just a wrapper around open(2)
notmuch_log_append: atomically append a buffer (character array) to a log file
Based on per-write file locking, performance will have to be tested.
---
Makefile.local |1 +
The patches following this message are my first attempt at
implementing atomic logging for notmuch. The idea is that such logs
could be useful in synchronizing notmuch instances.
Feedback of any kind is welcome. I'm particularly interested in
comments about the log format and performance.
In my
The patches following this message are my first attempt at
implementing atomic logging for notmuch. The idea is that such logs
could be useful in synchronizing notmuch instances.
Feedback of any kind is welcome. I'm particularly interested in
comments about the log format and performance.
In my
From: David Bremner brem...@unb.ca
notmuch_log_open: open a log file; just a wrapper around open(2)
notmuch_log_append: atomically append a buffer (character array) to a log file
Based on per-write file locking, performance will have to be tested.
---
Makefile.local |1 +
notmuch-client.h
From: David Bremner brem...@unb.ca
Since the function is supposed to work for any pair of strings, this
means some form of quoting seems necessary. I decided to re-use the
json quoting routines for convenience.
---
notmuch-client.h |4
notmuch-log.c| 18 ++
2 files
Hi,
I think many people agree notmuch mainline has been rather slow. So
I'm proposing to have notmuch-next branch, either on github or
gitorious (please vote).
More than one person should have write access to this repo, but some
guidelines should be in place. I propose that patches should be
On 11 October 2010 14:45, Felipe Contreras felipe.contre...@gmail.com wrote:
Hi,
I think many people agree notmuch mainline has been rather slow. So
I'm proposing to have notmuch-next branch, either on github or
gitorious (please vote).
+1 for gitorious, you can use OpenID and their code is
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras
felipe.contre...@gmail.com wrote:
I think many people agree notmuch mainline has been rather slow. So
I'm proposing to have notmuch-next branch, either on github or
gitorious (please vote).
More than one person should have write access to
On 11 October 2010 15:01, Jameson Rollins jroll...@finestructure.net wrote:
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras
felipe.contre...@gmail.com wrote:
I think many people agree notmuch mainline has been rather slow. So
I'm proposing to have notmuch-next branch, either on github or
On Mon, Oct 11, 2010 at 22:00, Jameson Rollins
jroll...@finestructure.net wrote:
As long as all the repos are synced, then you only need to track one.
But notmuch already has official repos [0], and making another
pseudo-official repo will probably just makes things more confusing.
Patches
I just wrote a simple script to turn rss feeds into notmuch-parsable
directories.
Script and docs available at: http://github.com/krl/sluk/
I had run into problems with both of the two other solutions for this i know
feed2imap: problems with threading consuming 100% cpu somehow (seems like a
On Mon, Oct 11, 2010 at 10:01 PM, Jameson Rollins
jroll...@finestructure.net wrote:
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras
felipe.contre...@gmail.com wrote:
I think many people agree notmuch mainline has been rather slow. So
I'm proposing to have notmuch-next branch, either on
23 matches
Mail list logo