cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [MERGE][ACS41] javelin to master
Date Tue, 29 Jan 2013 06:49:38 GMT
On Tue, Jan 29, 2013 at 12:54 AM, 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.
As a disclaimer I absolutely abhor Spring. I think it's a big turd and
should be whipped off the face of the earth. I was sad to see Spring make
it in over OSGi.


Sheng has a great point about developer passion. It's not always about the
features and about utility. The passion is indeed what keeps the project
alive. MIght want to stop and rethink this.


Again I hate Spring! Yuck!

> 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.
Or just extend the deadline and relax.

> 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.
This is  a point I tried to make to a few folks before CloudStack came
here. If you want to provide a smooth path to committership you need a
solid regression testing framework (with near total coverage) and an
environment. Feeling blind and vulnerable to big changes like this limits
trust and we can't have a lack of trust. If you want this project growing
faster and healthier regression testing is key: it has a social impact.

Best Regards,
-- Alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message