| Hi all, 
 I recently requested a Hudson instance (called HIPP) for Platform:
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=417030
 Here it is: https://hudson.eclipse.org/platform/
 
 It contains:
 * The Platform-Sonar job (which is failing because of
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=416904 , requires
    changes in almost all pom.xml for tests, and also in some code which
    expects running in a full Eclipse distro whereas Tycho uses a
    minimal target platform)
 * Some *-Gerrit job for each repository.
 
 == How to use Gerrit jobs?
 
 These jobs are active and will vote +1 or -1 on any Gerrit
    contribution: if build is green, Hudson votes +1; if not it will
    vote -1. The command line which is used it "mvn clean verify
    -Pbuild-individual-bundles -Dmaven.test.skip=true". Just continue to
    use Gerrit, and you'll see Hudson chatting with you to say what he
    thinks about this contribution.
 
 A "-1" on a contribution should mean a compile or build issue, so
    it's a blocker for a contribution to be merged. It can be
    interpreted as a blocking issue for a human review: if Hudson says
    no, it's too early to review the code, you can tell the contributor
    "Please make Hudson happy, I come back after that".
 A "+1" means that the change doesn't break compilation, it's a good
    starting point to review the contribution.
 
 == What's next?
 
 It would be nice to have test running with Tycho (
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=416904 ), so we could
    switch the -Dmaven.test.skip to false for all these *-Gerrit jobs.
    As a consequence, Hudson would run tests, and vote -1 if build fails
    or a test fails, and +1 if everything is still green. This gives
    some more trust in the contribution and reduce the risk of merging
    something bad.
 Then, when we have all tests running with Tycho, it will also be
    easy to add some fun metrics such as code coverage.
 
 == Goals
 
 * Decrease amount of erroneous commits (always using Gerrit should
    show almost any change that breaks the build) and consequently
    failed builds
 * Ease contribution reviews by spotting bad changes automatically
 * Give immediate feedback to lazy contributors who don't want to
    build locally. They can push to Gerrit and see what will happen
    (it's not a very good workflow, but it appears to be helpful for
    many people)
 
 Hopefully, all this leading to better productivity, more
    contributors, better code quality and so on...
 
 == Limitations
 
 * https://bugs.eclipse.org/bugs/show_bug.cgi?id=416904 makes that
    those jobs can't run tests
 * This appraoch uses the last integration build to resolve
    dependencies, so it won't detect breaking changes between 2
    components immediately. Such change needs to wait for next I-Build
    to be cascaded to other components using them.
 
 
 Cheers,
 
 |