Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of runseb@gmail.com designates
 74.125.83.43 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [PROPOSAL] Using continuous integration to maintain our code
 quality...
From: sebgoa <runseb@gmail.com>
In-Reply-To: <C3637609BC1C0D40A2AC70F4760C7A2D8003B0@SJCPEX01CL02.citrite.net>
Date: Wed, 21 May 2014 08:30:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <10427A11-AE59-4299-9951-3CA15344B90B@gmail.com>
References: <20CF38CB4385CE4D9D1558D52A0FC05870768C@SJCPEX01CL03.citrite.net>
 <32F1CBD4-08EE-4313-9E20-B55906266DFE@apache.org>
 <C3637609BC1C0D40A2AC70F4760C7A2D8003B0@SJCPEX01CL02.citrite.net>
To: dev@cloudstack.apache.org


On May 21, 2014, at 12:40 AM, Animesh Chaturvedi =
<animesh.chaturvedi@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.=20=

>=20

Why don't Citrix developers show us how they would do it in the open ? =
Right now it's all hidden.=20

> Animesh
>=20
>> -----Original Message-----
>> From: Trippie [mailto:trippie@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...
>>=20
>> Hey Alex,
>>=20
>> 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.
>>=20
>> I do have some feedback on the policy though.
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> Cheers,
>>=20
>> Hugo
>>=20
>>=20
>> On 7 mei 2014, at 02:03, Alex Huang <Alex.Huang@citrix.com> wrote:
>>=20
>>> Hi All,
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Please have a read and let me know what you think.
>>>=20
>>> --Alex
>>>=20
>>> [1]
>> =
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+Pro
>> cess
>=20