How do I initiate a new GBTIDL release?
Notes:
- The following example assumes that the new release is 2.4 and you are using the bash shell as user
gbtidl.
- You have admin permissions for the GBTIDL project on Sourceforge (for uploading new release).
- Remember that there are three source trees for GB, AOC, and CV, and that GB and AOC are copies of CV:
- CV: /export/users/gbtidl
- GB: /home/gbtidl
- AOC: /users/gbtidl
Instructions:
1. Make sure that the motd and init_guide_struct have the correct version number. These should be the same and integration should now reflect this upcoming release's version number. After verifying that these changes work in your sandbox, commit those changes. Also, edit the master version of the web pages to include any changes appropriate to this release. Finally, edit the overview pages for the reference manual documentation. They contain one line identifying the current version number. Commit those changes as well.
- motd is in the root gbtidl directory
- init_guide_struct is in pro/guide
- gbtidl.nrao.edu web pages are in doc/gbtidl.nrao.edu
- content/index.shtml is the main page. Edit any notes there and change any release references to the new release.
- content/downloads.shtml is the downloads page. Make any changes there (usually related to new version numbers).
- There is one overview page in each of doc/contrib, doc/devel, and doc/user.
2. Log on to the gbtidl machine as gbtidl. This will work only if you are part of the gbtidl group.
ssh -l gbtidl gbtidl
3. Confirm there are no locally modified files in the integration directory by running cvs status. If you edited any files in step 1 update those files in the integration tree before proceding with this step.
$ cd /export/users/gbtidl/integration/gbtidl
$ cvs status > status.txt
Search the resulting status file for "Locally Modified" or "Needs Merge" files. Files with these statuses need to have whatever action is appropriate taken to make them become "Up to Date". File with status "Needs Patch" are ok.
If any actions are needed to update integration, then this CV integration directory should be copied to GB.
4. Run the tests as the last check to make sure the current state of integration is healthy. If the below tests produce errors, these should be resolved before proceeding.
- run_unit_tests
- run_makedocs
- run_benchmarks
5. Tag the files in the integration directory using the cvs tag command. Note that this step has failed in the past due to the quota limit being exceeded for the monctrl account in Green Bank. If that happens, consult with other members of the SDD group about removing files from the disk(s) where the quota limit has been exceeded.
$ cd /export/users/gbtidl/integration/gbtidl
$ cvs tag release_2_4
$ cvs tag -b release_2_4_patches .
6. Create the new source directory and cd to it.
$ cd /home/gbtidl
$ mkdir 2.4
$ cd 2.4
$ cvs -d :ext:gbtidl@cvs.gb.nrao.edu:/cvs checkout -P -r release_2_4_patches gbtidl
$ cd gbtidl
The "-P" will prevent previously removed (aka "empty") directories from being checked out.
7. Change calling script and message of the day:
- copy 'run_gbtidl' to 'gbtidl'.
- at the top of 'gbtidl', edit GBT_IDL_DIR to the location of this installation
- for the example new version, export GBT_IDL_DIR=/home/gbtidl/2.4/gbtidl
- edit and commit the 'motd' file so that it contains the appropriate greeting.
8. Run the unit tests again. Make sure these all pass before before proceeding. All errors must be resolved.
- Unzip fits files:
- cd to tests/data
- ./prepare_test_data
- cd ../..
- run_unit_tests
9. Build the release docs
- As gbtidl in Green Bank, create a new empty directory to hold the new release's reference manual pages.
$ cd /home/www.gb.nrao.edu/content/gbt/DA/gbtidl
$ mkdir release2pt4
- Back in the CV, edit run_makedocs so that the vers string equals the new release directory: "release2pt4"
- run_makedocs
- Verify that these pages now can be seen on the web: www.gb.nrao.edu/content/DA/gbtidl/release2pt4/user
- commit run_makedocs to this branch
10. Copy new directory from CV to GB. Do this in a similar fashion as the nightly rsyncs for integration:
- in GB, create the new dir /home/gbtidl/2.4
- ssh -l gbtidl colossus
- cd /home/gbtidl
- remove versions older than the most recent release to save space
- mkdir 2.4
- in CV, create a copy of dorsync that is specific to this version, and run it:
- cd /home/gbtidl
- cp dorsync dorsyn_2_4
- in dorsync_2_4, change the source and destination directories from 'integration', to '2.4' (2 changes)
- ./dorsync_2_4
It does not take very long for the .pro files to copied. However, finishing the tests directory can take much longer.
11. Go to the new GB source tree, and run the tests one more time!. Make sure these all pass before before proceeding. All errors must be resolved.
- create a 'gbtidl' script in the same manner as mentioned above
- Change the path to the IDL install. /opt/local/bin/idl instead of idl. This is new as of RHEL5.
- run_unit_tests
- makedocs - not run_makedocs, as this overwrites the new documentation (not harmful at this point, just unnecessary)
12. Repeat steps 10 and 11 for AOC (use "jasmine" as the host at the AOC). The root directory at the AOC is /users/gbtidl. Watch for quota limits at the AOC and remove older versions of gbtidl (but not the previous release) to make space for the new version as necessary.
13. To switch to the new version is very simple. In both CV, AOC, and GB, switch the symbolic link release to point to the new version directory (in /home/gbtidl in CV and GB and in /users/gbtidl at the AOC). In GB switch the symbolic link release in the documentation directory to point to the new version documentation (in /home/www.gb.nrao.edu/content/gbt/DA/gbtidl). This step may be deferred until the actual release time.
14. To prepare the tar file for the sourceforge.net file release, from GB or CV first comment out the .compile of the tests scripts from init_gbtidl. The files to be excluded from the tar file are listed in gbtidl/buildExcludeFile.
- in init_gbtidl comment out the lines underneath the 'unit tests' comment
15. Create the tar file:
- cd /home/gbtidl/2.4
- tar -cvf gbtidl-2.4.tar --exclude-from=gbtidl/buildExcludeFile gbtidl
16. Compress the tar file:
17. Uncomment the lines underneath the 'unit tests' comment in init_gbtidl and verify that gbtidl still starts up without errors.
18. Upload this file to Sourceforge.net using rsync and your sourceforge username and password:
19. Access sourceforge's File Release System interface.
20. Create a file release within the GBTIDL package, for this specific release and attach the file(s) you uploaded to that file release.
- From the page opened by the link in step 19 (after logging in)
- click on the "Add Release" link
- Enter the release name (2.4) and click on the "Create the Release" button
- Step 1
- Change the release date (this may or may not have any effect, I'm still puzzled by this field)
- Cut and paste the release notes in their entirety from the wiki version into a file on your computer and edit that to insert line breaks with about a maximum width of 80 characters.
- Using the "Browse" button on the sourceforge page, add that newly created file.
- select the box that preserves the formatting of the notes
- Click on submit/update button
- Step 2
- select the tar file you just uploaded from the list of available files
- click on the submit/update button
- Step 3
- Edit the release date (same comments as above)
- Processor: platform-independent
- File type: source .gz
- click on update/refresh button
- This release should now be visible in the downloads section of gbtidl. View the release notes and redo step one as necessary to make them look reasonably good on your browser.
21. Download the tar ball and step through the installation notes to make sure everything is working.
22. Upload the new web pages to the site by simply copying them to the appropriate local directory
- cd /home/gbtidl/2.4/gbtidl/doc/gbtidl.nrao.edu
- copy any changed web pages to the appropriate place in /home
- Verify that the new files seem to be working correctly in a browser. Especially verify that the links to the release notes and tar file are correct.
23. When you're ready to make it public, send the release announcment to the list below:
- gbtlocal
- cvsci
- The contents of the users list as found in doc/gbtidl.nrao.edu/conf/usergroup-list
24. If this new release comes with a new Quick Reference, collect all old QR's (primarily in the Control Room), and replace them with the new ones.
Revision r1.28 - 04 Aug 2008 - 19:40 GMT - BobGarwood
Parents: WebHome > DataKnowledge
|
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.
|
| |