Re: FYI: Status of gdb usage of gerrit

["Gabriel F. T. Gomes" <gabriel at inconstante dot net dot br>]

On Wed, 27 Nov 2019, Florian Weimer wrote:

>* Carlos O'Donell:
>>
>> So my suggestion was:
>> * You review via gerrit and push in gerrit
>> or
>> * You review via email and push directly (no Changeset-Id).  

Could we push directly to gerrit's master (if review happened on the mailing
list), or must it always go through refs/for/master and thus trigger a new
review entry on the web interface and email notifications (duplicate, since
the patch must have been discussed on the mailing list already)?

I'm wondering if that would allow gerrit to push to master with
Reviewed-by statements automatically added (Jonathan mentioned [1] that
gerrit wants to own the branches, but maybe it would work if it co-owned
it with the rest of us).

[1] https://sourceware.org/ml/libc-alpha/2019-11/msg00532.html

(PS: This would be Jonathan's option #1, but bypassing review on gerrit)

>I see.
>
>I think this dual setup is too confusing.  People will ack patches on
>one side of the fence that have been vetoed on the other side.

I also believe that this segmentation between people who like to review by
email and people who like to review on gerrit will happen.  Is that only
because we can't *start* the review of a patch on the mailing list if it
has been sent to gerrit?

If someone on the mailing list could reply to the first notification email
and that could become a simple comment (without any fancy file/hunk
detection mechanism) on the web interface, that would help reduce the
segmentation.

The only remaining segmentation would be from people who only check
patches on gerrit's web interface (i.e. people not reading the list),
because they wouldn't see patches sent directly to the mailing list.

I'm aware that many of you think that fixing gerrit's email interface is a
dead-end and I tend to agree, I'm just wondering how much of it really
needs to be fixed for our purposes.