Deleting unnecessary code, introducing a stabilization cycle and/or making definite steps towards a unified SDK are definitely my votes.
*Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Tue, Sep 9, 2014 at 5:09 PM, Joe Gordon <joe.gord...@gmail.com> wrote: > > > On Wed, Sep 3, 2014 at 8:37 AM, Joe Gordon <joe.gord...@gmail.com> wrote: > >> As you all know, there has recently been several very active discussions >> around how to improve assorted aspects of our development process. One >> idea >> that was brought up is to come up with a list of cycle goals/project >> priorities for Kilo [0]. >> >> 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. >> > > > > 1. Strengthen our north bound APIs > > * API micro-versioning > * Improved CLI's and SDKs > * Better capability discovery > * Hide usability issues with client side logic > * Improve reliability > > 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. > > 2. 'Fix' our development process > > * 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. > * functional testing and post merge testing. As discussed elsewhere in > this thread our current testing model isn't meeting our current > requirements. > > 3. Pay down technical debt > > 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. > > >> >> best, >> Joe Gordon >> >> [0] >> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html >> [1] >> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
