hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravi Prakash <ravi...@ymail.com>
Subject Re: [DISCUSS] fixing jenkins; policing the build
Date Mon, 14 Sep 2015 21:03:14 GMT

With regard to the unit test failures, maybe it's time for another fix-it day?

     On Monday, September 14, 2015 1:50 PM, Colin P. McCabe <cmccabe@apache.org> wrote:

 I think building on Jenkins with jdk8 (even with source version = 1.7)
would help prevent the jdk8 javadoc failures from creeping in.

With regard to the unit test failures, maybe it's time for another fix-it day?


On Sun, Sep 13, 2015 at 6:58 AM, Steve Loughran <stevel@hortonworks.com> wrote:
> Jenkins is pretty unhappy with the build ... its slowly been collecting patched (including
one i put in) triggering test failures, and we've all been lax about fixing them. They're
often pretty minor -as an example. trunk has been breaking on java 8 with javadoc errors.
> I don't know what others think, but I personally think we need to be a lot more focused
on keeping the build happy. This is alongside the Yertus work: that improves how we build;
I'm more interested in the process of not breaking the build —and addressing it when it
> If we were really ruthless, we'd be strict about reverting any patch that triggers a
failure. And maybe even halt all other commits until jenkins is happy. That's pretty brutal,
but it certainly gets people to care.
> A less ruthless but stricter-than-today policy could be
>  1.  Build failures are filed on JIRA @ critical or blocker. They need to take priority.
>  2.  Patches that fix it get priority over everything else: don't be afraid to ping
people to keep that build up.
>  3.  We should recognise that trunk will be java8+ only, and even if don't (yet) switch
the source to being java8, the jenkins scheduled builds should go to java8+. That way, we
can't ignore java8+trunk failures, and don't have to worry about java7 & trunk.
>  4.  Anyone who is a committer can get the login for builds.apache.org<http://builds.apache.org>
to trigger rebuilds; It lets you do a quick verify that the full builds are happy.
> Thoughts?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message