Re: How to keep Reviewed-by lines in git commits with gerrit.

[Florian Weimer <fw at deneb dot enyo dot de>]

* Carlos O'Donell:

>> We should not edit the commit message manually after it has been
>> reviewed.
>
> I agree. Should we setup gerrit to push to glibc git?

I think it's to early for that.  I'm not sure that Gerrit is the right
tool for us.  Too many of us have yet to use it as patch submitters
and reviewers.

I also think that improving the email interface is a dead end and not
worth the effort.  Unless we are willing to abandon email-based patch
review, we should not switch to Gerrit (or any other web-based tool).

Gerrit doesn't have to be in push mode in order to edited commit
messages.  You can press the DOWNLOAD button, copy the cherry-pick
command line into a shell, and use that to push a commit to master.
I've been doing that a couple of times and it works well.

>> Either it is automatically added by the review tool, or we need to
>> gather patch review statistics from the review tool.
>
> I would prefer it to be automatically added by the review tool, as
> gerrit is designed to do.

Is it?  If we need too many customizations, we'll be stuck with our
own special pet, which I don't want.

>> The latter has the advantage that post-commit review also counts,
>> which is not possible if we only consider Reviewed-By: lines in
>> commits.
>
> Post-commit review is indeed lost in a system that uses commit
> messages to track review, but I'd argue that this is a such a small
> minority of the work that it's not worth accurately modeling in
> the framework.

I'm not sure about that.  In many cases, I've missed Reviewed-By:
lines due to lack of tool support.  But there have been a few where I
simply had not received the review email message when producing the
actual commit.

> The reason I'm strongly in favor of Reviwed-by: in commit messages
> is also that the review data goes with the commit, and clones of the
> repo for analysis by any other 3rd party with normal git tooling.

I would argue this is a fringe use case.  How is this relevant to the
glibc project, anyway?  It's not that we're going to promote
contributors due to new roles based on the number of reviews they
conducted.