Open Stack

On Thu, Apr 23, 2015 at 10:14 AM, Chris Dent <chdent at redhat.com> wrote:



> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?



Thank you for your question.

I think the largest hurdle for quality is a lack of a unified vision and
direction for OpenStack. Without coordinated objectives for releases we
have now 19+ projects driving in scattered directions. This effects quality
on all levels. If we have a documented set of common release goals, we can
better coordinate progress and deliver on the largest pain points for
end-users and deployers. This was my hope for the Cross-Project Sessions at
the summits, but it has not been realized. The TC should drive this
coordination.

A growing ecosystem provides choice for deployers, but it also creates more
questions and uncertainty. We need to provide some guidance to deployers as
to what components are considered ready for production use and which pieces
work complimentary together. The integrated release previously served that
goal. We don't have a concrete plan moving forward to provide this
guidance. To improve quality for deployers we need to make choosing which
services to install simpler and the process to deploy and configure those
services simpler. Additionally for horizontal projects rapid ecosystem
growth creates a very difficult situation where either those horizontal
projects attempt to provide that function for all, or leave it wide open
which creates inconsistencies. This effects quality for end-users and
deployers. The TC needs to stop hand-waiving here and concretely address
the implications of this growth.

Improving the experience for developers means driving our ability to
effectively scale the development process. Progress around excising tests
from the coordinated gate begins to improve how well the gate works for
individual projects. The other central component of this is scaling the
review process. Too much frustration faces developers submitting specs and
patches. The TC needs to push targeting less bureaucracy for developers and
more toward allowing developers to contribute.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150424/91b60a81/attachment.html>