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

Shawn Hartsock hartsock at acm.org
Mon Mar 24 18:24:07 UTC 2014

I fully support https://review.openstack.org/#/c/70175/ but I fail to
see why the spawn-refactor should depend on that. There are only 13
lines touched that are related. These two tasks could be completed
more or less in parallel.

On Mon, Mar 24, 2014 at 4:57 AM, Gary Kotton <gkotton at vmware.com> wrote:
> 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.
> https://review.openstack.org/#/q/topic:bp/vmware-spawn-refactor,n,z
> 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)
> Thanks
> Gary
> 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.
>>> --Dan
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

# Shawn.Hartsock - twitter: @hartsock - plus.google.com/+ShawnHartsock

More information about the OpenStack-dev mailing list