Re: Setup non-pushing gerrit instance for glibc.

[Joseph Myers <joseph@codesourcery.com>]

On Sun, 27 Oct 2019, Sergio Durigan Junior wrote:

> When the GDB community decided to give gerrit a try, the main problem it
> was looking to solve was the "patches go missing" issue.

We have that problem in glibc, but we also have the problem of how to make 
review as efficient for the reviewer as possible - enabling reviewing 100 
patches a day, as Carlos said at the glibc BoF.

If reviewing a patch, or understanding the context for comments, requires 
opening a browser tab and cutting and pasting a URL in there and clicking 
around to find things on that page, that *reduces* my efficiency and 
breaks up the flow of going through patches, bug reports and comments (on 
various projects) that have come in over the time interval since I last 
went through them, compared to simply having all the needed information in 
an email in at least 90% of cases.  Maybe there are 10% of cases where a 
patch needs to break the flow anyway (e.g. if I suspect some issue but 
need to do a build with the patch applied to test for it before replying).  
But there are 90% of common cases that it should be possible to handle 
properly by email if a few issues are fixed:

* Properly support emails with inline replies and the metadata at the 
bottom of the email not quoted (only the relevant content replied to being 
quoted).  This means (a) attaching them to the right issue, based on 
message-ids found in email headers and (b) not losing the quoted text 
being replied to which is important to understanding the replies.

* Handle email replies to notifications of new patches, not just to 
comments on them.

* Include diff hunks in emails with comments on changed code (we now have 
more context in the code quoted, which is an improvement, but seeing the 
actual *changes* being commented on, rather than just one version of the 
code, is important to provide sufficient information in many cases).


Most of the time, an initial response to a bug report in Bugzilla does not 
require opening a browser (the main pain point is dealing with attached 
testcases, since Bugzilla doesn't attach those to emails).  Reviewing and 
cleaning up state for all open bugs in a particular area, via the web 
interface, is a more occasional activity.  The first two points above are 
things that work just fine with email replies in Bugzilla (replying inline 
to any Bugzilla message works fine without any special rules about what to 
quote where); the third point isn't applicable there.

-- 
Joseph S. Myers
joseph@codesourcery.com