Differences between revisions 9 and 10
Revision 9 as of 2007-09-25 16:36:58
Size: 9371
Editor: Lunar
Comment: Remove a few "we"
Revision 10 as of 2007-09-25 16:42:58
Size: 9383
Editor: Lunar
Comment: Typographic fixes
Deletions are marked like this. Additions are marked like this.
Line 46: Line 46:
 * create new ${Release}Prep wiki page and start collecting changes for release announcement, ToDo, blockers, etc.  * create new ''${Release}Prep'' wiki page and start collecting changes for release announcement, ToDo, blockers, etc.
Line 54: Line 54:
 * follow what happens in *unstable*; maybe it will be needed to request that certain packages are temporarily blocked from migrating to testing; after all, the migration of one broken package can easily set back a carefully planned/prepared release by a week or more!  * follow what happens in '''unstable'''; maybe it will be needed to request that certain packages are temporarily blocked from migrating to testing; after all, the migration of one broken package can easily set back a carefully planned/prepared release by a week or more!
Line 58: Line 58:
 * make sure FTP-masters (elmo has done most BYHAND processing) know a D-I release is coming up (_private_ IRC is best; mails often get no response)  * make sure FTP-masters (elmo has done most BYHAND processing) know a D-I release is coming up (''private'' IRC is best; mails often get no response)
Line 67: Line 67:
 * when _all_ other arches are done too (arm and m68k are generally slowest), ask for final BYHAND  * when ''all'' other arches are done too (arm and m68k are generally slowest), ask for final BYHAND

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 [http://packages.debian.org/unstable/debian-installer/ every installer components] (udebs) to unstable.

  2. After a testing phase through [http://people.debian.org/~joeyh/d-i/build-logs.html daily netboot and weekly CDs/DVDs builds], manual coordination with the [http://lists.debian.org/debian-release/ release team] is done to migrate the udebs to testing.

  3. A new [http://packages.qa.debian.org/debian-installer debian-installer] package is uploaded to unstable, then built as usual by the buildd network.

  4. ftpmasters, through [http://ftp-master.debian.org/new.html BYHAND processing], install the result of these builds to the archive.

  5. Then, CDs and DVDs are built using debian-cd.
  6. The release is announced.

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 [http://svn.debian.org/wsvn/d-i/trunk/installer/doc/devel/package-upload.txt?op=file&rev=0&sc=0 doc/devel/package-upload.txt].

Kernel updates

TODO! But random notes:

  • See massbuild script in packages/kernel.

  • When updating a kernel, changes needs to be done in debian-installer/build. See revision 47254 for a canonical example.

Planning a release

In order to coordinate with every actors needed to get a release done, a schedule (see the one done for [http://lists.debian.org/debian-boot/2007/03/msg00115.html 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:

  • decide it is time to start working on a new release
  • decide which kernel we want; does that need an upload of kernel udebs?
  • check for major blockers; are all arches in sync and building OK
  • check with RMs if they have major migrations planned that could screw up testing for some time
  • check and upload pending changes; note that most changes should already be in unstable and tested by this time; minor translation updates can wait a bit, but components that have a large amount of translation updates should be uploaded now as well
  • create new ${Release}Prep wiki page and start collecting changes for release announcement, ToDo, blockers, etc.

  • decide if a string freeze is needed or not (consult with ChristianPerrier); check status of translations (any that should be activated/dropped?)

  • decide if an SVN freeze is needed (maybe only for some components or for the "installer" directory)
  • initial "heads-up" announcement to d-boot, d-release and d-cd with summary of above (BCC (!) d-ports; hopefully porters will wake up); separate mail to d-i18n to inform translators

  • run some installation tests (different methods and different arches!) to check for regressions
  • check for issues with installation of desktop task
  • start pushing versions of udebs that should be released to testing
  • follow progress of blockers and push for their resolution
  • follow what happens in unstable; maybe it will be needed to request that certain packages are temporarily blocked from migrating to testing; after all, the migration of one broken package can easily set back a carefully planned/prepared release by a week or more!

  • send periodic progress updates to relevant lists (do not just spam everybody by default); once a week is good, more often near the end
  • wash, rinse, repeat
  • when things are starting to look good (more testing!), announce timeline
  • make sure FTP-masters (elmo has done most BYHAND processing) know a D-I release is coming up (private IRC is best; mails often get no response)

BYHAND processing

One special action is getting the BYHAND processing done. Don't be too pushy, but be clear about what you want and when. Make sure that your preparations are good: FTP-masters don't like consecutive D-I build failures. The following receipe should work:

  • contact elmo on IRC about a week before planned upload of D-I
  • contact him immediately after upload as first BYHAND is needed to get D-I to the buildds for other arches
  • when most/main arches are done, ask for BYHAND for those
  • when all other arches are done too (arm and m68k are generally slowest), ask for final BYHAND

  • if nothing happens, remind at most once per 2 days, maybe see if another FTP-master (aj) can help if no response at all

Stable point releases

TODO! But random notes:

The debian-installer package needs to be uploaded with a build/sources.list.udeb.local with stable-proposed-updates added as an extra source.

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

  • playing with boot methods (e.g. introducing multiarch boot system)
  • solving disk space issues
  • playing with package ordering (e.g. to get a CD1 with what is needed for a full desktop)

Status of debian-cd

The software currently running on farbror is the [http://svn.debian.org/wsvn/debian-cd/trunk/ SVN version of debian-cd]. The [http://packages.debian.org/unstable/debian-cd package in unstable] is updated periodically.

The current code is based on a pretty huge Makefile and a lot of scattered shell scripts. A [http://wiki.debian.org/SummerOfCode2006?#head-e81137ee6145be9f62fc9fe81f6935684d856a9a 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 ?FransPop for the material that has been assembled here.