Dealing better with CD releases
Hi folks,
At the moment we have problems when we do releases including new
CD/DVD images, as you'll see from mailing list complaints about broken
links each time. Simon Paillard and I had some discussion about this
today on #debian-www and I've come up with a workflow that will
improve things, I think (see 2c below). Please feel free to point out
what I've missed... :-)
1. The Problem
We generate new CDs and DVDs for each point release. These are
published in the release area of cdimage.debian.org[1]. The image
filenames and the top-level directory are versioned for clarity, and
we add a "current" symlink in the debian-cd directory that points to
the most recent version. We move old trees of images into the archive
area[2] as each new build is published, We then prune most of the old
ISO images so we don't waste too much space - older images can be
recreated in the future using jigdo if necessary.
Mirrors automatically sync from the debian-cd directory, so it's not a
sane option to keep old images around there. Once we do a new build,
we need to move the old one aside into the archive.
We currently potentially have a window of a few hours of breakage, as
the web pages that point directly to the old images stay around for
quite a while. Even if they are updated directly in $VCS as we do a
release, the website is only rebuilt periodically from cron. Until
that happens, the stale pages will give 404 errors. This means pain on
the mailing lists.
We could *possibly* delay actually moving the new build into place
until the new pages go live, but there are problems there too: we
would rob the CD mirrors of any advance time to sync the images, plus
we could end up waiting for a few hours for the website update (not
ideal at the end of an already-long release process).
2. Possible solutions
a. Stop linking directly to the images, and go through a set of
symlinks instead. Potentially messy, and people may get mixed
sets. Probably difficult to set up on mirrors too?
b. Stop linking directly to the images, and go via redirects. Could
maybe be a central cgi, maybe even with intelligence to redirect
to good/close/fast/up-to-date mirrors. Could work, but needs
implementing. :-)
c. Do things in stages:
* Copy the old release to the archive area a few days before
release. Add a warning to users that a new build is due, and
they should be careful that their downloaded images are all
from one version.
* Once that archive copy is live, update the links to point to
the archive copy and push the new website.
* On the day of release, release as normal and update the web
pages in $VCS to point to the new release in "release". Remove
the "new build due" warning and add "new build just happened".
After the website is built, new users will see the new images.
* A few days/weeks later, prune the images in the old tree under
"archive". No current pages should be looking here, so we're
just dealing with stragglers.
d. Other ideas?
3. What do we do?
I'm thinking that solution b with a central redirector would be lovely
if possible, but may take a lot of effort. If that's not
feasible/desired, then should we try option c instead? Or, please
shout at me and tell me what obvious easy solution I'm missing here.
[1] http://cdimage.debian.org/debian-cd/
[2] http://cdimage.debian.org/cdimage/archive/
[3] http://www.debian.org/CD/http-ftp/
Cheers,
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
Reply to: