If I take a recent case we had, we’re looking for ways to simplify backup for 
our users. They should not have to write crons to do snapshots but leave that 
to a service.

Raksha seems promising… a wiki page on openstack.org, code in github etc.

How can the average deployer know whether a stackforge is

a.      An early prototype which has completed (such as some of the early LBaaS 

b.      A project which has lost its initial steam and further investment is 
not foreseen

c.      A reliable project where there has not been a significant need to 
change recently but is a good long term bet

The end result is that deployers hold back waiting for an indication that this 
is more than a prototype in whatever form that would take. This means a missed 
opportunity as if something is interesting to many deployers, that could create 
the community needed to keep a project going.

The statement of “this is good and mature, even if it's not in the inner 
circle" is exactly what is needed. When I offer something to my end-users, 
there is an implied promise of this (and a corresponding credibility issue if 
that is not met).


From: Dean Troyer [mailto:dtro...@gmail.com]
Sent: 05 September 2014 19:11
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the 
TC meeting

On Fri, Sep 5, 2014 at 4:27 AM, Thierry Carrez 
<thie...@openstack.org<mailto:thie...@openstack.org>> wrote:
Tim Bell wrote:
> The one concern I have with a small core is that there is not an easy way to 
> assess the maturity of a project on stackforge. The stackforge projects may 
> be missing packaging, Red Hat testing, puppet modules, install/admin 
> documentation etc. Thus, I need to have some indication that a project is 
> deployable before looking at it with my user community to see if it meets a 
> need that is sustainable.
> Do you see the "optional layer" services being blessed / validated in some 
> way and therefore being easy to identify ?
Yes, I think whatever exact shape this takes, it should convey some
assertion of stability to be able to distinguish itself from random
projects. Some way of saying "this is good and mature, even if it's not
in the inner circle".

Being in The "integrated release" has been seen as a sign of stability
forever, while it was only ensuring "integration" with other projects
and OpenStack processes. We are getting better at requiring "maturity"
there, but if we set up layers, we'll have to get even better at that.

The layers are (or originally were) a purely technical organization, 
intentionally avoiding association with defcore and other groupings, and on 
reflection, maturity too.  The problem that repeatedly bubbles up is that 
"people" (mostly outside the community) want a simple tag for maturity or 
blessedness and have been using the integrated/incubated status for that.  
Maturity has nothing to do with technical relationships between projects 
(required/optional layers).

The "good and mature" blessing should be an independent attribute that is set 
on projects as a result of nomination by TC members or PTLs or existing core 
members or whatever trusted group we choose.  I'd say for starters that 
anything from Stackforge that we use in integrated/incubated projects is on the 
short list for that status, as it already has that implicitly by our use.



Dean Troyer
OpenStack-dev mailing list

Reply via email to