Initial attempt at a "merge window" for notmuch

[Carl Worth]

I want to figure out how to make a release process that will work for
notmuch. An idea I have now is to use a date-based "merge window" during
which features are nominated for the release.

So I took a window starting at my original request for 0.2 features
until now. In our current (lame) syntax for specifying date ranges,
that gives me a search string of:

tag:notmuch and 1270678364..1270828505 and not (tag:merged or tag:postponed)

What I want to do now is to work through this list and tag things as
either "merged" or "postponed" until my list is empty. That should give
a good indication that we've actually got all the features we
want. (We'll still need something more for tracking bugs, of course.)

Here's the current list:

[22/22] Carl Worth, James... Plans for the 0.2 release (this week)
[2/6]   Carl Worth, Micha... Notmuch release 0.1 now available
[2/4]   Dirk Hohndel, Car... [PATCH] Fix code extracting the MTA from Received: headers
[1/2]   Mike Kelly, Carl ... [PATCH] Fix the default value for --includedir.
[2/5]   David Edmondson, ... [notmuch] [PATCH] notmuch.el: 'F' in search mode takes us to a list of folders.
[2/2]   Sebastian Spaeth,... RFC: User-Agent header
[1/30]  Aneesh Kumar K.V,... [notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages
[3/10]  Sebastian Spaeth,... [notmuch] [Sebastian Spaeth] Pull requests
[5/5]   Michal Sojka         [PATCH 0/4] Mailstore abstraction v4
[2/2]   Michal Sojka         [PATCH] Mailstore abstraction v4 - part 2 (maildir synchronization)
[2/2]   Mike Kelly, Sebas... [PATCH] Have notmuch count default to showing the total.
[3/3]   Mike Kelly           [PATCH 1/3] Initial support for maildir flags.
[1/2]   Dirk Hohndel, Mic... [RFC] reordering and cleanup of thread authors
[1/10]  Jesse Rosenthal, ... [notmuch] [PATCH] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id
[1/11]  Jesse Rosenthal, ... [notmuch] [PATCH] notmuch.el: add functionality to add or remove tags by region.

Of course, just looking at this list makes me want many more features
(but they are too late for this merge window):

  1. Real support for date-range-based searches

  2. The ability to split a thread.

     I know I argued against this previously, but I know that "Plans for
     the 0.2 release" contains multiple independent topics, and I'd
     really like to be able to track those separately.

  3. Ability to easily post search results to a web page.

     I'd like people to be able to easily view a web page with three
     lists on it for tracking the upcoming release: "proposed features",
     "merged features", and "postponed features".

  4. Fancy support for thread- vs. message-based search matches.

     We've talked about supporting a "muted" tag to make obnoxious
     threads disappear entirely. The idea we have there is a tag on a
     message, and then support for searches which compute set-theoretic
     operations based on sets of threads. So I want the set of threads
     which have a message of "tag:inbox" and subtract from that the set
     of threads which have a message of "tag:muted".

     Note that this result is different than what we can currently
     compute which is a set of threads containing messages that match
     "tag:inbox and not tag:muted". This will return threads that I have
     muted when new messages arrive to the thread after I added the
     muted tag to the older messages. So we do need some new support
     here.

     For my merge window, I also want something that can't be obtained
     today. I want to see all threads that contain at least one message
     that matches my date range and at least one message that doesn't
     have the "merged" or "postponed" tag. That is, I can merge a
     feature and mark it "merged", but if someone replies later noticing
     a defect in the patch I merged, then I want that thread to reappear
     in my search results. But my current date restriction prevents
     that.

     I'm not sure how to best provide the ability to express the result
     I want here. But clearly, we want to come up with a syntax that's
     powerful enough to capture these kinds of things. (And I think this
     will go beyond the search capabilities of most email systems that
     I'm aware of.)

-Carl
-------------- 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/20100409/a636756d/attachment.pgp>