> Also does it place a requirement that all projects wanting to request >incubation to be placed in stackforge ? That sounds like a harsh >requirement if we were to reject them.
I think that anything that encourages projects to get used to the OpenStack development process sooner, rather than later, is a good thing. If becoming incubated does not require the team to have a track record of proper formatting of commit messages, using Gerrit for reviews, use of Launchpad for bugs and blueprints, etc., we are setting ourselves up for a lot of pain. Being lax on incubation will only encourage teams to code in a slapdash, ³under the radar² fashion. IMO, it also makes it harder for the TC to evaluate the team and project, since there are fewer artifacts they can use as data points. Perhaps it was overkill, but the incubation requirements (somewhat self-imposed) for the Marconi team included: 1. Code against stackforge, follow the standard review process for patches via Gerrit and at least 2 x +2s before approving patches, and require OpenStack-standard commit messages. 2. Use Launchpad and the OpenStack wiki for specs and project management (blueprints, blug tracking, milestones). 3. Hold regular team meetings in #openstack-meeting(-alt), following the standard process there (i.g., using meetbot, publishing agenda on wiki and mailing list before each meeting, archiving meeting notes on the wiki) 4. Create a comprehensive unit test suite. 5. Define and enforce a HACKING guide based on standards culled from upstream OpenStack projects. 6. Demonstrate a pattern of consistent contribution (both code and design) from multiple organizations/vendors 7. Solicit code reviews from TC members, address feedback to their Satisfaction. 8. Solicit community feedback on the project¹s features, code, and overall design--both early and often. I guess I view the pre-incubation time period first of all as a ³practice period² for the team to get used to developing things *together*, engendering esprit de corps across company/vendor boundaries, and getting used to the standard OpenStack tools and processes for those team members not used to them already. Second, pre-incubation is a time for getting the implementation up to snuff so that during incubation you can focus on polishing off rough edges and integrating with upstream projects. Incubation is probably not the time to be rewriting massive amounts of code and/or redesigning your API; otherwise you create a moving target for everyone involved. > This is looking at raising the bar quite a bit along the way. +1. I like the idea of an intermediary ³emerging² stage to help crystalize what teams need to do in order to prepare for incubation, and to help smooth the transition from bootstrapped ---> incubated ---> integrated. @kgriffs _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
