On May 21, 2014, at 12:40 AM, Animesh Chaturvedi <animesh.chaturv...@citrix.com> wrote:
> Hugo without putting certain rules we are not going to get out of the > situation. I think it may seem draconian but stating "No merges are allowed > without a successful run of the automation" Let's be specific. Are we talking about merges of features or every commit. A successful run of all integration tests with the simulator can take 45 minutes maybe more. This means that everyone will have to wait for this to complete for even a typo. > is beneficial for everyone. It forces focus on automation and helps mitigate > regression. If we run into challenges in implementing those rules like > toolset not ready or infra then we would have to fix those. > Why don't Citrix developers show us how they would do it in the open ? Right now it's all hidden. > Animesh > >> -----Original Message----- >> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers >> Sent: Wednesday, May 14, 2014 12:32 AM >> To: dev@cloudstack.apache.org >> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code >> quality... >> >> Hey Alex, >> >> Nice job on getting this all done and working on some guidelines to improve >> quality of the overal guidelines. We discussed a lot of these things at the >> last >> CCC and i'm happy to see them here. >> >> I do have some feedback on the policy though. >> >> Specifically with the line stating "No merges are allowed without a >> successful >> run of the automation". You stated yourself that the infra running the >> automation is being run by Citrix. Introducing this statement links our >> policy >> to Citrix in such a way that we can't commit if the citrix supplied Infra is >> not >> availalbe. That doesn't sound like a good thing. Anyway part of being a >> committer is the responsibility to make a correct decision when and how to >> commit to the central code base, this includes deciding when running >> automation tests is appropriate. You know i'm in favor of quality controls >> and i am a strong proponent of testing before committing, but each >> committer has his own responsibility in this and has to show he/she takes >> this seriously. >> >> The JIRA process is pretty good and will certainly help with keeping track of >> what is going on, but is not mandatory in my opinion. Also arranging for a >> review is not a responsibility of the developer of a piece of code. If that >> is >> necessary it is the community that fails, the really responsibility to do >> code >> reviews is with the committers, "Each committer has a responsibility to >> monitor the changes made for potential issues, both coding and legal." >> (http://www.apache.org/dev/new-committers-guide.html). >> >> I'm a firm believer of providing tooling and support to help make "doing the >> right thing" as easy as possible. In my opinion the focus should be on making >> sure this tooling is as easy to use as possible so committers and >> contributors >> will want to use this, because it helps them instead of forcing them to use >> it >> by policy. >> >> Cheers, >> >> Hugo >> >> >> On 7 mei 2014, at 02:03, Alex Huang <alex.hu...@citrix.com> wrote: >> >>> Hi All, >>> >>> This is something I brought up a long time ago but really didn't have the >> resources to get it all up and running until now. Throughout the past year, >> Edison, Prasanna, Amogh, Bharat, Koushik, Talluri, and others have been >> chipping away at it. At this point, we finally pull together a continuous >> integration setup that we can use to make sure that CloudStack master and >> the currently release branch are always stable. This is getting pretty >> close to >> be completed and we like to share it with the community in hopes that we >> can reduce/eliminate that problems we've seen with our recent releases. >> Currently, the physical hardware are hosted by Citrix but we'll be more than >> willing to donate the work to infra when that's all settled. >>> >>> This does require effort from the community to make a change in their >> development process. These steps are detailed at [1]. I like to get >> feedback >> on what everyone think about this. >>> >>> What have we done: >>> - We replaced a large selection of the BVT tests to run with the simulator >> instead of actual hardware. This shortens the duration of each BVT run. >> Today, a BVT that runs tests for XenServer and KVM completes in 30-40 >> minutes. >>> - We will run the new BVT on master and the current release branch on a >> continuous basis. >>> - Developers can use Jenkins to ask BVT to be run on their branch so they >> can know it won't break the continuous integration before they merge to >> master and the current release branch. >>> >>> Please have a read and let me know what you think. >>> >>> --Alex >>> >>> [1] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+Pro >> cess >
