Since the discussion has returned to the thread rather than Dan's PR, I want to paraphrase the point I feel strongest about here:
*For a new contributor, I want to minimize the distance between them deciding to hack and becoming our friends.* So I don't want them to have to learn much, if anything, about our idioms prior to opening a PR. That includes checkstyle, findbugs, javadoc, RAT, (any others?). Once a PR is open, we can welcome them to the community, help them understand any failure that happened via Jenkins, tell them the command to run the more thorough test, or even issue little fix PRs against their branch. If they get blocked by nitpicky or confusing failures in their console or while hacking, they might (reasonably, IMO) decide to go do something else. Folks other than newcomers can learn a repertoire of commands, like Robert says. So we shouldn't consider them (aka "us") so much when deciding whether "fast" or "slow" is the default, as long as we can explicitly choose. Kenn On Fri, Feb 10, 2017 at 11:00 AM, Robert Bradshaw < [email protected]> wrote: > > 1. Developer productivity -- Jenkins should run many more checks than > > developers do. Especially time-, resource-, or setup- intensive tasks. > > 2. Automated enforcement -- Jenkins is better at running the right > commands > > than we are. > > 3. Lower the barrier to entry -- individual developers need not have a > > running Spark/Flink/Apex/Dataflow setup in order to contribute code. > > 4. Focus on the user -- someone checking out the code and using it for > the > > first time does not care whether the code style checks or has the right > > licenses -- that should have been enforced by the Beam team before > > committing. > > > > We should be *very* choosy about what we enforce on every developer every > > time they go to compile. I probably compile Beam 50x-100x a day. > Literally, > > the extra minutes you want to add here will cost me an hour daily. > > > > By the same token of having a different bar for the Jenkins presubmit vs. > what's run locally, I think it makes a lot of sense to run a different > command for iterative development than you run before creating a pull > request. E.g. during development I'll often run only one test rather than > the entire suite, but do run the entire suite occasionally (often before > commit, especially before pushing). > > The contributors guild should give a suggested command to run before > creating a PR, right in the docs of how to create a PR, which may be more > expensive than what you run during development. IMHO, this should be fairly > comprehensive (certainly tests and checkstyle, maybe javadoc and findbugs). > This should be the "default" command that the one-time-contributor should > know. For those compiling 50x or more a day, I think the burden of learning > a second (or more) cheaper commands is not high, and we could even put such > a thing in the docs (and hopefully a common maven convention like "mvn > test"). Kenn > I've listed the fraction of commits I think will break one of the following > > if that property is not tested: > > > > * compiling (100%) > > * tests (100%) > > * checkstyle (90%) > > * javadoc (30%) > > * findbugs (5%) > > * rat (1%) > > > > So you can see where I stand and why. I'm sorry that 1/20 PRs has Apache > > RAT catch a licensing issue or Findbugs catch a threading issue -- you > can > > always get a larger set of the precommit checks using -Prelease, though > of > > course the integration tests and runnableonservice tests may catch more > > issues still. But I want my developer minutes back for the 95%+ of the > > rest. > > > > Dan > > >
