openstack-poc team mailing list archive
Mailing list archive
Re: 3rd Party APIs
Joshua McKenty wrote:
> I'm a fan of c), where the "officialness" is tied to a committed
> organization or team that is keeping the code up-to-date and tested. I'd
> also be a fan of making that a per-release designation, with an easy
> renewal if the commitment is still in place.
> Generally, a smaller core with a "supported" status for satellite
> projects is my favorite model, for much of OpenStack development.
I don't have very strong feelings on that subject. My gut feeling would
be to support (c), but I could be convinced by a strong argument why we
If that's the decision we end up taking, the PPB discussion quickly
shifts to defining the taxonomy of OpenStack projects. On this subject
and others that were raised at the Design Summit (like plug-ins),
Core/Incubated/Other doesn't really cut it anymore. In particular I'd
like to have at least one category for projects that are essential to
the OpenStack development community but should not be part of the
OpenStack core "product" (the IaaS stack of projects with a coordinated
release every 6 months).
Openstack-common, openstack-ci, or things we gate the core product on
(devstack, tempest) should never be part of OpenStack Core (or ever be
incubated to become core). However they are necessary for us to produce
OpenStack core, and require our collective attention and support. So
they need to be blessed in some kind of "official" category meaning they
are an central part of "OpenStack" as a development community. Maybe
"OpenStack Companion project"...
Another category could be necessary to describe external
projects/plug-ins that are continuously tested with OpenStack Core as
part of our integration testing and for which we therefore have a pretty
good idea of how well they work with OpenStack. Choosing the right term
is a bit more tricky here since most names are a bit overloaded. Maybe
"OpenStack recommended project/plugin"...
Thierry Carrez (ttx)
Release Manager, OpenStack