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" <cbehr...@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 <d...@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@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@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev