cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [MERGE][ACS41] javelin to master
Date Mon, 28 Jan 2013 23:18:35 GMT
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:shadowsor@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.Liang@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
> >

Mime
View raw message