[Insight-developers] Update on DICOM

[Jean-Christophe Fillion-Robin]

Matt,

Within CTK, we are applying the strategy you just described and it allows
us to contribute upstream very easily.

Jc

On Fri, Dec 23, 2011 at 1: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/README-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
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20111223/07ab9e74/attachment.htm>