It seems to me the following: Glenn, perhaps you could submit a separate de-warning patch or patches against trunk. That could be reviewed, applied, and downmerged into the complex script work. That might make this more manageable to the committers. I would also respectfully wonder if diffing the build output before and after your patches might be sufficient for your purposes.
On Tue, Aug 3, 2010 at 8:20 PM, 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. >> > >