Hello Mathieu, thanks for continuing to have a useful discussion.
> You found a bug in A (ginkgocadx), That is correct - in a way. I found a bug when using A on Debian. I then went upstream and used their static binary of A compiled for Debian. That binary worked. This meant that the bug lies in "the Debian variant of A". Nevertheless I reported the bug to A-upstream because just because it doesn't happen in upstream doesn't mean it doesn't _exist_ in upstream. > which uses B (ITK) which in turns uses C (GDCM). > Upstream for A says: "this is not our fault it is somewhere in B or C". I agree with you here. I would assume upstream decided that they don't want to afford searching for a bug in a non-upstream variant of their code. Good or bad -- it is their decision. > I believe somewhere in between A or B there is a missing link to > report *exactly* what is wrong with C. You are correct. That missing link would probably be me because I am a user who wants to use A but in conjunction with a version of B and/or C which A-upstream doesn't directly support. However, I lack the skills to nail the problem myself. Therefore I went A-upstream and asked for details. I then reported what I got as a response. I agree this response would be a lot more helpful if A-upstream pointed out the exact issues they had with in-Debian B and/or C. > In summary yes I expect a bug report for C to be somewhat minimalist, > but don't ask me to use A -> B -> C to dig a bug somewhere in A. The > chain as I see it is that either someone from A or B is capable of > reporting a reduced test case for C. So, in effect, A (or me equipped with information gotten from A) should report a bug against B (ITK). Then B (or me, equipped with information gotten from B) would report a bug against C (GDCM). Or else A would provide information on the exact problem against C in which case B can be skipped. Now, since A doesn't seem to afford the resources to help us find bugs in our use of their code I guess we are stuck. In short: Debian doesn't have a DICOM viewer suitable for clinical care. Which is a great pity. BTW: I do acknowledge that Dmitry has at least tried to reproduce the problem. BTWBTW: I also know that all of you guys volunteer your time. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
