Re: Patch queue management systems

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/09/2014 07:20 PM, Lars Magne Ingebrigtsen wrote:

>> I can['t] even get a list of "all bugs with patches" from inside of Emacs.
>
> Sure you can.  `C-u / patch' in debbugs-gnu.

Okay, thanks. Any reason why it includes closed bugs in the list? And 
could Debbugs be made to work snappier? 20000 is not much, on a database 
scale.

>> - A working integration server that gives an overview of whether each
>>    patch (or better: Git branch) compiles, passes tests, etc, which will
>>    be a good reminder for a contributor if they broke something, even
>>    before a reviewer is involved.
>
> This can all be done by adding tags to bug reports in debbugs.

...I suppose. Note that integration server build status usually includes 
a status value (passed, failed, or errored before it had a chance to 
fail) and a url to the build info (where we can look at the log).

Do you intend to keep the patch submission workflow the same? I.e. 
free-form (inline or in an attachment with arbitrary name), instead of a 
Git branch somewhere. How would integration server pick up and apply 
such patches?

>> - Inline comments: hide the old ones as the discussion progresses, only
>>    show the ones still pertinent to the current changeset (though this
>>    part may be hard to integrate into Emacs either way). I was kinda
>>    hoping it might would serve as an alternative for debbugs comments.
>
> That sounds nice, but 99% of patches in the bug tracker are small and
> need only a couple passes or less before they can be applied.  So this
> would give us no extra patch handling power in reality.

It increases visibility into the discussion. Even if we're only talking 
two passes, being able to see just the comments that apply to the latest 
proposed version is pretty nice.

Though of course, the smaller patches that don't need discussion would 
benefit more from being able to see that the build passes and instantly 
merge the contribution.