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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
