Re: [feature request] emacs: use `notmuch insert` for FCC
[notmuch-archives.git] / 89 / be59c4f14d2f9fe15e06ba2df5f434fe62c612
1 Return-Path: <daniel@schoepe.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 E799E431FD0\r
6         for <notmuch@notmuchmail.org>; Tue, 25 Oct 2011 13:44:24 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.79\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
13         RCVD_IN_DNSWL_LOW=-0.7, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id Qouv3uI0RSpg for <notmuch@notmuchmail.org>;\r
17         Tue, 25 Oct 2011 13:44:22 -0700 (PDT)\r
18 Received: from mail-fx0-f53.google.com (mail-fx0-f53.google.com\r
19         [209.85.161.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id B1563431FB6\r
22         for <notmuch@notmuchmail.org>; Tue, 25 Oct 2011 13:44:22 -0700 (PDT)\r
23 Received: by faai28 with SMTP id i28so1010606faa.26\r
24         for <notmuch@notmuchmail.org>; Tue, 25 Oct 2011 13:44:21 -0700 (PDT)\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=schoepe.org; s=google;\r
26         h=from:to:subject:user-agent:date:message-id:mime-version\r
27         :content-type; bh=pPKh9eAUmVEOiFjadXT3hKH/gtVVwqY/oMqCTZ4KUys=;\r
28         b=JOLxOEAjHHHwgHd6u8MZu1t1nGxjZKMtP8OlR6fr2eXZCnmLYkQtjzZx41CCHFyK2G\r
29         qJ4BwxmFASqTGbVnT8rb2yIS2ET9pySzTctglIFpZULCzsa10ry8F9amaofi/CwPRk8x\r
30         BiWXvRDkhl3tXG9QisbcJH56wXHNZ/K1T1ocY=\r
31 Received: by 10.223.60.73 with SMTP id o9mr53682822fah.18.1319575375506;\r
32         Tue, 25 Oct 2011 13:42:55 -0700 (PDT)\r
33 Received: from localhost (dslb-178-004-024-186.pools.arcor-ip.net.\r
34         [178.4.24.186])\r
35         by mx.google.com with ESMTPS id w11sm19003651fad.7.2011.10.25.13.42.45\r
36         (version=TLSv1/SSLv3 cipher=OTHER);\r
37         Tue, 25 Oct 2011 13:42:45 -0700 (PDT)\r
38 From: Daniel Schoepe <daniel@schoepe.org>\r
39 To: notmuch@notmuchmail.org \r
40 Subject: Patch review/application process\r
41 User-Agent: Notmuch/0.9-19-ga25c9a0 (http://notmuchmail.org) Emacs/23.3.1\r
42         (x86_64-pc-linux-gnu)\r
43 Date: Tue, 25 Oct 2011 22:42:33 +0200\r
44 Message-ID: <878vo8kdl2.fsf@gilead.invalid>\r
45 MIME-Version: 1.0\r
46 Content-Type: multipart/signed; boundary="=-=-=";\r
47         micalg=pgp-sha1; protocol="application/pgp-signature"\r
48 X-BeenThere: notmuch@notmuchmail.org\r
49 X-Mailman-Version: 2.1.13\r
50 Precedence: list\r
51 List-Id: "Use and development of the notmuch mail system."\r
52         <notmuch.notmuchmail.org>\r
53 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
54         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
55 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
56 List-Post: <mailto:notmuch@notmuchmail.org>\r
57 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
58 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
59         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
60 X-List-Received-Date: Tue, 25 Oct 2011 20:44:25 -0000\r
61 \r
62 --=-=-=\r
63 Content-Transfer-Encoding: quoted-printable\r
64 \r
65 Hello,\r
66 \r
67 as many of you have probably noticed, the time after which patches are\r
68 reviewed and/or applied is considerably higher lately than it was, for\r
69 example, earlier this year. My subjective impression is that there is\r
70 also a recent increase in contributions and general activity for/about\r
71 notmuch. Since long waiting times between sending a patch and receiving\r
72 a response will probably deter some (potential) contributors from\r
73 working / continuing to work on notmuch, I find this to be an important\r
74 issue. There is also a number of patches that have been reviewed by\r
75 long-term contributors, but are then seemingly forgotten (I can find\r
76 some concrete examples of this, if this claim is in doubt).\r
77 \r
78 For me notmuch is a huge improvement compared to existing clients (with\r
79 the somewhat obvious exception of sup which comes close), so I'd really\r
80 hate to see this project stagnate or "wither" because of this.\r
81 \r
82 I am aware that this is a volunteer project and hence the intent of this\r
83 post is not to urge Carl Worth or anyone else to "hurry up!" with the\r
84 patch review. Instead I'd like to discuss approaches on how to deal with\r
85 this problem. Here a few ideas I was able to come up with:\r
86 \r
87 =2D Further delegate responsibility for the various parts, specifically\r
88   the emacs UI, which has a large number of outstanding patches. I'd be\r
89   in favor (if Carl is okay with it, of course) of giving one or more\r
90   people (Jameson and Austin came up as possible candidates when\r
91   discussing this on IRC, if they are willing) the authority to apply\r
92   patches for the emacs UI, similar to how patches for bindings are\r
93   handled.\r
94 \r
95 =2D (Re)try some patch/issue management software: Since patches are easily\r
96   forgotten if they just float around in several months old mails, it\r
97   might be prudent to use something to keep track of patches or issues\r
98   these patches address. I know that the patchwork instance didn't work\r
99   out so well, partly because it didn't recognize new versions of sent\r
100   patches. An alternative might be an issue-based system, which would be\r
101   comfortably usable if it supported discussing issues via mail instead\r
102   of having to use some web interface. I think this is supported by\r
103   redmine.\r
104 =20=20\r
105   A mechanism to share notmuch tags between users could probably also be\r
106   adapted for this purpose, but this would make it harder for\r
107   non-notmuch users to discuss issues / see existing with the same\r
108   comfort. (Package maintainers or people who want to check what\r
109   outstanding flaws exist before migrating to notmuch come to mind).\r
110 \r
111 =2D Some kind of "voting system" that gets a patch applied if some\r
112   number of "trusted" contributors reviewed a patch and think it is\r
113   good. I haven't given this idea much thought and I guess it might\r
114   lead to a "lack of direction / guiding principles" in the development\r
115   of notmuch.\r
116 \r
117 I'm probably overlooking some downsides of those ideas, so I'd like to\r
118 hear any responses and/or other approaches to deal with this (Of course,\r
119 I'm also open to arguments showing that I'm making too big a deal out of\r
120 this :)).\r
121 \r
122 Cheers,\r
123 Daniel\r
124 \r
125 --=-=-=\r
126 Content-Type: application/pgp-signature\r
127 \r
128 -----BEGIN PGP SIGNATURE-----\r
129 Version: GnuPG v1.4.11 (GNU/Linux)\r
130 \r
131 iQIcBAEBAgAGBQJOpx85AAoJEIaTAtce+Z+JGzEP/RxDpbsYYasss+h8PxCWFuDJ\r
132 TDyywc42Vl5sxRXEdWn6PlFQN4zft8x7Fg/eptYo94ZP2EW9tt4Z8jbeXHWl1FIp\r
133 RI7vSS+JB10rxW4eov/gpmwxmPLC0VopfA7KiF9F0FFMxVnDPg/sI63lCV74NHTF\r
134 2yWfqAKV10h0O0uz1kmwE2z4RW8GfjMT8ncXivB3p6CXVFULr0HTTrT9NxDJOPxD\r
135 Gj6B9ZA+zT6vOQwO0gyszFRGcE9s0/kEVl3hhhlFdggxpddnsKU0PJt6GQNPfd+J\r
136 WJCSOcyk1oDXZ41MRGO3duuty2kvTqqa4mX7VKRxnYgcWyrJ/Zw7Llk5BoQP/8WQ\r
137 tOV4BJKJFHbqb6VHJjeoGCygzN/33PWi7Y7oeISW+OuGW4O1d1pcIf+rpXqRJwpl\r
138 SGtRbX6eZM+1Y64FqBRgB/3gopos55/vYOAkSRwZkwvh5FktO46R8pURTyp/QjW/\r
139 4K5ROGbrujlwki3mkVfkxL6PDYGPvPsb3GgxfuRpumjtgZk/cle/Ptd+aJqOFlhx\r
140 dJNe3yc86H3EkJxSMKRuQTU6/SJg/SYg25Lwg3EPa5aC3VPJj6NHWTvRGk7du0FN\r
141 RC8Abk+sidCsLxCgpBu/DHohjZFxNNi2HDxXAkm+HHpvCcrOynSFl0f5ZanexFHX\r
142 tpMBAkWtwNH/3/AFPfhO\r
143 =miT0\r
144 -----END PGP SIGNATURE-----\r
145 --=-=-=--\r