Is the water in the river safe to drink?

Each committer is ensuring that it is safe to drink. We can change the definition of “safe” so we don’t put an undue burden on the committer. But I would be inclined to put more burden on the committer so that each developer knows that the master branch meets a given minimum standard. 

I totally agree with you that we need PR testing. That helps developers submitting PRs, and also helps committers. I don’t worry too much that the PR test takes ~20 minutes (including a javadoc build). But until then, committers need to use whatever tools are that their disposal to make sure the water is clean before they put it into the river. If the river is not clean it makes everyone’s life more difficult.

Julian
 

> On Feb 9, 2016, at 11:52 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
> 
>> If there are even checkstyle errors, they should be fixed before the commit.
> 
> Of course they should.
> However, I am not sure if it wise to ask "full javadoc build" before
> each commit. It takes enormous time (especially, if jdk sources are
> included to properly inherit javadocs from java.* classes).
> 
> I mean:
> 1) Having checkstyle separate shaves time on "test execution".
> 2) Assuming we'll implement PR testing shortly, "checkstyle" job might
> catch non-yet-well-formed PRs
> 
> PR-testing is something a bit different from "CI-testing of the main
> brach". I wonder if we need a separate set of jobs for that (e.g. in
> order not to clutter main build history).
> 
> What are the opinions here?
> 
> For my in-house Jenkins deployment I'm having great fun with a mix of
> Job DSL plugin + Multijob plugin.
> The former allows to script job configuration (in groovy), so I do not
> need to edit jobs manually here and there.
> The latter allows to organize job hierarchy in a series of phases when
> each phase launches a set of concurrent jobs.
> We do not need OOP for current couple of jobs, however it might be
> something to consider.
> 
> Vladimir