Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of srivatsav.prasanna@gmail.com
 designates 209.85.219.47 as permitted sender)
MIME-Version: 1.0
Sender: srivatsav.prasanna@gmail.com
In-Reply-To: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA1E1C5F1@SJCPMAILBOX01.citrite.net>
References: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA1E1C50C@SJCPMAILBOX01.citrite.net>
	<0BCCCE152323764BB7FD6AE6D7A1D90601004B435A55@BANPMAILBOX01.citrite.net>
	<CAKprHVZzDc=83bLtYu3GrdsLnnpF3mL5Fx0mL-r6wynYYv8=Uw@mail.gmail.com>
	<B1DF26ECC0458748AC97CECE2DA98D41012FA1E1C5F1@SJCPMAILBOX01.citrite.net>
Date: Sat, 10 Nov 2012 20:12:48 +0530
Message-ID: 
 <CAEwhOuJ4b+ZSLvY2FPUoJ1j7VnHs_x_C5TsZ8JyCsZPNYDwnFA@mail.gmail.com>
Subject: Re: [DISCUSS] All checkins must include unit testing
From: prasanna <tsp@apache.org>
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I like the idea of unittests with every commit.

A few related topics I have that might be worth considering in this discuss=
ion:

1) What about unittests for the existing code? Or do we fill that gap slowl=
y?
2) Minor but we should probably update the unittesting wiki on how to
mock our managers, daos etc?

And a few things I'm confused about:

1) Gerrit is a code review tool just like reviewboard? So - would it
really serve the purpose if committers can still check-in without
unittests?
2) Or do we enforce everyone to send in for gerrit review? That seems
counter-intuitive to the idea of committer-ship?

On 10 November 2012 18:59, Alex Huang <Alex.Huang@citrix.com> wrote:
> While I understand what you are saying, I still think anyway we can get g=
errit up and running and just have people used to using it is a big plus.  =
The fact is we really don't know what people are checking in right now.  If=
 we actually have testing, I wouldn't be as big on this.  It is precisely b=
ecause we don't have testing that makes me want to make sure we at least ha=
ve a review system in place to catch problems.
>
> --Alex
>
>> -----Original Message-----
>> From: David Nalley [mailto:david@gnsa.us]
>> Sent: Saturday, November 10, 2012 3:41 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [DISCUSS] All checkins must include unit testing
>>
>> On Sat, Nov 10, 2012 at 2:04 AM, Rohit Yadav <rohit.yadav@citrix.com> wr=
ote:
>> > Can we ask ASF infra to setup gerrit, it that a possibility? If yes, t=
hat would
>> give us a lot more flexibility and quality control.
>> > Regards,
>> > Rohit
>>
>> So I am going to don my ASF infra hat for a minute, despite having no
>> real authority within infra, but just another volunteer doing work
>> there.
>> I think it is important for us to recognize our place at the ASF and
>> the reality of infra at the ASF. We are a single project, and one that
>> is still incubating. The ASF has more than 100 top level projects, and
>> scores of incubating projects. Moreover ASF infra has scarce few
>> dedicated human resources to apply - and the rest is all volunteer.
>> The number of services they are already maintaining is sizeable, and
>> it is unlikely that they will be willing to take on the installation,
>> management, and availability of yet another service, especially when
>> the following is true:
>>
>> * There is only a single project asking for the resource, and an
>> incubating one at that.
>> * It only works with git, which only a small fraction of projects at
>> the ASF use, and for which infra already has an impressive backlog of
>> tickets [1] the git backlog looks to represent almost 25% of the
>> unresolved infra tickets, and is more than double any other component
>> of ASF infra.
>>
>> What you 'might' be able to do is request a VM from infra and setup
>> gerrit on it, and take on the responsibility of keeping it updated and
>> maintaining availability yourself (and with others you manage to
>> attract to help you). In my mind there is also the question of
>> opportunity cost - we still lack much from a testing perspective
>> (which would be an important prereq for gerrit to be really effective,
>> actually being able to run tests against the code proposed) so while I
>> really like the idea of gerrit we still have a good way to go before
>> we'd be ready.
>>
>> [1]
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=3Dtrue&j=
qlQ
>> uery=3Dproject+%3D+INFRA+AND+resolution+%3D+Unresolved+AND+compo
>> nent+%3D+Git+ORDER+BY+priority+DESC&mode=3Dhide