<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 8:37 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>As you all know, there has recently been several very active discussions</div><div>around how to improve assorted aspects of our development process. One idea</div><div>that was brought up is to come up with a list of cycle goals/project</div>
<div>priorities for Kilo [0].</div><div><br></div><div>To that end, I would like to propose an exercise as discussed in the TC meeting yesterday [1]:</div><div>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.</div>
<div>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.</div></div></blockquote><div><br></div><div><br></div><div><br></div><div>1. Strengthen our north bound APIs </div><div><br></div><div>* API micro-versioning</div><div>* Improved CLI's and SDKs</div><div>* Better capability discovery  </div><div>* Hide usability issues with client side logic</div><div>* Improve reliability</div><div><br></div><div>As others have said in this thread trying to use OpenStack as a user is a very frustrating experience. For a long time now we have focused on southbound APIs such as drivers, configuration options, supported architectures etc. But as a project we have not spent nearly enough time on the end user experience. If our northbound APIs aren't something developers want to use, our southbound API work doesn't matter. </div><div><br></div><div>2. 'Fix' our development process</div><div><br></div><div>* openstack-specs. Currently we don't have any good way to work on big entire-project efforts, hopefully something like a openstack-specs repo (with liasons from each core-team reviewing it) will help make it possible for us to tackle these issues.  I see us addressing the API micro-versioning and capability  discovery issues here. </div><div>* functional testing and post merge testing. As discussed elsewhere in this thread our current testing model isn't meeting our current requirements.</div><div><br></div><div>3. Pay down technical debt</div><div><br></div><div>This is the one I am actually least sure about, as I can really only speak for nova on this one. In our constant push forward we have accumulated a lot of technical debt. The debt manifests itself as hard to maintain code, bugs (nova had over 1000 open bugs until yesterday), performance/scaling issues and missing basic features. I think its time for us to take inventory if our technical debt and fix some of the biggest issues.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div><br></div><div>best,</div><div>Joe Gordon</div><div><br></div><div>[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html</a></div>
<div>[1] <a href="http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html</a></div></div>
</blockquote></div><br></div></div>