[vtk-developers] Dashboard test failure question

[David Gobbi]

Well, yeah, the dashboard became green because the tests had been
modified to use SetNumberOfThreads(1) so that the bug didn't show up
on the dashboard anymore.  I guess that overall, it's just an instance
of miscommunication.

I've marked the bug as "won't fix".

On Fri, Jan 17, 2014 at 12:29 PM, David E DeMarle
<dave.demarle at kitware.com> wrote:
> I marked it as fixed because I was told it was and because the dashboard
> stopped showing the issue at about the right time.
>
> Won't fix or Open are fine by me and I lean toward open. In any case Fixed
> is definitely not right! My fault sorry about that.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Fri, Jan 17, 2014 at 2:24 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> I understand.  However, if the bug isn't fixed and there is a very low
>> probability that it every will be fixed, it should be marked as "won't
>> fix"
>> instead of being marked as "fixed".
>>
>> So I'm just wondering how it came to pass that the bug is marked as
>> fixed, when it isn't.
>>
>>   David
>>
>>
>> On Fri, Jan 17, 2014 at 12:11 PM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>> > I'm pretty sure that did not fix the bug.
>> >
>> > We spent a lot of time on this one. The volume rendering code is old
>> > and tough to follow.
>> >
>> >
>> >
>> > On Fri, Jan 17, 2014 at 1:38 PM, David Gobbi <david.gobbi at gmail.com>
>> > wrote:
>> >> I went back to the bug report on this multi-threading issue, and oddly
>> >> enough the bug is marked as "fixed":
>> >> http://www.vtk.org/Bug/view.php?id=13420
>> >>
>> >> A note in the bug report says "Was fixed in commit: e4a793c47cc3"
>> >> But I looked at the commit, and it seems to be unrelated.  Why was
>> >> the bug closed, when the problem still exists?  Was it closed
>> >> accidentally?
>> >>
>> >>   David
>> >>
>> >>
>> >> On Fri, Jan 17, 2014 at 10:40 AM, David Gobbi <david.gobbi at gmail.com>
>> >> wrote:
>> >>> On Fri, Jan 17, 2014 at 10:07 AM, David Cole <dlrdave at aol.com> wrote:
>> >>>>
>> >>>> If that warning is true, then shouldn't any test that uses that class
>> >>>> set
>> >>>> the number of threads to 1 instead of trying to use all the cores
>> >>>> available
>> >>>> on a machine......?
>> >>>
>> >>> Bill already fixed a bunch of tests to set NumberOfThreads=1 for this
>> >>> mapper.  TestSmartVolumeMapperWindowLevel must have slipped through
>> >>> the cracks.
>> >>>
>> >>>> Does anybody really want non-repeatable results?
>> >>>
>> >>> Fixing the bug in the mapper would be the correct way of ensuring
>> >>> repeatable results: it's a multi-threaded mapper, but running it
>> >>> with too many threads causes artifacts.  In my view, the
>> >>> "SetNumberOfThreads(1)" trick is a way of sweeping the problem
>> >>> under the rug, out of sight and out of mind.
>> >>>
>> >>>   David
>
>