> -----Original Message----- > From: Sylvain Bauza [mailto:sylvain.ba...@bull.net] > Sent: Wednesday, December 18, 2013 5:04 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] Diversity as a requirement for incubation > > Le 18/12/2013 11:40, Thierry Carrez a écrit : > > I guess there are 3 options: > > > > 1. Require diversity for incubation, but find ways to bless or > > recommend projects pre-incubation so that this diversity can actually > > be achieved > > > > 2. Do not require diversity for incubation, but require it for > > graduation, and remove projects from incubation if they fail to > > attract a diverse community > > > > 3. Do not require diversity at incubation time, but at least judge the > > interest of other companies: are they signed up to join in the future ? > > Be ready to drop the project from incubation if that was a fake > > support and the project fails to attract a diverse community > > > > Personally I'm leaning towards (3) at the moment. Thoughts ? > > I would vote for (1). FWIW, incubated projects are robust enough to fail from > a resource perspective. > That definitely goes to what an incubated project is : to me, incubated > projects *will* be integrated, but they currently aren't due to some > *technical* (code compliancy, unittesting, frameworks, integration with > other projects) concerns.
I would go the entirely opposite direction. It is difficult to get community support for unrecognized projects, especially when that support is usually in the form of FTEs from interested companies. Without some assurance that the project will make it into OpenStack, it is significantly more difficult to get companies to assign resources. Coming up with another status doesn't seem to solve that problem unless that status is 'this will be in OpenStack soon, start collaborating' which, to me, is what incubation is designed to do. If the new status requires no investment from OpenStack, then it doesn't signal any strong commitment, making it less clear that other vendors should support the effort. I would say that fixing some technical issues pre-incubation seems fine, but expecting every project to have a diverse (as in multi-vendor) team before the project has achieved any type of status is difficult. Also, any general technical requirements should be documented beforehand. For Barbican, there seems to be a lot of goalpost moving in that people just say what they want and there is very little way for us to know what those requirements will be. Additionally, measuring diversity of a project is also difficult. The current measure being used is commit percentage, which is terrible. If a project bakes for a while with a core set of developers, it will take a long time for new contributors to make a dent in the percentages. It also incentives bad behavior, e.g. wrapping up lots of small commits into one big one, etc. We need more inclusive measures, maybe including intent to deploy, etc. Barbican has been open since its inception. It has never been closed or limited in any way. However, we didn't really start getting interest until we reached our MVP. We have interest now, but even though people have started contributing, it will take a while to chip away at the commit percentages. For me, I would be fine with #2 or #3 (they seem very similar), but I don't think #1 is realistic. Keep in mind that many of the current OpenStack programs & projects were incubated without diverse communities. This doesn't seem to have caused outsized headaches. > If we assess that incubated projects could not part of Openstack one day or > so, that won't help community adoption and/or resources dedication. If something gets kicked out of incubation, it is explicitly because it didn't garner any additional community support. By being in incubation, the project becomes the owner of a particular set of features. If no one joins, it's either because the no one is interested in that feature set, the project's community is not receptive or the project already meets the needs of the user and they don't need to contribute devs. I see this as happening very rarely, but only if we get better measures for diversity. Jarret
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev