Open Stack

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
>> 
>>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi
>>-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r
>>=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=q5RejnjmrSIFg0K7ua
>>AZbKHVqAKLHnVAB98J%2BszOfhw%3D%0A&s=1629f4e9008260c5f8ea577da1bdc69388dbe
>>fa3646803244df992a31d94bc96
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-
>bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=e
>H0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=q5RejnjmrSIFg0K7uaAZb
>KHVqAKLHnVAB98J%2BszOfhw%3D%0A&s=1629f4e9008260c5f8ea577da1bdc69388dbefa36
>46803244df992a31d94bc96