> At the same time we are really close to freeze, this potentially blocks the > work of others; and while it should be mostly innocuous, it is still a large > amount of disruption, for what appears to me to be > precious little benefit > for the project or the 4.1 release.
> So why are we pushing so hard to get this done by freeze? We are pushing so hard to get this done for 4.1 release because the developers who built it are passionate about their work and we are well within the deadline of checking in new features. Passion of developers is what keeps the project alive. I personally think this check-in has huge benefit. It lays the foundation for cleaner componentization (which is huge for CloudStack) and the new storage architecture. In any case "lack of benefit" does not seem like a technical reason to prevent a check-in. It would benefit a fledging project like CloudStack to be inclusive. The potential disruption is a valid concern. And that's why we need to complete this check-in before deadline so we have time to stabilize the code base prior to the 4.1 release. It is also true CloudStack does not have a good automated regression test suite to make sure a check-in like this does not break some other features in CloudStack. But lack of a thorough automated regression suite a problem with CloudStack in general. We've let in other big changes in this release. I know developers who wrote this check-in have thoroughly regression tested to the best of their abilities. Sheng
