September 11, 2008

Attendees: tef, Tom, Elaine, Greg, Eric, Conrad

New Action Items

• Al will decommission SGI after the next Chimera production release
• Al will install stereo-capable workstation to replace SGI before decommissioning SGIs
• Greg will check on SGI activity (both spinoza and euler)
• Eric will notify Ed Pate that SGI files need to be backed up manually
• Greg will provide time line on OpenGL preference panel (item 2c)
• Scooter will walk through a tree forking scenario with CVS (item 2d)
• Tom will contact Sebastien about utility of Volume Series

Action Items from previous meetings

• tef will contact Miracube to see if we can get a LCD stereo panel for testing
• tef will contact Adobe for more information about embedding 3d graphics in PDF documents
• Conrad will fix daily build script to copy app and build tree to desktop machines
• Scooter will investigate what wiki technologies are suitable for (internal?) use by Chimera team
• Greg will implement OpenGL-feature-usage interface

Minutes

1. Action item questions
   1. Conrad asked whether copying build trees to development machines should completely replace or simply overwrite existing files. Consensus is to wipe out the old tree and install the new tree.
   2. tef asked whether Ed Pate was notified that SGI files will need to be moved manually. Tom suggested that SGI files be backed up to socrates, but others said that no one (other than Pate) uses SGI. Greg mentioned that Sali group uses SGI to build software. Greg will check on activities on SGIs and report back. Eric will send e-mail notifying Pate.
2. Select verion of Aqua build for candidate status.
   1. As Al mentioned in e-mail, the new low-end test machine reproduced many of the symptoms in Chimera bug reports. Greg was able to fix or work around driver bugs so that the latest version of Chimera will run on the test machine "out of the box." Greg suggested that a new Windows production release be made to reduce the number of bug reports related to this problem.
   2. It was agreed that we make a new production release for all platforms. This eliminates the "different version on different platform" issue for Aqua, which will remain a candidate release. IRIX and Tru64 can also be retired on a production release rather than having a subsequent daily build with bug fixes.
   3. It was agreed that having the OpenGL preference panel in the next release would be a good thing. Greg will provide a time line for implementation at next meeting.
   4. Conrad suggested that we use this opportunity to test out the proposed CVS tree-forking when making production releases. The tree should be forked when we are ready to make candidate releases. Subsequent bug fixed will need to go into both the release branch and the development branch, while improvements will only go into the development branch.

3. Go over list of features to be removed or improved.
   1. Eric suggested that a new criterion be added. List below has been reworded so that a low score favors removal and a high score favors improvement for all criteria:
      • Is this feature simple and low/no effort to maintain?
      • Is this feature providing some unique and useful capability?
      • Will many users notice the removal of this feature?
      • Is this feature well-implemented and complete? + How much effort is it to remove this feature?
   2. List of features was evaluated. First a vote is taken to see if there is consensus whether a feature should be on the "Remove" or "Improve" list. Putting a feature on the "Remove" list does _not_ mean immediate removal. After the "Remove" list has been constructed, we will follow the removal procedure agreed upon in previous meetings (eg sending e-mail, waiting for replies, etc). Features with no consensus decisions are evaluated and will be placed into list later. Evaluations are listed below as five letters, Low-Medium-High, for each criterion listed above.
      • Nucleotides
        • Consensus: Improve by integrating with sessions.
      • Auto-generated Programmer's Guide
        • Consensus: Remove
      • Lenses/Lens Inspector
        • Evaluation: LLLMM
        • Code at C++ layer is extensive.
      • Surfnet - Interface/Selected Atoms
        • Consensus: Remove
      • ResProp (just the coloring part)
        • Evaluation: HLLHM
      • Model Loops
        • Consensus: Remove
      • PseudoBond Reader:
        • Consensus: Keep (no changes needed).
      • Demo Editor/Demos:
        • Evaluation: MMMML
        • Not used much for creating demos but good for showing Chimera functionality.
      • Phantom Force Feedback
        • Evaluation: LMLML
        • (See item 2c)
      • Resolution: high/low in Side View dialog
        • Consensus: Remove
        • Low resolution not available for anything but molecules and high resolution is often needed for adjusting clip planes
      • Delphi Controller
        • Consensus: Remove
        • (See item 2c)
      • Volume Series
        • Tom will contact Sebastien.
      • Chimera/Mesa (headless)
        • Consensus: Improve
      • FreeBSD port
        • Consensus: Remove

Meeting ended before other features were discussed.

• Tom mentioned that many features that he wants removed are really experimental/exploratory features. They are useful for demonstrations (eg Phantom, head tracking) but are not really useful to general user community (eg lack of hardware, platform limitations). These features take up menu space and often confuse/frustrate users who try them out. Eric mentioned that even though novice users may find some features confusing, experienced users may really like them; for example, Rachel Karchin uses DelPhi Controller and probably would be disappointed if it were removed. Conrad suggested having a way of installing features by querying remote repository but Tom believes that's still too much effort for local demonstrations (since one would have to reinstall for each release). Greg(?) suggested that the features be included in releases, but that we add a "Show in Menus" column to the extension manager; questionable features are hidden until user explicitly enable them via the extension manager. (Along similar lines, after the meeting, Tom suggested labeling the questionable features as prototypes and ask the user when they first run Chimera whether they want to enable prototypes.) No consensus/decision was reached.