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.


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.


This message was sent using IMP, the Internet Messaging Program.

Reply via email to