Patch queue management systems

[Eli Zaretskii <eliz@gnu.org>]

[Moved the discussion to emacs-devel.]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 06 Dec 2014 04:27:22 +0200
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Because nobody has set such a thing up (and AFAICT Savannah doesn't
> > have such a thing built-in, oddly enough).
> 
> It shouldn't be too hard, actually, to set up some code review tool,
> such as Gerrit [0], Review Board [1] or Differential [2].

I took a quick look at these.

I think by far the 2 main issues we will have with these tools are:

 . The tools don't have Emacs integration built into them, nor offer
   Emacs VC sub-modes.  (Gerrit has a magit plugin.)  I'm guessing we
   would like to arrange for such an integration in VC, because people
   who review patches are accustomed to using Emacs and have elaborate
   customizations for this that they would lose if the review is only
   done via a Web browser (even if that browser is eww).

 . The tools require non-trivial changes in the workflow advertised on
   the Wiki.  E.g., Gerrit requires to work with magic local branches
   and detached heads.  We should carefully evaluate this and decide
   how to make sure this won't trip those of us who are less
   proficient in Git (which, judging by the current traffic on
   emacs-devel, seems like a rule rather than exception) and cause
   corruption of the upstream repository.

There are also other minor issues we need to figure out: licenses, the
underlying infrastructure (e.g., AFIU, Phabricator requires PHP), etc.

Personally, I think arranging the development around this kind of
process will not work without some critical mass of patch reviewers
who are able to endure the current constant high volume of changes,
let alone if we want to increase that volume.  Being an efficient
patch reviewer requires good knowledge of at least a few areas of the
Emacs core, and we currently have only a handful of people who can
qualify.  (The obvious exception from this rule is a maintainer of a
single package who can review patches for his/her package.)  From
experience of other projects, 5 reviewers is not enough for this task.

So we are again back to the hardest problem in Emacs development: the
extremely small number of core maintainers.

> I'd also welcome opinions from people who have experience working with
> them

Seconded.