Open Stack

> 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