xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Adams <gl...@skynav.com>
Subject Re: FindBugs exclusion policy proposal (was: Re: junit tests in nightly builds etc.)
Date Fri, 25 Feb 2011 00:57:57 GMT
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 <
andreas.delmelle@telenet.be> 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
> ---
>
>

Mime
View raw message