Fosdem 2005
Andi Barth <aba@not.so.argh.org>

• Packages are usually uploaded to unstable
• They enter testing after some rough testing
• Testing is declared stable from time to time (release)
• Experimental for packages not suitable for next release

• Ensure testing meets the release targets
• Ensure testing is not broken
• Keep the strings together (large packages, base packages, kernel, toolchain, ftp scripts, installer, ...)
• Collect and distribute informations

• Release Managers: Steve Langsak (vorlon), Collin Watson (Kamion)
• Release Assistents: Joey Hess (joeyh), Frank Lichtenheld (djpig), Andi Barth (aba)
• "Role Account": debian-release@lists.debian.org
• http://release.debian.org/

• Testing migration: britney
• Release critical bugs: http://bugs.debian.org/release-critical and http://bts.turmzimmer.net/details.php
• Security status: http://merkel.debian.org/~joeyh/...
• Lots of "normal" tools like madison, grep-dctrl, debdiff

• Packages are considered first after 2, 5 or 10 days
• Packages must be in sync on all archs
• Packages must have not more release critical bugs
• Packages must not break any packages currently in testing, except if packages has a newer version also going in

• Packages need to be approved
• Packages must not break any packages currently in testing, except if packages has a newer version also going in

• Main part is update_out, a python-script including c-code
• update_out starts with Packages lists, and returns a list for heidi
• heidi is called to update the tag database ("commits results")
• The tag database is used to generate Packages on the next cron.daily run ("dinstall run")

• Britneys results can by modified by hints
• Britney consists of two parts:
  • update excuses (out-of-sync, too young, RC-bugs, freeze, ...)
  • update output (breaks other packages)
• Britney is run shortly after cron.daily on ftp-master

• Remove packages
• (un)block packages
• Force packages
• Allow packages with cyclic dependencies to enter testing

• No critical or grave bugs (makes the package or system unusable, or introduces a security hole)
• Releaseable from the maintainer point of view
• Canonical list of further issues at release.debian.org (autobuildable, ...)

• Make sure all release critical issues are handled prior to release
• Any changes in testing must not push us back
• Get wise of the release blockers and tackle them

• Woody has 11 different kernel source packages - a mess for security updates
• There was a time where sarge had 17 different kernel source packages
• Through tracking and freezing of packages, sarge has now only 3 different source packages (one per 2.2, 2.4 and 2.6)
• This defined state also makes installer builds easier
• Current problem: we lack maintainers for arm and sparc - turnaround time for security issues is 2 months!

• Gnome 2.8 was uploaded first into experimental
• After building on all archs, and futher testing, Gnome 2.8 was accepted for upload into unstable
• Extremly smooth transition
• Most of the hard work done by the maintainers

• Sometimes, packages stuck together for testing migration
• Extremly bad in combination with buildd issues and library shlib bumps
• Lagging buildds create new dependencies on newer libs - longer waiting time
• Current example: gtk+2.0 - buildds run out of space, xfree86 harms buildd chroots, the transition is getting larger and larger

• Strategy: Get wise of the issues soon, use all tools to avoid it, in worst case do binary-only NMUs - and coordinate in time with buildd maintainers and ftp-masters
• Never upload a package into unstable that's not meant for testing!
• Maintainer should look at their package status before another upload

• Release Updates - at least once a month
• http://release.debian.org/

• debian-installer RC 3: needs just time
• Security support: needs updates of buildds and some related issues
• Some small issues (upgrade kernels, ...)
• About 100 Release Critical bugs: needs help - anyone can help
• We are heading for release - support us!