Review-Priority for Project Repos
doug at doughellmann.com
Thu Jan 10 13:32:59 UTC 2019
Ghanshyam Mann <gmann at ghanshyammann.com> writes:
> ---- On Thu, 03 Jan 2019 22:51:55 +0900 Sean McGinnis <sean.mcginnis at gmx.com> wrote ----
> > On Fri, Dec 28, 2018 at 11:04:41AM +0530, Surya Singh wrote:
> > > Dear All,
> > >
> > > There are many occasion when we want to priorities some of the patches
> > > whether it is related to unblock the gates or blocking the non freeze
> > > patches during RC.
> > >
> > > So adding the Review-Priority will allow more precise dashboard. As
> > > Designate and Cinder projects already experiencing this and after
> > > discussion with Jeremy brought this to ML to interact with these team
> > > before landing , as there is possibility that reapply the priority vote
> > > following any substantive updates to change could make it more cumbersome
> > > than it is worth.
> > With Cinder this is fairly new, but I think it is working well so far. The
> > oddity we've run into, that I think you're referring to here, is how those
> > votes carry forward with updates.
> > I set up Cinder with -1, +1, and +2 as possible priority votes. It appears when
> This idea looks great and helpful especially for blockers and cycle priority patches to get regular
> review bandwidth from Core or Active members of that project.
> IMO only +ve votes are more appropriate for this label. -1 is little confusing for many reasons like
> what is the difference between Review-Priority -1 and Code-Review -2 ? Review-Priority -1 means,
> it is less priority than 0/not labelled (explicitly setting any patch very less priority).
> After seeing Cinder dashboard, I got to know that -1 is used to block the changes due to procedural
> or technical reason. But that can be done by -2 on Code-Review label. Keeping Review-Priority label
> only for priority set makes it more clear which is nothing but allowing only +ve votes for this label.
> Personally, I prefer only a single vote set which can be +1 to convey that these are the set of changes
> priority for review but having multiple +ve vote set as per project need/interest is all fine.
Given the complexity of our review process already, if this new aspect
is going to spread it would be really nice if we could try to agree on a
standard way to apply it. Not only would that let someone build a
dashboard for cross-project priorities, but it would mean contributors
wouldn't need to learn different rules for interacting with each of our
More information about the openstack-discuss