Open Stack

>From the etherpad [1]

* We got a lot of value out of the ovo-ectomy and de-list. We're now
   at a stage where there is plenty more that could be done, but the
   choices are more subject to personal preference.

     * How (and should) we further split and shrink objects/resource_provider.py


We got a lot of value out of the big refactoring the removed OVO and
split objects/resource_provider.py into smaller files. It's also a
stated goal that we should continue refactoring and continuously
revisit existing code.

However, we started to stumble because we had some disagreements on
how to proceed. We should resolve those disagreements so we can
proceed (he said, obviously).

Questions that have come up (plus other ones I can think off the top
of my head):

* Is it worth reordering methods to some kind of arbitrary ordering?

* If a method or module is "long" (by some definition) does that
   make it bad?

* Where is the balance between backport hurting churn and keeping
   the mix fresh?

* Should there be a more cleanly defined boundary between the
   methods that marshal data (the top-level methods in objects/*.py)
   and those that talk to the persistence layer (also in
   objects/*.py)?

     * Do we need to define (better) or document the layers/boundaries
       in the system?

* How can we encourage a similar refactor/revisit-often attitude to
   the docs?

There are plenty of other refactoring related thoughts too. Have at.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent