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 packages) 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). Tim 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. dt -- Dean Troyer dtro...@gmail.com<mailto:dtro...@gmail.com>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
