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?
