I agree. Having a short-test and long-test might make more sense. IE
long-test includes funky serdes and UDFs.
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.
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.
On Sun, Jun 10, 2012 at 11:14 PM, Gang Liu <[EMAIL PROTECTED]> wrote:
> Yeah it is frustrated to take a long time to turn around for a tiny change. It is understood.
> In the meanwhile, check in without test may introduce bug which can break production cluster.costly.
> 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.
> In a summary let us keep high quality via running test for every commit. Target to make unit test fast.
> Btw we can run test in parallel a hive wiki has details
> Sent from my iPhone
> On Jun 10, 2012, at 7:29 PM, "Edward Capriolo" <[EMAIL PROTECTED]> wrote:
>> 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:
>> https://issues.apache.org/jira/browse/HIVE-3081 --> spelling mistakes
>> that involved types
>> https://issues.apache.org/jira/browse/HIVE-3061 --> patches with code cleanup
>> https://issues.apache.org/jira/browse/HIVE-3048 --> patches that are
>> one or two lines of code
>> https://issues.apache.org/jira/browse/HIVE-2288 --> patches that are
>> only additive
>> 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.
>> 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.
>> In this case the committer should just make he change, re upload the
>> patch and say 'committed with typo fixed' and commit.
>> please comment,