Clark Boylan <cboylan@sapwetik.org> writes:
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).
It is possible to tell the difference between not having a value set and having the default set, but as you point out if the dashboards are simply configured to look for +1 and -1 then the other distinction isn't important.
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.
We could also have a bot do it. The history of each patch is available, so it's possible to determine that a priority was set but lost when a new patch is submitted. The first step to having a bot would be to write the logic to fix the lost priorities, and if someone does that as a CLI then teams could use that by hand until someone configures the bot.
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
-- Doug