Open Stack

On 11/08/2012 06:57 AM, Mark McLoughlin wrote:
> Hey
>
> I think too much of this discussion has been about the fairly arbitrary
> names we have for different classes of projects. The term "Core" isn't
> actually all that useful to us in the discussion, or more generally,
> because everyone has their own idea of what the term means.
>
> There are two important things being discussed here - our vision for the
> coordinated OpenStack releases and the rules around the use of the
> OpenStack trademark.

I think there is actually a 3rd thing as well, who gets first class 
infrastructure support. The infrastructure team provides a huge service 
to "core" projects today, the ability to layer in really complex gates 
and periodic jobs.

That's a finite resource in terms of people and cpu cycles, and 
something we shouldn't take for granted (especially as non of those 
folks are currently openstack.org employees IIRC, and the cpu cycles are 
donated today, not purchased by openstack.org).

> They are different things - a project being included in the coordinated
> release does not mean it has to be deployed in order for a provider to
> use the trademark.
>
> For the sake of focusing the discussion, we should ignore the trademark
> question for now and focus on our vision for the coordinated release.
>
> I see our coordinated release as being a cloud provider's toolbox of
> great projects that are designed to work well together built by a
> community with a unified mission.
>
> To be included in the coordinated release, a project needs to meet set
> of criteria which we should clearly define[1].
>
> If a project looks promising, it is accepted into Incubation for a full
> release cycle so that is fully prepared to be included in the next
> coordinated release. Projects must go through at least one release cycle
> as an Incubated Project, but multiple cycles may be required if it turns
> out it needs more time to be fully ready for inclusion.
 >
> Cheers,
> Mark.
>
> [1] - Example of what our criteria for inclusion in the coordinated
> release might look like:
>
>    - Development process - follows the standard OpenStack development
>      process; everything from git, gerrit, launchpad, team meetings,
>      wiki, blueprints, milestone releases, etc.
>
>    - Community - has a solid community of folks contributing to the
>      project, a community that looks like it has longevity
>
>    - Openness - the project's community not only follows our development
>      process, but is truly committed to open development and welcoming
>      new leaders into its community
>
>    - Fit - the software needs to "fit" with the rest of OpenStack. I
>      don't think we should be overly prescriptive about this (e.g.
>      "projects absolutely must be written in Python") but deviations
>      from Openstack norms (like use of Python) would need to be
>      justified and considered carefully.
>
>    - Integration - as well as being a good fit for OpenStack, new
>      project's should also integrate well with existing projects where
>      that makes sense.
>
>    - Scope - new projects, almost by definition, will expand the scope
>      of the OpenStack release but we should be growing the scope in
>      careful, measured ways. Maybe someday OpenStack might have a e.g.
>      CDN project, but we should only consider including such a thing
>      where it is a sensible, incremental expansion of OpenStack's scope.
>      In the case of the CDN example, that might be where OpenStack
>      already does PaaS really well and a CDN to support applications
>      deployed on our PaaS solution is an obvious need for providers
>      already using our PaaS solutions. Clearly, that's a long, long way
>      off if it ever happens at all.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com