Re: Patch queue management systems

[Dmitry Gutov]

On 12/06/2014 12:08 PM, Eli Zaretskii wrote:

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

Looking at magit-gerrit, it's not that big. If you're okay with that 
level of integration, it shouldn't take too much work, as long as the 
review system comes with a command-line tool or an API (which, of 
course, will be a requirement).

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

Right, I'll have to investigate that. Licenses shouldn't be a problem (I 
only looked for Free Software packages), and as for infrastructure, 
someone should point out any particular problems that can turn out to be 
insurmountable. I can't think of any.

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

Right, but that's only if/when we decide to push all contributions 
though this system. We could start light, and continue allowing 
committing directly to the repository, but move the 
patches-to-be-discussed (which will take up reviewers' time anyway) to 
the new system.

On the other hand, if we want to use this to guarantee quality of commit 
messages, a review process in some form will be required anyway, but 
since a lot of focus would be on the form rather than substance, not 
every reviewer would have to be intimately familiar with the area of the 
code they're reviewing.