Sage Release Management

The first rule of release management, is that the release manager is in charge. They get to decide on whether or not any ticket goes into the next Sage release, gets closed, etc. If they feel like not merging a particular patch, spkg, or conribution from somebody, that is their right. If you don't like it, wait for another release manager. (Of course, the BDFL has final say.)

Overview

These are some notes on various aspects of the Sage release process. It is also worth reading Eric S. Raymond's article Software Release Practice HOWTO. The following serve as introductory materials to beginning release managers:

sage -merge/sage-apply-ticket

This is a new script written by Craig Citro and Nick Alexander. It tries to automate much of the process of downloading patches from trac, merging them, and running doctests. Here's a quick rundown of usage:

Notes

More options

Standard use cases

sage -merge todo list

Doctesting on the sage.math cluster

When you run doctests with "make ptest" or "make ptestlong", Sage will by default use a number of threads equal to the number of cores. On sage.math, this is often inadvisable, so when running doctests, always use something like make ptest NUM_THREADS=16 (replace 16 with a sensible number; 24 minus the current load average will usually be considered "sensible")

Building on boxen.math

The machine boxen.math hosts a number of virtual machines that run various 32- and 64-bit Linux distributions. Here is a list of supported Linux distributions on boxen.math:

The following Windows XP virtual machines are also hosted on boxen.math:

Before starting the build process on the build farm, first login to boxen.math using either one of two methods shown below: 

$ ssh -C -x -a <username>@boxen                      # use this syntax if you're 
                                                     # already login to the Sage cluster

$ ssh -C -x -a <username>@boxen.math.washington.edu  # this syntax is required if 
                                                     # you're not already login to the Sage cluster

Replace <username> with your username. Next, ensure that you have the privilege to run as the username wstein. If you are able to sudo as username wstein, then do so as follows: 

$ sudo -H -u wstein bash

The option -H would set your home directory to that of username wstein, the option -u wstein is the username you want to sudo as (in this case it's wstein), and bash would login with the Bash shell. Delete all source tarballs in /home/wstein/farm/src and place the source tarball you want to build in /home/wstein/farm/src. Navigate to the directory /home/wstein/farm and run ./go, which would actually start the build process on the Linux virtualized guests. The results would appear in /home/wstein/farm/out/<version_number>/ as they complete. You can watch the build progress on all virtualized guests using 

$ tail -f /home/wstein/farm/out/<version_number>/*

or watch the progress of a virtualized guest as follows: 

$ tail -f /home/wstein/farm/out/<version_number>/<guest_name>.out

Press Control-C to quit watching.

Known issues:

Building on SkyNet

Use /home/wstein/farm/go_skynet to start the build on SkyNet. The files appear in /home/wstein/build/logs/<version_number>. As of 4.0.2, eno and cleo works fine, but the rest would fail. You can restart the builds on menas, cicero, and iras by hand, and they should complete just fine.

Releasing source tarballs and binaries

You can use sage -sdist <version> to create a new source tarball, and sage -bdist <version> to create a new binary. These scripts are very particular about the formatting of version strings, see trac #6338. Both sage -sdist <version> and sage -bdist <version> take care of updating the Sage banner for you so you don't need to manually edit the file SAGE_ROOT/local/bin/sage-banner.

It's very useful to put the various bits of the release in /home/release on sage.math, and to follow a directory structure somewhat like this: http://sage.math.washington.edu/home/release/sage-4.5.2.alpha0 which includes a sage.math binary, source tarball, md5sums, a directory for upgrading, and the text of the release note. It's also nice to put Solaris/t2.math binaries there, too. Using a standard location for releases makes it easier for developers to follow things.

NOTE: When cutting a new rc or alpha release, make sure to always produce binaries for sage.math. This also applies to any stable release -- several people will make use of these. The download page for 64-bit Linux contains a text file called sage-x.y.z-sage.math.washington.edu-x86_64-Linux.txt. This file lists directories on sage.math where sage.math account holders are able to get a copy of a binary specifically built for that machine.

NOTE: After an sdist, one needs to call sage -br to rebuild the library. This is annoying, and should be fixed.

Release checklist

Here's a list of things you want to make sure to do before every release:

Optional Packages

If you don't know how, get a more senior release manager to do this part for you.