Open Stack

Howdy,

So we're just about to hit the 400th project hosted by the 
infrastructure team (and there are at least a dozen in review). I think 
this is great feat although I'm concerned about how our resources are 
being used.

Despite stackforge projects meaning to be self-sufficient they do create 
extra work for us - at least in terms of reviews (such as adding or 
tweaking tests). I do think that once they are up and running they are 
generally low maintenance but they still add overhead in terms of 
overall complexity and so on.

I think it goes without saying that the stackforge programme is an 
important asset to OpenStack. However, with our current challenges and 
limitations of the gate and resources I wonder if we should set the bar 
higher for accepting stackforge projects.

I'm not sure how this might look. For example, do we need to closer 
consider the relevancy of a project; or perhaps if two projects might be 
able to be joined together. These metrics can be ambiguous and require 
good insight into the proposed project(s) to tell. Additionally we could 
require a certain level of maturity in the codebase before accepting a 
project over to stackforge. However, this would hinder projects being 
started in the open (which would be a big deal).

It might be helpful to look at what we currently have project-wise to 
determine how tangential or relevant projects are on average. We may 
also wish to consider ways to mark projects as inactive to begin 
removing them from our configuration files as a tidy up.

Another idea may also be to consider what tests are critical and what 
could be ran as 3rd party tests for non-incubated projects. Or perhaps 
working towards testing more tactical[0] on all projects.

I'm not actually sure where I sit on this matter myself but I think it's 
an interesting conversation to flag.

Cheers,
Josh

[0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html

-- 
Rackspace Australia