Setup non-pushing gerrit instance for glibc.

[Joseph Myers]

On Mon, 28 Oct 2019, Jonathan Nieder wrote:

> >                                        (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)?

My example is from GDB.

https://sourceware.org/ml/gdb-patches/2019-10/msg00942.html was a message 
sent to gerrit, in reply to a comments message.

Now look at that one in gerrit - 
https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/126 - or as it came 
back to the list from gerrit - 
https://sourceware.org/ml/gdb-patches/2019-10/msg00943.html - and note 
that in gerrit's version, the first paragraph "On 2019-10-26 7:10 p.m., 
Tom Tromey (Code Review) wrote:" is followed by the next paragraph *after* 
the quoted text - the quoted text in between has been lost (Simon's 
comment in gerrit two comments later clarifies for gerrit readers, "I 
replied by email, so that's the header my email client added when replying 
to Tom's comment, and Gerrit interpreted it as part of my comment.").

The problem of course isn't that gerrit kept that heading text, it's that 
it lost the quoted text after it.  Removing quoted text at the end of the 
message makes sense, but removing quoted text that's followed by comments 
doesn't.

(The examples in the gerrit documentation of email handling suggest it's 
already *supposed* to handle inline replies interspersed with quoted text, 
not just pure top-posting, but it evidently mishandled this particular 
email.)

> > * Handle email replies to notifications of new patches, not just to
> > comments on them.
> 
> I would expect this to already work as well.

So would I; only handling replies to comments seems an odd limitation.  I 
haven't verified if it does or not; I'm just going on what 
https://sourceware.org/ml/libc-alpha/2019-10/msg00812.html says about "We 
will also have to warn the user that replying directly to a new change 
message will not work; gerrit can only understand email replies to 
comments.".

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

Yes.  Giving snippets in diff format (assuming there actually are changes 
around the code in question rather than someone commenting on unmodified 
code) is a reasonable heuristic to give the relevant information in 90% of 
cases.  (The remaining 10% includes cases that already exist where e.g. 
reordering code in the file means the diff output isn't very helpful 
anyway, and whatever gerrit does then would be no worse than quoting an 
unhelpful diff in a manually sent email.)

-- 
Joseph S. Myers
joseph@codesourcery.com