[openstack-dev] [nova] An analysis of code review in Nova
gkotton at vmware.com
Mon Mar 24 08:57:27 UTC 2014
Regarding the spawn there are a number of patches up for review at the
moment - they are all mutually exclusive and hopefully will make the
process a lot smoother.
In addition to this we have a patch up for review with the OSLO
integration - https://review.openstack.org/#/c/70175/ (ideally it would be
best that this gets in first)
On 3/22/14 8:03 PM, "Chris Behrens" <cbehrens at codestud.com> wrote:
>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.
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev