As before, I will generally not fix findbugs errors or warnings in
contributions by other people. I will fix findbugs errors or warnings
in code that I write, or code changes that I make.

Note that the use of the findbugs code analysis tool is not a policy
of the FOP project, and that consequently FOP committers are not
bound to use findbugs and fix its errors or warnings.


On Thu, Feb 24, 2011 at 04:57:57PM -0800, Glenn Adams wrote:
> I think the existing exclusions should be left in trunk, and that no new
> ones should be permitted in (or should be fixed immediately). If you do as
> you suggest below, then the list of findbugs errors will just continue to
> grow because nobody will pay attention to them.
> We are at a known, stable point, we do have some exclusions that we know
> need fixing, and we can do that as time permits; but let's keep it that way
> and not backpedal by allowing in new ones.
> G.
> On Thu, Feb 24, 2011 at 8:40 AM, Andreas Delmelle <
>> wrote:
> >
> > No response to any of the posts in particular, just a general
> > thought/proposal.
> >
> > I can appreciate that the ComplexScripts branch requires a clean FB report
> > so that Glenn is not continuously sent on a wild goose chase.
> > However, personally (and Vincent seems to agree), I do not favor 'blind'
> > exclusions just to make the warnings go away. Following the same reasoning,
> > we could define thousands of CheckStyle suppressions, instead of encouraging
> > people to do it correctly.
> >
> > I do not have a problem with looking into those issues, if no one else has
> > the time and/or motivation, although that will not always happen
> > _immediately_.
> >
> > The general idea is good, but I am wondering, given the circumstances, if
> > we had not better invert the approach: keep the warnings alive in trunk, and
> > add exclusions for them only in the branch.
> > That way, devs who are not involved in the branch but do use FB, will be
> > constantly reminded that those issues should be looked into. For the
> > maintainer(s) of the branch, if the exclusion is properly commented, it can
> > serve as an indication that the warning originated in trunk and has nothing
> > to do with their changes. Should a genuine bug result from it, and it turns
> > out to hamper the development on the branch, it can then be raised as a
> > priority issue on this list.
> >
> > Ultimately, it is still a worthwhile goal to eliminate all of the warnings,
> > but we also have to be realistic enough to admit that that will not happen
> > overnight.
> >
> >
> > WDYT?
> >
> > Regards,
> >
> > Andreas
> > ---
> >
> >

Reply via email to