Re: Setup non-pushing gerrit instance for glibc.

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Joseph Myers wrote:

> 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
[...]
> But there are 90% of common cases that it should be possible to handle
> properly by email if a few issues are fixed:

Thanks for writing this up.  I agree with this goal.

For that 10% that you can't handle by email, let me also recommend
https://opendev.org/ttygroup/gertty.

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

This is https://crbug.com/gerrit/8904.

>                                        (b) not losing the quoted text
> being replied to which is important to understanding the replies.

Can you say more about this (e.g. do you have an example)?

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

I would expect this to already work as well.

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

This is related to https://crbug.com/gerrit/11804, but it's not quite
the same.  It sounds like you'd like the snippets to be in unified
diff format (which makes sense to me).

> Most of the time, an initial response to a bug report in Bugzilla does not
> require opening a browser
[etc]

Thanks for this context as well.  It makes the workflow a bit more
concrete.

Sincerely,
Jonathan