Open Stack

On Thu, Jan 3, 2019, at 4:26 PM, Jay Bryant wrote:
> 
> <snip>

snip

> > So far, that's just a slight inconvenience. It would be great if we can figure
> > out a way to have them all be sticky, but if we need to live with reapplying +1
> > votes, that's manageable to me.
> 
> </snip>
> 
>   Is there someway that we could allow the owner to reset this priority 
> after pushing up a new patch.  That would lower the dependence on the 
> cores in that case.

If you use a three value label: [-1: +1] then you could set copy min and max scores so all values are carried forward on new patchsets. This would allow you to have -1 "Don't review", 0 "default no special priority", and +1 "this is a priority please review now". This may have to take advantage of the fact that if you don't set a value its roughly the same as 0 (I don't know if this is explicitly true in Gerrit but we can approximate it since -1 and +1 would be explicitly set and query on those values).

If you need an explicit copy all values function in Gerrit you'll want to get that merged upstream first then we could potentially backport it to our Gerrit. This will likely require writing Java.

For some reason I thought that Prolog predicates could be written for these value copying functions, but docs seem to say otherwise. Prolog is only for determining if a label's value allows a change to be submitted (merged).

Clark