Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 447574196F0 for ; Fri, 9 Apr 2010 09:23:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcgVgJGzRpLC for ; Fri, 9 Apr 2010 09:23:28 -0700 (PDT) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 4AF66431FC1 for ; Fri, 9 Apr 2010 09:23:28 -0700 (PDT) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id EAF66568E07; Fri, 9 Apr 2010 09:23:27 -0700 (PDT) From: Carl Worth To: notmuch@notmuchmail.org Subject: Initial attempt at a "merge window" for notmuch Date: Fri, 09 Apr 2010 09:23:27 -0700 Message-ID: <87hbnktx1c.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 16:23:29 -0000 --=-=-= 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 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLv1R/6JDdNq8qSWgRAnrnAJ4pHJyjmuTocz8kyiUvIvhWeXZ9rQCgqBXg lrXUyFvu/GXBZvII4I89ZEQ= =AGur -----END PGP SIGNATURE----- --=-=-=--