On Thu, Jan 16, 2014 at 12:30 PM, Xiaoxiao Liu <[email protected]> wrote: > Luis, the current code flow diagram was suggested in > http://www.kitware.com/blog/home/post/557 ( in the bottom). Probably needs > some updates after the discussion.
Yes, this is a great start. What could use refinement is the definition of "hot features". Any author will tell you that their slice of code is the most important piece of code ever written. Agree with Bill L. that it is more appropriate to place sparse classes in their proper module than creating another module. At the same time, Brad L. makes good points that we want to avoid increasing maintenance burden and decreasing quality of the toolkit. And, as Brad K. and Luis point out, a second-class-citizen Review designation is proven not to work well. It would be good to have some quantifiable, well-defined, objective criteria on what new classes should be merged. A possible starting point that emphasizes increasing quality while avoiding bloat by leveraging modularity: - 84% code coverage or better - CDash@Home green - Expected Nightly green within 2 weeks - Avoids additional modules dependencies and new modules - Passes review - Avoids duplication of functionality - ... > Agree with you all that a collection of related class/filter contributions > can be submitted a remote module for fast outreach (similar to the slicer > extension modules). > A single purposed class/filter that fit into existing internal modules > should go directly to Gerrit review (does not make much sense to warp it as > a single class module to go to IJ). +1 (but we should have some good criteria). > The remote module mechanism is a great way to extend the toolkit ( similar > to the extension modules in slicer) without dividing the maintenance efforts > from the core library. > Brad (L), we could add a "remote" group cmake option to make group testing > those remote modules easier, if you think this is helpful. But the idea of > mixing remote and internal modules together in the same group does not sound > very appealing to me. There are definitely things that could be done to improve the ease of Remote Module testing. Something to keep in mind is that the Remote may have third party dependencies not present in the toolkit. > > At last, whatever strategy we agreed on in the end, don't forget to document > it well for people to refer to. Yes, definitely. The Software Guide would be a good place. Thanks, Matt _______________________________________________ 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.php 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
