Changes between Initial Version and Version 1 of ChimeraTeamMeetings

Timestamp:

Sep 21, 2008, 5:33:02 PM (18 years ago)

Author:

Scooter Morris

Comment:

--

ChimeraTeamMeetings

@@ +1 @@
+The Chimera Development Team has weekly meetings on Thursdays from 3:00-4:30 PST.  The minutes of the meetings are posted below.
+
+[[TableOfContents]]
+
+= 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:
+
+0. Review Action Items
+
+0a.  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).
+
+0b.  Greg reported that the OpenGL preference panel code has been designed and will be implemented in one week.
+
+0c.  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.
+
+0d.  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).
+
+0e.  Scooter will discuss Wiki technology during group meeting when demonstrating Trac.
+
+1. Discuss source tree forking mechanism (Scooter)
+
+1a.  Scooter discussed tree forking in CVS using example from http://users.csc.calpoly.edu/~jdalbey/205/Resources/cvsBranchMerge.html  The example web page has examples on how to tag a branch, switch between branches, merging branches, etc.
+
+1b.  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.
+
+1c.  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.
+
+1d.  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.
+
+1e.  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.
+
+2. Discuss test lab, viz room and public cubicle setup (Conrad)
+3. 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." 
+}}}