On Apr 22, 2015, at 12:24 PM, Raja Pullela <raja.pull...@citrix.com> wrote:
> Sebastien, I am taking about the tests we have under "test/integration/smoke" > folder. > Not sure how the tests run through Travis, will try to understand. > These are tests were run on a local cloudstack env. > Just catching up and making sure I reply to Raja here. Travis (https://travis-ci.org) runs those tests, by building cloudstack and running the simulator. All the travis setup is defined in the travis.yml file in the root of the repo. This setup can probably be improved. Do note that if you fork on your own github, pushes to your own branch will run through Travis as well. > best, > Raja > -----Original Message----- > From: Sebastien Goasguen [mailto:run...@gmail.com] > Sent: Friday, April 17, 2015 1:14 PM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] 4.6 release management > > >> On Apr 17, 2015, at 6:26 AM, Raja Pullela <raja.pull...@citrix.com> wrote: >> >> +1 for the "Some people (I'm part of them) are concerned on our current way >> of supporting and back porting fixes to multiple release" >> This should be a top priority along with keeping master stable - make sure >> BVTs are passing at 100% all the time. > > Raja, which BVT are you talking about ? AFAIK, all current tests run on all > commits through Travis. > >> Also if we can plan/target increasing test/BVT coverage, that will be super! >> >> Thanks, >> Raja >> -----Original Message----- >> From: Marcus [mailto:shadow...@gmail.com] >> Sent: Friday, April 17, 2015 4:35 AM >> To: dev@cloudstack.apache.org >> Subject: Re: [DISCUSS] 4.6 release management >> >> "storage plugin involve changes on Hypervisor code" >> >> I know this is just an example, but at least on KVM side this is no longer >> true. Previously you had to implement a KVM-specific 'StorageAdaptor' that >> would run on the hypervisor, and register that with the agent code, but Mike >> and I added some reflection/annotation that allows for auto-detection of the >> adaptor upon Agent start up, so storage plugins can be completely >> self-contained now. They don't even have to be a part of our code base. >> >> There may be other parts of the code where we can do similar things to >> decouple if we can identify those points. Ideally, if someone has to modify >> core code to add their plugin it should only be because they are adding some >> new functionality *that core cloudstack needs to be aware of*, and that >> functionality should be added in a way that other plugins can also >> provide/implement it. Otherwise, they can always add new APIs specific to >> their appliance or product and leveraging data from cloudstack's db, all via >> plugin. They can add new global/zone/cluster configs and UI tools via plugin >> as well. >> >> On Thu, Apr 16, 2015 at 3:49 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote: >>> Today during the CloudStackdays we did a round table about Release >>> management targeting the next 4.6 releases. >>> >>> >>> Quick bullet point discussions: >>> >>> ideas to change release planning >>> >>> - Plugin contribution is complicated because often a new plugin involve >>> change on the core: >>> - ex: storage plugin involve changes on Hypervisor code >>> - There is an idea of going on a 2 weeks release model which could >>> introduce issue the database schema. >>> - Database schema version should be different then the application >>> version. >>> - There is a will to enforce git workflow in 4.6 and trigger simulator >>> job on PullRequest. >>> - Some people (I'm part of them) are concerned on our current way of >>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x, >>> 4.5.x). But the current level of confidence against latest release is low, >>> so that need to be improved. >>> >>> >>> So, the main messages is that w'd like to improve the release >>> velocity, and release branch stability. so we would like to propose >>> few change in the way we would add code to the 4.6 branch as follow: >>> >>> - All new contribution to 4.6 would be thru Pull Request or merge >>> request, which would trigger a simulator job, ideally only if that >>> pass the PR would be accepted and automatically merged. At this >>> time, I think we pretty much have everything in place to do that. At >>> a first step we would use >>> simulator+marvin jobs then improve tests coverage from there. >>> >>> Please comments :-) >
