On 1/28/13 10:49 PM, "Alex Karasulu" <akaras...@apache.org> wrote:
>On Tue, Jan 29, 2013 at 12:54 AM, Sheng Liang ><sheng.li...@citrix.com>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. > >HOWEVER ... > >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. > ><back-to-spring-hater-mode/> > >Again I hate Spring! Yuck! Let Spring bear the blame for a while, more deeper reason is actually that we are trying to clear the way a little bit towards a cleaner, loosely-coupled component model. We have too many runtime hard-coded wiring logic between components within the system, make it hard to unit-test and also to encourage a too-free-style coding habit for developers to code in CloudStack. Bearing this in mind, we've particularly refactored the code to have very minimal dependency to the component container itself, cut a clear line between component and component container, this also lays out the way towards adopting other better container in the future so that replacing it become a piece of cake task (not like this one at this time) It will be a long journey to shape CloudStack into a better next-generation structure, this is just a start and this is why we'd like to get it more early than later. Otherwise, it may take another 4 months to get the idea into CloudStack main stream. > > >> 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. >> >> >+1 > > >> 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. +1 And this is exactly what we are achieving to have. > >-- >Best Regards, >-- Alex >
