This page describes the process of making a release of the DebianInstaller. Its primary goal is to be a memento for the release managers of the DebianInstaller and to ease the transfer of these responsabilities to new people.

This page is currently not complete and have not been proofread by experienced people.

Process outline

  1. The debian-installer team upload every installer components (udebs) to unstable.

  2. After a testing phase through daily netboot and weekly CDs/DVDs builds, manual coordination with the release team is done to migrate the udebs to testing.

  3. A new debian-installer package is uploaded to unstable, then built as usual by the buildd network.

  4. ftpmasters copy stuff from the sid directories (dak copy-installer).
  5. The release team “urgents” the debian-installer source package, so that the source of the d-i images gets into testing.
  6. Then, CDs and DVDs are built using debian-cd.
  7. Images are put in some semi-public space where developers can perform last-minute checks.
  8. The release is announced: mail to dda@/dd@, and website update.

Announcing the release

Gathering package changelogs: scripts/prepare-release-announce to the rescue. A full example is available in the code.

Web site checkout (replace “kibi” with the proper username):

sudo apt-get install cvs
cvs -d :pserver:anonymous@anonscm.debian.org:/cvs/webwml login
cvs -d :ext:kibi@cvs.debian.org:/cvs/webwml checkout webwml
cvs -d :ext:kibi@cvs.debian.org:/cvs/webwml checkout cron/scripts/validate

Add a .wml file in the right directory, adding a Makefile (copying over is enough). Then render with make foo.en.html, run validate on the generated html file.

Update errata.wml; cat the news and errata to send the announce. Finally update index.wml and images.data to point to the new release.

Releasing DebianInstaller components

Even if any member of the team can upload a DebianInstaller component (udebs are no different than normal packages in this regard), release managers are expected to regularily test and upload the version in the repository.

The list-unreleased script is helpful to get an overview of packages which need an upload.

The package upload process is described in doc/devel/package-upload.txt.

Kernel updates

TODO! But random notes:

TODO: Also quoting Frans :

The procedure in the past (as I saw it at least) was: - Joey would check for changes in x86, thereby also catching most/all

- Then he or I would request porters to do their own arches. In some

- Additional kernel-wedge uploads would be done as needed.

Note that for some arches there has not been a great involvement from porters and I've done the last updates for sparc, hppa and s390 myself. Which was possible as those are relatively stable arches, sometimes with some help on IRC from porters.

Planning a release

In order to coordinate with every actors needed to get a release done, a schedule (see the one done for Etch RC2 as an example) needs to be done.

From previous experinces, the most important blocker has always been waiting for the targetted kernel to migrate to testing. To announce a timeline it is a good idea to know when that migration will happen. Quite a few times it has been necessary to negotiate with RMs about this, either to speed up a kernel migration or, just as important, to _delay_ one in order to make a release with the version in testing.

Here is the procedure that was followed by FJP:

BYHAND processing

BYHAND processing is now done automatically for debian-installer (and also for tasksel). If it should not happen, then contact FTP-masters.

Stable point releases

TODO! But random notes:

For releases before Lenny the debian-installer package needs to be uploaded with a build/sources.list.udeb.local with <codename>-proposed-updatesadded as an extra source.

For later releases this is automated by the USE_PROPOSED_UPDATES in the debian/rules file, which should only need to be changed for the first upload to stable for a given Debian release.

Erratas

random note: doc-update at release punkt debian punkt net

Relationships with the debian-cd team

The debian-cd team is responsible for building out the full CDs and DVDs which can be used to install Debian systems.

The build box

CDs and DVDs builds, both for the weekly builds and for releases, are currently done on farbror.acc.umu.se.

Release managers and debian-cd hackers can have access to the deb-cd user by providing an SSH key to Steve ?McIntyre. Its often the best way to debug build problems.

Example of tasks

Status of debian-cd

The software currently running on farbror is the SVN version of debian-cd. The package in unstable is updated periodically.

The current code is based on a pretty huge Makefile and a lot of scattered shell scripts. A rewrite in Python was done during Google Summer of Code 2006 by Carlos Parra Camargo.

Unfortunately this happened during the preparation of the Etch release. In the meantime, a lot of new features were added to the code (e.g. multiarch CDs) which have not been ported to the Python version.

The debian-cd team intends to move to the new code base at some point, but has no precise timeframe for it.

New releases

Steve ?McIntyre usually takes care of the full CDs and DVDs builds done for a release. From is experience, it mostly boils down to a sleepless night.

Even if he's normally available through a reasonably short notice, warning him 3 weeks ago sounds like a good timeframe.

Data sources

Here is a list of data that needs to be tracked in order to make nice releases:


Many thanks to JoeyHess and Frans Pop for the material that has been assembled here.