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 Thanks Sent from my iPhone On Jun 10, 2012, at 7:29 PM, "Edward Capriolo" <edlinuxg...@gmail.com> 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, > > Edward
