Possibly a vote to establish such a policy falling through. Just a hunch.

On 25.02.2011 08:09:11 Glenn Adams wrote:
> Well then, let's make it a policy. What's preventing that?
> 
> On Thu, Feb 24, 2011 at 11:07 PM, Simon Pepping <spepp...@leverkruid.eu>wrote:
> 
> > 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.
> >
> > Simon
> >
> > 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 <
> > > andreas.delme...@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
> > > > ---
> > > >
> > > >
> >




Jeremias Maerki

Reply via email to