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.
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel