[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch queue management systems

From: Dmitry Gutov
Subject: Re: Patch queue management systems
Date: Tue, 09 Dec 2014 15:03:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]