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 > > > > > > 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 > > > > Jeremias Maerki
