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. 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/ ) Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel