From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 6604E431FD0 for ; Tue, 1 Nov 2011 14:28:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] autolearn=disabled 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 PTlacR0V4M2e for ; Tue, 1 Nov 2011 14:28:00 -0700 (PDT) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.239.19]) by olra.theworths.org (Postfix) with ESMTP id C01E2431FB6 for ; Tue, 1 Nov 2011 14:28:00 -0700 (PDT) Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1]) by fire-doxen-postvirus (Postfix) with ESMTP id 5B5E23281CE; Tue, 1 Nov 2011 14:28:00 -0700 (PDT) X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new Received: from finestructure.net (DHCP-123-180.caltech.edu [131.215.123.180]) (Authenticated sender: jrollins) by fire-doxen-submit (Postfix) with ESMTP id F2F132E50D56; Tue, 1 Nov 2011 14:27:55 -0700 (PDT) Received: by finestructure.net (Postfix, from userid 1000) id DB8484BF; Tue, 1 Nov 2011 14:27:55 -0700 (PDT) From: Jameson Graef Rollins To: David Bremner , Daniel Schoepe , notmuch@notmuchmail.org Subject: Re: Patch review/application process In-Reply-To: <87vcr3ehyg.fsf@convex-new.cs.unb.ca> References: <878vo8kdl2.fsf@gilead.invalid> <87hb2n7w82.fsf@zancas.localnet> <87sjm74z36.fsf@servo.finestructure.net> <87vcr3ehyg.fsf@convex-new.cs.unb.ca> User-Agent: Notmuch/0.9+39~g74c9dba (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Tue, 01 Nov 2011 14:27:53 -0700 Message-ID: <87ehxr4jom.fsf@servo.finestructure.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; 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: Tue, 01 Nov 2011 21:28:01 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Tue, 01 Nov 2011 16:55:03 -0300, David Bremner wrote: > One thing I think we need to clarify a bit is are we tagging whole > threads or individual messages in the database. Because of the way > notmuch search works, I had been tagging whole threads with > notmuch::pushed (effectively to "mute" them) in the search >=20 > notmuch search tag:notmuch::patch and \ > not tag:notmuch::pushed >=20 > This is a bit aesthetically unappealing, anad every time someone replies > to a thread it is effectively unmuted. I have to say that I am very much against tagging threads with tags that are really only applicable to specific messages, ie. ::patch, ::pushed (I prefer ::applied, but whatever), etc. For instance, a thread maybe contain multiple patches, but it is not itself a patch. Tagging entire threads as ::patch means you can't do something like this: notmuch show --format=3Dmbox tag:notmuch::patch and not tag:notmuch::applie= d | git am which would in my opinion be a shame. > Since we don't have thread tagging yet (where e.g. tags are > automagically applied to new messages I was thinking it might work have > a tag like "notmuch::todo" and something like the following workflow > (for patches) I'm not sure why this is needed, since it seems to me that the whole argument for tagging entire threads is that the individual messages are *not* distinguishable from the thread. > initially tag +notmuch::patch +notmuch::todo >=20 > then when we "dispose" of the patch somehow, remove the notmuch::todo tag= and > replace with > notmuch::pushed > notmuch::obsolete > or... Please do *not* remove the ::patch tag. There is really no reason to. The message still contain a patch whether or not it is applied upstream. I really think this is important. The addition of something From=20a set of "resolution" tags (::pushed, ::applied, ::obsolete, ::rejected, etc.) should indicate resolution of the issue. jamie. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOsGRZAAoJEO00zqvie6q8DLwP/jrXnfe4JMaEQM5husRaoblE xnN/Ocbu9fZ5dioz5l65RnJOYigUk+1k4v0cCUCE4MFs5iYkbuKjHIOpfN4wbuTg 7O3uFuOdTGy9IduTrrg3oEdC2TyQsCW/GCRUNcNksDHMd6WoBxs2YVqL9KXEbJP2 KHNlk1qXeDkLq0sqeLRMPoreLd3olUxD3HtahkxQfEt74fgYfXDFm7En6oUbAnG4 i2c/wLd6h6Ip+tb0/tDkpFzTeey0yqvh4x1tG9GK9/NVNu3nZXlKVgfMPBHqes8x qltVMRhfkHY1cwNE3xDCkQXItiWEhY+GYA1++QY+RsSM2orHAgSoFhLStjG/agev lKdXSQ09osP4hJAYv2iH9lu1vuL8eUgm2MQzvuNCFhjfWbkxiPtyvpM4kJ7cpBAQ QgiCTP3sPQtZC2qkSMnFRErtizrv1j7b2Bcy5WitOAtil+AI+X83yne5tvY/wIjS nqLCMz+fJrWWgZ2ILSfTtGX0v8A5+oXWpRwnju1PHo6xMKuPAqU5mGoen2+RAB7u RQnEJHCCMBlAYL7gll1FTCvOUtLH3UHuSl/fV2MWum1LG+Yu7bGMCePIvV2R22vH ivF4rs2ZCInNgIfsWIW0aTW6wYwJ5jcBX2ox9cUQv2ifLg2WGcwY4UPxC6H3npnJ ZWPNw4f1rdya2l2m4pyj =lpjq -----END PGP SIGNATURE----- --=-=-=--