[Insight-developers] [ITK Community] A Contrib group?

[Matt McCormick]

On Thu, Jan 16, 2014 at 12:30 PM, Xiaoxiao Liu <xiaoxiao.liu at kitware.com> 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 at 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