On Tue, Aug 5, 2014 at 9:03 AM, Thierry Carrez <thie...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
