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 25860431FD0
\r
6 for <notmuch@notmuchmail.org>; Wed, 22 Jun 2011 18:21:17 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
\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 J+kVLy+uJKCJ for <notmuch@notmuchmail.org>;
\r
16 Wed, 22 Jun 2011 18:21:16 -0700 (PDT)
\r
17 Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])
\r
18 by olra.theworths.org (Postfix) with ESMTP id 1D93A431FB6
\r
19 for <notmuch@notmuchmail.org>; Wed, 22 Jun 2011 18:21:16 -0700 (PDT)
\r
20 Received: from yoom.home.cworth.org (localhost [127.0.0.1])
\r
21 by arlo.cworth.org (Postfix) with ESMTP id 910F829A4FB;
\r
22 Wed, 22 Jun 2011 18:21:14 -0700 (PDT)
\r
23 Received: by yoom.home.cworth.org (Postfix, from userid 1000)
\r
24 id 83702254157; Wed, 22 Jun 2011 18:21:14 -0700 (PDT)
\r
25 From: Carl Worth <cworth@cworth.org>
\r
26 To: Jameson Graef Rollins <jrollins@finestructure.net>,
\r
27 Notmuch Mail <notmuch@notmuchmail.org>
\r
28 Subject: Re: When will we have our next release?
\r
29 In-Reply-To: <87r575eglj.fsf@servo.factory.finestructure.net>
\r
30 References: <878vtile1h.fsf@yoom.home.cworth.org>
\r
31 <87r575eglj.fsf@servo.factory.finestructure.net>
\r
32 User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
\r
34 Date: Wed, 22 Jun 2011 18:21:08 -0700
\r
35 Message-ID: <874o3hfim3.fsf@yoom.home.cworth.org>
\r
37 Content-Type: multipart/signed; boundary="=-=-=";
\r
38 micalg=pgp-sha1; protocol="application/pgp-signature"
\r
39 X-BeenThere: notmuch@notmuchmail.org
\r
40 X-Mailman-Version: 2.1.13
\r
42 List-Id: "Use and development of the notmuch mail system."
\r
43 <notmuch.notmuchmail.org>
\r
44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
45 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
47 List-Post: <mailto:notmuch@notmuchmail.org>
\r
48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
50 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
51 X-List-Received-Date: Thu, 23 Jun 2011 01:21:17 -0000
\r
54 Content-Type: text/plain; charset=utf-8
\r
55 Content-Transfer-Encoding: quoted-printable
\r
57 On Tue, 07 Jun 2011 09:44:40 -0700, Jameson Graef Rollins <jrollins@finestr=
\r
59 > > Frankly, I wouldn't mind doing strict time-based releases with something
\r
60 > > like the following:
\r
62 > Hi, Carl. I think this is a fine idea, and we (not you) can definitely
\r
63 > run this process. I'm quite sure that at least bremner and I can
\r
64 > completely handle this together, and I'm sure we can get others to
\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:
\r
72 This is a problem if master isn't moving, I agree. And that has been a
\r
73 problem in the past.
\r
75 More recently, master has been moving just fine, and I have proven to
\r
76 get too caught up in "oh, just a few more bug fixes to merge..." to just
\r
77 sit down and make a release. So that's what I want to fix now.
\r
79 To that end, I've just nominated David Bremner as our release
\r
80 manager. He's already been pushing packages of recent notmuch master to
\r
81 Debian experimental, so he's effectively already in the role of choosing
\r
82 particular code states that the "masses" can easily get their hands on.
\r
84 I've asked him to just take over the release process from here and I've
\r
85 pretty much left all decisions in his hands. He'll probably make a
\r
86 separate branch for the release at some point, (in the primary
\r
87 repository). I'll let him talk more about plans if he needs to.
\r
89 > This is *not* meant to be an indictment of you at all. I know it's
\r
90 > incredibly hard to keep up with the incoming patch flow. It takes a lot
\r
91 > of time and work to review every patch. I also really like your
\r
92 > reviews. They are incredibly thorough and insightful, and I always
\r
95 Thanks. That's very kind of you to say so.
\r
97 > I would really like to continue to get your review of patches. I think
\r
98 > they're just too valuable. So it would be really nice if one of the
\r
99 > solutions was a way to just "grease" the bottleneck, so to speak. For
\r
100 > instance, if you could commit to reviewing just 1 patch series a week we
\r
101 > would be way ahead of where we have been.
\r
103 I can't really promise anything other than doing the best I can to stay
\r
104 on top of things. Lately, I am at least using notmuch itself more
\r
105 effectively to manage outstanding patches and this is helping I thinl.
\r
107 > Another thing that would help would be to delegate responsibility of
\r
108 > certain components to others, as you have with the python binding to
\r
109 > spaetz. For instance, we have at least a couple of elisp experts
\r
110 > hanging around. Maybe you could cede handling of all emacs patches to
\r
111 > someone like jkr or dme, and to felipe for vim, etc. (if they're willing
\r
112 > to take on those rolls). That would help reduce your burden a bit.
\r
114 Yes! For people that are already effectively maintaining isolated
\r
115 portions of the code, I'm more than happy to delegate full editorial
\r
116 control over those pieces, (and allow direct pushes, etc.). This has
\r
117 actually already been happening with python and vim pieces. And I plan
\r
118 to add some new mutt code soon with its own maintainer.
\r
120 And the delegation of release management that I'm announcing here will
\r
123 > We could also formalize some sort of tiered review system. amdragon has
\r
124 > been doing a really good job of frequently providing good review of
\r
125 > patches on list. I think that any proposed patch that gets a thumbs up
\r
126 > From someone like amdragon should immediately be elevated in your queue,
\r
127 > or just applied out-right. If the review of others explicitly helped
\r
128 > get patches merged faster, I'm quite sure it would encourage more folks
\r
129 > to submit their reviews as well.
\r
131 I would love to have more review from anyone. I don't think there's any
\r
132 need to formalize anything.
\r
134 Much of it can be as simple as watching things you've seen me do and
\r
135 then doing them yourself. For example, there are a lot of recent patches
\r
136 that I merged only after I wrote a test case for the bug fix. It's quite
\r
137 a bottleneck for me to write new tests like that. If other people could
\r
138 review patches and ask for test cases, or write test cases themselves,
\r
139 then that would definitely relieve a burden on my part.
\r
141 Similarly, I think the most regular coders on the project have come to
\r
142 understand what I expect from commit messages. So that's something else
\r
143 that's pretty easy for anyone to review.
\r
145 So, yes, please help in the review process, everybody! I don't think I
\r
146 have any particularly exclusive talent with regard to judging code to be
\r
147 clean and in good taste. I definitely appreciate the good sense of taste
\r
148 that many on this list are demonstrating regularly.
\r
150 > Notmuch is an incredible project, with an absolutely incredible
\r
151 > development community. It's an absolute joy to work on.
\r
153 I absolutely agree. I haven't taken the opportunity often enough to say
\r
154 thank you to everyone who has contributed!
\r
158 It's such a wonderful thing to me to see so many good people working
\r
159 hard and having fun to collectively make such a fun tool![*]
\r
161 > If we can just grease the wheels a little bit to get releases out the
\r
162 > door a little quicker, I think we'll all be a lot happier.
\r
164 Hopefully, we're doing that. Thanks for all your efforts, Jamie. I
\r
165 really appreciate them. And I'm happier at least!
\r
169 [*] For "fun tool" I always have to hesitate a bit=E2=80=94notmuch itself is
\r
170 fun, but it's funny that email itself is often more annoying to me than
\r
171 anything else. I suppose what makes notmuch fun is that it helps me more
\r
172 quickly eliminate so much of the annoyance of email from my life so that
\r
173 I can focus more on the things that I really want to.
\r
176 carl.d.worth@intel.com
\r
179 Content-Type: application/pgp-signature
\r
181 -----BEGIN PGP SIGNATURE-----
\r
182 Version: GnuPG v1.4.11 (GNU/Linux)
\r
184 iEYEARECAAYFAk4ClQQACgkQ6JDdNq8qSWicwACfWlA+8VfDxkl9Qk2pc/AIXYaz
\r
185 5jUAoJEKj6UPkQbEs1fuXw02DGKdSCJV
\r
187 -----END PGP SIGNATURE-----
\r
projects / notmuch-archives.git / blob