Alex, I agree that the risk I am describing is always present, and that unit tests only serve to reduce it. However, the typical mitigation of this risk is time. Therefore, we integrate such as these as early as possible and test them it relentlessly.
The question for me continues to come around to what capabilities/value is it delivering for 4.1.0? Being two days before code freeze, I think we need to understand the risk/reward specifically for 4.1.0. It feels like javelin represents foundational work that will benefit post 4.1.0 development. Therefore, it feels like the safest approach is to merge it once after we cut the 4.1.0 branch as one of the first additions for next release. Thanks, -John On Jan 28, 2013, at 5:56 PM, Alex Huang <alex.hu...@citrix.com> wrote: > John, > > +1 on that but it is true for every single feature. There's no guarantees on > how reaching a feature is. At least with the javelin changes we know if > management server loads, it can't do much harm. > > --Alex > >> -----Original Message----- >> From: John Burwell [mailto:jburw...@basho.com] >> Sent: Monday, January 28, 2013 1:43 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: Re: [MERGE][ACS41] javelin to master >> >> David, >> >> I mentioned to Chip on IRC that the biggest challenge for me is that there is >> not a unit test suite that we can run before and after the merge to verify >> it. >> Therefore, until we expand our unit test coverage, merges of structural >> changes such as javelin will carry an inherently higher risk. >> >> Thanks, >> -John >> >> On Jan 28, 2013, at 2:48 PM, Chip Childers <chip.child...@sungard.com> >> wrote: >> >>> On Mon, Jan 28, 2013 at 12:42 PM, Alex Huang <alex.hu...@citrix.com> >> wrote: >>>>> Obviously that doesn't answer the question for this release, and I >>>>> think John's question is a good one. What benefits does 4.1 accrue >>>>> from landing javelin at this point? Obviously after code freeze no new >>>>> features get to make it in, so from a feature standpoint, if it isn't >>>>> directly enabled or can be within one day, I am not sure what the >>>>> point is. >>>> >>>> One consideration is that 4.1 is shaping up to be low on features (other >> than the ones on ip clearance which generally have already been qaed on >> account that they've been released). The new storage engine getting the >> benefits of 2 months of QA by itself (assuming Edison's hookup code makes it >> into 4.1) is actually a good thing. I'm less concerned about Spring part as >> it >> has low risk in what it affects. >>>> >>>> Edison in writing the new storage stuff also attempted to add a standard >> for integration testing. It would be good to get evals from everyone on if >> it is >> enough. >>>> >>>> --Alex >>>> >>> >>> Alex - I'm specifically concerned about getting the pending features >>> into master. Does merging Javelin (1) not impact those pending >>> features, and (2) is it a pre-requisite to any pending features? >>> What's the harm in merging into master immediately after the 4.1 >>> branch is cut? That would seem like the optimal time to have changes >>> like this hit master. >>> >>> Thoughts? >
