From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id E799E431FD0 for ; Tue, 25 Oct 2011 13:44:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_MIME_NO_TEXT=0.01] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qouv3uI0RSpg for ; Tue, 25 Oct 2011 13:44:22 -0700 (PDT) Received: from mail-fx0-f53.google.com (mail-fx0-f53.google.com [209.85.161.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id B1563431FB6 for ; Tue, 25 Oct 2011 13:44:22 -0700 (PDT) Received: by faai28 with SMTP id i28so1010606faa.26 for ; Tue, 25 Oct 2011 13:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=schoepe.org; s=google; h=from:to:subject:user-agent:date:message-id:mime-version :content-type; bh=pPKh9eAUmVEOiFjadXT3hKH/gtVVwqY/oMqCTZ4KUys=; b=JOLxOEAjHHHwgHd6u8MZu1t1nGxjZKMtP8OlR6fr2eXZCnmLYkQtjzZx41CCHFyK2G qJ4BwxmFASqTGbVnT8rb2yIS2ET9pySzTctglIFpZULCzsa10ry8F9amaofi/CwPRk8x BiWXvRDkhl3tXG9QisbcJH56wXHNZ/K1T1ocY= Received: by 10.223.60.73 with SMTP id o9mr53682822fah.18.1319575375506; Tue, 25 Oct 2011 13:42:55 -0700 (PDT) Received: from localhost (dslb-178-004-024-186.pools.arcor-ip.net. [178.4.24.186]) by mx.google.com with ESMTPS id w11sm19003651fad.7.2011.10.25.13.42.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Oct 2011 13:42:45 -0700 (PDT) From: Daniel Schoepe To: notmuch@notmuchmail.org Subject: Patch review/application process User-Agent: Notmuch/0.9-19-ga25c9a0 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Tue, 25 Oct 2011 22:42:33 +0200 Message-ID: <878vo8kdl2.fsf@gilead.invalid> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 20:44:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Hello, as many of you have probably noticed, the time after which patches are reviewed and/or applied is considerably higher lately than it was, for example, earlier this year. My subjective impression is that there is also a recent increase in contributions and general activity for/about notmuch. Since long waiting times between sending a patch and receiving a response will probably deter some (potential) contributors from working / continuing to work on notmuch, I find this to be an important issue. There is also a number of patches that have been reviewed by long-term contributors, but are then seemingly forgotten (I can find some concrete examples of this, if this claim is in doubt). For me notmuch is a huge improvement compared to existing clients (with the somewhat obvious exception of sup which comes close), so I'd really hate to see this project stagnate or "wither" because of this. I am aware that this is a volunteer project and hence the intent of this post is not to urge Carl Worth or anyone else to "hurry up!" with the patch review. Instead I'd like to discuss approaches on how to deal with this problem. Here a few ideas I was able to come up with: =2D Further delegate responsibility for the various parts, specifically the emacs UI, which has a large number of outstanding patches. I'd be in favor (if Carl is okay with it, of course) of giving one or more people (Jameson and Austin came up as possible candidates when discussing this on IRC, if they are willing) the authority to apply patches for the emacs UI, similar to how patches for bindings are handled. =2D (Re)try some patch/issue management software: Since patches are easily forgotten if they just float around in several months old mails, it might be prudent to use something to keep track of patches or issues these patches address. I know that the patchwork instance didn't work out so well, partly because it didn't recognize new versions of sent patches. An alternative might be an issue-based system, which would be comfortably usable if it supported discussing issues via mail instead of having to use some web interface. I think this is supported by redmine. =20=20 A mechanism to share notmuch tags between users could probably also be adapted for this purpose, but this would make it harder for non-notmuch users to discuss issues / see existing with the same comfort. (Package maintainers or people who want to check what outstanding flaws exist before migrating to notmuch come to mind). =2D Some kind of "voting system" that gets a patch applied if some number of "trusted" contributors reviewed a patch and think it is good. I haven't given this idea much thought and I guess it might lead to a "lack of direction / guiding principles" in the development of notmuch. I'm probably overlooking some downsides of those ideas, so I'd like to hear any responses and/or other approaches to deal with this (Of course, I'm also open to arguments showing that I'm making too big a deal out of this :)). Cheers, Daniel --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJOpx85AAoJEIaTAtce+Z+JGzEP/RxDpbsYYasss+h8PxCWFuDJ TDyywc42Vl5sxRXEdWn6PlFQN4zft8x7Fg/eptYo94ZP2EW9tt4Z8jbeXHWl1FIp RI7vSS+JB10rxW4eov/gpmwxmPLC0VopfA7KiF9F0FFMxVnDPg/sI63lCV74NHTF 2yWfqAKV10h0O0uz1kmwE2z4RW8GfjMT8ncXivB3p6CXVFULr0HTTrT9NxDJOPxD Gj6B9ZA+zT6vOQwO0gyszFRGcE9s0/kEVl3hhhlFdggxpddnsKU0PJt6GQNPfd+J WJCSOcyk1oDXZ41MRGO3duuty2kvTqqa4mX7VKRxnYgcWyrJ/Zw7Llk5BoQP/8WQ tOV4BJKJFHbqb6VHJjeoGCygzN/33PWi7Y7oeISW+OuGW4O1d1pcIf+rpXqRJwpl SGtRbX6eZM+1Y64FqBRgB/3gopos55/vYOAkSRwZkwvh5FktO46R8pURTyp/QjW/ 4K5ROGbrujlwki3mkVfkxL6PDYGPvPsb3GgxfuRpumjtgZk/cle/Ptd+aJqOFlhx dJNe3yc86H3EkJxSMKRuQTU6/SJg/SYg25Lwg3EPa5aC3VPJj6NHWTvRGk7du0FN RC8Abk+sidCsLxCgpBu/DHohjZFxNNi2HDxXAkm+HHpvCcrOynSFl0f5ZanexFHX tpMBAkWtwNH/3/AFPfhO =miT0 -----END PGP SIGNATURE----- --=-=-=--