[Debconf6-data-commit] r498 - in procedings: . 18-releasing-in-time 18-releasing-in-time/orig

Mon Apr 10 21:37:37 UTC 2006

Author: tolimar
Date: 2006-04-10 21:37:35 +0000 (Mon, 10 Apr 2006)
New Revision: 498

Added:
   procedings/18-releasing-in-time/
   procedings/18-releasing-in-time/orig/
   procedings/18-releasing-in-time/orig/dc-release
   procedings/18-releasing-in-time/paper.tex
Modified:
   procedings/all.dvi
   procedings/all.tex
Log:
adding preliminary version of the 'releasing in time' paper

Added: procedings/18-releasing-in-time/orig/dc-release
===================================================================

--- procedings/18-releasing-in-time/orig/dc-release	2006-04-10 21:23:56 UTC (rev 497)
+++ procedings/18-releasing-in-time/orig/dc-release	2006-04-10 21:37:35 UTC (rev 498)
@@ -0,0 +1,143 @@
+Abstract
+
+Debian makes a "stable release" from time to time. This article shows how
+the background work looks like, what the major issues are and which
+improvements are planned; the intended audience are people knowing
+Debian closely.  The authors are the Debian Release Managers.
+More information is available at http://release.debian.org/
+
+
+Releasing means
+
+Sarge, the recent stable release of Debian, was published at beginning of
+June 2005 after about three years of hard development. The packages
+included in that release began their life in "unstable" (border cases are
+discussed later on). If they were fit enough, they were automatically
+copied to testing; "fit enough" is determined by a script called britney
+that pushes packages from unstable to testing that survived a minimum time
+(usually ten days), are not too broken themselves and do not break other
+packages in testing. Also, for packages not meant for the next stable
+release, there exists a suite called "experimental"; packages in that suite
+stay where they are and provide a playground for changes.
+
+The task of release management in Debian is to make sure that Debian can
+actually release. This sounds like a trivial statement. But in fact, that
+is our standard for all decisions. It is a hard fight to make sure that
+testing does not become more buggy. Also, a lot of other people need to be
+kept in the loop. Debian can only release if almost all people working on
+Debian believe it. That includes speaking with all the major teams
+(ftp-masters, installer, tool chain, (base) package maintainers, X, and so
+on).
+
+
+Behind the curtain
+
+Our most famous tool is "britney", the release team's working tool that
+updates testing from unstable. Other tools include the lists of release
+critical bugs, both at http://bugs.debian.org/release-critical and
+http://bts.turmzimmer.net/details.php. Also, there are scripts
+to track the security status on
+http://merkel.debian.org/~joeyh/testing-security.html. Of course, also the
+"normal" tools like madison, grep-dctrl and debdiff are used very much (and
+partly with small helper scripts).
+
+Britney starts considering packages after 10, 5 or 2 days, depending on how
+urgent the uploads since the last testing migration are. A package needs to
+be in sync on all architectures, and also be less buggy than the package
+currently in testing. Also, they must not break another package in testing.
+Britney is a python script, mixed with c-code, and available at
+http://ftp-master.debian.org/testing/update_out_code/
+
+Another way to get a package in testing is via testing-proposed-updates;
+that requires a release team member to manually approve the package. For
+sanity reasons (as the new package is more or less untested), it is
+preferred that packages go in via unstable. (Technically, also this part is
+taken care of by britney.)
+
+Britney is run shortly after the daily install on ftp-master, and uses the
+packages lists of testing and unstable as starting point. Britney produces
+a file suitable to synchronise the database with by heidi, an ftp-master's
+tool; the updated database can however be seen only after the next day's
+installer run. Also, britney produces the so called "testing excuses" and
+"testing output" that indicates why a package did (not) make it to testing.
+These explanations are deciphered on http://bjorn.haxx.se/debian/.
+
+The release team can influence the result of britney by usage of hints.
+They especially allow to remove (buggy) packages, freeze and thaw
+packages and ignore some of the usual preconditions for a testing migration.
+Britney can be re-run during the day if the needs arise.
+
+
+Release standards
+
+A package can only be part of the next stable release if it doesn't contain
+critical nor grave bugs (makes the package or the system unusable or
+introduces a security hole). It needs also to be releasable from the
+maintainers point of view, and it must meet the release standards. The
+canonical list of release standards is available from
+http://release.debian.org/.
+
+
+Why managing
+
+Woody has 11 different kernel source packages. Sarge had at one time 17
+different kernel source packages. Together with the kernel team, the
+release team was able to reduce the number of source packages to three, one
+per 2.2, 2.4 and 2.6 kernel major releases. This is quite important to be
+able to make security support. It also made the life of the installer team
+easier. However, that showed also an quite important problem - there are
+currently no maintainers for two architectures, which meant round trip
+times of about two months for security updates via unstable.
+
+
+Heading towards etch
+
+As of writing this, we are more than halfway through to release of etch.
+Working constantly towards etch has paid itself. We have a quite good working
+toolchain, a fair overview about the open issues, and a limited number
+of RC bugs. Etch should release beginning of December 2006.
+
+To make this target date realistic, the release team minimised the number of
+release blockers. A lot more wishes became "pet release goals" which means
+they will not be allowed to block etch, though it would be really nice to get
+them also be done in time for etch.
+
+Our list of release blockers contained the gcc-4.0 transition and the xorg
+transition, which are both done. Amd64 is now part of unstable and will become
+part of testing in time. Sorting out the documentation in main is slowly going
+on, but it is happening - with the recent General Resolution on the
+GFDL-documentation, also all open questions are settled for that. Some
+questions remain open with secure apt, but it is generally working. All other
+wishes (as nice and useful they might be) were decided to not be release
+blockers.
+
+
+Architecture status
+
+For the first time, a formal requirement for release architectures was
+defined. We noticed quite fast that the requirements alone improved handling
+of the architectures where we had issues with, and it also showed where the
+issues were basically only on the top, or if the problems are in reality too
+large for keeping the architecture in the next stable release.
+
+The basic core of the architecture requirements are: Does the architecture
+add more value to Debian, or is it rather only a source of pain? If it's the
+first, it is welcome. If it's the second, we can only afford a certain amount
+of pain. On this high-level, the necesserity of architecture requirements are
+undoubted. However, in going more into detail, there were some discussions.
+One has to draw a decision line somewhere - for example, whether 50 users are
+required, and not 40 or 60 is a wilfull decision. That one has to put up some
+requirement on having real users is natural and correct.
+
+In the end, we think our requirements were pretty sane. We found out that most
+architectures managed to go through easy enough, and the remaining
+architectures have severe issues like no debian-installer.
+
+
+Timeline
+
+Soon, the first parts of debian will be frozen - at the beginning of July the
+toolchain, the kernels and base will be the first ones. Soon after that, the
+final release candidate of the debian installer will be done, and the
+installer will be frozen. Two months later, the general freeze will set in, so
+that we can release beginning of December.

Added: procedings/18-releasing-in-time/paper.tex
===================================================================
--- procedings/18-releasing-in-time/paper.tex	2006-04-10 21:23:56 UTC (rev 497)
+++ procedings/18-releasing-in-time/paper.tex	2006-04-10 21:37:35 UTC (rev 498)
@@ -0,0 +1,143 @@
+\section{Abstract}
+
+Debian makes a "stable release" from time to time. This article shows how
+the background work looks like, what the major issues are and which
+improvements are planned; the intended audience are people knowing
+Debian closely.  The authors are the Debian Release Managers.
+More information is available at \url{http://release.debian.org/}
+
+
+\section{Releasing means}
+
+Sarge, the recent stable release of Debian, was published at beginning of
+June 2005 after about three years of hard development. The packages
+included in that release began their life in "unstable" (border cases are
+discussed later on). If they were fit enough, they were automatically
+copied to testing; "fit enough" is determined by a script called britney
+that pushes packages from unstable to testing that survived a minimum time
+(usually ten days), are not too broken themselves and do not break other
+packages in testing. Also, for packages not meant for the next stable
+release, there exists a suite called "experimental"; packages in that suite
+stay where they are and provide a playground for changes.
+
+The task of release management in Debian is to make sure that Debian can
+actually release. This sounds like a trivial statement. But in fact, that
+is our standard for all decisions. It is a hard fight to make sure that
+testing does not become more buggy. Also, a lot of other people need to be
+kept in the loop. Debian can only release if almost all people working on
+Debian believe it. That includes speaking with all the major teams
+(ftp-masters, installer, tool chain, (base) package maintainers, X, and so
+on).
+
+
+\section{Behind the curtain}
+
+Our most famous tool is "britney", the release team's working tool that
+updates testing from unstable. Other tools include the lists of release
+critical bugs, both at \url{http://bugs.debian.org/release-critical} and
+\url{http://bts.turmzimmer.net/details.php}. Also, there are scripts
+to track the security status on
+\url{http://merkel.debian.org/\~joeyh/testing-security.html}. Of course, also the
+"normal" tools like madison, grep-dctrl and debdiff are used very much (and
+partly with small helper scripts).
+
+Britney starts considering packages after 10, 5 or 2 days, depending on how
+urgent the uploads since the last testing migration are. A package needs to
+be in sync on all architectures, and also be less buggy than the package
+currently in testing. Also, they must not break another package in testing.
+Britney is a python script, mixed with c-code, and available at
+\url{http://ftp-master.debian.org/testing/update\_out\_code/}
+
+Another way to get a package in testing is via testing-proposed-updates;
+that requires a release team member to manually approve the package. For
+sanity reasons (as the new package is more or less untested), it is
+preferred that packages go in via unstable. (Technically, also this part is
+taken care of by britney.)
+
+Britney is run shortly after the daily install on ftp-master, and uses the
+packages lists of testing and unstable as starting point. Britney produces
+a file suitable to synchronise the database with by heidi, an ftp-master's
+tool; the updated database can however be seen only after the next day's
+installer run. Also, britney produces the so called "testing excuses" and
+"testing output" that indicates why a package did (not) make it to testing.
+These explanations are deciphered on \url{http://bjorn.haxx.se/debian/}.
+
+The release team can influence the result of britney by usage of hints.
+They especially allow to remove (buggy) packages, freeze and thaw
+packages and ignore some of the usual preconditions for a testing migration.
+Britney can be re-run during the day if the needs arise.
+
+
+\section{Release standards}
+
+A package can only be part of the next stable release if it doesn't contain
+critical nor grave bugs (makes the package or the system unusable or
+introduces a security hole). It needs also to be releasable from the
+maintainers point of view, and it must meet the release standards. The
+canonical list of release standards is available from
+\url{http://release.debian.org/}.
+
+
+\section{Why managing}
+
+Woody has 11 different kernel source packages. Sarge had at one time 17
+different kernel source packages. Together with the kernel team, the
+release team was able to reduce the number of source packages to three, one
+per 2.2, 2.4 and 2.6 kernel major releases. This is quite important to be
+able to make security support. It also made the life of the installer team
+easier. However, that showed also an quite important problem - there are
+currently no maintainers for two architectures, which meant round trip
+times of about two months for security updates via unstable.
+
+
+\section{Heading towards etch}
+
+As of writing this, we are more than halfway through to release of etch.
+Working constantly towards etch has paid itself. We have a quite good working
+toolchain, a fair overview about the open issues, and a limited number
+of RC bugs. Etch should release beginning of December 2006.
+
+To make this target date realistic, the release team minimised the number of
+release blockers. A lot more wishes became "pet release goals" which means
+they will not be allowed to block etch, though it would be really nice to get
+them also be done in time for etch.
+
+Our list of release blockers contained the gcc-4.0 transition and the xorg
+transition, which are both done. Amd64 is now part of unstable and will become
+part of testing in time. Sorting out the documentation in main is slowly going
+on, but it is happening - with the recent General Resolution on the
+GFDL-documentation, also all open questions are settled for that. Some
+questions remain open with secure apt, but it is generally working. All other
+wishes (as nice and useful they might be) were decided to not be release
+blockers.
+
+
+\section{Architecture status}
+
+For the first time, a formal requirement for release architectures was
+defined. We noticed quite fast that the requirements alone improved handling
+of the architectures where we had issues with, and it also showed where the
+issues were basically only on the top, or if the problems are in reality too
+large for keeping the architecture in the next stable release.
+
+The basic core of the architecture requirements are: Does the architecture
+add more value to Debian, or is it rather only a source of pain? If it's the
+first, it is welcome. If it's the second, we can only afford a certain amount
+of pain. On this high-level, the necesserity of architecture requirements are
+undoubted. However, in going more into detail, there were some discussions.
+One has to draw a decision line somewhere - for example, whether 50 users are
+required, and not 40 or 60 is a wilfull decision. That one has to put up some
+requirement on having real users is natural and correct.
+
+In the end, we think our requirements were pretty sane. We found out that most
+architectures managed to go through easy enough, and the remaining
+architectures have severe issues like no debian-installer.
+
+
+\section{Timeline}
+
+Soon, the first parts of debian will be frozen - at the beginning of July the
+toolchain, the kernels and base will be the first ones. Soon after that, the
+final release candidate of the debian installer will be done, and the
+installer will be frozen. Two months later, the general freeze will set in, so
+that we can release beginning of December.

Modified: procedings/all.dvi
===================================================================
(Binary files differ)

Modified: procedings/all.tex
===================================================================
--- procedings/all.tex	2006-04-10 21:23:56 UTC (rev 497)
+++ procedings/all.tex	2006-04-10 21:37:35 UTC (rev 498)
@@ -42,6 +42,11 @@
 
 \part{Talks}
 
+\chapter[PREL: releasing in time - etch in December 06]
+  {releasing in time - etch in December 06\\
+  \small{by Andi Barth and Steve Langasek}}
+\input{18-releasing-in-time/paper}
+
 \chapter[Nobody expects the Finnish inquisition]
   {Nobody expects the Finnish inquisition: Confessions of a Debian package torturer\\
   \small{by Lars Wirzenius (liw at iki.fi)}}


