This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Setup non-pushing gerrit instance for glibc.
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