> -----Original Message-----
> From: sebgoa [mailto:run...@gmail.com]
> Sent: Tuesday, May 20, 2014 11:30 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
> quality...
>
>
> 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.
[Animesh] Alex can correct me if my interpretation is incorrect. But the idea
is to protect release and master branch. Folks can continue to checkin into
their own branch but before merge into the release branches the tests should
pass for 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] Certainly that is the intent and the proposal calls it out, we will
have teething trouble initially but hopefully we will grow over it quickly
>
> > 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+Pr
> >> o
> >> cess
> >
