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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev