Release Punch List

Not logged in

• Browse
• Help
• Home
• Login
• Reports
• Search
• Timeline
• Wiki

• Contents
• No-Diff
• Text

 *:::: (You can also use "=scp nmi-s006:/space/tmp/release-$RELEASE/public/v$RELEASE_MAJOR/'*' ./=" to copy the binaries over. rsync provides the advantage that you can re-run it over and over again if your transfer is interrupted and you won't re-copy what you already have.)
 *::: Option 3: Derek has a script to search through a given NMI rundir and move everything we need. The script lives in the nmi_tools directory in git, and is called =move_to_afs=. Beware that this script will eat up around 8 gigabytes while it runs. It's also old and crusty and should be avoided.
 
-1: Push native packages into the repositories.
-1:: Find a machine with at least 3 GB scratch space
-1:: Obtain the RUNID and the Condor's branch name ( stable | development )
-1:: If a new platform (OS or Arch) is added, see this {wiki: CondorRepos documentation }
-1:: Check the mapping file to see if release platforms are correct
+1: Release source tarball. The source tarball is created every night as part of the nightly builds. Nick's =nmi-extract-results= script will extract it along will all of the binary tarballs. Otherwise, you can extract it yourself. If you look in the =rundir= of a given NMI runid, you should see a tarball in =userdir/common= named =results.tar.gz=, which contains the source tarball. Extract it like so:
 {code}
-cat /p/condor/public/html/yum/files/mapping.txt
+tar zxvf results.tar.gz condor-X.Y.Z.tar.gz
 {endcode}
-1:: Invoke the script to download packages and update the repositories. The script will wait for confirmation, proceed by press enter.
+The source should be placed in =/p/condor/public/binaries/vX.Y/X.Y.Z= using the name "=condor_src-X.Y.Z-all-all.tar.gz=".
+
+
+1: Is this a new series release (x.x.0)?  There are some additional details:
+
+*::Add a new license agreement.  This is usually just copying the old license to a new name.
+
+*:::Check out the condor-web CVS module.
+*:::cd condor-web/src/downloads
+*:::cp v7.3.license.html v7.4.license.html
+*:::edit v7.4.license.html to change the Condor version numebr.
+*:::cvs add v7.4.license.html
+*:::cvs ci
+*:::cd ../..
+*:::./generate_html src
+
+*::Update the download system's information.  Note that the warnings above download-versions being incompatible with the standard Python install stands; make sure you use a more recent Python.
 {code}
-/p/condor/public/html/yum/files/manage_repo.pl -i 24009 -s /scratch/kooburat -b stable
+download-versions update --lic=http://parrot.cs.wisc.edu/v7.4.license.html \
+  --inst=http://www.cs.wisc.edu/condor/manual/v7.4/3_2Installation.html 7.4.0
+{endcode}
 
-Downloading from runid: 24009
-Using scratch folder: /scratch/kooburat/condor_repo
-Put packages into stable repos
-Enter to confirm or Ctrl^C to cancel
+*::The download log files must exist; the download scripts won't create them if they don't.
+{code}
+cd /p/condor/public/license
+touch licensers-v7.4 problem-v7.4 sendfile-v7.4
 {endcode}
 
+1: Set the release date (the date the new version hit the Condor web site) in the Condor Manual's Version History item devoted
+to identifying the release date.  OR, tell Karen exactly what
+date to use, and she'll do it for you. (#1236)
 
-1: XXX This step needs a refinement in the script intellect. XXX
-{linebreak}{linebreak}
-Create matching glidein tarballs, and install in /p/condor/public/html/glidein/binaries. This process is handled by running the following script, replacing 7.1.1 with the version you are releasing:
+1: Release the manual. Continuing the V7_0_3 example...
+*:: build the manual
 {code}
-make_glidein_tarballs 7.1.1
+git clone /p/condor/repository/CONDOR_DOC.git
+cd CONDOR_DOC
+git checkout -b V7_0_3-branch origin/V7_0_3-branch
+cd doc
+make release
 {endcode}
-This script is pretty crude, and it'll only work with verion numbers (and directory names) of the form x.y.z, not vx.y.z. It puts the output files in /p/condor/public/binaries/glidein .
-The script expects to find the condor build tarballs either in the normal release directory in AFS or in a subdirectory of it named with the version numbers of the release. If anything goes wrong, ask Dan for help.
-
-1: Release source tarball. The source tarball is created every night as part of the nightly builds. Nick's =nmi-extract-results= script will extract it along will all of the binary tarballs. Otherwise, you can extract it yourself. If you look in the =rundir= of a given NMI runid, you should see a tarball in =userdir/common= named =results.tar.gz=, which contains the source tarball. Extract it like so:
+*:: move the symlink in /p/condor/public/html/manual for whatever release series you're changing to point at the new version.
 {code}
-tar zxvf results.tar.gz condor-X.Y.Z.tar.gz
+cd /p/condor/public/html/manual
+rm v7.0
+ln -s v7.0.3 v7.0
 {endcode}
-The source should be placed in =/p/condor/public/binaries/vX.Y/X.Y.Z= using the name "=condor_src-X.Y.Z-all-all.tar.gz=".
+
+
+{subsection: Release Condor}
+Once you start following these steps, Condor is available to the public.
 
 1: Tell the new download system about the new binaries.
 *:: All of the programs listed here take --help options, and the are all discussed to some extent in /p/condor/downloads/doc/operation.txt .
@@ -341,53 +363,38 @@
 $ download-gen-symlinks -v --mirror parrot
 {endcode}
 
-1: Verify that you can actually download a binary, unpack it, run condor_version and get the expected output.  Also download the source and one other binary.
-
-1: Is this a new series release (x.x.0)?  There are some additional details:
-
-*::Add a new license agreement.  This is usually just copying the old license to a new name.
-
-*:::Check out the condor-web CVS module.
-*:::cd condor-web/src/downloads
-*:::cp v7.3.license.html v7.4.license.html
-*:::edit v7.4.license.html to change the Condor version numebr.
-*:::cvs add v7.4.license.html
-*:::cvs ci
-*:::cd ../..
-*:::./generate_html src
+1: Verify the downloads work.
+1:: Download the binaries for one platform. Unpack them. Verify condor_version runs and returns the expected result.
+1:: Download the binaries for a different platform. Unpack them. Verify that they look right.
+1:: Download the source. Unpack it. Verify that it looks right.
 
-*::Update the download system's information.  Note that the warnings above download-versions being incompatible with the standard Python install stands; make sure you use a more recent Python.
+1: Push native packages into the repositories.
+1:: Find a machine with at least 3 GB scratch space
+1:: Obtain the RUNID and the Condor's branch name ( stable | development )
+1:: If a new platform (OS or Arch) is added, see this {wiki: CondorRepos documentation }
+1:: Check the mapping file to see if release platforms are correct
 {code}
-download-versions update --lic=http://parrot.cs.wisc.edu/v7.4.license.html \
-  --inst=http://www.cs.wisc.edu/condor/manual/v7.4/3_2Installation.html 7.4.0
+cat /p/condor/public/html/yum/files/mapping.txt
 {endcode}
-
-*::The download log files must exist; the download scripts won't create them if they don't.
+1:: Invoke the script to download packages and update the repositories. The script will wait for confirmation, proceed by press enter.
 {code}
-cd /p/condor/public/license
-touch licensers-v7.4 problem-v7.4 sendfile-v7.4
+/p/condor/public/html/yum/files/manage_repo.pl -i 24009 -s /scratch/kooburat -b stable
+
+Downloading from runid: 24009
+Using scratch folder: /scratch/kooburat/condor_repo
+Put packages into stable repos
+Enter to confirm or Ctrl^C to cancel
 {endcode}
 
-1: Set the release date (the date the new version hit the Condor web site) in the Condor Manual's Version History item devoted
-to identifying the release date.  OR, tell Karen exactly what
-date to use, and she'll do it for you. (#1236)
 
-1: Release the manual. Continuing the V7_0_3 example...
-*:: build the manual
-{code}
-git clone /p/condor/repository/CONDOR_DOC.git
-cd CONDOR_DOC
-git checkout -b V7_0_3-branch origin/V7_0_3-branch
-cd doc
-make release
-{endcode}
-*:: move the symlink in /p/condor/public/html/manual for whatever release series you're changing to point at the new version.
+1: XXX This step needs a refinement in the script intellect. XXX
+{linebreak}{linebreak}
+Create matching glidein tarballs, and install in /p/condor/public/html/glidein/binaries. This process is handled by running the following script, replacing 7.1.1 with the version you are releasing:
 {code}
-cd /p/condor/public/html/manual
-rm v7.0
-ln -s v7.0.3 v7.0
+make_glidein_tarballs 7.1.1
 {endcode}
-
+This script is pretty crude, and it'll only work with verion numbers (and directory names) of the form x.y.z, not vx.y.z. It puts the output files in /p/condor/public/binaries/glidein .
+The script expects to find the condor build tarballs either in the normal release directory in AFS or in a subdirectory of it named with the version numbers of the release. If anything goes wrong, ask Dan for help.
 
 
 

This work is supported by NSF under Cooperative Agreement OAC-2030508 as part of the PATh Project. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF. Site built using CVSTrac.