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: mrie...@us.ibm.com 3605 Hwy 52 N Rochester, MN 55901-1407 United States From: Russell Bryant <rbry...@redhat.com> To: openstack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<<image/gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev