On 08/21/2014 07:58 AM, Chris Dent wrote:
On Thu, 21 Aug 2014, Sean Dague wrote:
By blessing one team what we're saying is all the good ideas pool for
tackling this hard problem can only come from that one team.
This is a big part of this conversation that really confuses me. Who is
that "one team"?
I don't think it is that team that is being blessed, it is that
project space. That project space ought, if possible, have a team
made up of anyone who is interested. Within that umbrella both
the competition and cooperation that everyone wants can happen.
You're quite right Sean, there is a lot of gravity that comes from
needing to support and slowly migrate the existing APIs. That takes
up quite a lot of resources. It doesn't mean, however, that other
resources can't work on substantial improvements in cooperation with
the rest of the project. Gnocchi and the entire "V3" concept in
ceilometer are a good example of this. Some folk are working on that
and some folk are working on maintaining and improving the old
stuff.
Some participants in this thread seem to be saying "give some else a
chance". Surely nobody needs to be given the chance, they just need
to join the project and make some contributions? That is how this is
supposed to work isn't it?
Specifically for Ceilometer, many of the folks working on alternate
implementations have contributed or are actively contributing to
Ceilometer. Some have stopped contributing because of fundamental
disagreements about the appropriateness of the Ceilometer architecture.
Others have begun working on Gnocchi to address design issues, and
others have joined efforts on Monasca, and others have continued work on
Stacktach. Eoghan has done an admirable job of informing the TC about
goings on in the Ceilometer community and being forthright about the
efforts around Gnocchi. And there isn't any perceived animosity between
the aforementioned contributor subteams. The point I've been making is
that by the TC continuing to bless only the Ceilometer project as the
OpenStack Way of Metering, I think we do a disservice to our users by
picking a winner in a space that is clearly still unsettled.
Specifically for Triple-O, by making the Deployment program == Triple-O,
the TC has picked the disk-image-based deployment of an undercloud
design as The OpenStack Way of Deployment. And as I've said previously
in this thread, I believe that the deployment space is similarly
unsettled, and that it would be more appropriate to let the Chef
cookbooks and Puppet modules currently sitting in the stackforge/ code
namespace live in the openstack/ code namespace.
I recommended getting rid of the formal Program concept because I didn't
think it was serving any purpose other than solidifying existing power
centers and was inhibiting innovation by sending the signal of "blessed
teams/projects", instead of sending a signal of inclusion.
Best,
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
