Open Stack

On 06/02/2014 09:21 AM, Matthew Treinish wrote:
> On Mon, Jun 02, 2014 at 06:57:04AM -0400, Sean Dague wrote:
>> Towards the end of the summit there was a discussion about us using a
>> shared review dashboard to see if a common view by the team would help
>> accelerate people looking at certain things. I spent some time this
>> weekend working on a tool to make building custom dashboard urls much
>> easier.
>>
>> My current proposal is the following, and would like comments on it:
>> https://github.com/sdague/gerrit-dash-creator/blob/master/dashboards/qa-program.dash
> 
> I like this idea, it's definitely a good idea to try and help prioritize certain
> reviews to try and streamline reviewing.
> 
> I'm wondering do you think we'll eventually bring this into infra? I definitely
> get JJB vibes from this too, and I think having a similar workflow for creating
> dashboards would be awesome.

Site level dashboard support is proposed here for jeepyb -
https://review.openstack.org/#/c/94260/

I'd also like project level dashboards that could be approved by the
local core teams. A path to do that well hasn't been sorted yet. Until
then I figure we can work with client dashboards.

>> All items in the dashboard are content that you've not voted on in the
>> current patch revision, that you don't own, and that have passing
>> Jenkins test results.
>>
>> 1. QA Specs - these need more eyes, so we highlight them at top of page
>> 2. Patches that are older than 5 days, with no code review
>> 3. Patches that you are listed as a reviewer on, but haven't voting on
>> current version
>> 4. Patches that already have a +2, so should be landable if you agree.
>> 5. Patches that have no negative code review feedback on them
>> 6. Patches older than 2 days, with no code review
>>
>> These are definitely a judgement call on what people should be looking
>> at, but this seems a pretty reasonable triaging list. I'm happy to have
>> a discussion on changes to this list.
> 
> I think this priority list is good for right now. I try to do this same basic
> prioritization when I'm doing reviews. (although maybe not using exact day counts)
> Although, I'm hoping that eventually reviews on the qa-specs repo will be active
> enough that we won't need to prioritize it over other repos. But, until then I
> think putting it at the top is the right move.
> 
>>
>> The url for this is -  http://goo.gl/g4aMjM
>>
>> (the long url is very long:
>> https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%2Ftempest+OR+project%3Aopenstack-dev%2Fgrenade+OR+project%3Aopenstack%2Fqa-specs%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D-1+label%3AVerified%3E%3D1%2Cjenkins+NOT+label%3ACode-Review%3C%3D-1%2Cself+NOT+label%3ACode-Review%3E%3D1%2Cself&title=QA+Review+Inbox&QA+Specs=project%3Aopenstack%2Fqa-specs&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode-Review%3C%3D2+age%3A5d&Your+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself&Needs+final+%2B2=%28project%3Aopenstack%2Ftempest+OR+project%3Aopenstack-dev%2Fgrenade%29+label%3ACode-Review%3E%3D2+limit%3A50&Passed+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode-Review%3E%3D2+NOT+label%3ACode-Review%3C%3D-1+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode-Review%3C%3D2+age%3A2d
>>
>> The url can be regenerated easily using the gerrit-dash-creator.
>>
> r
> These generated URLs don't quite work as expected for me, I see a bunch of -1s
> from jenkins in all the sections. 

They aren't Jenkins -1, they are other CI systems.
https://review.openstack.org/#/settings/preferences (check - Display
Person Name In Review Category) to see that.

Other things like reviews with -2s showing up
> "in need final +2", 

I tended not to filter out -2s for that to it would be more clear to see
there was a conflict going on. Typically in those situations I vote -1
to say I agree with the -2 that's there, and move on. Then it's been
voted on so drops from your list.

> or reviews with -2s and +2s from me being listed in the "but
> haven't voted in the current revision". 

That's odd, and definitely not intended.

Also the top section just seems to list
> every open QA program review regardless of it's current review state.

The top section does list every qa-spec that is open and you don't have
a vote on. That was intentional. The point being that everyone should
read them and vote on them. Once you do they go away from your list.

Unlike normal reviews I don't think that masking qa-specs once they have
a single negative piece of feedback is the right workflow. Especially as
there are a small enough number.

> I'll take a look at the code and see if I can help figure out what's going on.

Sure, pull requests welcomed. :)

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140602/5ce580c2/attachment.pgp>