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.
>>
>
>

Reply via email to