[PATCH] emacs: Show all multipart/alternative parts by default.
On Wed, 22 Jun 2011 18:14:12 -0700, Jameson Graef Rollins wrote: > > One way to get around this is to set the > "notmuch-show-all-multipart/alternative-parts" customization variable > to True ('t'), which will cause all parts to always be displayed. > Pushed.
Notmuch 0.6: Let's do it.
No, it's not a code name, unless you really want it to be. After some discussion with Carl and Jamie on IRC, I have declared myself release tyrant, with Jamie as my assistant [1]. The release plan is as follows. 1) Create a release branch (called release) at b0ba84f9e71b0. You can get this branch now from the main notmuch repo. 2) Add id:"1308791652-17372-2-git-send-email-jrollins at finestructure.net" or equivalent 3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now and July 1. 4) Release July 1. The next release will approximately August 1, with a feature freeze around July 23. Normally this might be a lousy time for a release, but some of us will be hacking in Banja Luka the week before. David [1] In the traditional manner, Jamie has done most of the work, and I am swooping in at the last minute to steal credit ;). [2] If you have to ask who decides what is _important_, you haven't understood the release tyrant concept completely. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110622/9633d22a/attachment.pgp>
When will we have our next release?
see so many good people working hard and having fun to collectively make such a fun tool![*] > If we can just grease the wheels a little bit to get releases out the > door a little quicker, I think we'll all be a lot happier. Hopefully, we're doing that. Thanks for all your efforts, Jamie. I really appreciate them. And I'm happier at least! -Carl [*] For "fun tool" I always have to hesitate a bit?notmuch itself is fun, but it's funny that email itself is often more annoying to me than anything else. I suppose what makes notmuch fun is that it helps me more quickly eliminate so much of the annoyance of email from my life so that I can focus more on the things that I really want to. -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110622/fe0ecb45/attachment.pgp>
[PATCH] emacs: Show all multipart/alternative parts by default.
This is patch is a temporary work-around for a slight regression that popped up in the part handling reorganization. Currently, text/plain parts are always preferred, if present, over other non-text/plain parts in multipart/alternative. However, this means that if there is a blank text/plain part, no content will be displayed. One way to get around this is to set the "notmuch-show-all-multipart/alternative-parts" customization variable to True ('t'), which will cause all parts to always be displayed. Since we want to move forward with the next release, we're going to set this variable true by default, to make sure that no content is unretrievably hidden from the user. Once we come up with a better solution for easy display of hidden parts we can set this back to a default value of 'nil'. --- emacs/notmuch-show.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 0d9b52a..af1d44b 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -96,7 +96,7 @@ same as that of the previous message." notmuch-wash-excerpt-citations)) ;; Mostly useful for debugging. -(defcustom notmuch-show-all-multipart/alternative-parts nil +(defcustom notmuch-show-all-multipart/alternative-parts t "Should all parts of multipart/alternative parts be shown?" :group 'notmuch :type 'boolean) -- 1.7.5.4
I feel a release coming!
I think we just agreed with cworth on irc that this simple patch will satisfy his regression worry for 0.6. Meaning that we can push out the release after this patch is merged. bremner, our new "Release Tyrant", has his finger on the trigger...
[PATCH v6 00/17] Fix 'notmuch new' atomicity issues
Ping. On Sat, Jun 11, 2011 at 4:04 PM, Austin Clements wrote: > Here's the reworked patch series that uses atomic sections more > heavily rather than changing the removal API. ?This is atomic-new-v6 > on http://awakening.csail.mit.edu/git/notmuch.git . > > (I was planning to make this series on Monday while stuck on a plane, > but an opportunity presented itself when I needed something better to > do than fix the sink. ?As a result, if you can look over this before > Monday, I can use that time to address any further comments.) > > The beginning of the sequence---"test: Fix message when skipping > test_expect_equal* tests" through "new: Defer updating directory > mtimes until the end."---has not changed besides than the minor things > you pointed out earlier. ?Here's a quick summary of the differences in > the rest of the sequence: > > lib: Add notmuch_database_{begin,end}_atomic. > ?Rebased but otherwise identical. > > lib: Add support for nested atomic sections. > ?New. > > lib: Indicate if there are more filenames after removal. > ?Rebased but otherwise identical. > > lib: Remove message document directly after removing the last file > name. > ?New. ?Supersedes the patches that rewrote > ?notmuch_database_remove_message and made sync delete messages. > > lib: Add an API to find a message by filename. > ?Culled from "lib: Add API's to find by filename and ..." in the old > ?series. ?What I kept is identical. > > lib: Wrap notmuch_database_add_message in an atomic section. > ?New. > > new: Cleanup. Put removed/renamed message count in add_files_state_t. > new: Cleanup. De-duplicate file name removal code. > ?Both new, but closely related to previous remove_filename patch. > > new: Synchronize maildir flags eagerly. > ?New, but very closely related to previous patch of the same name. > ?This patch is simpler now because of the previous two cleanups. > > new: Wrap adding and removing messages in atomic sections. > ?Rebased and added an atomic section around removal. > > lib: Improve notmuch_database_{add,remove}_message documentation. > ?New. > > Ultimately, I still think the existing removal API is weird because it > forces you to do things like lookup a message by file name just in > case you need that message object after removal tells you that it > didn't actually remove the message. ?But I don't know what to do about > it that isn't equally weird. > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch >
[PATCH] tests: add a test for symbol hiding side effects
From: David BremnerThe worry here is that a binary linking with libnotmuch might lose access to Xapian::Error symbols because libnotmuch hides them. --- test/basic |2 +- test/notmuch-test |1 + test/symbol-hiding | 21 + test/symbol-test.cc | 17 + 4 files changed, 40 insertions(+), 1 deletions(-) create mode 100755 test/symbol-hiding create mode 100644 test/symbol-test.cc diff --git a/test/basic b/test/basic index 808c968..d6e8c10 100755 --- a/test/basic +++ b/test/basic @@ -56,7 +56,7 @@ tests_in_suite=$(for i in $TESTS; do echo $i; done | sort) available=$(ls -1 ../ | \ sed -r -e "/^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test)/d" \ -e "/^(README|test-lib.sh|test-lib.el|test-results|tmp.*|valgrind|corpus*)/d" \ - -e "/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose)/d" \ + -e "/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose|symbol-test.cc)/d" \ -e "/^(test.expected-output|.*~)/d" \ -e "/^(gnupg-secret-key.asc)/d" \ -e "/^(gnupg-secret-key.NOTE)/d" \ diff --git a/test/notmuch-test b/test/notmuch-test index 83f284d..fe85c6a 100755 --- a/test/notmuch-test +++ b/test/notmuch-test @@ -40,6 +40,7 @@ TESTS=" emacs-large-search-buffer maildir-sync crypto + symbol-hiding " TESTS=${NOTMUCH_TESTS:=$TESTS} diff --git a/test/symbol-hiding b/test/symbol-hiding new file mode 100755 index 000..1c1f34e --- /dev/null +++ b/test/symbol-hiding @@ -0,0 +1,21 @@ +#!/usr/bin/env bash +# +# Copyright (c) 2011 David Bremner +# + +test_description='exception symbol test + +This test tests whether hiding Xapian::Error symbols in libnotmuch +also hides them for other users of libxapian. This is motivated by +the discussion in http://gcc.gnu.org/wiki/Visibility' + +. ./test-lib.sh + +output="Error opening database at /nonexistant/.notmuch: No such file or directory +caught No chert database found at path \`/nonexistant'" + +g++ -o symbol-test ../symbol-test.cc -L../lib -lnotmuch -lxapian +test_expect_success "$message" ./symbol-test +test_done + + diff --git a/test/symbol-test.cc b/test/symbol-test.cc new file mode 100644 index 000..f077845 --- /dev/null +++ b/test/symbol-test.cc @@ -0,0 +1,17 @@ +#include +#include +#include +main (int argc, char **argv){ + +notmuch_database_t *notmuch + = notmuch_database_open ("/nonexistant", +NOTMUCH_DATABASE_MODE_READ_ONLY); + + try{ +(void)new Xapian::WritableDatabase ("/nonexistant", + Xapian::DB_OPEN); + } catch (const Xapian::Error ) { +printf("caught %s\n",error.get_msg().c_str()); + } + return 0; +} -- 1.7.5.3
Python updates
On Tue, 21 Jun 2011 14:46:02 -0700, Carl Worth wrote: Non-text part: multipart/signed > On Thu, 16 Jun 2011 15:58:39 +0200, Sebastian Spaeth wrote: > > Message().maildir_flags_to_tags and tags_to_maildir_flags, which are now > > by default invoked on Database().add_message and on any operation that > > modifies notmuch tags. See the updated API docs at: > > I'm not a fan of the above. Hi Carl, I see your point. I was approached with this by someone very confused that tagging via notmuch binary would automatically move mails between cur/new folders while tagging via python would do nothing of this sort. The automatic tag/flag synchronization can be disabled via a command line option already now, it is just enabled by default. The behavior is of course documented in the python API docs. It would be no problem, to disable the syncing by default to achieve API consistency. (and allow people to turn it on, if they wish to do so explicitly) > If we should fix Database().add_message to automatically call > maildir_flags_to_tags, then we should also fix > notmuch_database_add_message to do the same thing. > I can't see any good justification for behavior like this to be > different depending on the language being used to access the library. See above, people don't consider using the libnotmuch API, they "tag" a message via python and it behaves differently than "tag" a message via notmuch binary So we'll have some level of inconsistency in any case. :) > Please consider changing things to match the semantics of the underlying > library. Would you be happy to have maildir syncing disabled by default and users can enable it via a parameter? I do see why you want to achieve consistency with the API. On the other hand are the python API somewhat more highlevel than the low-level API calls, and we provide a few convenience functions that are not available in the API at all. I can do away with it and force people to invoke the syncing manually, if you feel strongly about this. I don't have a problem with either way. Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110622/509f54ec/attachment.pgp>
Python updates
On Wed, 22 Jun 2011 08:57:09 +0200, Sebastian Spaeth wrote: > I see your point. I was approached with this by someone very > confused that tagging via notmuch binary would automatically move mails > between cur/new folders while tagging via python would do nothing of > this sort. That's also a good point. But the same confusion can happen to someone using "notmuch tag" and then switching to using notmuch_message_add_tag at the C library interface. That's what I meant when I said that if there's an inconsistency here, then we should fix it at the C library interface, and not just in a language-specific wrapper. > See above, people don't consider using the libnotmuch API, they "tag" a > message via python and it behaves differently than "tag" a message via > notmuch binary > So we'll have some level of inconsistency in any case. :) Let's figure out one right answer for the library interface, (regardless of language) and implement that. > Would you be happy to have maildir syncing disabled by default and users > can enable it via a parameter? I'd be happy to hear a proposal to add a parameter to the library interface for maildir syncing, (and I wouldn't even be opposed to having it enabled by default). The only thing I care about strongly here is that we have a single library interface. I don't want one interface in C, a different interface in python, (and different interfaces in go, ruby, etc.). Sometimes a language will provide some convenient builtin handling for something that's awkward at the notmuch C interface, (such as a native interface for iterators). And I definitely don't mind a language binding using something like that as opposed to manually binding every iteration-supporting function that we have in the notmuch library. But I don't want to see semantic changes to the interface that don't have anything to do with the language itself. > I do see why you want to achieve consistency with the API. Thanks. > On the other hand are the python API somewhat more highlevel than the > low-level API calls, and we provide a few convenience functions that > are not available in the API at all. That's not the stance I'd like to see. If you want convenience in the python interface that doesn't exist in the C interface, then let's start by fixing the C interface. If there's convenience you want in the python interface that shouldn't exist in the C interface, then I would propose that that functionality should be in a separate python layer (above the binding) with its own name. What do you think? -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110622/6eba85f3/attachment.pgp>
bug in emacs-ui ?
On Wed, 22 Jun 2011 08:50:23 +0200, Sebastien Binet wrote: > On Tue, 21 Jun 2011 15:09:20 -0700, Carl Worth wrote: > > Perhaps this is an emacs bug? > could be, but, > > > I'm using Debian's emacs 23.3.1 and have not encountered the problem > > described. > I don't see anything related to 'point', 'point-invisible-p' nor > 'forward-char' in there: > http://patch-tracker.debian.org/package/emacs23/23.3+1-1 Perhaps I was confused. I thought 23.3.1 was a distinct upstream release
hiding xapian symbols
On Tue, 21 Jun 2011 22:05:15 -0400, Daniel Kahn Gillmor wrote: > However, i'm concerned that the act of hiding these symbols will make it > so that any program that tries to link both libnotmuch and libxapian > will be unable to use these symbols. > > This makes me think that a program that links against libnotmuch and > libxapian, but actually tries to *use* libxapian's exception handling > may have a problem. > This seems to work, when compiled "g++ foo.c -lnotmuch -lxapian" I get , | Error opening database at /nonexistant/.notmuch: No such file or directory | caught Cannot create directory `/nonexistant' ` don't run it as root ;) #include #include #include main (int argc, char **argv){ notmuch_database_t *notmuch = notmuch_database_open ("/nonexistant", NOTMUCH_DATABASE_MODE_READ_ONLY); try{ (void)new Xapian::WritableDatabase ("/nonexistant", Xapian::DB_CREATE_OR_OPEN); } catch (const Xapian::Error ) { printf("caught %s\n",error.get_msg().c_str()); } }
[PATCH] tests: add a test for symbol hiding side effects
From: David Bremner brem...@debian.org The worry here is that a binary linking with libnotmuch might lose access to Xapian::Error symbols because libnotmuch hides them. --- test/basic |2 +- test/notmuch-test |1 + test/symbol-hiding | 21 + test/symbol-test.cc | 17 + 4 files changed, 40 insertions(+), 1 deletions(-) create mode 100755 test/symbol-hiding create mode 100644 test/symbol-test.cc diff --git a/test/basic b/test/basic index 808c968..d6e8c10 100755 --- a/test/basic +++ b/test/basic @@ -56,7 +56,7 @@ tests_in_suite=$(for i in $TESTS; do echo $i; done | sort) available=$(ls -1 ../ | \ sed -r -e /^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test)/d \ -e /^(README|test-lib.sh|test-lib.el|test-results|tmp.*|valgrind|corpus*)/d \ - -e /^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose)/d \ + -e /^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose|symbol-test.cc)/d \ -e /^(test.expected-output|.*~)/d \ -e /^(gnupg-secret-key.asc)/d \ -e /^(gnupg-secret-key.NOTE)/d \ diff --git a/test/notmuch-test b/test/notmuch-test index 83f284d..fe85c6a 100755 --- a/test/notmuch-test +++ b/test/notmuch-test @@ -40,6 +40,7 @@ TESTS= emacs-large-search-buffer maildir-sync crypto + symbol-hiding TESTS=${NOTMUCH_TESTS:=$TESTS} diff --git a/test/symbol-hiding b/test/symbol-hiding new file mode 100755 index 000..1c1f34e --- /dev/null +++ b/test/symbol-hiding @@ -0,0 +1,21 @@ +#!/usr/bin/env bash +# +# Copyright (c) 2011 David Bremner +# + +test_description='exception symbol test + +This test tests whether hiding Xapian::Error symbols in libnotmuch +also hides them for other users of libxapian. This is motivated by +the discussion in http://gcc.gnu.org/wiki/Visibility' + +. ./test-lib.sh + +output=Error opening database at /nonexistant/.notmuch: No such file or directory +caught No chert database found at path \`/nonexistant' + +g++ -o symbol-test ../symbol-test.cc -L../lib -lnotmuch -lxapian +test_expect_success $message ./symbol-test +test_done + + diff --git a/test/symbol-test.cc b/test/symbol-test.cc new file mode 100644 index 000..f077845 --- /dev/null +++ b/test/symbol-test.cc @@ -0,0 +1,17 @@ +#include stdio.h +#include xapian.h +#include notmuch.h +main (int argc, char **argv){ + +notmuch_database_t *notmuch + = notmuch_database_open (/nonexistant, +NOTMUCH_DATABASE_MODE_READ_ONLY); + + try{ +(void)new Xapian::WritableDatabase (/nonexistant, + Xapian::DB_OPEN); + } catch (const Xapian::Error error) { +printf(caught %s\n,error.get_msg().c_str()); + } + return 0; +} -- 1.7.5.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bug in emacs-ui ?
On Wed, 22 Jun 2011 08:50:23 +0200, Sebastien Binet seb.bi...@gmail.com wrote: On Tue, 21 Jun 2011 15:09:20 -0700, Carl Worth cwo...@cworth.org wrote: Perhaps this is an emacs bug? could be, but, I'm using Debian's emacs 23.3.1 and have not encountered the problem described. I don't see anything related to 'point', 'point-invisible-p' nor 'forward-char' in there: http://patch-tracker.debian.org/package/emacs23/23.3+1-1 Perhaps I was confused. I thought 23.3.1 was a distinct upstream release From 23.3, but maybe not, (emacs version numbers use 1-based indexing perhaps?). anyways... for the moment I'll just live with it... Sorry about that. except if somebody has some insights on how to catch the 'End of buffer' error and add some more protective programming around the 'scroll-up' function ? My emacs lisp skills are primarily restricted to actual experimentation. So if I can replicate the bug, I might be able to find a fix. I'm not very good at doing theoretical fixes with emacs lisp code. -Carl pgpFoPwpDytML.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Python updates
On Wed, 22 Jun 2011 08:57:09 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: I see your point. I was approached with this by someone very confused that tagging via notmuch binary would automatically move mails between cur/new folders while tagging via python would do nothing of this sort. That's also a good point. But the same confusion can happen to someone using notmuch tag and then switching to using notmuch_message_add_tag at the C library interface. That's what I meant when I said that if there's an inconsistency here, then we should fix it at the C library interface, and not just in a language-specific wrapper. See above, people don't consider using the libnotmuch API, they tag a message via python and it behaves differently than tag a message via notmuch binary So we'll have some level of inconsistency in any case. :) Let's figure out one right answer for the library interface, (regardless of language) and implement that. Would you be happy to have maildir syncing disabled by default and users can enable it via a parameter? I'd be happy to hear a proposal to add a parameter to the library interface for maildir syncing, (and I wouldn't even be opposed to having it enabled by default). The only thing I care about strongly here is that we have a single library interface. I don't want one interface in C, a different interface in python, (and different interfaces in go, ruby, etc.). Sometimes a language will provide some convenient builtin handling for something that's awkward at the notmuch C interface, (such as a native interface for iterators). And I definitely don't mind a language binding using something like that as opposed to manually binding every iteration-supporting function that we have in the notmuch library. But I don't want to see semantic changes to the interface that don't have anything to do with the language itself. I do see why you want to achieve consistency with the API. Thanks. On the other hand are the python API somewhat more highlevel than the low-level API calls, and we provide a few convenience functions that are not available in the API at all. That's not the stance I'd like to see. If you want convenience in the python interface that doesn't exist in the C interface, then let's start by fixing the C interface. If there's convenience you want in the python interface that shouldn't exist in the C interface, then I would propose that that functionality should be in a separate python layer (above the binding) with its own name. What do you think? -Carl -- carl.d.wo...@intel.com pgpwEMfEAIRQE.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v6 00/17] Fix 'notmuch new' atomicity issues
Ping. On Sat, Jun 11, 2011 at 4:04 PM, Austin Clements amdra...@mit.edu wrote: Here's the reworked patch series that uses atomic sections more heavily rather than changing the removal API. This is atomic-new-v6 on http://awakening.csail.mit.edu/git/notmuch.git . (I was planning to make this series on Monday while stuck on a plane, but an opportunity presented itself when I needed something better to do than fix the sink. As a result, if you can look over this before Monday, I can use that time to address any further comments.) The beginning of the sequence---test: Fix message when skipping test_expect_equal* tests through new: Defer updating directory mtimes until the end.---has not changed besides than the minor things you pointed out earlier. Here's a quick summary of the differences in the rest of the sequence: lib: Add notmuch_database_{begin,end}_atomic. Rebased but otherwise identical. lib: Add support for nested atomic sections. New. lib: Indicate if there are more filenames after removal. Rebased but otherwise identical. lib: Remove message document directly after removing the last file name. New. Supersedes the patches that rewrote notmuch_database_remove_message and made sync delete messages. lib: Add an API to find a message by filename. Culled from lib: Add API's to find by filename and ... in the old series. What I kept is identical. lib: Wrap notmuch_database_add_message in an atomic section. New. new: Cleanup. Put removed/renamed message count in add_files_state_t. new: Cleanup. De-duplicate file name removal code. Both new, but closely related to previous remove_filename patch. new: Synchronize maildir flags eagerly. New, but very closely related to previous patch of the same name. This patch is simpler now because of the previous two cleanups. new: Wrap adding and removing messages in atomic sections. Rebased and added an atomic section around removal. lib: Improve notmuch_database_{add,remove}_message documentation. New. Ultimately, I still think the existing removal API is weird because it forces you to do things like lookup a message by file name just in case you need that message object after removal tells you that it didn't actually remove the message. But I don't know what to do about it that isn't equally weird. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Show all multipart/alternative parts by default.
This is patch is a temporary work-around for a slight regression that popped up in the part handling reorganization. Currently, text/plain parts are always preferred, if present, over other non-text/plain parts in multipart/alternative. However, this means that if there is a blank text/plain part, no content will be displayed. One way to get around this is to set the notmuch-show-all-multipart/alternative-parts customization variable to True ('t'), which will cause all parts to always be displayed. Since we want to move forward with the next release, we're going to set this variable true by default, to make sure that no content is unretrievably hidden from the user. Once we come up with a better solution for easy display of hidden parts we can set this back to a default value of 'nil'. --- emacs/notmuch-show.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 0d9b52a..af1d44b 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -96,7 +96,7 @@ same as that of the previous message. notmuch-wash-excerpt-citations)) ;; Mostly useful for debugging. -(defcustom notmuch-show-all-multipart/alternative-parts nil +(defcustom notmuch-show-all-multipart/alternative-parts t Should all parts of multipart/alternative parts be shown? :group 'notmuch :type 'boolean) -- 1.7.5.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: When will we have our next release?
On Tue, 07 Jun 2011 09:44:40 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Frankly, I wouldn't mind doing strict time-based releases with something like the following: Hi, Carl. I think this is a fine idea, and we (not you) can definitely run this process. I'm quite sure that at least bremner and I can completely handle this together, and I'm sure we can get others to help. Excellent! But the mechanics of the actual release are not the problem. The problem is the current one-person bottleneck for all patches: This is a problem if master isn't moving, I agree. And that has been a problem in the past. More recently, master has been moving just fine, and I have proven to get too caught up in oh, just a few more bug fixes to merge... to just sit down and make a release. So that's what I want to fix now. To that end, I've just nominated David Bremner as our release manager. He's already been pushing packages of recent notmuch master to Debian experimental, so he's effectively already in the role of choosing particular code states that the masses can easily get their hands on. I've asked him to just take over the release process from here and I've pretty much left all decisions in his hands. He'll probably make a separate branch for the release at some point, (in the primary repository). I'll let him talk more about plans if he needs to. This is *not* meant to be an indictment of you at all. I know it's incredibly hard to keep up with the incoming patch flow. It takes a lot of time and work to review every patch. I also really like your reviews. They are incredibly thorough and insightful, and I always learn from them. Thanks. That's very kind of you to say so. I would really like to continue to get your review of patches. I think they're just too valuable. So it would be really nice if one of the solutions was a way to just grease the bottleneck, so to speak. For instance, if you could commit to reviewing just 1 patch series a week we would be way ahead of where we have been. I can't really promise anything other than doing the best I can to stay on top of things. Lately, I am at least using notmuch itself more effectively to manage outstanding patches and this is helping I thinl. Another thing that would help would be to delegate responsibility of certain components to others, as you have with the python binding to spaetz. For instance, we have at least a couple of elisp experts hanging around. Maybe you could cede handling of all emacs patches to someone like jkr or dme, and to felipe for vim, etc. (if they're willing to take on those rolls). That would help reduce your burden a bit. Yes! For people that are already effectively maintaining isolated portions of the code, I'm more than happy to delegate full editorial control over those pieces, (and allow direct pushes, etc.). This has actually already been happening with python and vim pieces. And I plan to add some new mutt code soon with its own maintainer. And the delegation of release management that I'm announcing here will help too. We could also formalize some sort of tiered review system. amdragon has been doing a really good job of frequently providing good review of patches on list. I think that any proposed patch that gets a thumbs up From someone like amdragon should immediately be elevated in your queue, or just applied out-right. If the review of others explicitly helped get patches merged faster, I'm quite sure it would encourage more folks to submit their reviews as well. I would love to have more review from anyone. I don't think there's any need to formalize anything. Much of it can be as simple as watching things you've seen me do and then doing them yourself. For example, there are a lot of recent patches that I merged only after I wrote a test case for the bug fix. It's quite a bottleneck for me to write new tests like that. If other people could review patches and ask for test cases, or write test cases themselves, then that would definitely relieve a burden on my part. Similarly, I think the most regular coders on the project have come to understand what I expect from commit messages. So that's something else that's pretty easy for anyone to review. So, yes, please help in the review process, everybody! I don't think I have any particularly exclusive talent with regard to judging code to be clean and in good taste. I definitely appreciate the good sense of taste that many on this list are demonstrating regularly. Notmuch is an incredible project, with an absolutely incredible development community. It's an absolute joy to work on. I absolutely agree. I haven't taken the opportunity often enough to say thank you to everyone who has contributed! So, thanks! It's such a wonderful thing to me to see so many good people working hard and having fun to collectively make such a fun tool![*] If we can just grease the wheels a little bit to get
Notmuch 0.6: Let's do it.
No, it's not a code name, unless you really want it to be. After some discussion with Carl and Jamie on IRC, I have declared myself release tyrant, with Jamie as my assistant [1]. The release plan is as follows. 1) Create a release branch (called release) at b0ba84f9e71b0. You can get this branch now from the main notmuch repo. 2) Add id:1308791652-17372-2-git-send-email-jroll...@finestructure.net or equivalent 3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now and July 1. 4) Release July 1. The next release will approximately August 1, with a feature freeze around July 23. Normally this might be a lousy time for a release, but some of us will be hacking in Banja Luka the week before. David [1] In the traditional manner, Jamie has done most of the work, and I am swooping in at the last minute to steal credit ;). [2] If you have to ask who decides what is _important_, you haven't understood the release tyrant concept completely. pgpGbyF8CmNNP.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Show all multipart/alternative parts by default.
On Wed, 22 Jun 2011 18:14:12 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: One way to get around this is to set the notmuch-show-all-multipart/alternative-parts customization variable to True ('t'), which will cause all parts to always be displayed. Pushed. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch