Re: [PATCH] test: do not hide test_emacs errors
[notmuch-archives.git] / f3 / d55a4a7403a049fc2d476238e0b137bd500f41
1 Return-Path: <jrollins@finestructure.net>\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 6C234429E25\r
6         for <notmuch@notmuchmail.org>; Tue,  7 Jun 2011 09:44:55 -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: -2.29\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01]\r
13         autolearn=unavailable\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 spWWo3FiSSoY for <notmuch@notmuchmail.org>;\r
17         Tue,  7 Jun 2011 09:44:55 -0700 (PDT)\r
18 Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
19         [131.215.239.19])\r
20         by olra.theworths.org (Postfix) with ESMTP id 28C09431FB6\r
21         for <notmuch@notmuchmail.org>; Tue,  7 Jun 2011 09:44:55 -0700 (PDT)\r
22 Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
23         by fire-doxen-postvirus (Postfix) with ESMTP id DE4352E50F10;\r
24         Tue,  7 Jun 2011 09:37:42 -0700 (PDT)\r
25 X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new\r
26 Received: from servo.finestructure.net (cpe-98-149-172-122.socal.res.rr.com\r
27         [98.149.172.122]) (Authenticated sender: jrollins)\r
28         by fire-doxen-submit (Postfix) with ESMTP id A57DD2E50C0A;\r
29         Tue,  7 Jun 2011 09:37:35 -0700 (PDT)\r
30 Received: by servo.finestructure.net (Postfix, from userid 1000)\r
31         id AF9947B8; Tue,  7 Jun 2011 09:44:44 -0700 (PDT)\r
32 From: Jameson Graef Rollins <jrollins@finestructure.net>\r
33 To: Carl Worth <cworth@cworth.org>, Notmuch Mail <notmuch@notmuchmail.org>\r
34 Subject: Re: When will we have our next release?\r
35 In-Reply-To: <878vtile1h.fsf@yoom.home.cworth.org>\r
36 References: <878vtile1h.fsf@yoom.home.cworth.org>\r
37 User-Agent: Notmuch/0.6 (http://notmuchmail.org) Emacs/23.3.1\r
38         (x86_64-pc-linux-gnu)\r
39 Date: Tue, 07 Jun 2011 09:44:40 -0700\r
40 Message-ID: <87r575eglj.fsf@servo.factory.finestructure.net>\r
41 MIME-Version: 1.0\r
42 Content-Type: multipart/signed; boundary="=-=-=";\r
43         micalg=pgp-sha256; protocol="application/pgp-signature"\r
44 X-BeenThere: notmuch@notmuchmail.org\r
45 X-Mailman-Version: 2.1.13\r
46 Precedence: list\r
47 List-Id: "Use and development of the notmuch mail system."\r
48         <notmuch.notmuchmail.org>\r
49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
50         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
52 List-Post: <mailto:notmuch@notmuchmail.org>\r
53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
55         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
56 X-List-Received-Date: Tue, 07 Jun 2011 16:44:55 -0000\r
57 \r
58 --=-=-=\r
59 Content-Transfer-Encoding: quoted-printable\r
60 \r
61 On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth <cworth@cworth.org> wrote:\r
62 > Frankly, I wouldn't mind doing strict time-based releases with something\r
63 > like the following:\r
64 \r
65 Hi, Carl.  I think this is a fine idea, and we (not you) can definitely\r
66 run this process.  I'm quite sure that at least bremner and I can\r
67 completely handle this together, and I'm sure we can get others to help.\r
68 \r
69 But the mechanics of the actual release are not the problem.  The\r
70 problem is the current one-person bottleneck for all patches: your\r
71 review and merge of all patches into the notmuch/master branch.  This\r
72 would not necessarily be a problem if you could get to reviewing and\r
73 merging patches more frequently.  But as it is now, if there are no new\r
74 patches on notmuch/master for longer than the release period, there will\r
75 be nothing to package and upload.\r
76 \r
77 This is *not* meant to be an indictment of you at all.  I know it's\r
78 incredibly hard to keep up with the incoming patch flow.  It takes a lot\r
79 of time and work to review every patch.  I also really like your\r
80 reviews.  They are incredibly thorough and insightful, and I always\r
81 learn from them.  Your intimate knowledge of the code base also means\r
82 that you can frequently come up with cleaner solutions to the proposed\r
83 patches (as with the reworked part handling).\r
84 \r
85 However, the bottleneck presents a big problem when delays are\r
86 introduced.  We can't really do anything until you can get to the\r
87 review.  Furthermore, even if we do push ahead to put together a release\r
88 candidate branch (as we did with 0.6), if your review severely alters\r
89 patches early in that branch we have to do a lot of work to rework their\r
90 decedents (as we did with 0.6).  This leads to a lot of inefficiencies.\r
91 \r
92 So we need to figure out a way to break the bottleneck.\r
93 \r
94 I would really like to continue to get your review of patches.  I think\r
95 they're just too valuable.  So it would be really nice if one of the\r
96 solutions was a way to just "grease" the bottleneck, so to speak.  For\r
97 instance, if you could commit to reviewing just 1 patch series a week we\r
98 would be way ahead of where we have been.\r
99 \r
100 Another thing that would help would be to delegate responsibility of\r
101 certain components to others, as you have with the python binding to\r
102 spaetz.  For instance, we have at least a couple of elisp experts\r
103 hanging around.  Maybe you could cede handling of all emacs patches to\r
104 someone like jkr or dme, and to felipe for vim, etc. (if they're willing\r
105 to take on those rolls).  That would help reduce your burden a bit.\r
106 \r
107 We could also formalize some sort of tiered review system.  amdragon has\r
108 been doing a really good job of frequently providing good review of\r
109 patches on list.  I think that any proposed patch that gets a thumbs up\r
110 From=20someone like amdragon should immediately be elevated in your queue,\r
111 or just applied out-right.  If the review of others explicitly helped\r
112 get patches merged faster, I'm quite sure it would encourage more folks\r
113 to submit their reviews as well.\r
114 \r
115 I would love to hear any other ideas people have on this front.\r
116 \r
117 Notmuch is an incredible project, with an absolutely incredible\r
118 development community.  It's an absolute joy to work on.  If we can just\r
119 grease the wheels a little bit to get releases out the door a little\r
120 quicker, I think we'll all be a lot happier.\r
121 \r
122 jamie.\r
123 \r
124 --=-=-=\r
125 Content-Type: application/pgp-signature\r
126 \r
127 -----BEGIN PGP SIGNATURE-----\r
128 Version: GnuPG v1.4.11 (GNU/Linux)\r
129 \r
130 iQIcBAEBCAAGBQJN7lV5AAoJEO00zqvie6q8OyYP/j+ibcApHlt6dQln9SEPWbMI\r
131 CAfI4zMWnwf9pGl/sbiV9BtVKVcYhibCv7BhzZyK2EjtpNhJsky/31HFi3F6RffN\r
132 R054XoN/Us2Vsa4Ed/aXK1VWpYeLsv+XOXoZ6nLx7v3fa7rrujJBvNgHGMksP0qs\r
133 RARlibPa9r85Mx/4IE4X7CZKNc8sCLyfoAs4gI96NQ5Fg3XTyAY80S5hvVGGECF6\r
134 mgjMrSGWOYGAhbfK2DQZriGEOy8SzAgwalr0FxRhZBBg/67vy71s1wALTc00Trmy\r
135 ePun0pf9EPLDRBuXz0jGFz23WLrHdviAerYRrlGY16Cb99QbLaDXExa8FET6DtpN\r
136 3tTKl17J/9RFunZ+UpQ4YosQ0oiSyFkeafY1anEnFjYRzECH2oH69L1VZ8/8q+6r\r
137 B+224n5Zam8/xiwVokgKPSUYrfLKht33kqPPtSjE+LLJvLSHRC/VfMncZwgyEtVo\r
138 qBziYh1Bc8yGJ9NWSclZtdpRpKhsvJCHpxakVoQZsdurvanzaUJ1JVZQ5Yho543e\r
139 Ocja02ZJJsvROJm6yG5GlfWmyjhzcmIPzeXZb88+VhWqTM+pAS9qhZoEyxkzM+z6\r
140 JKGTHNq8u27G/2P7pHPaFXYnyjCAALDPuAeBCuY6WnTzlq9vsObFUHN+jqQW1JHG\r
141 ufF81Zw227FnnB+XLbb1\r
142 =L2qz\r
143 -----END PGP SIGNATURE-----\r
144 --=-=-=--\r