The Chimera Development Team has weekly meetings on Thursdays from 3:00-4:30 PST. The minutes of the meetings are posted below.

2008

September

Thursday September 18, 2008

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

New Action Items

• Eric will send e-mail to Craig Gough and Bo Yang Baker about retirement of spinoza and euler (item 0a)

Action Items from previous meetings

• Al will decommission SGI after the next Chimera production release
• Al will install stereo-capable workstation to replace SGI before decommissioning SGIs
• 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
• Greg will implement OpenGL-feature-usage interface

Minutes

1. Review Action Items
   1. Greg checked SGI activity and found only four users: Ed Pate (visitor), Ben Webb (MODELLER builds), Craig Gough and Bo Yang Baker. Eric reported that the last two are no longer at UCSF and will contact them regarding impending retirement of SGI machines. A stereo-capable workstation will be made available for public (Pate) use before SGIs are turned off. An Octane will be "donated" to QB3 machine room for MODELLER builds (Webb).
   2. Greg reported that the OpenGL preference panel code has been designed and will be implemented in one week. See ticket #3 for more information.
   3. Tom contacted Sebastien who said that he is actively promoting the use of Volume Series. Consensus is to keep Volume Series in Chimera for now.
   4. tef contacted Miracube and is getting a new 24" LCD panel for evaluation (will arrive in a couple weeks). Unit will arrive with two pairs of stereo glasses. If testing goes well, we will purchase the unit for a discounted price of $3,900 (list if $4,900).
   5. Scooter will discuss Wiki technology during group meeting when demonstrating Trac.

1. Discuss source tree forking mechanism (Scooter)
   1. Scooter discussed tree forking in CVS using example from: ​CVS Branch and Merge Example. The example web page has examples on how to tag a branch, switch between branches, merging branches, etc.
   2. General practice is to keep a separated checked out tree for each branch. Changes should be made on the branch where it should first appear, e.g., bug fixes in the candidate release branch and new features in trunk. Bug fixes in the branch that also need to be in the trunk can be added back using the cvs update -j release-name filename command in the trunk tree.
   3. With branching, Chimera versioning using RCS/CVS version number may produce duplicate version strings for builds on different branches. Consensus is to use a four-number versioning system (major.minor.bugfix[build]) starting with the next release. The "major", "minor" and "bugfix" numbers need to be maintained manually, while the "build" can still be from RCS/CVS. After forking the tree, the minor number on the trunk should be incremented immediately so that the branch and trunk are easily distinguishable.
   4. Upcoming release will be "1.3.0[build_no]". 1.3 was chosen because current release is 1.2540 so if you squint and only look at the first part, the "natural" small version number is "1.2"; and "1.3" comes after "1.2". The candidate release branch will be 1.3; the trunk will be updated to 1.4 after forking.
   5. The source tree will be forked for candidate release after OpenGL preference panel is completed.

Items 2 and 3 were tabled when meeting ended at 4pm.

1. Discuss test lab, viz room and public cubicle setup (Conrad)
2. Continue evaluation of features to remove or improve (All)

Thursday September 11, 2008

ttendees: 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 1c)
- Scooter will walk through a tree forking scenario with CVS (item 1d)
- 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:

0. Action item questions

0a.  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.

0b.  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.

1. Select verion of Aqua build for candidate status.

1a.  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.

1b.  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.

1c.  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.

1d.  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.

2. Go over list of features to be removed or improved.

2a. 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?

2b. 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.

2c.  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. 

Thursday September 4, 2008

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

Action Items:

- tef will contact Miracube to see if we can get a LCD stereo panel for testing (from previous meeting)
- Al will decommission SGI machines on 9/15 (from previous meeting)
- Everyone will send e-mail to Conrad indicating where Chimera app and build tree should be 
  installed on the desktop machine (from previous meeting)
- Conrad will fix daily build script to copy app and build tree to desktop machines (from previous meeting)
- Conrad will circulate candidate list of items to be removed from Chimera (item 1b)
- Scooter will investigate what wiki technologies are suitable for (internal?) use by Chimera team (item 1c)
- Tom will send list of (Aqua-specific) changes to Chimera since 1.2540 (item 2b)
- Greg will implement OpenGL-feature-usage interface (item 3)
- tef will contact Adobe for more information about embedding 3d graphics in PDF documents (item 4d)

Minutes:

1. Procedure for removing features from Chimera

1a.  Conrad suggested that after proposed list of items to remove has been agreed upon, we announce 
     the list to the user community and wait one month for feedback.  To reach the user community, 
     we send email to the chimera-users list and put up a short announcement on the News section 
     of the home page.  Items that users wish to retain will return to the candidate list for removal; 
     all other items are immediately removed after the one-month waiting period.

1b.  tef suggested that to evaluate item for removal, we assign high/medium/low for each criterion:

- Complexity of code (Will removal save maintenance effort?)
- Utility of feature (Are there other ways to do the same thing?)
- Number of users of feature (Is it important to user community?)
- Quality of implementation (Will disgruntled users outnumber satisfied users?  Will unhappy users 
  leave Chimera for another package?)

(Criteria wording will be fixed so that high/low will all point in the same direction.)  Items can then 
be sorted into two lists: "remove" and "keep".  "Remove" list may be handled according to 1a.  "Keep" 
list will be prioritized.  Higher priority items are put in the "fix/enhance" list; lower priority 
items are in the "leave as is" list.

1c.  Tom suggested that we use a wiki-like mechanism for distributed maintenance of candidate removal 
     list, feature request list, change log, etc.  Scooter "volunteered" to investigate available technologies.

2. Status of Mac Aqua release

2a.  Everyone agreed that Scooter's idea of putting up Mac Aqua as a candidate release is a good one.

2b.  It was undecided whether to put up 1.2540 or a more updated version.  Tom will send e-mail describing 
     changes made since 1.2540.

2c.  Greg will test out some changes suggested by "OpenGL on the Mac" book that he saw at Siggraph.

3.  Required features for OpenGL configuration interface

3a.  Conrad reiterated that the interface should allow users to disable use of individual OpenGL features.  
     For the initial version, the interface should provide one control per feature.  This can be 
     made into an "Advanced" interface later on.

3b.  tef suggested that there be a "turn-all-features-off" button.

3c.  Greg mentioned that making new options take effect immediately may not be trivial, but decided that 
     it might be doable with some extra code.

3d.  Conrad suggested that the interface be another category in the Preferences panel since the options 
     should be saved anyway.

3e.  In answer to tef's question, Greg said that the interface will control OpenGL features that Chimera 
     either queries for as extensions or infers from the OpenGL version number.

3f.  Conrad suggested that the interface might also contain options for controlling what type of visual 
     Chimera should use.

4.  Generating PDF-embeddable graphics from Chimera

4a.  tef mentioned that he was asked whether we are interested in adding Chimera feature for generating 
     PDF-embeddable graphics.  There was some mention of using an SDK but not very much details.

4b.  Greg mentioned that there is an Adobe tool for capturing an OpenGL stream from an application and 
     converting it to PDF-compatible format.

4c.  Tom and Conrad agreed that, ideally, the output should be created via the x3d route.  Tom further 
     commented that previous attempts at creating data for QuicktimeVR were unsuccessful due to the lack 
     of tools and libraries for prepping the data.

4d.  tef said he will get more information about what is required to generate PDF-embeddable graphics. 

August

Thursday August 28, 2008

Attendees: tef, Tom, Elaine, Eric, Conrad

Action Items:

2a. Conrad
2b. Al
2d. Conrad
2e. Elaine
2g. Conrad

Minutes:

1. Hardware updates:

1a. A desk-side low-end machine with on-board graphics is being ordered.  It will be PCI-E based so that 
    we can use it for testing low-end graphics cards eventually.

1b. tef gave an update on interesting items at Siggraph.

- Stereo-capable projectors (e.g., DepthQ from LightSpeed Design) are now available for ~$6,000.  They are 
  not as bright and have lower resolution than our Christie projector but are far cheaper, so there may be 
  more research labs who are interested in stereo in the near future.
- Miracube LCD stereo panel (24", 1920x1200) can place left-eye on odd scan lines and right-eye on even 
  scan lines.  A polarized screen in front of the panel makes it possible to use _passive_ stereo glasses 
  with this display.  Cost is ~$4,900.  Unit should be easier to test than IZ3D screen since there should 
  be no need to change existing code.  tef will try to get one for evaluation.
- Disposable active stereo glasses are available.  No buttons to push; no batteries to change.
- Web3D consortium is pushing X3D format.
- "3D printing" service bureaus (e.g. Shapeways) are popping up.  They accept input (e.g., X3D or STL 
  format files) and send back a solid model.  Model must be architecturally sound and color may be an issue.

2. Retiring Chimera platforms

2a. Daily build script will be updated to automatically install latest application and build trees on 
    developer machines.  Currently, only the daily build tree is sync'ed on socrates.

2b. IRIX platform will be retired on 9/15/08.  All IRIX machines will be turned off on that date.  User 
    files will be on backup tape.

2c. Tru64 platform is "on notice."  Tru64 will become unsupported when (a) there is a problem that is 
    hard to fix and is unique to Tru64, or (b) socrates is upgraded to a Linux machine.

2d. Note that 1.2540 is the final release for IRIX and Tru64 will be added to the download page.

2e. News item on Chimera home page making the same announcement will be added.

2f. Mac Aqua build will be promoted to "Production" status for next release.  Promotion will encourage 
    users to try out the release and report problems.  There is uncertainly as to the usability and 
    reliability of current Aqua release for general use.  Mac X11 build will be supported for at least 
    one more production release.

2g. The script for generating Chimera download page will be investigated for creating a "Unsupported" 
    or "Deprecated" section.  Once Tru64 and IRIX releases are retired, the last builds will appear in this section.

3. Removing Chimera features

3a. Four criteria are used to evaluate whether a feature should be removed

- Complexity of code (Will removal save maintenance effort?)
- Utility of feature (Are there other ways to do the same thing?)
- Number of users of feature (Is it important to user community?)
- Quality of implementation (Will disgruntled users outnumber satisfied users?  Will unhappy users leave 
  Chimera for another package?)

3b. There was discussion on philosophy for adding features to Chimera. Is it is better (a) to release a 
    partially completed feature which makes some users happy but frustrates many, perhaps majority, of 
    users, or (b) to wait until the feature is polished.  Cases were made for both.  The main agreement 
    is that following up after feature release is a major component of making a feature successful.

3c. Three extensions were used as examples of removal candidates.

- Ray tracing.  Conrad argued that the mechanism works, but that it is difficult for the average 
  (non-artistic) user to create a striking ray-traced image; this does not constitute a good reason 
  for removing the feature.  TomG argued that if most users cannot get what they want, there is no 
  good reason to keep the feature; many users have reported to TomG that they spent hours/days on 
  ray tracing and never got a satisfactory result.

- Model Loops.  It was agreed that this is an example of a feature that should be removed.  In fact, 
  it probably should not have been released in the first place since it was never finished, i.e., 
  there is no useful end product.

- Nucleotides.  It was agreed that this is an example of a feature that needs to be improved.  The 
  images are useful but are difficult to recreate since Nucleotides data cannot be saved into sessions.  
  Rather than remove the feature, it needs to be fixed.

3d. Moving forward:

- Identify a set of candidate features for removal and see if there are objections from the user community.
- Identify and prioritize features that are not well implemented. Higher priority features need to be 
  fixed.  Lower priority features may "go on hiatus."