Thank you for feedback. Sure, correctly, that's the reason why the current
SparkPullRequestBuilder do not run `lint-java`. :-)

In addition, that's the same reason why contributors are reluctant to run
`lint-java` and causes breaking on JDK7 builds.

Such a tedious and time-consuming job should be done by CI without human
interventions.

By the way, why do you think we need to wait for that? We should not wait
for any CIs, we should continue our own work.

My proposal isn't for making you wait to watch the result. There are two
use cases I want for us to focus here.

Case 1: When you make a PR to Spark PR queue.

    Travis CI will finish before SparkPullRequestBuilder.
    We will run the followings in parallel mode.
         1. Current SparkPullRequestBuilder: JDK8 + sbt build + (no Java
Linter)
         2. Travis: JDK7 + mvn build + Java Linter
         3. Travis: JDK8 + mvn build + Java Linter
     As we know, 1 is the longest time-consuming one which have lots of
works (except maven building or lint-  java). You don't need to wait more
in many cases. Yes, in many cases, not all the cases.


Case 2: When you prepare a PR on your branch.

    If you are at the final commit (maybe already-squashed), just go to
case 1.

    However, usually, we makes lots of commits locally while making
preparing our PR.
    And, finally we squashed them into one and send a PR to Spark.
    I mean you can use Travis CI during preparing your PRs.
    Again, don't wait for Travis CI. Just push it sometime or at every
commit, and continue your work.

    At the final stage when you finish your coding, squash your commits
into one,
    and amend your commit title or messages, see the Travis CI.
    Or, you can monitor Travis CI result on status menu bar.
    If it shows green icon, you have nothing to do.

       https://docs.travis-ci.com/user/apps/

To sum up, I think we don't need to wait for any CIs. It's like an email.
`Send and back to work.`

Dongjoon.


On Sun, May 22, 2016 at 8:32 PM, Ted Yu <yuzhih...@gmail.com> wrote:

> Without Zinc, 'mvn -DskipTests clean install' takes ~30 minutes.
>
> Maybe not everyone is willing to wait that long.
>
> On Sun, May 22, 2016 at 1:30 PM, Dongjoon Hyun <dongj...@apache.org>
> wrote:
>
>> Oh, Sure. My bad!
>>
>> - For Oracle JDK7, mvn -DskipTests install and run `dev/lint-java`.
>> - For Oracle JDK8, mvn -DskipTests install and run `dev/lint-java`.
>>
>> Thank you, Ted.
>>
>> Dongjoon.
>>
>> On Sun, May 22, 2016 at 1:29 PM, Ted Yu <yuzhih...@gmail.com> wrote:
>>
>>> The following line was repeated twice:
>>>
>>> - For Oracle JDK7, mvn -DskipTests install and run `dev/lint-java`.
>>>
>>> Did you intend to cover JDK 8 ?
>>>
>>> Cheers
>>>
>>> On Sun, May 22, 2016 at 1:25 PM, Dongjoon Hyun <dongj...@apache.org>
>>> wrote:
>>>
>>>> Hi, All.
>>>>
>>>> I want to propose the followings.
>>>>
>>>> - Turn on Travis CI for Apache Spark PR queue.
>>>> - Recommend this for contributors, too
>>>>
>>>> Currently, Spark provides Travis CI configuration file to help
>>>> contributors check Scala/Java style conformance and JDK7/8 compilation
>>>> easily during their preparing pull requests. Please note that it's only
>>>> about static analysis.
>>>>
>>>> - For Oracle JDK7, mvn -DskipTests install and run `dev/lint-java`.
>>>> - For Oracle JDK7, mvn -DskipTests install and run `dev/lint-java`.
>>>> Scalastyle is included in the step 'mvn install', too.
>>>>
>>>> Yep, if you turn on your Travis CI configuration, you can already see
>>>> the results on your branches before making PR. I wrote this email to
>>>> prevent more failures proactively and community-widely.
>>>>
>>>> For stability, I have been monitoring that for two weeks. It detects
>>>> the failures or recovery on JDK7 builds or Java linter on Spark master
>>>> branch correctly. The only exceptional case I observed rarely is `timeout`
>>>> failure due to hangs of maven. But, as we know, it's happen in our Jenkins
>>>> SparkPullRequestBuilder, too. I think we can ignore that.
>>>>
>>>> I'm sure that this will save much more community's efforts on the
>>>> static errors by preventing them at the very early stage. But, there might
>>>> be another reason not to do this. I'm wondering about your thoughts.
>>>>
>>>> I can make a Apache INFRA Jira issue for this if there is some
>>>> consensus.
>>>>
>>>> Warmly,
>>>> Dongjoon.
>>>>
>>>
>>>
>>
>

Reply via email to