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? cheers, Colin On Sun, Sep 13, 2015 at 6:58 AM, Steve Loughran <ste...@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 does. > > 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?
