Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Turn around on patches that do not need full unit testing
From: Alan Gates <gates@hortonworks.com>
In-Reply-To: 
 <CAENxBwzzdqxXcwhWX-KZPY1Ws=v9-eceyOEj2JCQV4c2EdpCwg@mail.gmail.com>
Date: Fri, 15 Jun 2012 10:11:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <59FBEAD9-F41F-4C02-B2A7-CA00358B97CC@hortonworks.com>
References: 
 <CAENxBwzxcSYsfFJo=+wwdhZB9xEJVp7YBJa3kjjZtWUJx-X0iQ@mail.gmail.com>
 <A5EF09CA-575C-4949-892E-CDC4B35EE693@fb.com>
 <CAENxBwzzdqxXcwhWX-KZPY1Ws=v9-eceyOEj2JCQV4c2EdpCwg@mail.gmail.com>
To: dev@hive.apache.org

One approach I've seen other projects take is to have an "ant =
test-commit" target that users are responsible to run before committing. =
 This is a short (15 min or less) target that runs all true unit tests =
(tests that exercise just a class or two in isolation) and a couple of =
functional tests that exercise major functionality but not every last =
thing.  The full test suite can then be run nightly and any issues =
addressed.

Alan.

On Jun 11, 2012, at 6:17 AM, Edward Capriolo wrote:

> I agree. Having a short-test and long-test might make more sense. IE
> long-test includes funky serdes and UDFs.
>=20
> As for "In the meanwhile, check in without test may introduce bug
> which can break production cluster.costly." the solution is not to run
> trunk. Run only releases.
>=20
> All the tests are run by jenkins post commit so we know when trunk is
> broken and we should not cut a release if all the tests are not
> passing. Also we should not knowingly break the build or leave it
> broken. IE would should strive to have all tests passing on trunk at
> all times, but not committing a typo patch for fear that the "build
> might break" does not make much sense. We can easily revert things in
> such a case.
>=20
> Edward
>=20
> On Sun, Jun 10, 2012 at 11:14 PM, Gang Liu <gang@fb.com> wrote:
>> Yeah it is frustrated to take a long time to turn around for a tiny =
change. It is understood.
>>=20
>> In the meanwhile, check in without test may introduce bug which can =
break production cluster.costly.
>>=20
>> I think the problem is not if we should run test but running tests =
takes long time. If it takes reasonable time like 30 minutes, we have =
less pain.
>>=20
>> In a summary let us keep high quality via running test for every =
commit. Target to make unit test fast.
>>=20
>> Btw we can run test in parallel a hive wiki has details
>>=20
>> Thanks
>>=20
>> Sent from my iPhone
>>=20
>> On Jun 10, 2012, at 7:29 PM, "Edward Capriolo" =
<edlinuxguru@gmail.com> wrote:
>>=20
>>> Hive's unit tests take a long time. There are many simple patches we
>>> can get into hive earlier if we drop the notion of running the full
>>> test suite to QA every patch. For example:
>>>=20
>>> https://issues.apache.org/jira/browse/HIVE-3081  --> spelling =
mistakes
>>> that involved types
>>>=20
>>> https://issues.apache.org/jira/browse/HIVE-3061  --> patches with =
code cleanup
>>>=20
>>> https://issues.apache.org/jira/browse/HIVE-3048  --> patches that =
are
>>> one or two lines of code
>>>=20
>>> https://issues.apache.org/jira/browse/HIVE-2288  --> patches that =
are
>>> only additive
>>>=20
>>> Also I do not believe we should kick a patch back to someone for =
every
>>> tiny change. For example, suppose someone commits 9000 lines of =
code,
>>> with one typo. I have seen similar situations where the status gets
>>> reverted back to OPEN. It takes the person working on it a day to =
get
>>> back into the patch again, then by the time someone comes back =
around
>>> to reviewing another 3 days might go by.
>>>=20
>>> This is similar to a situation in the supermarket where  "You can =
only
>>> use one coupon" so people walk in and out of the store 6 times to =
buy
>>> 6 items. Procedure and rules are followed, end results is really the
>>> same, but 6 times the work.
>>>=20
>>> In this case the committer should just make he change, re upload the
>>> patch and say 'committed with typo fixed' and commit.
>>>=20
>>> please comment,
>>>=20
>>> Edward