Tagging a New QWG Release

Table of Contents

1. Updating templates/branches
2. Tagging a New Production Release
   1. Template validation
   2. Release Announcement

Instructions below are guidelines for better consistency between contributors to QWG templates and for easier history browsing of modifications.

Modification of QWG templates should be done directly in the trunk. This is the main source of information. In addition to the trunk, they are 2 branches that are in fact copy of the trunk :

• branches/version : this is a middleware version oriented view of the trunk contents (e.g. LCG-2.7.0) and doesn't contain all the SCB base (external/ tools, ant related files...).
• tags : there is one entry per tagged release. This entry is done by svn cp of the relevant branch in templates/branches).

Tagging a new release is a 2 steps process

• Merging relevant changes from trunk to a specific branch.
• Tagging the branch revision as a production release

Updating templates/branches

No change must be done directly in a branch (branches/version), they should go to the trunk first (see Updating the repository). Branch changes must be merge of changes from trunk and the commit message must state clearly the trunk revision interval corresponding to the commit. Generally, a branch commit includes several unrelated changes from trunk : this is not a problem as long as the commit message states it.

The easiest way to incorporate relevant changes from the trunk into a branch is to use svn merge with a revision interval starting at the last revision merged into the branch (you can get it from the last commit message).

Because a branch is a selected view of the trunk (not everything is in), it is normal to receive warnings about missing targets during the merge : this happens for every part of the trunk that is updated (not created) by the merge but doesn't exist in the working copy of the branch. If you have difficulties to do the merge operation at the top level of the working area, merge each sub-directory separatly.

Don't worry too much anyway : before committing the merge, you can revert anything with svn revert (after the commit, you need to do a reverse merge to cancel your change, look at ​Subversion Book for details).

In your commit message, try to use the TracWiki syntax, in particular for bullets, as the rendering is better when browsing the repository with Trac. A typical commit message is :

Merging changes from trunk:686-723, mainly
 * Upgrade of gLite to 3.0.2 (r686)
 * Security update for gLite 3.0.2 (proxy creation, Sept. 06) (r716)
 * VO : update VO ESR configuration (VOMS configuration), add VO proactive (r686, r713)
 * Fix Torque submit filter (account information) (r715)
 * Add fetch-crl to several machine types (r714)
 * Miscellanous reorganization (add standard/pan, move repository_common.tpl fro
m glite-3.0.0 to clusters/example) (r712)
 * Add sharutils (needed on WNs) (r694)
 * Rework of MPI-CH configuration, including re-enabling LAM installation (r693)
 * Miscellanous updates to standard/ (including ncm-accounts upgrade to 2.0.31) (r718)

In this message, you can see that each change is followed by a revision number (or a list of revision numbers) between (). With such a syntax (r + a number), when displayed with Trac, it gives a link to the revision.

It is generally easier to enter such a message in a file and use -F instead of -m in the commit command.

Tagging a New Production Release

Tagging a new production release involves :

• Creating the release tag in templates/tags release
• Producing a tarball for the release

Tags are stored under branch templates/tags in the repository. Each tag in this branch must be a copy from the relevant branch, done with svn cp command, for easier identification of the branch version that has been tagged. There should be no commit in a tag revision (you should not do svn co of a tag followed by svn ci, even if nothing prevent it).

A tag name is formed by a prefix designing the middleware variant (e.g. LCG, gLite) and a version number based on the middleware release the templates provide. For example :

gLite-3.0.0-4 : 4th release of templates for gLite 3.0.0
gLite-3.0.2-1 : first release of templates for gLite 3.0.2

As with branch commit, the message must be explicit about the main changes introduced and use the format proposed for branch commit.

After creating the new tag, it is necessary to build a tarball corresponding to the release and attach it to the Download page. To create the tarball, first do a svn export of the tag and then a compressed tar of the export. For example, to create the tarball corresponding to release gLite-3.0.2-2 :

cd /tmp
svn export https://svn.lal.in2p3.fr/LCG/QWG/templates/tags/gLite-3.0.2-2
tar -czf gLite-3.0.2-2.tar.gz gLite-3.0.2-2

Template validation

Before tagging a new release, be sure to check that examples provided compile successfully. To check this, follow the following steps

• Create a vanilla SCDB
• Load templates to be checked into the vanilla SCDB (with Subversion client or using the tarball)
• Compile with ant, the standard tool for compiling with SCDB

To do these checks, you don't need to run a Subversion server. You just need a Subversion client, Java for running ant and a PAN compiler (be sure to use a recent version of panc).

Below is a check example for gLite 3.0.0 branch (replace with the appropriate one) :

mkdir /tmp/template-validation
cd /tmp/template-validation
svn export https://svn.lal.in2p3.fr/LCG/QWG/SCDB/trunk .
cd cfg
# In the next command, change the branch to the appropriate one
svn export --force https://svn.lal.in2p3.fr/LCG/QWG/templates/branches/gLite-3.0.0 .
cd ..
external/ant/bin/ant

Tool check-compile.sh is executing this set of commands and can be used instead of entering command manually. Use option -h to get the list of available options.

The most common problem when checking templates is the RPM not found error. This is generally due to some RPMs being upgraded/added by new templates. This can easily be solved by updating the relevant repository template in sites/example/repository .

Release Announcement

After tagging a release, it is a good practice to announce it. This involved sending emails to specific mailing lists and updating the QWG wiki.

Mailing list to send release announcement to are :

• Quattor users mailing list : project-lcg-gdb-quattor-wg@…
• QWG mailing list : mailto:project-quattor@… project-quattor@…]

Update of the QWG wiki involves :

• Updating the main page.
• Updating the milestone entry (Roadmap menu) corresponding to the release or, if none exists, create a new one and rename existing milestones if relevant.
• Updating the appropriate release notes by adding one entry to the release history as a link to the relevant milestone.