Hi Marcus, Yes. We can wait until the end of code freeze to merge. See my other email.
--Alex > -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Monday, January 28, 2013 3:02 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [MERGE][ACS41] javelin to master > > 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 <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. > > > > 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 > >
