Did I miss seeing such a vote? Could you give me an approximate date when it
occurred so I can check the archives for background?

Even if it failed to obtain consensus in the past, doesn't mean it might not
be accepted now.

G.

On Fri, Feb 25, 2011 at 4:32 AM, Jeremias Maerki <d...@jeremias-maerki.ch>wrote:

> 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