VTK/ARB/Meetings/October 2009

Meeting Times

Name	Time Zone	Local Time
	UTC	2009-Oct-01 14:00:00
Will Schroeder	EDT	2009-Oct-01 10:00:00-04:00
Berk Geveci	EDT	2009-Oct-01 10:00:00-04:00
Jeff Baumes	EDT	2009-Oct-01 10:00:00-04:00
Bill Lorensen	EDT	2009-Oct-01 10:00:00-04:00
Steve Pieper	EDT	2009-Oct-01 10:00:00-04:00
Andrew Maclean	AEST	2009-Oct-02 00:00:00+10:00 (Midnight Oct 01/02)
Jim Ahrens	MDT	2009-Oct-01 08:00:00-06:00
Brian Wylie	MDT	2009-Oct-01 08:00:00-06:00
Claudio Silva	MDT	2009-Oct-01 08:00:00-06:00
Paolo Quadrani	CET	2009-Oct-01 16:00:00+02:00

Agenda

• Welcome
  • Thanks to all ARB members for their participation
  • 10 individuals from academic, national labs, commercial and retirement communities
  • representing North and South America, Europe and Australia

• Purpose and Goals
  • See the ARB Description
  • Focus on larger strategic issues
  • Address critical technical decisions
  • Foster the growth of VTK
  • Manage the growth of VTK
  • Communicate to the broader VTK community

• Process
  • Most of the work via email/wiki
  • Hold Periodic meetings
  • We are all busy, do not worry about making every TCon

• Discussion Points
  • Organizing for growth (Will Schroeder)
  • VTK Journal (Will Schroeder)
  • Add UserVoice site to VTK
  • Move to SVN

Notes

• Welcome. VTK has grown without a lot of supervision. Has not "settled down", instead there is an explosion of development. Need to manage growth, focus on strategic vision. Communicate to the VTK community.

• Need to manage growth. People have tools they want to contribute to VTK. Create a layered approach to incorporate code from the community, somewhat like Insight applications. Proposes three layers

• Core - tested
• Other contributions, important to VTK - also tested
• Dump anything they want - not tested or validated

• Insight brings code from a journal article to a review stage where things are tested. Assign shepherd to move it into ITK. Run into a bottleneck, a few hundred classes in review, some have been there for several years. People can take it out of the review sandbox and use it directly. It has kept new things from getting into ITK.

• From Kitware perspective, funding from places like Sandia need quicker turnaround time for incorporation in VTK. Need something like ITK Journal if just to communicate documentation to the community.

• How would VTK Journal be different from a Wiki? Discussing new features is better on a wiki.

• Need to enforce some discipline.

• VTK is different from ITK. What are the specific qualities of the VTK development community? Other toolkits have a loose affiliation page that people like.

• Not concerned about slowing down development, more concerned about organizing documentation. Concerned about VTK becoming the "kitchen sink". For example, text processing. Pulling in more external dependencies also an issue.

• Need to define the core of VTK.

• Don't make it become like VXL with lots of libraries that are not compatible with each other. This happens to some extent with VTK with other repositories.

• Don't want to check out everything then choose what to compile. Instead there should be something like "modules" like linux packages that can be queried based on what is needed in a particular application.

• To do this would need a cleanup of dependency structure of toolkits in VTK.

• Explained uservoice service. It allows you to vote for features.

• Action item - Consensus is that we try out uservoice with VTK. Berk and Will will work on this.

• Discussion about moving from CVS to SVN.

• With version control, keeping things in separate packages will introduce the issue of synchronizing revisions between repositories. This is simple with CVS with symbolic linking on the server side.

• A distributed version control system may be more suitable for this tiered model that was proposed. Mercurial is a good option for supporting all operating system well.

• SVN has worked well for Slicer. Could start with an SVN mirror, but .

• Reorganize wiki, develop communication.

• Who are the main VTK users? Update the list on the wiki, determine main contact. Contact them to find out what they are using, what version, affects of API changes?

• Find tools that we can consider a model, provide links to other tools and what they do.

Next time

• Discuss what compilers should and shouldn't be supported.

• Discuss topic leads.