Re: Patch queue management systems

[Eli Zaretskii]

> Date: Tue, 09 Dec 2014 15:03:00 +0200
> From: Dmitry Gutov <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> 
> 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).

Magit is not part of Emacs.  I think we would like this to be
integrated into VC.

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

I'm not sure such a split process makes sense.  It will complicate
procedures and most probably cause some patches fall through the
cracks.

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

I think comments about the form are usually the easiest part of the
review, and some of that can be automated.  Also, some form-related
issues are actually derived from familiarity with Emacs design and
implementation.  So yes, we could have "junior reviewers" who'd only
deal with form issues, but that would off-load only a minor portion of
the work required to do this.