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. 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 >> >
