Open Stack

On 11/8/2012 2:49 PM, Vishvananda Ishaya wrote:
> On Nov 8, 2012, at 11:06 AM, John Dickinson<me at not.mn>  wrote:
>
>> We should empower HP, RAX, ATT, and others to build great products for their customers. Ensuring that they work together is in the realm of branding and trademarks, though, and that's managed by the Board of Directories. This also give private cloud deployments a standard to work against as they deploy their solutions.
> I don't think we can push "ensuring that they work together" off onto the board of directors. Interopability is only going to be achieved by the projects collaborating to provide a seamless experience. This is a hard problem and while I lean strongly towards  including other projects in our shared releases, we have to be careful not to just throw in a bunch of stuff and watering down the quality of the release.
>
> Each time we add a new project to the release it makes it harder to deploy openstack. Witness the issues with glance then keystone then cinder and quantum. Fundamentally there are two issues with including more projects:
I agree with this but:
>
> a) confusing end users by giving them too many options.
It can be equally confusing to end users when the result of *not* 
including a project to do important function X
is that users are faced with multiple, incompatible ways to do X.
> b) increased load ci, doc, and testing resources leading to poor release quality.
This is not working as well as is needed even now. The ratio of 
developers to resources committed to open testing and doc are way off from
what they would be in a closed engineering environment. I think we need 
a model where a project is more self-contained (develop,test,doc) instead
of (develop, unit-tests) where the rest is to be done by some mythical 
OpenStack resources. How about we raise the
bar for new projects. A new project could be required to provide its own 
integration tests and documentation as
part of the acceptance process.

  -David