[openstack-dev] [nova] An analysis of code review in Nova

Chris Behrens cbehrens at codestud.com
Sat Mar 22 18:03:34 UTC 2014

I'd like to get spawn broken up sooner rather than later, personally. It has additional benefits of being able to do better orchestration of builds from conductor, etc.

On Mar 14, 2014, at 3:58 PM, Dan Smith <dms at danplanet.com> wrote:

>> Just to answer this point, despite the review latency, please don't be
>> tempted to think one big change will get in quicker than a series of
>> little, easy to review, changes. All changes are not equal. A large
>> change often scares me away to easier to review patches.
>> Seems like, for Juno-1, it would be worth cancelling all non-urgent
>> bug fixes, and doing the refactoring we need.
>> I think the aim here should be better (and easier to understand) unit
>> test coverage. Thats a great way to drive good code structure.
> Review latency will be directly affected by how good the refactoring
> changes are staged. If they are small, on-topic and easy to validate,
> they will go quickly. They should be linearized unless there are some
> places where multiple sequences of changes make sense (i.e. refactoring
> a single file that results in no changes required to others).
> As John says, if it's just a big "change everything" patch, or a ton of
> smaller ones that don't fit a plan or process, then it will be slow and
> painful (for everyone).
>> +1 sounds like a good first step is to move to oslo.vmware
> I'm not sure whether I think that refactoring spawn would be better done
> first or second. My gut tells me that doing spawn first would mean that
> we could more easily validate the oslo refactors because (a) spawn is
> impossible to follow right now and (b) refactoring it to smaller methods
> should be fairly easy. The tests for spawn are equally hard to follow
> and refactoring it first would yield a bunch of more unit-y tests that
> would help us follow the oslo refactoring.
> However, it sounds like the osloificastion has maybe already started and
> that refactoring spawn will have to take a backseat to that.
> --Dan
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list