Re: [notmuch] patch queue

2010-02-22 Thread Michal Sojka
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins 
jroll...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] patch queue

2010-02-22 Thread Carl Worth
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins 
jroll...@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.



pgppbNp9wdS4R.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.

2010-02-22 Thread Carl Worth
From 8693995fde71e8b028318e1e83bdbb6ae759335a Mon Sep 17 00:00:00 2001
From: Carl Worth cwo...@cworth.org
Date: Sat, 20 Feb 2010 11:41:24 -0800
Subject: [PATCH] test-lib.sh: Add explicit license detail, with change from 
GPLv2 to GPLv2+.

This file has had no explicit license information noted in it, but
has clearly been created and modified according to the terms of GPLv2
as with the rest of the git code base.

The purpose of relicensing is to allow other GPLv3+ projects (in
particular, the notmuch project: http://notmuchmail.org) to use this
same test-suite structure and to contribute changes back as well.

The relicensing was agreed to by Junio C Hamano here:

http://thread.gmane.org/gmane.mail.notmuch.general/1389/focus=140156

and in follow-up messages by Sverre Rabbelier, Johannes Schindelin,
Pierre Habouzit, and Johannes Sixt.

Signed-off-by: Carl Worth cwo...@cworth.org
Acked-by: Johannes Schindelin johannes.schinde...@gmx.de
---

 Message-ID alone is not a good way to help people locate the request.
 Please at least mention what mailing list the message was sent to; better
 yet, do so like this:

Done as requested.

But while we're on the subject, let me at least make a case for
communication by way of Message-ID. The URL above is good for as long as
gmane continues to live, but that may not be as long as the git project
(and its mailing-list archives) are interesting.

Meanwhile, a message ID lives forever and can be used in multiple
contexts. For example, gmane does already support message-ID-based URLs:

http://mid.gmane.org/7vaav3bnr5@alter.siamese.dyndns.org

That interface happens to only display the single message, (requiring
clicking on the subject to see the thread), but one can imagine gmane
getting a similar interface to display the thread directly from the
message ID.

Meanwhile, people using systems like notmuch can also use the message ID
directly to view the thread, with something like:

notmuch show id:7vaav3bnr5@alter.siamese.dyndns.org

So I'm very much in favor of using message IDs more regularly, (and just
expecting that users and their tools will be more accepting of them).

But for now, you've hopefully got your commit message the way you want
it. :-)

 t/test-lib.sh |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index afd3053..004470f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -2,6 +2,18 @@
 #
 # Copyright (c) 2005 Junio C Hamano
 #
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see http://www.gnu.org/licenses/ .
 
 # if --tee was passed, write the output not only to the terminal, but
 # additionally to the file test-results/$BASENAME.out, too.
-- 
1.6.5.7



pgpaqtchFdAuV.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[notmuch] [PATCH] Added mail directory filename pattern support.

2010-02-22 Thread Bart Massey
Typically, the filenames in a mail directory that actually
contain mail obey some specific format.  For example, in my
MH email directory, all mail filenames consist only of
digits.

This patch adds support for a config file variable
filename_pattern which maybe set to a regex used to filter
only valid mail filenames when scanning.  Effective use of
filename_pattern cuts down on the noise from notmuch, and
may speed it up in some cases.

Signed-off-by: Bart Massey b...@cs.pdx.edu
---
 notmuch-client.h |7 +++
 notmuch-config.c |   47 +--
 notmuch-new.c|   35 +++
 3 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index 77766de..191988c 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -146,6 +146,13 @@ notmuch_config_set_database_path (notmuch_config_t *config,
  const char *database_path);
 
 const char *
+notmuch_config_get_filename_regex (notmuch_config_t *config);
+
+void
+notmuch_config_set_filename_regex (notmuch_config_t *config,
+ const char *filename_regex);
+
+const char *
 notmuch_config_get_user_name (notmuch_config_t *config);
 
 void
diff --git a/notmuch-config.c b/notmuch-config.c
index 95430db..4189f03 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -31,11 +31,22 @@ static const char toplevel_config_comment[] =
 static const char database_config_comment[] =
  Database configuration\n
 \n
- The only value supported here is 'path' which should be the top-level\n
+ The value 'path' should be the top-level\n
  directory where your mail currently exists and to where mail will be\n
  delivered in the future. Files should be individual email messages.\n
  Notmuch will store its database within a sub-directory of the path\n
- configured here named \.notmuch\.\n;
+ configured here named \.notmuch\.\n
+\n
+ The optional value 'filename_pattern' should be\n
+ a POSIX regular expression matching only those\n
+ filenames that will be checked for email\n
+ messages.  The match is against the last\n
+ component of the pathname only.  Anchors may be\n
+ used, and probably should be.  Typically, this\n
+ is used to match only files whose name is a\n
+ number ala MH, or to match only files in\n
+ standard maildir format.  The default pattern\n
+ matches anything.\n;
 
 static const char user_config_comment[] =
  User configuration\n
@@ -58,6 +69,7 @@ struct _notmuch_config {
 GKeyFile *key_file;
 
 char *database_path;
+char *filename_regex;
 char *user_name;
 char *user_primary_email;
 char **user_other_email;
@@ -151,6 +163,8 @@ get_username_from_passwd_file (void *ctx)
  *
  * database_path:  $HOME/mail
  *
+ * filename_pattern:   .*
+ *
  * user_name:  From /etc/passwd
  *
  * user_primary_mail:  $EMAIL variable if set, otherwise
@@ -195,6 +209,7 @@ notmuch_config_open (void *ctx,
 config-key_file = g_key_file_new ();
 
 config-database_path = NULL;
+config-filename_regex = NULL;
 config-user_name = NULL;
 config-user_primary_email = NULL;
 config-user_other_email = NULL;
@@ -354,6 +369,34 @@ notmuch_config_set_database_path (notmuch_config_t *config,
 }
 
 const char *
+notmuch_config_get_filename_regex (notmuch_config_t *config)
+{
+char *regex;
+
+if (config-filename_regex == NULL) {
+   regex = g_key_file_get_string (config-key_file,
+ database, filename_pattern, NULL);
+   if (regex) {
+   config-filename_regex = talloc_strdup (config, regex);
+   free (regex);
+   }
+}
+
+return config-filename_regex;
+}
+
+void
+notmuch_config_set_filename_regex (notmuch_config_t *config,
+  const char *filename_regex)
+{
+g_key_file_set_string (config-key_file,
+  database, filename_pattern, filename_regex);
+
+talloc_free (config-filename_regex);
+config-filename_regex = NULL;
+}
+
+const char *
 notmuch_config_get_user_name (notmuch_config_t *config)
 {
 char *name;
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..531f9a3 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,8 @@
 #include notmuch-client.h
 
 #include unistd.h
+#include sys/types.h
+#include regex.h
 
 typedef struct _filename_node {
 char *filename;
@@ -207,6 +209,7 @@ _entries_resemble_maildir (struct dirent **entries, int 
count)
 static notmuch_status_t
 add_files_recursive (notmuch_database_t *notmuch,
 const char *path,
+const regex_t *maybe_regex,
 add_files_state_t *state)
 {
 DIR *dir = NULL;
@@ -302,7 +305,7 @@ add_files_recursive (notmuch_database_t *notmuch,
}
 
next = talloc_asprintf (notmuch, %s/%s, 

Re: [notmuch] [PATCH] notmuch.el: quote args in notmuch-show to facilitate remote use

2010-02-22 Thread Jesse Rosenthal
The above patch and script don't deal with attachments or inline html,
both of which require (for now) that the mail file be present
locally. That may not be necessary with planned changed to notmuch in
the future.

For the time being, though, you can get attachments and html to work
with over TRAMP, by adding the following to your .emacs
file, which I'm sharing based on the encouragement of some folks on
IRC:

(setq notmuch-command /script/in/the/above/message)

(setq notmuch-remote-host y...@your.remote.host)

;; tell notmuch-show-get-filename to use TRAMP to open the file

(defadvice notmuch-show-get-filename (around 
  notmuch-show-get-remote-filename 
  activate)
  (setq ad-return-value (concat /ssh:
notmuch-remote-host
:
ad-do-it)))

There's an annoying bit of redundancy in the fact that you have to
define your remote server both in the elisp and in the
shell-script. You could possibly extract it from the script if you
wanted to, but that seems like it might be prone to error.

Like the script, this requires password-less login to your ssh server.

You can also speed this up by using an already open connection, using
the ControlMaster feature in openssh.

All best,
Jesse
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.

2010-02-22 Thread Tay Ray Chuan
Hi,

On Tue, Feb 23, 2010 at 11:42 AM, Junio C Hamano gits...@pobox.com wrote:
 FWIW, I only said _at least_ you need consent from them, and it was not
 meant to be an exhaustive list.  blame -C -C -C may tell you more.

Without substantial analysis, blame alone is not sufficient - it
does not show which work was original, or derivative.

-- 
Cheers,
Ray Chuan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] [PATCH] Added mail directory filename pattern support.

2010-02-22 Thread Stewart Smith
On Mon, Feb 22, 2010 at 12:07:31PM -0800, Bart Massey wrote:
 Typically, the filenames in a mail directory that actually
 contain mail obey some specific format.  For example, in my
 MH email directory, all mail filenames consist only of
 digits.
 
 This patch adds support for a config file variable
 filename_pattern which maybe set to a regex used to filter
 only valid mail filenames when scanning.  Effective use of
 filename_pattern cuts down on the noise from notmuch, and
 may speed it up in some cases.

What about the other way around?

e.g. if anybody has ever pointed Evolution at a Maildir, you get a
bunch of Maildir-name.ev-summary and .ev-summary-meta and .ibex.index
and whatever.

A default list of ignored patterns would be pretty easy to come up with. 

-- 
Stewart Smith
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[notmuch] patch queue

2010-02-22 Thread Michal Sojka
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins  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


[notmuch] patch queue

2010-02-22 Thread Sebastian Spaeth
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins  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:
 bremner: OK. So my plan: 1) Commit stash stuff. 2) Make emacs 
directory. 3) Find and apply all obvious notmuch.el patches
 And bremner can help me stay focused.
 After that: 1) Modularize test suite 2) Add testing of emacs stuff
 Then: 1) Add folder: search 2) Don't index data redundantly
 And: 1) Add --format (JSON) 2) Add --output
 There. Now I've published a plan at least.
 luckily there are no public logs .

hehe, wrong ;-)

Sebastian


[notmuch] patch queue

2010-02-22 Thread Carl Worth
On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins  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.

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100222/63eb9098/attachment.pgp>


[notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.

2010-02-22 Thread Carl Worth


[notmuch] [PATCH] Added mail directory filename pattern support.

2010-02-22 Thread Bart Massey
Typically, the filenames in a mail directory that actually
contain mail obey some specific format.  For example, in my
MH email directory, all mail filenames consist only of
digits.

This patch adds support for a config file variable
"filename_pattern" which maybe set to a regex used to filter
only valid mail filenames when scanning.  Effective use of
filename_pattern cuts down on the noise from notmuch, and
may speed it up in some cases.

Signed-off-by: Bart Massey 
---
 notmuch-client.h |7 +++
 notmuch-config.c |   47 +--
 notmuch-new.c|   35 +++
 3 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index 77766de..191988c 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -146,6 +146,13 @@ notmuch_config_set_database_path (notmuch_config_t *config,
  const char *database_path);

 const char *
+notmuch_config_get_filename_regex (notmuch_config_t *config);
+
+void
+notmuch_config_set_filename_regex (notmuch_config_t *config,
+ const char *filename_regex);
+
+const char *
 notmuch_config_get_user_name (notmuch_config_t *config);

 void
diff --git a/notmuch-config.c b/notmuch-config.c
index 95430db..4189f03 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -31,11 +31,22 @@ static const char toplevel_config_comment[] =
 static const char database_config_comment[] =
 " Database configuration\n"
 "\n"
-" The only value supported here is 'path' which should be the top-level\n"
+" The value 'path' should be the top-level\n"
 " directory where your mail currently exists and to where mail will be\n"
 " delivered in the future. Files should be individual email messages.\n"
 " Notmuch will store its database within a sub-directory of the path\n"
-" configured here named \".notmuch\".\n";
+" configured here named \".notmuch\".\n"
+"\n"
+" The optional value 'filename_pattern' should be\n"
+" a POSIX regular expression matching only those\n"
+" filenames that will be checked for email\n"
+" messages.  The match is against the last\n"
+" component of the pathname only.  Anchors may be\n"
+" used, and probably should be.  Typically, this\n"
+" is used to match only files whose name is a\n"
+" number ala MH, or to match only files in\n"
+" standard maildir format.  The default pattern\n"
+" matches anything.\n";

 static const char user_config_comment[] =
 " User configuration\n"
@@ -58,6 +69,7 @@ struct _notmuch_config {
 GKeyFile *key_file;

 char *database_path;
+char *filename_regex;
 char *user_name;
 char *user_primary_email;
 char **user_other_email;
@@ -151,6 +163,8 @@ get_username_from_passwd_file (void *ctx)
  *
  * database_path:  $HOME/mail
  *
+ * filename_pattern:   .*
+ *
  * user_name:  From /etc/passwd
  *
  * user_primary_mail:  $EMAIL variable if set, otherwise
@@ -195,6 +209,7 @@ notmuch_config_open (void *ctx,
 config->key_file = g_key_file_new ();

 config->database_path = NULL;
+config->filename_regex = NULL;
 config->user_name = NULL;
 config->user_primary_email = NULL;
 config->user_other_email = NULL;
@@ -354,6 +369,34 @@ notmuch_config_set_database_path (notmuch_config_t *config,
 }

 const char *
+notmuch_config_get_filename_regex (notmuch_config_t *config)
+{
+char *regex;
+
+if (config->filename_regex == NULL) {
+   regex = g_key_file_get_string (config->key_file,
+ "database", "filename_pattern", NULL);
+   if (regex) {
+   config->filename_regex = talloc_strdup (config, regex);
+   free (regex);
+   }
+}
+
+return config->filename_regex;
+}
+
+void
+notmuch_config_set_filename_regex (notmuch_config_t *config,
+  const char *filename_regex)
+{
+g_key_file_set_string (config->key_file,
+  "database", "filename_pattern", filename_regex);
+
+talloc_free (config->filename_regex);
+config->filename_regex = NULL;
+}
+
+const char *
 notmuch_config_get_user_name (notmuch_config_t *config)
 {
 char *name;
diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..531f9a3 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,8 @@
 #include "notmuch-client.h"

 #include 
+#include 
+#include 

 typedef struct _filename_node {
 char *filename;
@@ -207,6 +209,7 @@ _entries_resemble_maildir (struct dirent **entries, int 
count)
 static notmuch_status_t
 add_files_recursive (notmuch_database_t *notmuch,
 const char *path,
+const regex_t *maybe_regex,
 add_files_state_t *state)
 {
 DIR *dir = NULL;
@@ -302,7 +305,7 @@ add_files_recursive (notmuch_database_t *notmuch,
}

next = 

[notmuch] [PATCH] notmuch.el: quote args in notmuch-show to facilitate remote use

2010-02-22 Thread Jesse Rosenthal
The above patch and script don't deal with attachments or inline html,
both of which require (for now) that the mail file be present
locally. That may not be necessary with planned changed to notmuch in
the future.

For the time being, though, you can get attachments and html to work
with over TRAMP, by adding the following to your .emacs
file, which I'm sharing based on the encouragement of some folks on
IRC:

(setq notmuch-command "/script/in/the/above/message")

(setq notmuch-remote-host "you at your.remote.host")

;; tell notmuch-show-get-filename to use TRAMP to open the file

(defadvice notmuch-show-get-filename (around 
  notmuch-show-get-remote-filename 
  activate)
  (setq ad-return-value (concat "/ssh:"
notmuch-remote-host
":"
ad-do-it)))

There's an annoying bit of redundancy in the fact that you have to
define your remote server both in the elisp and in the
shell-script. You could possibly extract it from the script if you
wanted to, but that seems like it might be prone to error.

Like the script, this requires password-less login to your ssh server.

You can also speed this up by using an already open connection, using
the ControlMaster feature in openssh.

All best,
Jesse


[notmuch] [PATCH] test-lib.sh: Add explicit license detail, with change from GPLv2 to GPLv2+.

2010-02-22 Thread Junio C Hamano
Carl Worth  writes:

> From 8693995fde71e8b028318e1e83bdbb6ae759335a Mon Sep 17 00:00:00 2001
> From: Carl Worth 
> Date: Sat, 20 Feb 2010 11:41:24 -0800
> Subject: [PATCH] test-lib.sh: Add explicit license detail, with change from 
> GPLv2 to GPLv2+.

Please drop the above the next time.

> The relicensing was agreed to by Junio C Hamano here:
>
> http://thread.gmane.org/gmane.mail.notmuch.general/1389/focus=140156
>
> and in follow-up messages by Sverre Rabbelier, Johannes Schindelin,
> Pierre Habouzit, and Johannes Sixt.

FWIW, I only said "_at least_ you need consent from them", and it was not
meant to be an exhaustive list.  "blame -C -C -C" may tell you more.

You are the party that wants this relicensing, not me.  Please do not
burden me with excessive legwork for you, but help me a bit more
proactively to make this happen.

> Meanwhile, a message ID lives forever and can be used in multiple
> contexts.

Oh, I never said "do not use message ID".  I said "message ID alone is not
good enough for most people".  Users of gmane and notmuch who know the
tool they use would benefit from having message ID, _too_, but even if you
were a user of notmuch, unless you have subscribed to the list and have
your own archive, you wouldn't be able to say "show id:frotz".