Open Stack

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[1][2] and after 
>  > > discussion with Jeremy  brought this to ML to interact with these team 
>  > > before landing [3], 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.
>
> -gmann

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
teams.

Doug