[Engine-devel] Copy reviewer scores on trivial rebase/commit msg changes

Itamar Heim iheim at redhat.com
Sun Jan 19 08:20:33 UTC 2014


On 01/19/2014 02:48 AM, Dan Kenigsberg wrote:
> On Sat, Jan 18, 2014 at 01:48:52AM +0200, Itamar Heim wrote:
>> I'd like to enable these - comments welcome:
>>
>> 1. label.Label-Name.copyAllScoresOnTrivialRebase
>>
>> If true, all scores for the label are copied forward when a new
>> patch set is uploaded that is a trivial rebase. A new patch set is
>> considered as trivial rebase if the commit message is the same as in
>> the previous patch set and if it has the same code delta as the
>> previous patch set. This is the case if the change was rebased onto
>> a different parent. This can be used to enable sticky approvals,
>> reducing turn-around for trivial rebases prior to submitting a
>> change. Defaults to false.
>>
>>
>> 2. label.Label-Name.copyAllScoresIfNoCodeChange
>>
>> If true, all scores for the label are copied forward when a new
>> patch set is uploaded that has the same parent commit as the
>> previous patch set and the same code delta as the previous patch
>> set. This means only the commit message is different. This can be
>> used to enable sticky approvals on labels that only depend on the
>> code, reducing turn-around if only the commit message is changed
>> prior to submitting a change. Defaults to false.
>>
>>
>> https://gerrit-review.googlesource.com/Documentation/config-labels.html
>
> I think that the time saved by these copying is worth the dangers.
>
> But is there a way to tell a human ack from an ack auto-copied by these
> options? It's not so fair to blame X for "X approved this patch" when he
> only approved a very similar version thereof.
>

we'll find out when we enable it.

> Assuming that a clean rebase can do no wrong is sometimes wrong
> (a recent example is detailed by Nir's http://gerrit.ovirt.org/21649/ )

of course it can do wrong, but that's the exception usually.




More information about the Devel mailing list