incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: [MERGE][ACS41] javelin to master
Date Mon, 28 Jan 2013 23:01:59 GMT
I don't think anyone is questioning the benefit of moving to spring
framework, as it has already been established and people are moving
forward on it. The question is, if spring is merged now, as opposed to
Friday, are there any features besides the storage (which has been
mentioned will be functionally identical) which will also make it into
4.1 as a benefit of merging spring now.  You see, if there is feature
parity between merging spring for 4.1 and not merging spring for 4.1,
but risk to merge spring, then we don't gain anything by including it
within the 4.1 cutoff, only risk. That's what people are asking about,
are we losing any feature by waiting for the cutoff and then merging
it into master?

On Mon, Jan 28, 2013 at 3:54 PM, Sheng Liang <> wrote:
>> 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

View raw message