I think we should first clear up all pending reviews and then proceed with any merge. Otherwise there is a high chance that most of them needs to be resubmitted.
-Koushik > -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Saturday, January 05, 2013 5:21 AM > To: cloudstack-dev@incubator.apache.org > Subject: [MERGE] Merge Javelin branch into master > > I propose that we use the MERGE tag for any branch merging. I've changed > this subject as such. > > Chip also raised some issues in another thread. Let's try to merge them on to > this discussion. Please raise again if this doesn't answer your questions. > > I like to add some things to what Kelven has talked about here. > > - Item 1 touch a great deal of of CloudStack 4.0 code but problems will rise > very quickly and the fixes should be small. Basically if the server can't > come > up during our test, this doesn't work. So we will make sure that server is up > and running the automated tests before merging. > - For items 2, 3, 4, we were worried about the effect extended changes > would have on the CloudStack 4.0 code so what we've done are as follows: > - A new set of subdirectories: > - framework - for any work in ipc/jobs/event notification. > - engine - for any work in storage refactoring and vm > orchestration refactoring > - services - for any services build on top of framework and > engine but currently there are none. > - We have minimized changes in the CloudStack 4.0 code to > appropriately call out to engine libraries but no in place changes to logic. > For > example, none of the old code has been changed to use the new ipc > mechanism. > - The code changes in engine have their own unit tests. I will let > Edison and Prachi talk about that. Until the unit tests have worked out, we > do not swap out code from the CloudStack 4.0 code. > > For the merge, we will do the following: > - Wait for the api-refactoring merge. > - Pull in all master changes and make sure the unit tests are all running or > have been appropriately changed to run. > - Make sure automated testing is running against the new server. > - Merge back into master. > > --Alex > > > -----Original Message----- > > From: Kelven Yang [mailto:kelven.y...@citrix.com] > > Sent: Friday, January 04, 2013 3:13 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: [PROPOSAL] Merge Javelin branch into master > > > > I'm proposing another branch merge after API-refactoring branch, to > > merge javelin branch into the main stream. Javelin branch contains a > > number of architecture refactoring efforts, > > > > 1. Adopting Spring Framework for dependency injection of CloudStack > > internal components 2. IPC framework for inter component > > communications 3. Storage subsystem refactoring 4. CloudStack > > Orchestration Engine refactoring > > > > Majorities of the new refactoring work are independent of existing > > CloudStack components, therefore merging these independent newly > > developed components should not have a big impact to existing code > > base. The major impact of this merge will be on #1, as it touches > > almost every component in the existing code base, DAOs, Adapters, > > Managers, etc. In order to seamlessly replace our existing > > ComponentLocator with Spring injection framework. We've done following > > refactoring to existing code base. > > > > 1) Remove all un-necessary runtime bindings to ComponentLocator at > > Daos, Managers, Adapters, etc > > 2) Using standard javax @Inject to replace with customized > > com.cloud.utils.component.Inject > > 3) Using Spring AOP to support @DB semantics > > 4) Separate component loading and initializing to avoid inter-leaving > > dependencies between Spring bootstrap loader and CloudStack run-time > > business logic. > > 5) Move CloudStack bootstrap logic out of ComponentLocator to the > > initialization process at business logic layer > > > > The plan of performing such merge will be, we will first pull the > > latest master content into javelin branch, complete the merge at > > javelin branch and commit it into master after certain level of > > testing. The goal is to make existing code works as before but will > > drop in newly add-ons of refactoring work. > > > > Kelven
