Attendees: Joanne Bogart, Emmanuel Cephas, Richard Dubois, Navid Golpayegani, Karen Heidenreich, Tony Johnson, Heather Kelly, Chuck Patterson
Status
Karen showed us the current Release Manager pages. These are currently behind the firewall:
http://glast-tomcat03.slac.stanford.edu:8080/releasemanager/releaseManager-NEW.jsp
The top-level page first displays the currently running builds followed by a table of recently completed builds. At the bottom of the page, the user may choose to only view GR or ST. There is a glitch with the GR-only option, which currently displays SciTools-only. Richard asked about the option of hiding builds as was available in the old RM. The general consensus was that such builds deemed worthy of hiding would be deleted, so there is no need to add the "Hide" facility.
After some discussion, it was decided that the top-level page would list each build, i.e. GR-LATEST-1.5555, rather than listing each individual build and its variants for each operating system, compiler, and opt/debug. The currently running builds table on the top-level page will be ordered by "Start Time". The "Start Time" for a build is the time the ReleaseManager realizes a new build is started. Thus, the "Stop Time", "Variant", "Checkout StartTime", and "Checkout StopTime" columns have no meaning on the top-level page and will be removed. We discussed providing a pull-down menu of the builds by operating system/compiler types). It was also suggested that the builds be listed with the most recent builds first, Karen will reverse the current ordering.
We reconfirmed that there are three types of builds: tags, HEAD, and LATEST.
Links to the source distribution and Doxygen pages will also be available from the top-level. Note that source distributions will continue to be Windows versus linuxes specific, so this require two separate links. Heather asked how the Doxygen pages change in location will affect Chuck and the workbook. Navid explained that when Doxygen is enabled (it is not yet in the new RM), there will be a new location for Chuck to point to. Navid is hoping to make the Doxygen links more robust this time around.
The next level in the web pages displays the information concerning a specific build. Links to all the variants will be provided, including the "Checkout Output", "Compile Output", and "Test Output". Currently there appears to be a bug where only one operating system and variant are displayed per build, even for builds where there were more than one.
From the second-level, there will be a (third level) summary page for each build variant (operating system, compiler, debug/optimized). Navid will provide a description of the table for Karen. SCons does not have the notion of packages, and provides a global failure for a build. Navid will parse the output to determine which package(s) caused the failure. He will be able to construct a list of packages and their build status. Clearly, this mechanism is error prone, but will provide at least a yea or nay concerning whether the build completely succeeded or not. Reporting the status of the unit tests will be much easier, as their names are of the form test_<packageName>. Richard and Joanne discussed the possibility of flagging error messages either through color-coding (something Karl did in the past) or by inserting a prefix in the SCons output.
Richard commented that the old RM included "Status of RM" - that should be included here as well. Also it would be helpful to have the choice of GR versus ST only at the top. Perhaps the empty tabs on the top of the top-level page could be used for this purpose. We agreed that the old EngineeringModel is defunct and need not be included. There are still tags of BeamtestRelease but it can be ignored for now. Perhaps Bryson's CHS checkout package should be included. [what plans are there to update CHS/eventFile to use SCons?]
Heather asked about the ability to delete a build. There will be the command line option to do so. For the web interface, the authentication issues are taken care of. Navid has to work through some issues with having the delete request from the web to erase the actual build areas as well as updating the database.
Navid reports that the Release Manager currently builds RHEL4. Windows was enabled yesterday, there are some issues to work through. RHEL5 can be submitted, however, we are waiting for the RHEL5 boxes to be reconfigured. The RHEL4 64 bit builds could be enabled - all of SciTools will work except Likelihood. Once Qt is compiled for the Mac, the Mac builds could be enabled. Please note that the Mac builds for Qt at SLAC are taking a very long time - 12 hours to run configure.
Navid asked about the possibility to have the ReleaseManager page update itself, as the old RM does every 5 minutes. Tony's pages do have an "update" option which can be toggled on and off. Navid also mentioned that one could use the stop time to automatically determine if updating the page is necessary.
We agreed that the RM Performance Plots from the old RM pages should carry over to the new RM pages.
Once we agree the new RM web pages have reached a point for public viewing (hopefully in the next couple of weeks), Karen will coordinate with Tony to get the pages out from behind the firewall. They will give it a new name, so there is no conflict with the older RM pages.
Action Items
1. Navid will provide a description of the table used to fill the summary page (third-level) for each variant build.
These pages will include an indication of how the builds succeeded or failed for the subpackages included in the build.
2. The top-level page will have its tables updated to contain:
Name | Start Time | pull down menu for build variants | Doxygen Link | source Dist for win and lin |
3. The top-level page should include a RM status.
4. The RM Performance Plots will carry over to the new RM pages.
5. The second-level page will include a list of all variant builds, the table will include:
Variant | Start Time | Stop Time | Checkout Ouput | Test Output |
6. Karen will fix the second-level page to include all variants.
7. The CHS checkout package will be added in addition to GlastRelease and ScienceTools
8. A delete build option will be added when it becomes available.
9. The tag collector will be linked in when it becomes available.
10. Once the web pages are deemed ready, Karen will work with Tony to bring out from behidn the firewall.
11. Tony's update page facility will be used on these pages to provide the option for the pages to be updated automatically.