Open Stack

On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez <thierry at openstack.org> wrote:
> We seem to be unable to address some key issues in the software we
> produce, and part of it is due to strategic contributors (and core
> reviewers) being overwhelmed just trying to stay afloat of what's
> happening. For such projects, is it time for a pause ? Is it time to
> define key cycle goals and defer everything else ?

I think it's quite reasonable for a project to set aside some time to
focus on stability, whether that is a whole release cycle or just a
milestone. However, I think your question here is more about
OpenStack-wide issues, and how we enco^D^D^D^D whether we can require
integrated projects that are seen as having gate-affecting instability
to pause and address that.

> On the integrated release side, "more projects" means stretching our
> limited strategic resources more. Is it time for the Technical Committee
> to more aggressively define what is "in" and what is "out" ? If we go
> through such a redefinition, shall we push currently-integrated projects
> that fail to match that definition out of the "integrated release" inner
> circle ?

"The integrated release" is an overloaded term at the moment. Outside
of the developer community, I see it often cited as a blessing of a
project's legitimacy and production-worthiness. While I feel that a
non-production-ready project should not be "in the integrated
release", this has not been upheld as a litmus test for integration in
the past. Also, this does not imply that non-integrated projects
should not be used in production. I've lost track of how many times
I've heard someone say, "Why would I deploy Ironic when it hasn't
graduated yet."

Integration is foremost an artifact of our testing and development
processes -- an indication that a project has been following the
release cadence, adheres to cross-project norms, is ready for
cogating, and can be counted on to produce timely and stable builds at
release time. This can plainly be seen by looking at the criteria for
incubation and integration in our governance repo [1]. As written
today, this does not have anything to do with the technical merit or
production-worthiness of a project. It also does not have anything to
do with what "layer" the project sits at -- whether it is IaaS, PaaS,
or SaaS does not dictate whether it can be integrated.

The TC has begun to scrutinize new projects more carefully on
technical grounds, particularly since some recently-integrated
projects have run into scaling limitations that have hampered their
adoption. I believe this sort of technical guidance (or curation, if
you will) is an essential function of the TC. We've learned that
integration bestows legitimacy, as well as assumptions of stability,
performance, and scalability, upon projects which are integrated.
While that wasn't the intent, I think we need to accept that that is
where we stand. We will be faced with some hard decisions regarding
projects, both incubated and already integrated, which are clearly not
meeting those expectations today.

-Devananda


[1] http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rst