Hey all, I brought this up in jira (HBASE-5589) and stack suggested posting to dev@, so here's a proposal
Currently we are somewhere around the 770 warnings/errors mark on trunk, and our hadoopqa bot will soon start complaining again as code gets checked in. Since many patches in flight and since it may be a bit onerous for committers to enforce a no new findbugs policy right away, what do you all think about committers enforcing a no-new-findbugs errors policy on reviews once this we finally get the findbugs warnings to 0? To knock down the findbugs violation number, we should probably chop this into subtasks to break down the workload. Ideally we'd first fix warnings/errors, and then for remaining spurious warnings (like System.exit in some tools), we use an excludes file as opposed to marking up code with findbugs-specific annotations since this may require the inclusion of a GPL licensed jar. (On a previous project, the findbugs annotation jar was GPL'd which causes license problems, maybe different now). Sound good? Jon -- // Jonathan Hsieh (shay) // Software Engineer, Cloudera // [email protected]
