unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Jani Nikula <jani@nikula.org>
To: Daniel Schoepe <daniel@schoepe.org>, notmuch@notmuchmail.org
Subject: Re: Patch review/application process
Date: Wed, 26 Oct 2011 18:29:37 +0000	[thread overview]
Message-ID: <87mxcnbo8e.fsf@nikula.org> (raw)
In-Reply-To: <878vo8kdl2.fsf@gilead.invalid>

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

  parent reply	other threads:[~2011-10-26 18:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-25 20:42 Patch review/application process Daniel Schoepe
2011-10-25 23:16 ` David Bremner
2011-10-26 18:29 ` Jani Nikula [this message]
2011-10-26 18:55   ` Daniel Schoepe
2011-11-01 14:28 ` David Bremner
2011-11-01 15:55   ` Jameson Graef Rollins
2011-11-01 19:55     ` David Bremner
2011-11-01 21:27       ` Jameson Graef Rollins
2011-11-01 23:22         ` David Bremner
2011-11-01 23:43           ` Jameson Graef Rollins
2011-11-02 15:49 ` Philip Hands

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mxcnbo8e.fsf@nikula.org \
    --to=jani@nikula.org \
    --cc=daniel@schoepe.org \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).