[openstack-dev] [all] The future of the integrated release

Thierry Carrez thierry at openstack.org
Mon Aug 11 09:24:29 UTC 2014


Eoghan Glynn wrote:
>> 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.
> 
> How does this relate to the recent gap analysis undertaken by the
> TC for already integrated projects, in order to measure their status
> against the steadily rising bar for integration?

It is almost orthogonal. During the Icehouse cycle the TC created clear
requirements for projects wishing to incubate or graduate for
incubation. But it was unclear how well the *currently-incubated*
projects fulfilled those requirements. Since it was a bit unfair to hold
new entrants to different standards, during the Juno cycle we completed
a gap analysis of currently-integrated projects, created gap coverage
plans to address any identified gap, and reviewed progress on those
after each milestone.

So the idea that being (and remaining) in the integrated release should
also be judged on technical merit is a slightly different effort. It's
always been a factor in our choices, but like Devananda says, it's more
difficult than just checking a number of QA/integration checkboxes. In
some cases, blessing one project in a problem space stifles competition,
innovation and alternate approaches. In some other cases, we reinvent
domain-specific solutions rather than standing on the shoulders of
domain-specific giants in neighboring open source projects.

This all has created a world where you need to be *in* OpenStack to
matter, or to justify the investment. This has created a world where
everything and everyone wants to be in the "OpenStack" integrated
release. This has created more pressure to add new projects, and less
pressure to fix and make the existing projects perfect. 4 years in, we
might want to inflect that trajectory and take steps to fix this world.

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list