47/6687e01498bcfe47716fec84550b4a89a95bef

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 0B352431FB6\r
   6         for <notmuch@notmuchmail.org>; Mon, 28 Jan 2013 18:44:54 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.01\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
  12         tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id ZuQYcSllI8Iv for <notmuch@notmuchmail.org>;\r
  16         Mon, 28 Jan 2013 18:44:53 -0800 (PST)\r
  17 Received: from arlo.cworth.org (arlo.cworth.org [50.126.95.6])\r
  18         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id 5DC2A431FAE\r
  21         for <notmuch@notmuchmail.org>; Mon, 28 Jan 2013 18:44:53 -0800 (PST)\r
  22 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  23         by arlo.cworth.org (Postfix) with ESMTP id EF01C29A063;\r
  24         Mon, 28 Jan 2013 18:44:51 -0800 (PST)\r
  25 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  26         id C700A67855; Mon, 28 Jan 2013 18:47:33 -0800 (PST)\r
  27 From: Carl Worth <cworth@cworth.org>\r
  28 To: Robert Mast <beheerder@tekenbeetziekten.nl>,\r
  29         'Jani Nikula' <jani@nikula.org>, notmuch@notmuchmail.org\r
  30 Subject: RE: Reply all - issue\r
  31 In-Reply-To: <002601cdfd83$83b283f0$8b178bd0$@nl>\r
  32 References: <000001cdfcd9$82500f00$86f02d00$@nl> <87wquxjq7k.fsf@nikula.org>\r
  33         <002601cdfd83$83b283f0$8b178bd0$@nl>\r
  34 User-Agent: Notmuch/0.13.1 (http://notmuchmail.org) Emacs/23.4.1\r
  35         (x86_64-pc-linux-gnu)\r
  36 Date: Tue, 29 Jan 2013 13:47:33 +1100\r
  37 Message-ID: <87boc8bt8a.fsf@yoom.home.cworth.org>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: multipart/signed; boundary="=-=-=";\r
  40         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Tue, 29 Jan 2013 02:44:54 -0000\r
  54 \r
  55 --=-=-=\r
  56 \r
  57 Robert Mast <beheerder@tekenbeetziekten.nl> writes:\r
  58 > Your point on patch-breaking related to gmail and my proposal isn't\r
  59 > completely clear to me, but I've probably addressed it well with my new\r
  60 > approach.\r
  61 \r
  62 The issue here is that many developers tend to develop a patch series\r
  63 (perhaps with dozens of patches) as a single conceptual unit. When these\r
  64 are emailed out, they are often sent as one thread with a new subject\r
  65 for every patch. In particular, users of git and "git send-email" often\r
  66 send patches this way. For what it's worth, it's my preferred way to\r
  67 send and receive patches via email.\r
  68 \r
  69 It's extremely useful for messages like this to be presented as a\r
  70 single thread. This means that the dozens of messages don't clutter the\r
  71 inbox, and it also allows for an operation to act on all of the messages\r
  72 at once, (for example, notmuch provides "C-u |" which can apply all of\r
  73 the received patches to a code repository in a single operation).\r
  74 \r
  75 So, those of us accustomed to sending, receiving, reviewing, and\r
  76 applying patches emailed in this way would be basically unable to use an\r
  77 email program that split threads unconditionally on subject changes.\r
  78 \r
  79 So it may be tricky to find a single behavior that would make everyone\r
  80 happy. Perhaps a configuration option for splitting threads on subject\r
  81 changes.\r
  82 \r
  83 > I'll study the code for adding the option of unconditional (stripped)\r
  84 > subject breaking on top of the existing thread-breaking.\r
  85 \r
  86 Is there any existing thread-breaking? There wasn't the last time I\r
  87 looked at the code closely, (but admittedly, that was a while ago).\r
  88 \r
  89 -Carl\r
  90 \r
  91 \r
  92 --=-=-=\r
  93 Content-Type: application/pgp-signature\r
  94 \r
  95 -----BEGIN PGP SIGNATURE-----\r
  96 Version: GnuPG v1.4.12 (GNU/Linux)\r
  97 \r
  98 iEYEARECAAYFAlEHOEUACgkQ6JDdNq8qSWgLlgCffo6q71opXZZ8zt3iCRQPQhIW\r
  99 9KMAmQGmrC8Y7y8WPbD29mBlpKVj3lkb\r
 100 =d9g7\r
 101 -----END PGP SIGNATURE-----\r
 102 --=-=-=--\r