| 28 | | 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). |
| | 31 | 0a. Greg checked SGI activity and found only four users: Ed Pate (visitor), Ben Webb (MODELLER builds), |
| | 32 | Craig Gough and Bo Yang Baker. Eric reported that the last two are no longer at UCSF and will contact |
| | 33 | them regarding impending retirement of SGI machines. A stereo-capable workstation will be made |
| | 34 | available for public (Pate) use before SGIs are turned off. An Octane will be "donated" to QB3 machine |
| | 35 | room for MODELLER builds (Webb). |
| 32 | | 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. |
| 33 | | |
| 34 | | 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). |
| | 39 | 0c. Tom contacted Sebastien who said that he is actively promoting the use of Volume Series. Consensus is to |
| | 40 | keep Volume Series in Chimera for now. |
| | 41 | |
| | 42 | 0d. tef contacted Miracube and is getting a new 24" LCD panel for evaluation (will arrive in a couple weeks). |
| | 43 | Unit will arrive with two pairs of stereo glasses. If testing goes well, we will purchase the unit for a |
| | 44 | discounted price of $3,900 (list if $4,900). |
| 40 | | 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. |
| 41 | | |
| 42 | | 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. |
| 43 | | |
| 44 | | 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. |
| 45 | | |
| 46 | | 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. |
| | 50 | 1a. Scooter discussed tree forking in CVS using example from [http://users.csc.calpoly.edu/~jdalbey/205/Resources/cvsBranchMerge.html] |
| | 51 | The example web page has examples on how to tag a branch, switch between branches, merging branches, etc. |
| | 52 | |
| | 53 | 1b. General practice is to keep a separated checked out tree for each branch. Changes should be made on |
| | 54 | the branch where it should first appear, e.g., bug fixes in the candidate release branch and new features |
| | 55 | in trunk. Bug fixes in the branch that also need to be in the trunk can be added back using the |
| | 56 | "cvs update -j release-name filename" command in the trunk tree. |
| | 57 | |
| | 58 | 1c. With branching, Chimera versioning using RCS/CVS version number may produce duplicate version strings for |
| | 59 | builds on different branches. Consensus is to use a four-number versioning system (major.minor.bugfix[build]) |
| | 60 | starting with the next release. The "major", "minor" and "bugfix" numbers need to be maintained manually, |
| | 61 | while the "build" can still be from RCS/CVS. After forking the tree, the minor number on the trunk should |
| | 62 | be incremented immediately so that the branch and trunk are easily distinguishable. |
| | 63 | |
| | 64 | 1d. Upcoming release will be "1.3.0[build_no]". 1.3 was chosen because current release is 1.2540 so if you squint |
| | 65 | and only look at the first part, the "natural" small version number is "1.2"; and "1.3" comes after "1.2". |
| | 66 | The candidate release branch will be 1.3; the trunk will be updated to 1.4 after forking. |
| 82 | | 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. |
| 83 | | |
| 84 | | 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. |
| | 102 | 0a. Conrad asked whether copying build trees to development machines should completely replace or |
| | 103 | simply overwrite existing files. Consensus is to wipe out the old tree and install the new tree. |
| | 104 | |
| | 105 | 0b. tef asked whether Ed Pate was notified that SGI files will need to be moved manually. Tom suggested |
| | 106 | that SGI files be backed up to socrates, but others said that no one (other than Pate) uses SGI. |
| | 107 | Greg mentioned that Sali group uses SGI to build software. Greg will check on activities on SGIs and |
| | 108 | report back. Eric will send e-mail notifying Pate. |
| 88 | | 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. |
| 89 | | |
| 90 | | 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. |
| 91 | | |
| 92 | | 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. |
| 93 | | |
| 94 | | 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. |
| | 112 | 1a. As Al mentioned in e-mail, the new low-end test machine reproduced many of the symptoms in Chimera |
| | 113 | bug reports. Greg was able to fix or work around driver bugs so that the latest version of Chimera |
| | 114 | will run on the test machine "out of the box." Greg suggested that a new Windows production release |
| | 115 | be made to reduce the number of bug reports related to this problem. |
| | 116 | |
| | 117 | 1b. It was agreed that we make a new production release for all platforms. This eliminates the "different |
| | 118 | version on different platform" issue for Aqua, which will remain a candidate release. IRIX and Tru64 |
| | 119 | can also be retired on a production release rather than having a subsequent daily build with bug fixes. |
| | 120 | |
| | 121 | 1c. It was agreed that having the OpenGL preference panel in the next release would be a good thing. Greg |
| | 122 | will provide a time line for implementation at next meeting. |
| | 123 | |
| | 124 | 1d. Conrad suggested that we use this opportunity to test out the proposed CVS tree-forking when making production |
| | 125 | releases. The tree should be forked when we are ready to make candidate releases. Subsequent bug fixed will |
| | 126 | need to go into both the release branch and the development branch, while improvements will only go into the |
| | 127 | development branch. |
| 106 | | 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. |
| | 140 | 2b. List of features was evaluated. First a vote is taken to see if there is consensus whether a feature |
| | 141 | should be on the "Remove" or "Improve" list. Putting a feature on the "Remove" list does _not_ mean |
| | 142 | immediate removal. After the "Remove" list has been constructed, we will follow the removal procedure |
| | 143 | agreed upon in previous meetings (eg sending e-mail, waiting for replies, etc). Features with no consensus |
| | 144 | decisions are evaluated and will be placed into list later. Evaluations are listed below as five letters, |
| | 145 | Low-Medium-High, for each criterion listed above. |
| 146 | | 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. }}} |
| | 185 | 2c. Tom mentioned that many features that he wants removed are really experimental/exploratory features. |
| | 186 | They are useful for demonstrations (eg Phantom, head tracking) but are not really useful to general |
| | 187 | user community (eg lack of hardware, platform limitations). These features take up menu space and |
| | 188 | often confuse/frustrate users who try them out. Eric mentioned that even though novice users may find |
| | 189 | some features confusing, experienced users may really like them; for example, Rachel Karchin uses |
| | 190 | DelPhi Controller and probably would be disappointed if it were removed. Conrad suggested having |
| | 191 | a way of installing features by querying remote repository but Tom believes that's still too much |
| | 192 | effort for local demonstrations (since one would have to reinstall for each release). Greg(?) |
| | 193 | suggested that the features be included in releases, but that we add a "Show in Menus" column to |
| | 194 | the extension manager; questionable features are hidden until user explicitly enable them via the |
| | 195 | extension manager. (Along similar lines, after the meeting, Tom suggested labeling the questionable |
| | 196 | features as prototypes and ask the user when they first run Chimera whether they want to enable |
| | 197 | prototypes.) No consensus/decision was reached. |
| | 198 | }}} |
| 168 | | 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. |
| | 221 | 1a. Conrad suggested that after proposed list of items to remove has been agreed upon, we announce |
| | 222 | the list to the user community and wait one month for feedback. To reach the user community, |
| | 223 | we send email to the chimera-users list and put up a short announcement on the News section |
| | 224 | of the home page. Items that users wish to retain will return to the candidate list for removal; |
| | 225 | all other items are immediately removed after the one-month waiting period. |
| 175 | | - Quality of implementation (Will disgruntled users outnumber satisfied users? Will unhappy users leave Chimera for another package?) |
| 176 | | |
| 177 | | (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. |
| 178 | | |
| 179 | | 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. |
| | 232 | - Quality of implementation (Will disgruntled users outnumber satisfied users? Will unhappy users |
| | 233 | leave Chimera for another package?) |
| | 234 | |
| | 235 | (Criteria wording will be fixed so that high/low will all point in the same direction.) Items can then |
| | 236 | be sorted into two lists: "remove" and "keep". "Remove" list may be handled according to 1a. "Keep" |
| | 237 | list will be prioritized. Higher priority items are put in the "fix/enhance" list; lower priority |
| | 238 | items are in the "leave as is" list. |
| | 239 | |
| | 240 | 1c. Tom suggested that we use a wiki-like mechanism for distributed maintenance of candidate removal |
| | 241 | list, feature request list, change log, etc. Scooter "volunteered" to investigate available technologies. |
| 196 | | 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. |
| 197 | | |
| 198 | | 3d. Conrad suggested that the interface be another category in the Preferences panel since the options should be saved anyway. |
| 199 | | |
| 200 | | 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. |
| 201 | | |
| 202 | | 3f. Conrad suggested that the interface might also contain options for controlling what type of visual Chimera should use. |
| | 260 | 3c. Greg mentioned that making new options take effect immediately may not be trivial, but decided that |
| | 261 | it might be doable with some extra code. |
| | 262 | |
| | 263 | 3d. Conrad suggested that the interface be another category in the Preferences panel since the options |
| | 264 | should be saved anyway. |
| | 265 | |
| | 266 | 3e. In answer to tef's question, Greg said that the interface will control OpenGL features that Chimera |
| | 267 | either queries for as extensions or infers from the OpenGL version number. |
| | 268 | |
| | 269 | 3f. Conrad suggested that the interface might also contain options for controlling what type of visual |
| | 270 | Chimera should use. |
| 206 | | 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. |
| 207 | | |
| 208 | | 4b. Greg mentioned that there is an Adobe tool for capturing an OpenGL stream from an application and converting it to PDF-compatible format. |
| 209 | | |
| 210 | | 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. |
| | 274 | 4a. tef mentioned that he was asked whether we are interested in adding Chimera feature for generating |
| | 275 | PDF-embeddable graphics. There was some mention of using an SDK but not very much details. |
| | 276 | |
| | 277 | 4b. Greg mentioned that there is an Adobe tool for capturing an OpenGL stream from an application and |
| | 278 | converting it to PDF-compatible format. |
| | 279 | |
| | 280 | 4c. Tom and Conrad agreed that, ideally, the output should be created via the x3d route. Tom further |
| | 281 | commented that previous attempts at creating data for QuicktimeVR were unsuccessful due to the lack |
| | 282 | of tools and libraries for prepping the data. |
| 236 | | - 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. |
| 237 | | - 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. |
| | 309 | - Stereo-capable projectors (e.g., DepthQ from LightSpeed Design) are now available for ~$6,000. They are |
| | 310 | not as bright and have lower resolution than our Christie projector but are far cheaper, so there may be |
| | 311 | more research labs who are interested in stereo in the near future. |
| | 312 | - Miracube LCD stereo panel (24", 1920x1200) can place left-eye on odd scan lines and right-eye on even |
| | 313 | scan lines. A polarized screen in front of the panel makes it possible to use _passive_ stereo glasses |
| | 314 | with this display. Cost is ~$4,900. Unit should be easier to test than IZ3D screen since there should |
| | 315 | be no need to change existing code. tef will try to get one for evaluation. |
| 244 | | 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. |
| 245 | | |
| 246 | | 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. |
| 247 | | |
| 248 | | 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. |
| | 323 | 2a. Daily build script will be updated to automatically install latest application and build trees on |
| | 324 | developer machines. Currently, only the daily build tree is sync'ed on socrates. |
| | 325 | |
| | 326 | 2b. IRIX platform will be retired on 9/15/08. All IRIX machines will be turned off on that date. User |
| | 327 | files will be on backup tape. |
| | 328 | |
| | 329 | 2c. Tru64 platform is "on notice." Tru64 will become unsupported when (a) there is a problem that is |
| | 330 | hard to fix and is unique to Tru64, or (b) socrates is upgraded to a Linux machine. |
| 254 | | 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. |
| 255 | | |
| 256 | | 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. |
| | 336 | 2f. Mac Aqua build will be promoted to "Production" status for next release. Promotion will encourage |
| | 337 | users to try out the release and report problems. There is uncertainly as to the usability and |
| | 338 | reliability of current Aqua release for general use. Mac X11 build will be supported for at least |
| | 339 | one more production release. |
| | 340 | |
| | 341 | 2g. The script for generating Chimera download page will be investigated for creating a "Unsupported" |
| | 342 | or "Deprecated" section. Once Tru64 and IRIX releases are retired, the last builds will appear in this section. |
| 265 | | - Quality of implementation (Will disgruntled users outnumber satisfied users? Will unhappy users leave Chimera for another package?) |
| 266 | | |
| 267 | | 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. |
| | 351 | - Quality of implementation (Will disgruntled users outnumber satisfied users? Will unhappy users leave |
| | 352 | Chimera for another package?) |
| | 353 | |
| | 354 | 3b. There was discussion on philosophy for adding features to Chimera. Is it is better (a) to release a |
| | 355 | partially completed feature which makes some users happy but frustrates many, perhaps majority, of |
| | 356 | users, or (b) to wait until the feature is polished. Cases were made for both. The main agreement |
| | 357 | is that following up after feature release is a major component of making a feature successful. |
| 271 | | - 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. |
| 272 | | |
| 273 | | - 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. |
| 274 | | |
| 275 | | - 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. |
| | 361 | - Ray tracing. Conrad argued that the mechanism works, but that it is difficult for the average |
| | 362 | (non-artistic) user to create a striking ray-traced image; this does not constitute a good reason |
| | 363 | for removing the feature. TomG argued that if most users cannot get what they want, there is no |
| | 364 | good reason to keep the feature; many users have reported to TomG that they spent hours/days on |
| | 365 | ray tracing and never got a satisfactory result. |
| | 366 | |
| | 367 | - Model Loops. It was agreed that this is an example of a feature that should be removed. In fact, |
| | 368 | it probably should not have been released in the first place since it was never finished, i.e., |
| | 369 | there is no useful end product. |
| | 370 | |
| | 371 | - Nucleotides. It was agreed that this is an example of a feature that needs to be improved. The |
| | 372 | images are useful but are difficult to recreate since Nucleotides data cannot be saved into sessions. |
| | 373 | Rather than remove the feature, it needs to be fixed. |
![[Chimera Issue Tracking System]](/trac/chimera/chrome/site/chimera_logo.png){kind=logo}
