• Change the path to the IDL install. /opt/local/bin/idl instead of idl. This is new as of RHEL5.

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. Commit those changes as well.

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.

• There is one overview page in each of doc/contrib, doc/devel, and doc/user.

• cd /home/gbtidl/2.2
• tar -cvf gbtidl-2.2.tar --exclude-from=gbtidl/buildExcludeFile gbtidl

• cd /home/gbtidl/2.4
• tar -cvf gbtidl-2.4.tar --exclude-from=gbtidl/buildExcludeFile gbtidl

• gzip gbtidl-2.2.tar

• gzip gbtidl-2.4.tar

18. Upload this file to Sourceforge.net, logging on as 'anonymous', and using your email account as the password:

• cd /home/gbtidl/2.2
• ftp upload.sourceforge.net
• ftp>bin
• ftp>cd /incoming
• ftp>put gbtidl-2.2.tar.gz
• ftp>quit

18. Upload this file to Sourceforge.net using rsync and your sourceforge username and password:

• cd /home/gbtidl/2.4
• rsync -avP -e ssh gbtidl-2.4.tar.gz yourname@frs.sourceforge.net:uploads/

• • Enter the release name (2.2) and click on the "Create the Release" button

• • Enter the release name (2.4) and click on the "Create the Release" button

• • • Cut and paste the release notes in their entirety from the wiki version into the field on this page

• • • 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.

• This release should now be visible in the downloads section of gbtidl.

• 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.

22. Upload the new sourceforge web pages to the site (this works from my account, where I have things set up to allow scp to sourceforge for this purpose):

• cd /home/gbtidl/2.2/gbtidl/doc/sourceforge
• copy any changed web pages from doc/gbtidl.nrao.edu to the appropriate place in /home

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

• The contents of the users list as found in doc/sourceforge/cgi-bin/usergroup-list

• The contents of the users list as found in doc/gbtidl.nrao.edu/conf/usergroup-list

• The following example assumes that the new release is 2.3 and you are using the bash shell as user gbtidl.

• The following example assumes that the new release is 2.4 and you are using the bash shell as user gbtidl.

$ cvs tag release_2_3 $ cvs tag -b release_2_3_patches .

$ cvs tag release_2_4 $ cvs tag -b release_2_4_patches .

$ mkdir 2.3 $ cd 2.3 $ cvs -d :ext:gbtidl@cvs.gb.nrao.edu:/cvs checkout -P -r release_2_3_patches gbtidl

$ mkdir 2.4 $ cd 2.4 $ cvs -d :ext:gbtidl@cvs.gb.nrao.edu:/cvs checkout -P -r release_2_4_patches gbtidl

• for the example new version, export GBT_IDL_DIR=/home/gbtidl/2.3/gbtidl

• for the example new version, export GBT_IDL_DIR=/home/gbtidl/2.4/gbtidl

$ mkdir release2pt2

$ mkdir release2pt4

• Back in the CV, edit run_makedocs so that the vers string equals the new release directory: "release2pt3"

• Back in the CV, edit run_makedocs so that the vers string equals the new release directory: "release2pt4"

• Verify that these pages now can be seen on the web: www.gb.nrao.edu/content/DA/gbtidl/release2pt3/user

• Verify that these pages now can be seen on the web: www.gb.nrao.edu/content/DA/gbtidl/release2pt4/user

• in GB, create the new dir /home/gbtidl/2.2

• in GB, create the new dir /home/gbtidl/2.4

• • mkdir 2.3

• • mkdir 2.4

• • cp dorsync dorsyn_2_3
  • in dorsync_2_3, change the source and destination directories from 'integration', to '2.3' (2 changes)
  • ./dorsync_2_3

• • 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

• The following example assumes that the new release is 2.2 and you are using the bash shell as user gbtidl.

• The following example assumes that the new release is 2.3 and you are using the bash shell as user gbtidl.

• sourceforge web pages are in doc/sourceforge
  • htdocs/index.html is the main page. Edit any notes there and change any release references to the new release.
  • cgi-bin/downloads.tmpl is the downloads page. Update references to the release number and tar file in this file.

• 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).

4. Run the tests to 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.

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.

$ cvs tag release_2_2 $ cvs tag -b release_2_2_patches .

$ cvs tag release_2_3 $ cvs tag -b release_2_3_patches .

$ mkdir 2.2 $ cd 2.2 $ cvs -d :ext:gbtidl@cvs.gb.nrao.edu:/cvs checkout -P -r release_2_2_patches gbtidl

$ mkdir 2.3 $ cd 2.3 $ cvs -d :ext:gbtidl@cvs.gb.nrao.edu:/cvs checkout -P -r release_2_3_patches gbtidl

7. Change calling script, message of the day, and the !g.version value:

7. Change calling script and message of the day:

• for the example new version, export GBT_IDL_DIR=/home/gbtidl/2.2/gbtidl

• for the example new version, export GBT_IDL_DIR=/home/gbtidl/2.3/gbtidl

• • cd /home/gbtidl/2.2/gbtidl/tests/data

• • cd to tests/data

• Back in the CV, edit run_makedocs so that the vers string equals the new release directory: "release2pt2"

• Back in the CV, edit run_makedocs so that the vers string equals the new release directory: "release2pt3"

• Verify that these pages now can be seen on the web: www.gb.nrao.edu/content/DA/gbtidl/release2pt2/user

• Verify that these pages now can be seen on the web: www.gb.nrao.edu/content/DA/gbtidl/release2pt3/user

• • mkdir 2.2

• • remove versions older than the most recent release to save space
  • mkdir 2.3

• • cp dorsync dorsyn_2_2
  • in dorsync_2_2, change the source and destination directories from 'integration', to '2.2' (2 changes)
  • ./dorsync_2_2

• • cp dorsync dorsyn_2_3
  • in dorsync_2_3, change the source and destination directories from 'integration', to '2.3' (2 changes)
  • ./dorsync_2_3

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/DA/gbtidl). This step may be deferred until the actual release time.

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.

• • • click on the submit/update buggon

• • • click on the submit/update button

• scp htdocs/index.html shell.sourceforge.net:/home/groups/g/gb/gbtidl/htdocs
• scp cgi-bin/downloads.tmpl shell.sourceforge.net:/home/groups/g/gb/gbtidl/cgi-bin
• similarly for any other files that have changed

• copy any changed web pages from doc/gbtidl.nrao.edu to the appropriate place in /home

• in init_gbtidl comment out the lines underneath the 'unit tests' comment

• in init_gbtidl comment out the lines underneath the 'unit tests' comment

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 incldue any changes appropriate to this release. Commit those changes as well.

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. Commit those changes as well.

• run_benchmarks

$ cd /home/www.gb.nrao.edu/content/DA/gbtidl

$ cd /home/www.gb.nrao.edu/content/gbt/DA/gbtidl

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 line release in the documentation directory to point to the new version documentation (in /home/www.gb.nrao.edu/content/DA/gbtidl).

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/DA/gbtidl). This step may be deferred until the actual release time.

• scp htdocs/index.tmpl shell.sourceforge.net:/home/groups/g/gb/gbtidl/htdocs
• scp cgi-bin/downloads.html shell.sourceforge.net:/home/groups/g/gb/gbtidl/cgi-bin

• scp htdocs/index.html shell.sourceforge.net:/home/groups/g/gb/gbtidl/htdocs
• scp cgi-bin/downloads.tmpl shell.sourceforge.net:/home/groups/g/gb/gbtidl/cgi-bin

22. When you're ready to make it public, send the release announcment to the list below:

23. When you're ready to make it public, send the release announcment to the list below:

23. 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.

-- PaulMarganian - 11 Apr 2005

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.

• scp htdocs/index.html shell.sourceforge.net:/home/groups/g/gb/gbtidl/htdocs

• scp htdocs/index.tmpl shell.sourceforge.net:/home/groups/g/gb/gbtidl/htdocs

• The following example assumes that the new release is 1.1 and you are using the bash shell as user gbtidl.

• The following example assumes that the new release is 2.2 and you are using the bash shell as user gbtidl.

1. Log on to gbtidl machine as gbtidl. This will work only if you are part of the gbtidl group.

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 incldue any changes appropriate to this release. Commit those changes as well.

• motd is in the root gbtidl directory
• init_guide_struct is in pro/guide
• sourceforge web pages are in doc/sourceforge
  • htdocs/index.html is the main page. Edit any notes there and change any release references to the new release.
  • cgi-bin/downloads.tmpl is the downloads page. Update references to the release number and tar file in this file.

2. Log on to the gbtidl machine as gbtidl. This will work only if you are part of the gbtidl group.

2. Confirm there are no locally modified files in the integration directory by running cvs status

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.

3. Run the tests to 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.

4. Run the tests to 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.

4. Tag the files in the integration directory using the cvs tag command.

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.

$ cvs tag release_1_1 $ cvs tag -b release_1_1_patches .

$ cvs tag release_2_2 $ cvs tag -b release_2_2_patches .

5. Create the new source directory and cd to it.

6. Create the new source directory and cd to it.

$ mkdir 1.1 $ cd 1.1 $ cvs -d :ext:gbtidl@cvs.gb.nrao.edu:/cvs checkout -P -r release_1_1_patches gbtidl

$ mkdir 2.2 $ cd 2.2 $ cvs -d :ext:gbtidl@cvs.gb.nrao.edu:/cvs checkout -P -r release_2_2_patches gbtidl

6. Change calling script, message of the day, and the !g.version value:

7. Change calling script, message of the day, and the !g.version value:

• for the example new version, export GBT_IDL_DIR=/home/gbtidl/1.1/gbtidl

• for the example new version, export GBT_IDL_DIR=/home/gbtidl/2.2/gbtidl

• edit and commit pro/guide/init_guide_struct.pro so that !g.version is appropriate.

7. Run the tests again. Make sure these all pass before before proceeding. All errors must be resolved.

8. Run the unit tests again. Make sure these all pass before before proceeding. All errors must be resolved.

• • cd /home/gbtidl/1.1/gbtidl/tests/data

• • cd /home/gbtidl/2.2/gbtidl/tests/data

• makedocs - not run_makedocs, as this overwrites the integration's web docs.

8. Copy new directory from CV to GB. Do this in a similar fashion as the nightly rsyncs for integration:

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/DA/gbtidl
$ mkdir release2pt2

• Back in the CV, edit run_makedocs so that the vers string equals the new release directory: "release2pt2"
• run_makedocs
• Verify that these pages now can be seen on the web: www.gb.nrao.edu/content/DA/gbtidl/release2pt2/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/1.1

• in GB, create the new dir /home/gbtidl/2.2

• • mkdir 1.1

• • mkdir 2.2

• • cp dorsync dorsyn_1_1
  • in dorsync_1_1, change the source and destination directories from 'integration', to '1.1'
  • ./dorsync_1_1

• • cp dorsync dorsyn_2_2
  • in dorsync_2_2, change the source and destination directories from 'integration', to '2.2' (2 changes)
  • ./dorsync_2_2

9. 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.

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.

• makedocs - not run_makedocs, as this overwrites the integration's web docs.

• makedocs - not run_makedocs, as this overwrites the new documentation (not harmful at this point, just unnecessary)

10. Repeat steps 8, 9 and 10 for AOC (use "jasmine" as the host at the AOC). The root directory at the AOC is /users/gbtidl.

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.

11. 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.

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 line release in the documentation directory to point to the new version documentation (in /home/www.gb.nrao.edu/content/DA/gbtidl).

12. 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.

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.

13. Create the tar file:

• cd /home/gbtidl/1.1
• tar -cvf gbtidl-1.1.tar --exclude-from=gbtidl/buildExcludeFile

15. Create the tar file:

• cd /home/gbtidl/2.2
• tar -cvf gbtidl-2.2.tar --exclude-from=gbtidl/buildExcludeFile gbtidl

14. Compress the tar file:

• gzip gbtidl-1.1.tar

16. Compress the tar file:

• gzip gbtidl-2.2.tar

15. Uncomment the lines underneath the 'unit tests' comment in init_gbtidl.

17. Uncomment the lines underneath the 'unit tests' comment in init_gbtidl and verify that gbtidl still starts up without errors.

16. Upload this file to Sourceforge.net, logging on as 'anonymous', and using your email account as the password:

• cd /home/gbtidl/1.1

18. Upload this file to Sourceforge.net, logging on as 'anonymous', and using your email account as the password:

• cd /home/gbtidl/2.2

• ftp>put gbtidl-1.1.tar.gz

• ftp>put gbtidl-2.2.tar.gz

17. Access sourceforge's File Release System interface.

19. Access sourceforge's File Release System interface.

18. Create a file release within the GBTIDL package, for this specific release and attach the file(s) you uploaded to that file release.

• create release

19. Go here and and click on "Edit this Release", then upload the release notes

20. Download the tar ball and step through the installation notes to make sure everything is working.

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.2) 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 the field on this page
    • 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 buggon
  • 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.

21. Download the tar ball and step through the installation notes to make sure everything is working.

22. Upload the new sourceforge web pages to the site (this works from my account, where I have things set up to allow scp to sourceforge for this purpose):

• cd /home/gbtidl/2.2/gbtidl/doc/sourceforge
• scp htdocs/index.html shell.sourceforge.net:/home/groups/g/gb/gbtidl/htdocs
• scp cgi-bin/downloads.html shell.sourceforge.net:/home/groups/g/gb/gbtidl/cgi-bin
• similarly for any other files that have changed
• 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.

21. When you're ready to make it public, send the release announcment to the list below:

22. When you're ready to make it public, send the release announcment to the list below:

• ghunt
• pmurphy
• russell

22. 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.

23. 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.

12. To prepare the tar file for the sourceforge.net file release, from GB or CV, temporarily remove the admin scripts, gbtidl startup script, and comment out the tests from init_gbtidl. We need a better way of doing this:

• cd /home/gbtidl/1.1/gbtidl
• mv run_benchmarks ../.
• mv run_makedocs ../.
• mv run_unit_tests ../.
• mv run_status ../.
• mv gbtidl ../gbtidl_start
• in init_gbtidl comment out the lines underneath the 'tests' comment

12. 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

• tar -cvf gbtidl-1.1 --exclude=CVS --exclude=tests --exclude=doc --exclude=liball gbtidl/

• tar -cvf gbtidl-1.1.tar --exclude-from=gbtidl/buildExcludeFile

15. Move back the files that were temporarily removed.

• cd /home/gbtidl/1.1
• mv run_benchmarks gbtidl/.
• mv run_makedocs gbtidl/.
• mv run_unit_tests gbtidl/.
• mv run_status gbtidl/.
• mv gbtidl_start gbtidl/gbtidl
• in init_gbtidl uncomment the lines underneath the 'tests' comment

15. Uncomment the lines underneath the 'unit tests' comment in init_gbtidl.

5. Create the new source directory.

5. Create the new source directory and cd to it.

$ cd gbtidl

• cd ../..

• • ssh -l gbtidl some_host

• • ssh -l gbtidl colossus

• • mkdir gbtidl

• • mkdir 1.1

10. Repeat steps 8, 9 and 10 for AOC.

10. Repeat steps 8, 9 and 10 for AOC (use "jasmine" as the host at the AOC). The root directory at the AOC is /users/gbtidl.

• The command cvss is aliased in gbtidl's .bash_profile to: cvss='cvs -d :ext:gbtidl@nrao-sparrow.cvs.sourceforge.net:/cvsroot/nrao-sparrow'. For now, this command demands gbtidl's sourceforge password.

2. Confirm there are no locally modified files in the integration directory by running cvss status

2. Confirm there are no locally modified files in the integration directory by running cvs status

$ cvss status > status.txt

$ cvs status > status.txt

4. Tag the files in the integration directory using the cvss tag command.

4. Tag the files in the integration directory using the cvs tag command.

$ cvss tag release_1_1 $ cvss tag -b release_1_1_patches .

$ cvs tag release_1_1 $ cvs tag -b release_1_1_patches .

$ cd /home/users/gbtidl

$ cd /home/gbtidl

$ cvss checkout -P -r release_1_1_patches gbtidl

$ cvs -d :ext:gbtidl@cvs.gb.nrao.edu:/cvs checkout -P -r release_1_1_patches gbtidl

• • cd /home/users/gbtidl/1.1/gbtidl/tests/data

• • cd /home/gbtidl/1.1/gbtidl/tests/data

6. Change calling script and message of the day:

6. Change calling script, message of the day, and the !g.version value:

• edit and commit pro/guide/init_guide_struct.pro so that !g.version is appropriate.

21. When you're ready to make it public, send the release announcment to the list below (get an update from Bob Garwood):

21. When you're ready to make it public, send the release announcment to the list below:

• Tom Bania:bania@bu.edu:CurrentGBTObserver
• Tuna Breath:mangophenomena@yahoo.com:OtherSingleDishObserver
• Jean-Michel Martin:jean-michel.martin@obspm.fr:OtherSingleDishObserver
• Glen Langston:glangsto@nrao.edu:CurrentGBTObserver
• Tim Robishaw:robishaw@astro.berkeley.edu:CurrentGBTObserver
• Karen o'Neil:koneil@nrao.edu:CurrentGBTObserver
• Kirsten K. Knudsen:knudsen@mpia-hd.mpg.de:CurrentGBTObserver
• Alok Singhal:as8ca@virginia.edu:CurrentGBTObserver
• William Alexander:alexanwr@jmu.edu:ProspectiveGBTObserver
• Chao-Wei Tsai:cwtsai@astro.ucla.edu:CurrentGBTObserver
• Amanda Kepley:kepley@astro.wisc.edu:CurrentGBTObserver

• The contents of the users list as found in doc/sourceforge/cgi-bin/usergroup-list

• Remember that there are two source trees for GB and CV, and that GB is a copy of CV:

• Remember that there are three source trees for GB, AOC, and CV, and that GB and AOC are copies of CV:

• • AOC: /users/gbtidl

10. To switch to the new version is very simple. In both CV and GB, switch the symbolic link release to point to the new version directory.

10. Repeat steps 8, 9 and 10 for AOC.

11. To prepare the tar file for the sourceforge.net file release, from GB or CV, temporarily remove the admin scripts, gbtidl startup script, and comment out the tests from init_gbtidl. We need a better way of doing this:

11. 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.

12. To prepare the tar file for the sourceforge.net file release, from GB or CV, temporarily remove the admin scripts, gbtidl startup script, and comment out the tests from init_gbtidl. We need a better way of doing this:

12. Create the tar file:

13. Create the tar file:

13. Compress the tar file:

14. Compress the tar file:

14. Move back the files that were temporarily removed.

15. Move back the files that were temporarily removed.

15. Upload this file to Sourceforge.net, logging on as 'anonymous', and using your email account as the password:

16. Upload this file to Sourceforge.net, logging on as 'anonymous', and using your email account as the password:

16. Access sourceforge's File Release System interface.

17. Access sourceforge's File Release System interface.

17. Create a file release within the GBTIDL package, for this specific release and attach the file(s) you uploaded to that file release.

18. Create a file release within the GBTIDL package, for this specific release and attach the file(s) you uploaded to that file release.

18. Go here and and click on "Edit this Release", then upload the release notes

19. Go here and and click on "Edit this Release", then upload the release notes

19. Download the tar ball and step through the installation notes to make sure everything is working.

20. Download the tar ball and step through the installation notes to make sure everything is working.

20 When you're ready to make it public, send the release announcment to the list below (get an update from Bob Garwood):

21. When you're ready to make it public, send the release announcment to the list below (get an update from Bob Garwood):

21 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.

22. 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.

21 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.

• The command cvss is aliased in gbtidl's .bash_profile to: cvss='cvs -d :ext:gbtidl@cvs.sourceforge.net:/cvsroot/nrao-sparrow'. For now, this command demands gbtidl's sourceforge password.

• The command cvss is aliased in gbtidl's .bash_profile to: cvss='cvs -d :ext:gbtidl@nrao-sparrow.cvs.sourceforge.net:/cvsroot/nrao-sparrow'. For now, this command demands gbtidl's sourceforge password.

20 When you're ready to make it public, send the release announcment to:

20 When you're ready to make it public, send the release announcment to the list below (get an update from Bob Garwood):

• Tim Robishaw:robishaw@astro.berkeley.edu:CurrentGBTObserver

• bania at inanna.bu.edu
• Jean-Michel Martin:jean-michel.martin at obspm.fr:OtherSingleDishObserver
• Kirsten K. Knudsen:knudsen at mpia-hd.mpg.de:CurrentGBTObserver
• Alok Singhal:as8ca at virginia.edu:CurrentGBTObserver

• Tom Bania:bania@bu.edu:CurrentGBTObserver
• Tuna Breath:mangophenomena@yahoo.com:OtherSingleDishObserver
• Jean-Michel Martin:jean-michel.martin@obspm.fr:OtherSingleDishObserver
• Glen Langston:glangsto@nrao.edu:CurrentGBTObserver
• Tim Robishaw:robishaw@astro.berkeley.edu:CurrentGBTObserver
• Karen o'Neil:koneil@nrao.edu:CurrentGBTObserver
• Kirsten K. Knudsen:knudsen@mpia-hd.mpg.de:CurrentGBTObserver
• Alok Singhal:as8ca@virginia.edu:CurrentGBTObserver
• William Alexander:alexanwr@jmu.edu:ProspectiveGBTObserver
• Chao-Wei Tsai:cwtsai@astro.ucla.edu:CurrentGBTObserver
• Amanda Kepley:kepley@astro.wisc.edu:CurrentGBTObserver

• tar -cvf gbtidl-1.1 --exclude=CVS --exclude=tests --exclude=doc gbtidl/

• tar -cvf gbtidl-1.1 --exclude=CVS --exclude=tests --exclude=doc --exclude=liball gbtidl/

• Unzip fits files:
  • cd /home/users/gbtidl/1.1/gbtidl/tests/data
  • ./prepare_test_data

8. Copy new directory from CV to GB. Currently this can be done using the following command:

8. Copy new directory from CV to GB. Do this in a similar fashion as the nightly rsyncs for integration:

$ scp -r /export/users/gbtidl/1.1 pmargani@gb.nrao.edu:/home/gbtidl/1.1

It does not take very long for the .pro files to copied. However, finishing the tests directory can take up to an hour due to the many test data sets.

• in GB, create the new dir /home/gbtidl/1.1
  • ssh -l gbtidl some_host
  • cd /home/gbtidl
  • mkdir gbtidl
• in CV, create a copy of dorsync that is specific to this version, and run it:
  • cd /home/gbtidl
  • cp dorsync dorsyn_1_1
  • in dorsync_1_1, change the source and destination directories from 'integration', to '1.1'
  • ./dorsync_1_1

It does not take very long for the .pro files to copied. However, finishing the tests directory can take much longer.

• create a 'gbtidl' script in the same manner as mentioned above

• trobisha

• Tim Robishaw:robishaw@astro.berkeley.edu:CurrentGBTObserver

• bania@inanna.bu.edu

• bania at inanna.bu.edu
• Jean-Michel Martin:jean-michel.martin at obspm.fr:OtherSingleDishObserver
• Kirsten K. Knudsen:knudsen at mpia-hd.mpg.de:CurrentGBTObserver
• Alok Singhal:as8ca at virginia.edu:CurrentGBTObserver

19. Download the tar ball and step through the installation notes to make sure everything is working.

20 When you're ready to make it public, send the release announcment to:

• gbtlocal
• cvsci
• trobisha
• ghunt
• pmurphy
• russell
• bania@inanna.bu.edu

6. Change calling script:

6. Change calling script and message of the day:

• edit and commit the 'motd' file so that it contains the appropriate greeting.

9. Run the tests one more time!. Make sure these all pass before before proceeding. All errors must be resolved.

9. 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.

• You have admin permissions for the GBTIDL project on Sourceforge (for uploading new release).

• run_makedocs

• makedocs - not run_makedocs, as this overwrites the integration's web docs.

9. To switch to the new version is very simple. In both CV and GB, switch the symbolic link release to point to the new version directory.

9. Run the tests one more time!. Make sure these all pass before before proceeding. All errors must be resolved.

• run_unit_tests
• makedocs - not run_makedocs, as this overwrites the integration's web docs.

10. To switch to the new version is very simple. In both CV and GB, switch the symbolic link release to point to the new version directory.

11. To prepare the tar file for the sourceforge.net file release, from GB or CV, temporarily remove the admin scripts, gbtidl startup script, and comment out the tests from init_gbtidl. We need a better way of doing this:

• cd /home/gbtidl/1.1/gbtidl
• mv run_benchmarks ../.
• mv run_makedocs ../.
• mv run_unit_tests ../.
• mv run_status ../.
• mv gbtidl ../gbtidl_start
• in init_gbtidl comment out the lines underneath the 'tests' comment

12. Create the tar file:

• cd /home/gbtidl/1.1
• tar -cvf gbtidl-1.1 --exclude=CVS --exclude=tests --exclude=doc gbtidl/

13. Compress the tar file:

• gzip gbtidl-1.1.tar

14. Move back the files that were temporarily removed.

• cd /home/gbtidl/1.1
• mv run_benchmarks gbtidl/.
• mv run_makedocs gbtidl/.
• mv run_unit_tests gbtidl/.
• mv run_status gbtidl/.
• mv gbtidl_start gbtidl/gbtidl
• in init_gbtidl uncomment the lines underneath the 'tests' comment

15. Upload this file to Sourceforge.net, logging on as 'anonymous', and using your email account as the password:

• cd /home/gbtidl/1.1
• ftp upload.sourceforge.net
• ftp>bin
• ftp>cd /incoming
• ftp>put gbtidl-1.1.tar.gz
• ftp>quit

16. Access sourceforge's File Release System interface.

• For us this is at edit packages

17. Create a file release within the GBTIDL package, for this specific release and attach the file(s) you uploaded to that file release.

• create release

18. Go here and and click on "Edit this Release", then upload the release notes

• for the example new version, export GBT_IDL_DIR=/export/users/gbtidl/1.1

• for the example new version, export GBT_IDL_DIR=/home/gbtidl/1.1/gbtidl

$ cvss checkout -P -r release_1_1_patches

$ cvss checkout -P -r release_1_1_patches gbtidl

6. Run the tests again. Make sure these all pass before before proceeding. All errors must be resolved.

6. Change calling script:

• 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=/export/users/gbtidl/1.1

7. Run the tests again. Make sure these all pass before before proceeding. All errors must be resolved.

7. Copy new directory from CV to GB. Currently this can be done using the following command:

8. Copy new directory from CV to GB. Currently this can be done using the following command:

It does not take very long for the .pro files to copied. However, finishing the tests directory can take up to an hour due to the many test data sets.

8. To switch to the new version is very simple. In both CV and GB, switch the symbolic link release to point to the new version directory.

9. To switch to the new version is very simple. In both CV and GB, switch the symbolic link release to point to the new version directory.

3. Tag the files in the integration directory using the cvss tag command.

3. Run the tests to 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

4. Tag the files in the integration directory using the cvss tag command.

4. Create the new source directory.

5. Create the new source directory.

5. Run all tests - make sure these all pass before before proceeding.

6. Run the tests again. Make sure these all pass before before proceeding. All errors must be resolved.

• run_benchmarks

6. Copy new directory from CV to GB.

7. Copy new directory from CV to GB. Currently this can be done using the following command:

$ scp -r /export/users/gbtidl/1.1 pmargani@gb.nrao.edu:/home/gbtidl/1.1

7. To switch to the new version is very simple. In both CV and GB, switch the symbolic link release to point to the new version directory.

8. To switch to the new version is very simple. In both CV and GB, switch the symbolic link release to point to the new version directory.

The following example assumes that the new release is and you are using the bash shell as user gbtidl.

Notes:

• The following example assumes that the new release is 1.1 and you are using the bash shell as user gbtidl.

• The command cvss is aliased in gbtidl's .bash_profile to: cvss='cvs -d :ext:gbtidl@cvs.sourceforge.net:/cvsroot/nrao-sparrow'. For now, this command demands gbtidl's sourceforge password.

Note: The systems are not part of the this build.

• Remember that there are two source trees for GB and CV, and that GB is a copy of CV:
  • CV: /export/users/gbtidl
  • GB: /home/gbtidl

1. Log on to gbtidl machine as gbtidl.

1. Log on to gbtidl machine as gbtidl. This will work only if you are part of the gbtidl group.

ssh -l gbtidl gbtidl

2. Confirm there are no locally modified files in the integration directory by running cvss status

2. Confirm there are no locally modified files in the integration directory by running cvs status

$ cd /export/users/gbtidl/integration/gbtidl $ cvss 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.

3. Tag the files in the integration directory using the cvss tag command.

$ cd /export/users/gbtidl/integration/gbtidl
$ cvss tag release_1_1
$ cvss tag -b release_1_1_patches .

4. Create the new source directory.

$ cd /home/users/gbtidl
$ mkdir 1.1
$ cd 1.1
$ cvss checkout -P -r release_1_1_patches 

The "-P" will prevent previously removed (aka "empty") directories from being checked out.

5. Run all tests - make sure these all pass before before proceeding.

• run_unit_tests
• run_makedocs
• run_benchmarks

6. Copy new directory from CV to GB.

7. To switch to the new version is very simple. In both CV and GB, switch the symbolic link release to point to the new version directory.

%META:TOPICINFO{author="PaulMarganian" date="1113230340" format="1.0" version="1.1"}% %META:TOPICPARENT{name="DataKnowledge"}%

Problem

How do I initiate a new GBTIDL release?

Solution

The following example assumes that the new release is and you are using the bash shell as user gbtidl.

Note: The systems are not part of the this build.

Instructions:

1. Log on to gbtidl machine as gbtidl.

2. Confirm there are no locally modified files in the integration directory by running cvs status

-- PaulMarganian - 11 Apr 2005 %META:FORM{name="WebForm"}% %META:FIELD{name="TopicClassification" title="TopicClassification" value="NoDisclosure"}% %META:FIELD{name="OperatingSystem" title="OperatingSystem" value=""}% %META:FIELD{name="OsVersion" title="OsVersion" value=""}%