This is a heads up -- I will be submitting a patch in a few hours that
corrects all outstanding compilation, javadocs, and checkstyle warnings,
which together produced about 2200 warning and error messages. This patch
changes around 400 files, so it is pervasive. It also incorporates the prior
patch I had previously posted for compile warnings only (Bug #49700). I have
already obsoleted the patch file attachment there in favor of the one I am
preparing to post.

I recommend that CTR policy apply in order to merge it into to fop/trunk as
quickly as possible in order to not interact with other mods.

Note that one compile warning wiill remain (a deprecation) until my recent
patch to xmlgraphics-commons is merged and a new build of commons is used
with fop builds.

G.

On Wed, Aug 4, 2010 at 8:20 AM, Glenn Adams <gl...@skynav.com> wrote:

> I don't plan to do any refactoring, just fixing warnings. The point of this
> is to be able to easily find new warnings introduced, and doing so is quite
> impractical with the current number of extant warnings. If we can get to a
> state of no warnings, then perhaps we can attempt to maintain that state of
> affairs for future commits, at least on the trunk.
>
> G.
>
>
> On Wed, Aug 4, 2010 at 6:30 AM, <spepp...@leverkruid.eu> wrote:
>
>> We have two outstanding branches. All changes you make in this work will,
>> after they have been merged into trunk, be propagated to those branches. I
>> would prefer to restrict the work to the new functionality, and not include
>> other refactoring/correction of warnings. Although I admit that correcting
>> warnings would in itself be very valuable; I guess most warnings were just
>> neglected by their authors, or are in older code.
>>
>> Simon
>>
>>
>> Quoting Glenn Adams <gl...@skynav.com>:
>>
>>  Would anyone mind if I submit a patch that fixes all the outstanding
>>> warnings, etc., reported during the build process and by checkstyles and
>>> findbugs on the trunk? More importantly, if I do this, is it possible to
>>> adhere to a zero tolerance policy on warnings for future commits?
>>>
>>> I find the 3000 or so warnings currently produced to be a rather
>>> significant
>>> impediment to doing work on this code base, or at least, in preventing an
>>> avalanche of new warnings upon future commits, given the trouble required
>>> to
>>> determine the diffs between new warnings and old warnings. Perhaps this
>>> isn't a problem for changes to one file, but for changes to a hundred
>>> files,
>>> it is a major headache. Anyway, some of these 3000 are actually real,
>>> lurking bugs.
>>>
>>> I'm willing to do the cleanup work if others will help maintain
>>> cleanliness
>>> going forward.
>>>
>>> Regards,
>>> Glenn
>>>
>>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>

Reply via email to