I believe English has more words than any other language, which is why they say it's the easiest language to learn and the hardest language to master. I would think warnings like calls to deprecated methods should be fixed asap. Other warnings like dead code and unused variables I would guess were left in for future reference, such as methods planned to be added later or methods removed leaving code in place in case they need added back in later. These should be removed if there's another way to document notes for potential future enhancements. If they were just sloppy coding, putting in or leaving in stuff that has no reason to be, I agree with Glenn it should be cleaned out. While high quality might refer more to making a program that does what the users need and doesn't crash, I'd agree coding should still need some "standard of quality" to include error free code. It could discourage new developers from joining the project if they get a copy of the Trunk and see all those warnings even if it does run despite them.
-----Original Message----- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Tuesday, August 10, 2010 9:09 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc warnings Well, I'm not a native English-speaker, so maybe my choice of the word "rant" was too much. Anyway, Glenn, we're not too far apart. I try to remove warnings whenever I change a class, i.e. gradual improvement as time allows. Sometimes CheckStyle would bark at something that I didn't consider a problem so I ignored it. That's why I mentioned that fine-tuning CheckStyle is probably a good thing. From time to time, people would fix a bunch of classes, but a thorough attempt such as yours hasn't happened, yet. So this is a chance for us and your work is definitely appreciated. I don't think we've had any voice, yet, who said that fixing the issues was a bad idea. On 10.08.2010 14:46:28 Glenn Adams wrote: > my apologies if my statement appeared to be a "rant", as it was not > intended as such; > > perhaps my emphasis was an exaggeration, but if one goes through the > trouble to add build rules for style checking, bug finding, and code > quality reporting, then it does appear odd to ignore them, which was > my reaction to the current code base and vincent's response; > > i admit that i prefer a zero warning policy, and i have attempted at > every opportunity to introduce or enforce such policy on the many dev > projects I've managed or participated in over four decades; in > general, i find it helps me and other devs, particularly as a way of > finding new noise we are introducing; if there is already a lot of > noise in the system, it is easy to ignore new noise, which is > precisely what i would like to avoid in my own > contributes: contributing to the noise level; > > note that i am not arguing for or against a specific set of policy > rules, just that whatever they are, they get implemented and enforced, > while knowing at the same time that every rule has exceptions, and > that mechanisms to provide filtering adequately address this point; > furthermore, arguing over which a particular exception is justified or > not can become a great waste of time; as I've stated previously, if a > contributor or committer has made the conscious choice to disable a > warning, then I'm happy to accept their judgement, as long as it is > done in a thoughtful way, and not merely as a way of ignoring rules; > > if the majority of committers feel it best not to patch these warnings > and move on from there, then i'll readily submit to that consensus; my > hope, however, is that this contribution can positively contribute to > FOP and the community, so it is natural that I would prefer it not be > delayed for some unknown process to create a "new consensus" on style > rules; > > regards, > glenn > > On Tue, Aug 10, 2010 at 8:07 PM, Jeremias Maerki <d...@jeremias-maerki.ch>wrote: > > > I kind of agree with Glenn that we have a de-facto agreement on the > > Checkstyle rules. We've adjusted them in the past and there's no > > reason why we can't change it in the future. If Glenn's patch gets > > the issue count down significantly so we can start to enforce the > > rules, then I'm fine with it. But I don't doubt that the checkstyle > > file may profit from some fine-tuning. > > > > Right now, I have a couple of things that I need to commit and I > > basically don't dare commit them as people may come screaming at me > > in that case. So I want this resolved quickly. Vincent, are going to > > process the patch? I have to do a few things first, but if you don't > > have a chance to handle it by then, I'll take a look myself. > > > > What I have a little problem with is Glenn's rant in the last paragraph. > > Some Apache project don't even have Checkstyle rules. Furthermore, > > having no Checkstyle issues doesn't equal high quality. High quality > > is the result of an open process of developing software (The Apache Way). > > There are no rules that we have to implement any particular > > technical measures. But I'm not saying that Checkstyle doesn't help > > improve quality. Then what is "high quality"? And we have to > > acknowledge that over time, many people with different skills and > > coding styles have been working on FOP and limited resources don't > > always allow the maximum possible. > > > > On 10.08.2010 13:13:08 Glenn Adams wrote: > > > Vincent, > > > > > > I disagree with your proposed delay. First, there is an > > > established consensus on the rules, namely those that are in the > > > existing checkstyle-5.0.xml file. The reason they are the current > > > consensus is > > that > > > they are there in the trunk, and nobody has objected to them. I do > > > not > > care > > > to object to them at this time, and merely applied them as they stand. > > > > > > I did nothing to change those rules in my patch, and saying that > > > you wish > > to > > > effectively delay incorporating the patch until there is a > > > consensus > > about > > > what is there already appears rather odd, if not counterproductive. > > > > > > What is most important overall is to eliminate all warnings. > > > Period. As > > fast > > > as possible. My patch does that, so please commit it without > > > delay. We > > can > > > then, over time, decide if the existing rules are overly > > > conservative or overly liberal. But that is not going to be a > > > useful way to spend our > > time, > > > it is much better to just use what is there, and when something > > > goes > > outside > > > of that set, there are adequate mechanisms to deal with it, which > > > I described in my patch. > > > > > > The alternative is to merely continue to propagate the current warnings. > > > Frankly, I was and am very surprised at the apparent lack of > > particularity > > > with respect to treatment of warnings. One of the six principles > > > of "The Apache Way" is "consistently high quality software". For > > > me, every > > warning > > > is a black mark against quality. Let's not continue to propagate > > > this > > state > > > of affairs. Now that FOP 1.0 has been released is the best time to > > > move forward, so why delay now? > > > > > > Regards, > > > Glenn > > > > > > > > > On Tue, Aug 10, 2010 at 6:34 PM, <bugzi...@apache.org> wrote: > > > > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=49733 > > > > > > > > --- Comment #5 from Vincent Hennebert <vhenneb...@gmail.com> > > 2010-08-10 > > > > 06:34:29 EDT --- > > > > Hi Glenn, > > > > > > > > Thanks for your patch. However, as I said we need to agree on a > > > > project-wide Checkstyle configuration first. Before enforcing a > > > > no-warning policy it > > is > > > > necessary to reach consensus among all the developers on a set > > > > of rules that everyone is happy to follow. > > > > > > > > We'll have a look at your patch once this is done. Meanwhile, > > > > I'll look > > at > > > > the > > > > parts that fix compilation warnings. > > > > > > > > Thanks, > > > > Vincent > > > > > > > > -- > > > > Configure bugmail: > > > > https://issues.apache.org/bugzilla/userprefs.cgi?tab=email > > > > ------- You are receiving this mail because: ------- You > > > > reported the bug. > > > > > > > > > > > > > > Jeremias Maerki > > > > Jeremias Maerki
