+1 - I wouldn't be bothered if a build becomes longer if I can write cleaner codes without manually running it.
I have just looked though the related PRs and JIRAs and it looks generally okay and reasonable to me. 2016-05-23 18:54 GMT+09:00 Steve Loughran <ste...@hortonworks.com>: > > On 23 May 2016, at 05:21, Dongjoon Hyun <dongj...@apache.org> wrote: > > 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. > > > > +1 > > Any time you spend waiting for tests to complete is time you could be > doing useful things. I've had VMs running jenkins watching git branches do > this in the past: every time I push > > > > 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.` > > > > I'd add another, which is "do a build and test of this patch while I get > on with something else, that is, things which aren't ready for review, just > the work you've done in the past hour or two which you'd like tested out >
