On 08/20/2014 11:41 AM, Zane Bitter wrote:
On 19/08/14 10:37, Jay Pipes wrote:

By graduating an incubated project into the integrated release, the
Technical Committee is blessing the project as "the OpenStack way" to do
some thing. If there are projects that are developed *in the OpenStack
ecosystem* that are actively being developed to serve the purpose that
an integrated project serves, then I think it is the responsibility of
the Technical Committee to take another look at the integrated project
and answer the following questions definitively:

  a) Is the Thing that the project addresses something that the
Technical Committee believes the OpenStack ecosystem benefits from by
the TC making a judgement on what is "the "OpenStack way" of addressing
that Thing.

and IFF the decision of the TC on a) is YES, then:

  b) Is the Vision and Implementation of the currently integrated
project the one that the Technical Committee wishes to continue to
"bless" as the "the OpenStack way" of addressing the Thing the project

I disagree with part (b); projects are not code - projects, like Soylent
Green, are people.

Hey! Don't steal my slide content! :P

http://bit.ly/navigating-openstack-community (slide 3)

> So it's not critical that the implementation is the
one the TC wants to bless, what's critical is that the right people are
involved to get to an implementation that the TC would be comfortable
blessing over time. For example, everyone agrees that Ceilometer has
room for improvement, but any implication that the Ceilometer is not
interested in or driving towards those improvements (because of NIH or
whatever) is, as has been pointed out, grossly unfair to the Ceilometer

I certainly have not made such an implication about Ceilometer. What I see in the Ceilometer space, though, is that there are clearly a number of *active* communities of OpenStack engineers developing code that crosses similar problem spaces. I think the TC blessing one of those communities before the "market" has had a chance to do a bit more natural filtering of quality is a barrier to innovation. I think having all of those separate teams able to contribute code to an openstack/ code namespace and naturally work to resolve differences and merge innovation is a better fit for a meritocracy.

I think the rest of your plan is a way of recognising this
appropriately, that the current implementation is actually not the
be-all and end-all of how the TC should view a project.

Yes, quite well said.


OpenStack-dev mailing list

Reply via email to