calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Apache-hosted CI (was Re: Build error in master branch)
Date Tue, 09 Feb 2016 20:14:12 GMT
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


Mime
View raw message