On Friday, February 24, 2012 at 12:01 PM, [email protected] wrote: > That can work and may be the only choice if there is an extended feature > freeze. Although, that may end up creating a service provider-specific > fork...which may not be a bad thing.
It can also be a very, very bad thing. Segmentation of the community and an exponentially increased complexity for those of us playing both sides of the private/public fence. I really can't see any advantage of forking, even temporarily. I'm opposed to a broad Folsom feature freeze as it would too greatly limit progression. However, I also agree that there needs to be a better core focus, rather than on sprawl. I'm not opposed to selective feature inclusion. On the same token, I believe we should either approach the Linux kernel model of "include the kitchen sink" or not, and by not, Nova would be the core framework upon which various drivers would be provided and could be plumbed. If today, for instance, it was announced that Folsom won't include new features, then it would be impossible for Coraid, Pillar, or some other storage solution provider to offer a driver in Folsom and would have wait until G. Yet, Nexenta just got their driver into Essex. Nexenta's 6 month lead just turned into a 12 month lead! Sure, their competitor could ship separately, but there *is* a difference between inclusion, and now, if only politically and from the perspective of marketing. If new drivers and new code won't be accepted easily, then these third party drivers should be maintained as external plugins. While nice in theory, I don't agree with it at this time. These are contributions to OpenStack and are core, essential to the success of the community. Breaking out drivers, while easier, would fracture the community in potentially devastating ways. -- Eric Windisch
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
