I believe it will make CI much smoother. Right now marvin is tied to the Cloudstack repo which was fine if all the integration tests were running from Cloudstack build but we are now seeing much better CI approaches with bubble and Trillian and having marvin in its own repo will facilitate that even further. I think Rohit can answer this better but this is what I got as a gist of the motive.
Does that answer your question Bharat? -Syed On Tue, Jul 19, 2016 at 9:14 AM, Bharat Kumar <bharat.ku...@accelerite.com> wrote: > Hi Rohit, > > > what are we trying to achieve by moving marvin into a separate repo.? > > > --Bharat. > > ________________________________ > From: Raja Pullela <raja.pull...@accelerite.com> > Sent: Tuesday, July 19, 2016 5:30:20 PM > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] Split Marvin to its own repository > > Hi Rohit, > > same question as Rene has posted, impact on older releases – will have > issues on older releases. I know that the older releases have marvin code > which can be used. Also, this will require changes on the CI side to pull > the correct repo for Marvin. > > +1, if Bharat can modify CI implementation to take care of this? > > best, > Raja > Senior Manager, Product Development > Accelerate, www.accelerite.com,@accelerite<http://www.accelerite.com > ,@accelerite> > 2055, Laurelwood Road, Santa Clara, CA 95054, USA > Phone: 1-408-216-7010 > > On 7/18/16, 3:14 PM, "Rohit Yadav" <bhais...@apache.org> wrote: > All, > > Based on a recent discussion thread [1], I want to start a voting thread to > gather consensus around splitting Marvin from the CloudStack repository. > > On successful voting, we would extract and maintain Marvin as a separate > library in a separate repository (example repository [2]) and various > build/test systems such as Travis [3] can install it directly for usage > with pip+git etc. > > Background: During the build process, a commands.xml generated to build > apidocs is also used to generate CloudStack Cmd and Request classes are > auto-generated, which is the only dependency why we needed Marvin and > CloudStack together. The auto-generated cloudstackAPI module can be also > generated against a live running CloudStack mgmt server which has api > discovery (listApis) enabled. The integration tests will still be tied to a > branch and will remain withing the repository. A PR [3] was sent to show > that we can still execute tests using this approach, and this would finally > allow us to build, release and use Marvin as an independent library. > > Vote will be open for 72 hours. > > For sanity in tallying the vote, can PMC members please be sure to indicate > "(binding)" with their vote? > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > [1] http://markmail.org/thread/kiezqhjpz44hvrau > [2] https://github.com/rhtyd/marvin > [3] https://github.com/apache/cloudstack/pull/1599 > > Regards, > Rohit Yadav > > > > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is > the property of Accelerite, a Persistent Systems business. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Accelerite, a Persistent Systems business does not accept any > liability for virus infected mails. > > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is > the property of Accelerite, a Persistent Systems business. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Accelerite, a Persistent Systems business does not accept any > liability for virus infected mails. >
