[Insight-developers] Update on DICOM

[Johnson, Hans J]

Matt,

I agree with you 100%.  HDF5 should definitely be one of the first ones
for this conversion.

I prefer the ExternalProject method for items from the Third party
directory.

Hans


On 12/23/11 12:39 PM, "Matthew McCormick (thewtex)" <matt at mmmccormick.com>
wrote:

>On Fri, Dec 23, 2011 at 12:44 PM, Steve M. Robbins <steve at sumost.ca>
>wrote:
>> Hi,
>>
>> If I may butt in with my Debian maintainer hat on ...
>>
>> On Fri, Dec 23, 2011 at 12:03:54PM -0500, Brad King wrote:
>>
>>> What is your plan for moving forward when the work is ready to be
>>> integrated in ITK upstream?  Do you want to try to maintain it as
>>> a submodule?  We could try bringing in a minimal snapshot of DCMTK
>>> like we do for HDF5:
>>>
>>>
>>>http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/ThirdParty/HDF5/src/REA
>>>DME-ITK.txt;hb=v4.0.0
>>
>> I see that the HDF5 support can be built with a system install of
>> HDF5.  From a packager point of view, that is crucial.  I hope you
>> will similarly support a system DCMTK.
>>
>>
>>> This will also allow us to make ITK-specific fixes without waiting
>>> for changes to go upstream.
>>
>> Is there a vision of coordinating with packagers on these ITK-specific
>> fixes?  As long as the ITK-specific fixes don't break non-ITK
>> software, Debian can generally apply the same fixes to the Debian
>> system HDF5, or DCMTK, etc.  So it would be awesome if there was a way
>> for me to receive notifications of such.  Any thoughts?
>>
>
>I think the current third party code in the ITK repository is a bad
>policy, and bringing DCMTK in code is not a good path.  DCMTK is a
>good opportunity to start doing things right, especially since the
>DCMTK code base is so huge.  We should avoid practices that:
>
>  - Make it hard to keep up-to-date with upstream.
>  - Discourage pushing patches upstream.
>  - Inflate the size of the repository.
>  - Discourage packaging by Linux distributions.
>
>A better solution would point to a fork on Github where we have a
>branch off upstream master.  We can easily merge in master, push
>patches upstream, keep the third party code out of the repository, and
>Linux distributions can see the patches applied with a 'git log'.
>
>Git submodule or CMake ExternalProject, either method is better than
>munging it into the repository.
>
>Matt
>
>Matt
>
>
>> Thanks,
>> -Steve
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>_______________________________________________
>Powered by www.kitware.com
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Kitware offers ITK Training Courses, for more information visit:
>http://kitware.com/products/protraining.html
>
>Please keep messages on-topic and check the ITK FAQ at:
>http://www.itk.org/Wiki/ITK_FAQ
>
>Follow this link to subscribe/unsubscribe:
>http://www.itk.org/mailman/listinfo/insight-developers



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________