If we don't, I'd like to see it go in soon because we (and perhaps others) are now waiting on merging until we see what's going on with javelin.
On Mon, Jan 28, 2013 at 8:24 AM, Chip Childers <chip.child...@sungard.com> wrote: > On Mon, Jan 28, 2013 at 10:17 AM, John Burwell <jburw...@basho.com> wrote: >> All, >> >> I echo Marcus' concerns regarding the timing of such a "high touch" change >> landing in master. We are two days before code freeze. What 4.1.0 >> features/capabilities are gained by merging javelin? Can someone speak to >> the regression test strategy that has been employed to verify the stability >> of the changes? >> >> I proposed 2pm today (28 Jan 2013) [1] to meet on #cloudstack-meeting to >> continue our storage design conversation. > > Alex - Is it more logical to merge into master after we cut the 4.1 branch? > >> >> Thanks, >> -John >> >> [1] http://markmail.org/message/xivs7fuompr3n3o6 >> >> On Jan 27, 2013, at 8:21 PM, Kelven Yang <kelven.y...@citrix.com> wrote: >> >>> >>> I put a wiki article about this at, >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+Spring+in+Clou >>> dStack >>> >>> >>> It explains some of the motivations for trying Spring in javelin together >>> with the architecture cleanup work, as Alex has pointed, it does not >>> change the business logic behind, the effort of the work is to lay out a >>> more open foundation for future CloudStack evolution. >>> >>> Kelven >>> >>> >>> On 1/26/13 9:52 AM, "Alex Huang" <alex.hu...@citrix.com> wrote: >>> >>>>> >>>>> Do you have consensus on the storage piece? >>>>> I didn't walk away from the storage meeting with the impression that >>>>> consensus had been achieved, and there's another meeting on it next >>>>> week... >>>>> >>>> >>>> We did not reach yet because John had something to take care of. We >>>> agreed to hold another meeting. In principle, I think John's ideas and >>>> the new storage engine are not far apart. We're going to go into >>>> specific design on the next meeting to verify that. >>>> >>>> That is what I'm trying to point out here. We should look at javelin as >>>> the piece that just brings Spring support. It's high touch but minimal >>>> effect on business logic. We can reach consensus on whether to bring in >>>> the storage hookup piece when Edison ask to merge that branch in. >>>> >>>> --Alex >>>> >>> >>
