ext attachment was scrubbed...
Name: 0001-Add-flush-and-reopen-methods-to-the-libnotmuch-and-t.patch
Type: text/x-patch
Size: 5657 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110909/53e9cf2c/attachment.bin>
On Fri, Sep 9, 2011 at 1:55 PM, Martin Owens wrote:
> That probably was unintended. See attached for the all new slimmed down
> patch.
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -700,18 +700,37 @@ notmuch_database_open (const char *path,
}
void
-notmuch_database_close (notmuch_database_t
onale behind this.)
Gr??e,
Thomas
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110909/efa28d97/attachment.pgp>
Quoth Sebastian Spaeth on Sep 09 at 11:27 am:
> On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements
> wrote:
> > In general, a garbage collector can't make any guarantees about
> > finalization order. When a collection of objects all become
> > unreachable simultaneously (for example, the last
Quoth Thomas Schwinge on Sep 09 at 7:22 pm:
> Hi!
>
> On Fri, 9 Sep 2011 12:13:06 -0400, Austin Clements
> wrote:
> > The idea behind sending the test first is that people can see that it fails
> > and that the subsequent patch indeed fixes it. What I find works well is to
> > submit the test
why for new
> features?
>
>> I would say that
>> the testsuite patch should follow the new feature patch, don't you?
>
> I would keep them together; why separate them?
>
>
> Gr??e,
> Thomas
-- next part --
An HTML attachment was scrubbed...
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110909/4c06c692/attachment.html>
t was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110909/7af439b5/attachment.pgp>
feature patch, don't you?
I would keep them together; why separate them?
Gr??e,
Thomas
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL:
<http://notmuchmail.org/piper
tp://notmuchmail.org/pipermail/notmuch/attachments/20110909/12dcece5/attachment.pgp>
On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote:
> Also, we generally prefer to have modifications to the test suite in
> separate patches that precede the patches that add the features/fix the
> bugs.
>
For new features, this does not look like 'git bisect'-safe. I would say that
the
Thanks for sending your patch. We are kind of limping along as far as
patch integration at the moment. It would help if you could seperate out
the parts you think are bugs from the new features part of your patches,
then the bug-fixes could get looked at sooner.
On Thu, 08 Sep 2011 22:54:21
On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote:
Also, we generally prefer to have modifications to the test suite in
separate patches that precede the patches that add the features/fix the
bugs.
For new features, this does not look like 'git bisect'-safe. I would say that
the testsuite
On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements amdra...@mit.edu wrote:
In general, a garbage collector can't make any guarantees about
finalization order. When a collection of objects all become
unreachable simultaneously (for example, the last reference to any
Messages object is dropped,
Hi!
On Fri, 9 Sep 2011 11:06:34 +0200, Louis Rilling l.rill...@av7.net wrote:
On 05/09/11 12:31 -0700, Jameson Graef Rollins wrote:
Also, we generally prefer to have modifications to the test suite in
separate patches that precede the patches that add the features/fix the
bugs.
For
Quoth Sebastian Spaeth on Sep 09 at 11:27 am:
On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements amdra...@mit.edu wrote:
In general, a garbage collector can't make any guarantees about
finalization order. When a collection of objects all become
unreachable simultaneously (for example, the
On Fri, 2011-09-09 at 08:06 -0300, David Bremner wrote:
I was also puzzled by your changes to debian/changelog. We really need
justification for every little change introduced by the patch; this is
another reason it helps to split things up a bit.
That probably was unintended. See attached
On Fri, 09 Sep 2011 19:22:49 +0200, Thomas Schwinge tho...@schwinge.name
wrote:
Ah, that's indeed a good approach for bug fixes (and it also preserves
git bisect compatibility), but still: why separate patches for new
functionality? (I'm not trying to be a pain here, but would like to
On Fri, Sep 9, 2011 at 1:55 PM, Martin Owens docto...@gmail.com wrote:
That probably was unintended. See attached for the all new slimmed down
patch.
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -700,18 +700,37 @@ notmuch_database_open (const char *path,
}
void
-notmuch_database_close
On Fri, 2011-09-09 at 19:40 -0400, Austin Clements wrote:
(indented correctly, of course). Reopen is a method of
Xapian::Database, which is what notmuch-xapian_db is anyway (unlike,
flush, which is a member of the subclass WritableDatabase and hence
requires the cast). And reopening is a
19 matches
Mail list logo
