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.


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