Patch review/application process

[Daniel Schoepe <daniel@schoepe.org>]

[-- Attachment #1: Type: text/plain, Size: 3121 bytes --]

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:

- 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.

- (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.
  
  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).

- 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

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]