Open Stack

On 3 Jan 2019, at 5:51, Sean McGinnis 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
> a patchset is updates, the -1 and +2 carry forward. But for some reason we
> can't get the +1 to be sticky.
>
> 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.
>
> The one thing I have been slightly concerned with is the process around using
> these priority votes. It hasn't been an issue, but I could see a scenario where
> one core (in Cinder we have it set up so all cores can use the priority voting)
> has set something like a procedural -1, then been pulled away or is absent for
> an extended period. Like a Workflow -2, another core cannot override that vote.
> So until that person is back to remove the -1, that patch would not be able to
> be merged.
>
> Granted, we've lived with this with Workflow -2's for years and it's never been
> a major issue, but I think as far as centralizing control, it may make sense to
> have a separate smaller group (just the PTL, or PTL and a few "deputies") that
> are able to set priorities on patches just to make sure the folks setting it
> are the ones that are actively tracking what the priorities are for the
> project.
>
> Anyway, my 2 cents. I can imagine this would work really well for some teams,
> less well for others. So if you think it can help you manage your project
> priorities, I would recommend giving it a shot and seeing how it goes. You can
> always drop it if it ends up not being effective or causing issues.
>
> Sean


This looks pretty interesting. I have a few question about how it's practically working out.


I get the impression that the values of the votes are configurable? So you've chosen -1, +1, and +2, but you could have chosen 1, 2, 3, 4, 5 (for example)?


Do you have an example of a dashboard that's using these values?


IMO, gerrit's display of votes is rather bad. I'd prefer that votes like this could be aggregated. How do you manage discovering what patches are priority or not? I guess that's where the dashboards come in?


I get the impression that particular priority votes have the ability to block a merge. How does that work?


half-plug/half-context, I've attempted to solve priority discovery in the Swift community with some customer dashboards. We've got a review dashboard in gerrit [1] that shows "starred by the ptl". I've also created a tool that finds all the starred patches by all contributors, weights each contributor by how much they've contributed recently, and then sorts the resulting totals as a list of "stuff the community thinks is important"[2]. As a community, we also manage our own wiki page for prioritization[3]. I'd love to see if some functionality in gerrit, eg these priority review votes, could supplant some of our other tools.



[1] http://not.mn/reviews.html
[2] http://d.not.mn/swift_community_dashboard.html
[3] https://wiki.openstack.org/wiki/Swift/PriorityReviews



--John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 850 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190103/36768e21/attachment.sig>