Review-Priority for Project Repos

Doug Hellmann doug at
Fri Jan 4 14:41:28 UTC 2019

Clark Boylan <cboylan at> 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

> 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


More information about the openstack-discuss mailing list