[Insight-developers] A Contrib group?

Thu Jan 16 10:18:00 EST 2014

Matt,

What were the problems with the non-Modular Review directory?
- It was too big, and un-organized. A Group with modules under it should help to maintain order, and no monolithic directory.
- It was all or nothing. When enabled you got it all. The modularity for being able to toggle Contrib module on and off should help.
- There was the expectation that there were resources available to review, edit, migrate, and maintain the contributions into ITK "proper", that is you code wasn't truly in ITK yet.
-?others?

In many ways my thoughts on a proposed Contrib module would just be a modularize Review directory, but with the expectation that the original author/community have more responsibility for maintenance.  Additional, it needs to be clear that once in the Contrib group IT IS IN ITK and there is a responsibility that come with that, as oppose to some limbo gateway/sandbox state.

In contrast to the "Remote" group. This seems to focus on where the code is, more so than anything else. As the current infrastructure (gerrit, cdash) better supports code inside the main repository, it is better to leverage this infrastructure so that more eyes can easily look at the contributed code as it comes in. The remote modules make a of sense for when the module is a large body of code that needs a lot of user improvement/changes that shouldn't need to go through gerrit.

Brad K:

The fundamental problem with the current approach is that these contributed modules are not reviewable in gerrit, are no automatically tested in gerrit, and are not tested in the dashboard.

Additionally, the other other goal it to have users have sense of ownership and responsibility for the code contributed and reduce the limited maintenance resources.

Also, everyone things there code is great and thinks it should get into ITK. With the current nebulous Community lead approach no direction or editorial leadership can occur.

The primary goal of the "Contrib" group was to provide an easy way to add additional ctest cycle on just this group, to provide software quality services.

Brad

On Jan 15, 2014, at 5:40 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:

> Hi Brian, Brad,
> 
> Yes, there is definitely room for improvement in the module dashboard
> coverage, Remote and otherwise.  I think it would be good to add CTest
> scripts, documentation, and builds to improve the dashboard coverage
> for these.  The ITK repository "dashboard" scripts can be updated.
> The Gerrit CDash at Home broker can be tweaked to detect changes in these
> modules and make sure they are turned on in the build.
> 
> An Contrib Group is a neat idea.  What is the difference between this
> and Nonunit/Review though?
> 
> Thanks,
> Matt
> 
> On Wed, Jan 15, 2014 at 1:51 PM, Brian Helba <brian.helba at kitware.com> wrote:
>> Here's an inventory of modules that have EXCLUDE_FROM_DEFAULT in their
>> module configuration, organized by their group. Note that group membership
>> is purely a function of directory location, and not something that's
>> explicitly specified in a CMake file.
>> 
>> Also note that if a module contains an "itk-module-init.cmake" file, then it
>> is still not enabled even if its respective Group_* option is enabled. These
>> _should_ be "bridge" modules that require system-installed third-party
>> libraries [1]. These modules can only be enabled by directly enabling their
>> respective Module_* option. These are indicated in the list below with a
>> "*".
>> 
>> Finally, note that while Module_ITKGDCM and Module_ITKOpenJPEG are flagged
>> as EXCLUDE_FROM_DEFAULT, they are typically enabled as dependencies of
>> Module_ITKIOGDCM, which is a "default" module.
>> 
>> Group_Bridge
>> *Module_ITKVtkGlue
>> Group_Compatibility
>>  Module_ITKDeprecated
>> *Module_ITKV3Compatibility
>> Group_IO
>> *Module_ITKIODCMTK
>> *Module_ITKIOMINC
>>  Module_ITKIOPhilipsREC
>> Group_Nonunit
>>  Module_ITKReview
>> Group_Segmentation
>> *Module_ITKLevelSetsv4Visualization
>> Group_ThirdParty
>> *Module_ITKDCMTK
>> *Module_ITKGDCM
>>  Module_ITKMINC
>> Module_ITKOpenJPEG
>> Group_Video
>> *Module_ITKVideoBridgeOpenCV
>> *Module_ITKVideoBridgeVXL
>> 
>> Group_Remote (there is no CMake option for this group)
>>  Module_LesionSizingToolkit
>>  Module_MGHIO
>>  Module_SCIFIO
>>  Module_SmoothingRecursiveYvvGaussianFilter
>> 
>> [1]
>> http://itk.org/gitweb?p=ITK.git;a=commit;h=8170063fa0832003974f1066313b48016253cae1
>> 
>> 
>> 
>> On Wed, Jan 15, 2014 at 9:23 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
>> wrote:
>>> 
>>> Hello,
>>> 
>>> I would like to propose that we need a Contrib group.
>>> 
>>> There has been recent push to migrate many contributions into remote
>>> modules. I believe this is premature.
>>> 
>>> A remote module is a good solution for medium to large contributions which
>>> are maintained by contributors. However, the current system does not
>>> leverage CDash or Gerrit. There is no easy way to review and comment on
>>> remote module code. Gerrit can not do builds for cross platform testing, and
>>> the night build systems does not easily test these modules. Yes, the module
>>> can be enable in certain cases, but this is not a sustainable practice.
>>> 
>>> Also for smaller contribution of just a class or two, the burden of code
>>> maintenance in increased when compared to just having it in the repository.
>>> 
>>> I would like to propose that we create a Contrib group, were these
>>> contributed remote modules and internal modules can exist. The goal here is
>>> that users can more easily turn on all the contributed modules if needed.
>>> Also I believe it would be do able to an option to our nightly build script,
>>> so that after the normal build a separate
>>> configure/build/test/coverage/submit can be done on the group.
>>> 
>>> This is my initial thought how how we can improve the current situation
>>> before it gets too unmanageable.
>>> 
>>> 
>>> Brad
>>> _______________________________________________
>>> 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
>> 
>> 
>> 
>> 
>> --
>> Brian Helba
>> Medical Imaging
>> Kitware, Inc.
>> 
>> _______________________________________________
>> 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
>> 
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/community
>> 