Open Stack

> 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