Open Stack

Going back to the original discussion, something I've noticed recently is 
the large patches coming through tied to blueprints.  In at least a few 
cases I've made comments in patches asking them to be broken up to be more 
easily digested.  The wiki also covers that area:

https://wiki.openstack.org/wiki/GitCommitMessages#Things_to_avoid_when_creating_commits 


Discussing this point in IRC today, I raised one of my primary issues with 
reviewing large patches (typically for a blueprint) is how much harder it 
makes to verify the code is adequately covered with unit tests.

One thought is it'd be cool if we could get code coverage reports tied to 
the patches so we know if a given patch is severely lacking in test 
coverage (when it's not obvious).

This was pointed out:

http://logs.openstack.org/5c/5cc63c91d045f7a37136107053f71db1d8edf425/post/nova-coverage/e91683d/cover/ 


Which is nice and it gives the commit, but when I asked around in 
#openstack-infra about it, apparently that's only in post-queue on merged 
commits, so doesn't help you with a review.  The infra guys said they'd 
toyed with doing coverage reports in the check queue but it took too long 
(instrumenting the code for coverage added too much time to the check).

However, with the recent push for running parallel tests with testr, it 
sounds like it might be worth looking at check queue coverage reports 
again which might be a good tool in improving review efficiency.  This is 
probably something to pursue again after h3.



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development

Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mriedem at us.ibm.com


3605 Hwy 52 N
Rochester, MN 55901-1407
United States




From:   Russell Bryant <rbryant at redhat.com>
To:     openstack-dev at lists.openstack.org, 
Date:   08/27/2013 01:19 PM
Subject:        Re: [openstack-dev] [Nova] Frustrations with review wait 
times



On 08/27/2013 01:30 PM, Matt Dietz wrote:
> Good idea!
> 
> Only thing I would point out is there are a fair amount of changes,
> especially lately, where code is just moving from one portion of the
> project to another, so there may be cases where someone ends up being
> authoritative over code they don't totally understand. 

Right.  While some automation can provide some insight, it certainly can
not make any decisions in this area, IMO.

-- 
Russell Bryant

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130827/7331117f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1851 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130827/7331117f/attachment.gif>