1 Return-Path: <jani@nikula.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 CFA3B429E21
\r
6 for <notmuch@notmuchmail.org>; Wed, 26 Oct 2011 11:29:45 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
\r
12 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 fJNAJW2M6a4o for <notmuch@notmuchmail.org>;
\r
16 Wed, 26 Oct 2011 11:29:44 -0700 (PDT)
\r
17 Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com
\r
18 [209.85.216.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
\r
19 (No client certificate requested)
\r
20 by olra.theworths.org (Postfix) with ESMTPS id 646F4431FB6
\r
21 for <notmuch@notmuchmail.org>; Wed, 26 Oct 2011 11:29:44 -0700 (PDT)
\r
22 Received: by qyk27 with SMTP id 27so2393986qyk.5
\r
23 for <notmuch@notmuchmail.org>; Wed, 26 Oct 2011 11:29:42 -0700 (PDT)
\r
24 Received: by 10.229.19.200 with SMTP id c8mr98117qcb.71.1319653782285;
\r
25 Wed, 26 Oct 2011 11:29:42 -0700 (PDT)
\r
26 Received: from localhost (nikula.org. [92.243.24.172])
\r
27 by mx.google.com with ESMTPS id gx9sm3307733qab.12.2011.10.26.11.29.39
\r
28 (version=SSLv3 cipher=OTHER); Wed, 26 Oct 2011 11:29:40 -0700 (PDT)
\r
29 From: Jani Nikula <jani@nikula.org>
\r
30 To: Daniel Schoepe <daniel@schoepe.org>, notmuch@notmuchmail.org
\r
31 Subject: Re: Patch review/application process
\r
32 In-Reply-To: <878vo8kdl2.fsf@gilead.invalid>
\r
33 References: <878vo8kdl2.fsf@gilead.invalid>
\r
34 User-Agent: Notmuch/0.5-232-g917e874 (http://notmuchmail.org) Emacs/23.1.1
\r
36 Date: Wed, 26 Oct 2011 18:29:37 +0000
\r
37 Message-ID: <87mxcnbo8e.fsf@nikula.org>
\r
39 Content-Type: text/plain; charset=us-ascii
\r
40 X-BeenThere: notmuch@notmuchmail.org
\r
41 X-Mailman-Version: 2.1.13
\r
43 List-Id: "Use and development of the notmuch mail system."
\r
44 <notmuch.notmuchmail.org>
\r
45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
46 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
47 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
48 List-Post: <mailto:notmuch@notmuchmail.org>
\r
49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
51 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
52 X-List-Received-Date: Wed, 26 Oct 2011 18:29:45 -0000
\r
54 On Tue, 25 Oct 2011 22:42:33 +0200, Daniel Schoepe <daniel@schoepe.org> wrote:
\r
55 > as many of you have probably noticed, the time after which patches are
\r
56 > reviewed and/or applied is considerably higher lately than it was, for
\r
57 > example, earlier this year. My subjective impression is that there is
\r
58 > also a recent increase in contributions and general activity for/about
\r
59 > notmuch. Since long waiting times between sending a patch and receiving
\r
60 > a response will probably deter some (potential) contributors from
\r
61 > working / continuing to work on notmuch, I find this to be an important
\r
62 > issue. There is also a number of patches that have been reviewed by
\r
63 > long-term contributors, but are then seemingly forgotten (I can find
\r
64 > some concrete examples of this, if this claim is in doubt).
\r
66 The good thing is, there are contributions and review. The bad thing is,
\r
67 unless you've hung around long enough, you don't know if the reviewers
\r
68 are people whose comments you should really pay attention to or not, and
\r
69 either way, fixing the patches seems pointless and frustrating if they
\r
70 don't get applied anyway.
\r
72 A MAINTAINERS file might be helpful in identifying some of the key
\r
73 people. AUTHORS could be updated to include people with not
\r
74 insignificant contributions.
\r
76 > - Further delegate responsibility for the various parts, specifically
\r
77 > the emacs UI, which has a large number of outstanding patches. I'd be
\r
78 > in favor (if Carl is okay with it, of course) of giving one or more
\r
79 > people (Jameson and Austin came up as possible candidates when
\r
80 > discussing this on IRC, if they are willing) the authority to apply
\r
81 > patches for the emacs UI, similar to how patches for bindings are
\r
84 Agreed. I sincerely hope Carl and the candidates are willing. And if
\r
85 not, a favorable review from the long-term contributors (see AUTHORS
\r
86 above) should carry more weight in getting the patches applied in a
\r
89 > - (Re)try some patch/issue management software: Since patches are easily
\r
90 > forgotten if they just float around in several months old mails, it
\r
91 > might be prudent to use something to keep track of patches or issues
\r
92 > these patches address. I know that the patchwork instance didn't work
\r
93 > out so well, partly because it didn't recognize new versions of sent
\r
94 > patches. An alternative might be an issue-based system, which would be
\r
95 > comfortably usable if it supported discussing issues via mail instead
\r
96 > of having to use some web interface. I think this is supported by
\r
99 If the problem is lack of time, I'm not sure if setting up and
\r
100 maintaining some world facing web service would help things.
\r
102 > A mechanism to share notmuch tags between users could probably also be
\r
103 > adapted for this purpose, but this would make it harder for
\r
104 > non-notmuch users to discuss issues / see existing with the same
\r
105 > comfort. (Package maintainers or people who want to check what
\r
106 > outstanding flaws exist before migrating to notmuch come to mind).
\r
108 Hmm, if there was a way to reference messages in Mailman/pipermail
\r
109 archive using message IDs, I'm sure it would be trivial to export the
\r
110 tags to simple html with links to the mails in the mailing list archive.
\r
112 > - Some kind of "voting system" that gets a patch applied if some
\r
113 > number of "trusted" contributors reviewed a patch and think it is
\r
114 > good. I haven't given this idea much thought and I guess it might
\r
115 > lead to a "lack of direction / guiding principles" in the development
\r
118 I wouldn't put too much emphasis on creating a voting system or a
\r
119 process. I do have hopes for the tag sharing mechanism helping in
\r
120 tracking the reviewed patches, though. That means figuring out whose
\r
121 tags to trust anyway.
\r
123 > I'm probably overlooking some downsides of those ideas, so I'd like to
\r
124 > hear any responses and/or other approaches to deal with this (Of course,
\r
125 > I'm also open to arguments showing that I'm making too big a deal out of
\r
128 Thanks for bringing this up.
\r
projects / notmuch-archives.git / blob