This message lacks of courtesy, therefore I do not wish to continue the
discussion.

I’ll proceed as I explained in my previous message.

Or maybe it’s just me not being a native English speaker...


Vincent


Glenn Adams wrote:
> Inline below.
> 
> On Wed, Aug 11, 2010 at 7:45 PM, Vincent Hennebert 
> <vhenneb...@gmail.com>wrote:
> 
>> Suppressing all the warnings at build time is a great goal that I would
>> love to see achieved eventually. This gives us an automatic way to spot
>> violations introduced in new code, which is better than the informal
>> check that developers do (or not...) before committing. But as I said
>> trying to achieve that goal now is premature.
>>
>>
> once again, i disagree with your reasoning; i heard unanimous support for
> this patch from other commenters, your reticence does not seem warranted;
> Jeremias and Simon have both stated their support for taking action to clean
> up the code base;
> 
> it is not premature to rid the codebase of warnings; in fact, one might
> argue that it was premature to release FOP 1.0 with the existing warnings;
> 
> 
>> More or less everyone agrees that the current checkstyle file is not
>> satisfying. Jeremias says that he doesn’t apply some rules sometimes.
>> I’ve done the same myself in a few occasions. So new warnings are bound
>> to appear shortly after this patch is applied.
>>
>>
> to translate lack of satisfaction with the current checkstyles to mean lack
> of acceptance is unwarranted; there have been no objections to it as far as
> I can tell, so it is effectively accepted; I haven't heard you or others
> proposing any concrete chantes to it, so it is accepted by lazy consensus;
> moreover, you appear to believe (wrongly in my opinion), that there could
> exist some future checkstyle rules set that was uniformly satisfactory to
> all; that will never happen, and for you to claim it should occur before
> taking action is nothing more than an excuse to delay taking action;
> 
> 
>> Once we agree on a new checkstyle file two things will happen: Some
>> rules may be removed and that may result into clutter CSOK comments in
>> the code; Are you happy to re-visit the code and remove them afterwards?
>> Some new rules may be put in place and that will result into a whole
>> bunch of new warnings, and we’re back to square one.
>>
>> Globally disabling some Checkstyle rules by using CSOFF comments is not
>> an option to me. This kills the very purpose of a Checkstyle file, which
>> is to have a consistent coding style within the project and no
>> distracting variations.
>>
> 
> who said anything about using CSOFF to *globally* disable options? warning
> suppression is a reasonable tool when used with appropriately, and
> developers should be able to override rules as needed; the fact that the
> comment remains in the code means it is easy to audit for these, and use
> that information to evaluate divergence from norm and practice;
> 
> 
>> We’ve been living with loads of Checkstyle warnings for years, now what
>> is this sudden urge to wipe off them all? If the goal is to achieve and
>> enforce zero warning, then I don’t think this is doable in the short
>> term. If the goal is to improve the quality of the software, then
>> I don’t see how putting unhelpful javadoc comments or even disabling
>> Checkstyle in some places will allow to achieve that.
>>
>>
> You say it is not doable in the short term, but it would take you no more
> than five minutes to apply and commit this patch. Instead of offering
> excuses, why don't you actually do something about it to help matters.
> 
> As for improving quality, if you walk into a house that is infested with
> fleas, do you stop to wonder at the quality of the furniture? FOP is
> infested with fleas. Let's exterminate them and move on to other matters. Or
> would you rather sit with them and scratch all day?
> 
> 
>> Anyway, from the quick look I’ve had at the patch, there are a few
>> things I don’t agree with:
>> • some methods marked deprecated were removed: this can’t be done
>>  arbitrarily and must follow some policy. Maybe this is fine in the
>>  present case but that must be discussed first.
>>
> 
> why? what policy was followed to deprecate them in the first place? why were
> methods marked deprecated and then no alternative provided? why were
> deprecated methods left in place that are no longer referenced? if there are
> deprecated methods that are no longer referenced or the code that references
> them is dead code, then they can and should be removed? how is this
> different than removing old unused renderers? is there a "policy" for
> removing old renderers? let's not invoke "lack of policy" as an objection
> when you independently take action as a committer yourself in cases that
> lack policy...
> 
> 
>> • the @deprecated annotations that were on some other methods were
>>  removed: there’s a reason why they were there, which is to warn
>>  developers that those methods shouldn’t be used in new code. If the
>>  @deprecated annotations must be removed, then they should at least be
>>  replaced with an appropriate warning in the Javadoc.
>>
> 
> methods should not be deprecated unless there is a documented and
> implemented alternative; this was not the case in certain of these
> deprecations; if you feel that a specific deprecation should stay in place,
> then argue its case here; don't just use this as a broad brush to reject the
> entire patch;
> 
> 
>> • before removing checkstyle-4.0.xml we must make sure that all the
>>  developers are happy with upgrading their tools to Checkstyle 5. This
>>  will probably be the case but still, that should be done at least
>>  through lazy consensus.
>>
> 
> why? the existing checkstyle build rules had already been updated to refer
> to CS 5 before this patch, so it is an unused and unneeded file; why wait to
> remove dead files?
> 
> 
>> I will have a closer look at the patch and will apply the
>> non-contentious parts. The rest will need to be discussed first.
>>
> 
> I believe that is the wrong way to handle this patch. It should be applied
> as a whole, then, once done, we can revisit specific issues, but only if
> there is a viable reason to do so.
> 
> 
>> I think rushing things will just go against the honourable goal of
>> improving the quality of the software.
>>
>>
> They say justice delayed is justice denied. The FOP code demands justice.
> And so do prospective developers. You seem to be laying artificial hurdles
> into the path of contributors who are trying to make valuable improvements.
> Why would you do that? What is the benefit of delay?
> 
> Regards,
> Glenn
> 

Reply via email to