Joe Gordon wrote:
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> Have anyone interested (especially TC members) come up with a list of
> what they think the project wide Kilo cycle goals should be and post
> them on this thread by end of day Wednesday, September 10th. After which
> time we can begin discussing the results.
> The goal of this exercise is to help us see if our individual world
> views align with the greater community, and to get the ball rolling on a
> larger discussion of where as a project we should be focusing more time.

Thanks again to Joe for starting this important discussion.

My personal list of Kilo goals goes as follows:

#1: Fix our growth pains

We grew a lot, and our recipes were designed for a smaller group where
trust happens more naturally. With our community growing to a Dunbar
order of magnitude above, some of those recipes don't work so great, so
we need to revisit them... That includes the binary "integrated release"
(introduce layers?), cross-project functional testing (push it at
project level?), the "programs" concept, encouraging PTL delegation (the
czar/liaisons proposal ?), scaling core reviewing in larger projects
(Nova driver split ?), etc.

We already started the conversation on those important topics, but Kilo
is the timeframe for us to implement those changes, because I don't see
our community wait for more than one cycle to see the light at the end
of the tunnel.

#2: Fix the end user experience

Monty expressed it better than I can. We need consistent and
better-designed APIs, client SDKs that provide useful primitives and
actually abstract differences in implementations, etc.

#3: Fix what we have: bugfixes, consistency, scaling up, scaling down,

Rather than adding more features for the mid-size private cloud, let's
make sure that what we have works well, provides a consistent experience
across projects, scales up beautifully, can be easily used at smaller
scale as well (simplicity), and allows seamless upgrades. This is
another way of looking at "paying our technical debt" that others have
mentioned as goals -- generally polishing what we have rather than
building out new things.


Thierry Carrez (ttx)

OpenStack-dev mailing list

Reply via email to