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+Process
