Differences between revisions 45 and 47 (spanning 2 versions)
Revision 45 as of 2022-01-07 18:01:32
Size: 9565
Comment:
Revision 47 as of 2023-09-21 05:12:16
Size: 9548
Editor: PaulWise
Comment: update ACC URL
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
 1. After a testing phase through [[http://d-i.debian.org/daily-images/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.  1. After a testing phase through [[https://d-i.debian.org/daily-images/build-logs.html|daily netboot and weekly CDs/DVDs builds]], manual coordination with the [[http:s//lists.debian.org/debian-release/|release team]] is done to migrate the udebs to testing.
Line 45: Line 45:
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. In order to coordinate with every actors needed to get a release done, a schedule (see the one done for [[https://lists.debian.org/debian-boot/2007/03/msg00115.html|Etch RC2]] as an example) needs to be done.
Line 100: Line 100:
The software currently running on pettersson is the [[http://anonscm.debian.org/viewvc/debian-cd/trunk/|SVN version of debian-cd]]. The [[DebianPkg:unstable/debian-cd|package in unstable]] is updated periodically. The software currently running on pettersson is the [[https://salsa.debian.org/images-team/debian-cd|git version of debian-cd]]. The [[DebianPkg:unstable/debian-cd|package in unstable]] is updated periodically.
Line 119: Line 119:
 * The [[http://lists.debian.org/debian-boot|debian-boot mailing list]]
 * Commits to the d-i repository: subscribe to the "cvs" keyword of the DebianPts:debian-installer package in the [[http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system|PTS]]
 * Daily and weekly [[http://d-i.debian.org/daily-images/build-logs.html|build logs]].
 * The [[https://lists.debian.org/debian-boot|debian-boot mailing list]]
 * Commits to the d-i repository: subscribe to the "cvs" keyword of the DebianPts:debian-installer package in the [[https://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system|PTS]]
 * Daily and weekly [[https://d-i.debian.org/daily-images/build-logs.html|build logs]].
Line 126: Line 126:
 * [[http://d-i.debian.org/testing-summary.html|udeb testing summary]] when handling the migration of installer components to testing  * [[https://d-i.debian.org/testing-summary.html|udeb testing summary]] when handling the migration of installer components to testing
Line 128: Line 128:
 * The [[http://lists.debian.org/debian-release|debian-release mailing list]] and `#debian-release` IRC channel
 * The [[http://lists.debian.org/debian-kernel|debian-kernel mailing list]] and `#debian-kernel` IRC channel
 * The [[http://people.debian.org/~igloo/status.php?email=&packages=linux-2.6&arches=|kernel migration status]]
 * The [[http://lists.debian.org/debian-mirrors|debian-mirrors mailing list]] to upload new versions of DebianPts:choose-mirror.
 * [[http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html|bandwidth statistics for cdimage.debian.org]] to see how much a new release is downloaded
 * The [[https://lists.debian.org/debian-release|debian-release mailing list]] and `#debian-release` IRC channel
 * The [[https://lists.debian.org/debian-kernel|debian-kernel mailing list]] and `#debian-kernel` IRC channel
 * The [[https://qa.debian.org/excuses.php?package=linux|Linux kernel migration status]]
 * The [[https://lists.debian.org/debian-mirrors|debian-mirrors mailing list]] to upload new versions of DebianPts:choose-mirror.
 * [[https://www.accum.se/technical/statistics/ftp/monitordata/index.html|bandwidth statistics for cdimage.debian.org]] to see how much a new release is downloaded

Translation(s): none


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 responsibilities to new people.

Process outline

  1. The debian-installer team uploads 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:

git clone git@salsa.debian.org:webmaster-team/webwml.git
git clone git@salsa.debian.org:webmaster-team/cron.git

Add a .wml file in the right directory, adding a Makefile (copying over is enough). Then render with make foo.en.html, run cron/scripts/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 regularly 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 via debuild is described in doc/devel/package-upload.txt. Or an updated one with sbuild under Uploading.

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 experience, the most important blocker has always been waiting for the targeted 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 i18n coordinator); check status of translations (any that should be activated/dropped?)
  • check if GI_LANGS or needed-characters need updating
  • decide if an GIT 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
  • update the translation-status file; make sure correct versions of udebs are used and to exclude components that are not actually used; if there's been no string freeze then it may be better to not update the file or to include an empty file (and thus disable warnings for incomplete translations)

  • make sure other relevant teams know a D-I release is coming up

Stable point releases

For releases before Lenny the debian-installer package needed to be uploaded with a build/sources.list.udeb.local with <codename>-proposed-updates added 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.

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 pettersson.debian.org.

Release managers and debian-cd hackers can be added to the debian-cd group by opening a ticket on RT and by being co-opted.

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 pettersson is the git version of debian-cd. The package in unstable is updated periodically.

New releases

Steve ?McIntyre usually takes care of the full CDs and DVDs builds done for a release. From past 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.

Checking pending requests from the Release Team

During last stages of release preparation, asking the release team to wait a bit before unblocking udebs is quite common. Then unblock requests are tagged 'd-i' to find them easily later on, which can be done using:

bts select package:release.debian.org status:open tag:d-i

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.


CategoryDebianInstaller