ah, in that case, I wonder who would oppose a policy to use checkstyle
and findbugs prior to commits in order to maintain a zero warnings
state? and if opposed, then a rationale for that position?

/g

On Friday, February 25, 2011, Jeremias Maerki <d...@jeremias-maerki.ch> wrote:
> It hasn't occurred, yet, but I expect one to happen if we were to
> install a new policy. I'm just predicting a possible outcome. ;-)
>
> On 25.02.2011 16:57:25 Glenn Adams wrote:
>> 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
>> > > > Jeremias Maerki
>
>

Reply via email to