Patch review/application process

Jani Nikula jani at nikula.org
Wed Oct 26 11:29:37 PDT 2011


On Tue, 25 Oct 2011 22:42:33 +0200, Daniel Schoepe <daniel at schoepe.org> wrote:
> 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).

The good thing is, there are contributions and review. The bad thing is,
unless you've hung around long enough, you don't know if the reviewers
are people whose comments you should really pay attention to or not, and
either way, fixing the patches seems pointless and frustrating if they
don't get applied anyway.

A MAINTAINERS file might be helpful in identifying some of the key
people. AUTHORS could be updated to include people with not
insignificant contributions.

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

Agreed. I sincerely hope Carl and the candidates are willing. And if
not, a favorable review from the long-term contributors (see AUTHORS
above) should carry more weight in getting the patches applied in a
timely manner.

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

If the problem is lack of time, I'm not sure if setting up and
maintaining some world facing web service would help things.

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

Hmm, if there was a way to reference messages in Mailman/pipermail
archive using message IDs, I'm sure it would be trivial to export the
tags to simple html with links to the mails in the mailing list archive.

> - 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 wouldn't put too much emphasis on creating a voting system or a
process. I do have hopes for the tag sharing mechanism helping in
tracking the reviewed patches, though. That means figuring out whose
tags to trust anyway.

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

Thanks for bringing this up.


BR,
Jani.


More information about the notmuch mailing list