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 <[email protected]> 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 >> <[email protected]>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 <[email protected] >> > >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 < >> > > > > [email protected]> 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 > >
