I just want to be clear, since I was the first to raise concerns, that I appreciate the work that has been put into javelin. It's been said multiple times now in various ways that merging is a form of reward for a job well done, and that denying that will affect the passion or drive of the developers who worked on it. I completely agree, and never intended to rob anyone of that.
I also agree that anything that will clear the path for better testing and easier development is worthwhile. I agree that javelin provides much needed value. The only concerns I think have been brought up really revolve about the value of shipping it to customers. From a customer perspective, does shipping a tool that will aid development in a branch that is in development freeze matter? All of the development will continue happily along in master and branches of master, and spring will be there. I think that's the main point people have been asking about, is what it provides to the 4.1 branch. I think the existing plan laid out is a good compromise. On Tue, Jan 29, 2013 at 11:16 AM, Kelven Yang <kelven.y...@citrix.com> wrote: > > > 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 > > >> >
