+ <sect id="collaborative-maint">
+ <heading>Collaborative maintenance</heading>
+ <p>
+"Collaborative maintenance" is a term describing the sharing of Debian
+package maintenance duties by several people. This collaboration is
+almost always a good idea, since it generally results in higher quality and
+faster bug fix turnaround time. It is strongly recommended that
+packages with a priority of <tt>Standard</tt> or which are part of
+the base set have co-maintainers.</p>
+ <p>
+Generally there is a primary maintainer and one or more
+co-maintainers. The primary maintainer is the person whose name is listed in
+the <tt>Maintainer</tt> field of the <file>debian/control</file> file.
+Co-maintainers are all the other maintainers.</p>
+ <p>
+In its most basic form, the process of adding a new co-maintainer is
+quite easy:
+<list>
+ <item>
+ <p>
+Setup the co-maintainer with access to the sources you build the
+package from. Generally this implies you are using a network-capable
+version control system, such as <prgn>CVS</prgn> or
+<prgn>Subversion</prgn>.</p>
+ </item>
+ <item>
+ <p>
+Add the co-maintainer's correct maintainer name and address to the
+<tt>Uploaders</tt> field in the global part of the
+<file>debian/control</file> file.
+<example>
+Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
+</example>
+</p>
+ </item>
+ <item>
+ <p>
+Using the PTS (<ref id="pkg-tracking-system">), the co-maintainers
+should subscribe themselves to the appropriate source package.</p>
+ </item>
+ </list></p>
+ <p>
+Collaborative maintenance can often be further eased with the use of
+tools on Alioth (see <ref id="alioth">).
+ </sect>
+
+ <sect id="testing">
+ <heading>The testing distribution</heading>
+ <p>
+ <sect1 id="testing-basics">
+ <heading>Basics</heading>
+ <p>
+Packages are usually installed into the `testing' distribution after they
+have undergone some degree of testing in unstable.
+ <p>
+They must be in sync on all architectures and
+mustn't have dependencies that make them uninstallable; they also have to
+have generally no known release-critical bugs at the time they're
+installed into testing.
+This way, `testing' should always be close to being a release candidate.
+Please see below for details.
+ <sect1 id="testing-unstable">
+ <heading>Updates from unstable</heading>
+ <p>
+The scripts that update the <em>testing</em> distribution are run each
+day after the installation of the updated packages. They generate the
+<file>Packages</file> files for the <em>testing</em> distribution, but
+they do so in an intelligent manner; they try to avoid any inconsistency
+and to use only non-buggy packages.
+ <p>
+The inclusion of a package from <em>unstable</em> is conditional on
+the following:
+<list>
+ <item>
+The package must have been available in <em>unstable</em> for 2, 5 or 10
+days, depending on the urgency (high, medium or low).
+Please note that the urgency is sticky, meaning that the highest
+urgency uploaded since the previous testing transition is taken into account.
+Those delays may be doubled during a freeze, or testing transitions may be
+switched off altogether;
+ <item>
+It must have fewer release-critical bugs than the version currently available
+in <em>testing</em>;
+ <item>
+It must be available on all architectures on which it has previously
+been built in unstable. <ref id="madison"> may be of interest to
+check that information;
+ <item>
+It must not break any dependency of a package which is already available
+in <em>testing</em>;
+ <item>
+The packages on which it depends must either be available in <em>testing</em>
+or they must be accepted into <em>testing</em> at the same time (and they will
+if they fulfill all the necessary criteria);
+</list>
+ <p>
+To find out whether a package is progressing into testing or not, see the
+testing script output on the <url name="web page of the testing distribution"
+id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
+which is in the <package>devscripts</package> package. This utility can
+easily be used in a <manref name="crontab" section="5"> to keep yourself
+informed of the progression of your packages into <em>testing</em>.
+ <p>
+The <file>update_excuses</file> file does not always give the precise reason
+why the package is refused; you may have to find it on your own by looking
+for what would break with the inclusion of the package. The
+<url id="&url-testing-maint;" name="testing web page"> gives some more
+information about the usual problems which may be causing such troubles.
+ <p>
+Sometimes, some packages never enter <em>testing</em> because the set of
+inter-relationship is too complicated and cannot be sorted out
+by the scripts. See below for details.
+ <p>
+Some further dependency analysis is shown on
+<url id="http://bjorn.haxx.se/debian/"> — but be warned,
+this page also shows build dependencies which
+are not considered by britney.
+
+ <sect2 id="outdated">
+ <heading>out-of-date</heading>
+ <p>
+<!-- FIXME: better rename this file than document rampant professionalism? -->
+For the testing migration script, "outdated" means: There are different
+versions in unstable for the release architectures (except for the
+architectures in fuckedarches; fuckedarches is a list of architectures
+that don't keep up (in update_out.py), but currently, it's empty).
+"outdated" has nothing whatsoever to do with the architectures this package
+has in testing.
+ <p>
+Consider this example:
+ <p>
+ <example>
+foo | alpha | arm
+---------+-------+----
+testing | 1 | -
+unstable | 1 | 2
+</example>
+ <p>
+The package is out of date on alpha in unstable, and will not go to
+testing. And removing foo from testing would not help at all, the package
+is still out of date on alpha, and will not propagate to testing.
+ <p>
+However, if ftp-master removes a package in unstable (here on arm):
+ <p>
+ <example>
+foo | alpha | arm | hurd-i386
+---------+-------+-----+----------
+testing | 1 | 1 | -
+unstable | 2 | - | 1
+ </example>
+ <p>
+In this case, the package is up to date on all release architectures in
+unstable (and the extra hurd-i386 doesn't matter, as it's not a release
+architecture).
+ <p>
+Sometimes, the question is raised if it is possible to allow packages in
+that are not yet built on all architectures: No. Just plainly no. (Except
+if you maintain glibc or so.)
+
+ <sect2 id="removals">
+ <heading>Removals from testing</heading>
+ <p>
+Sometimes, a package is removed to allow another package in: This happens
+only to allow <em>another</em> package to go in if it's ready in every other
+sense. Suppose e.g. that <em>a</em> conflicts with the new version of
+<em>b</em>; then <em>a</em> may be removed to allow <em>b</em> in.
+ <p>
+Of course, there is another reason to remove a package from testing: It's
+just too buggy (and having a single RC-bug is enough to be in this state).
+
+ <sect2 id="circular">
+ <heading>circular dependencies</heading>
+ <p>
+A situation which is not handled very well by britney is if package <em>a</em>
+depends on the new version of package <em>b</em>, and vice versa.
+ <p>
+An example of this is:
+ <p>
+ <example>
+ | testing | unstable
+--+-----------------+------------
+a | 1; depends: b=1 | 2; depends: b=2
+b | 1; depends: a=1 | 2; depends: a=2
+ </example>
+ <p>
+Neither package <em>a</em> nor package <em>b</em> is considered for update.
+ <p>
+Currently, this requires some manual hinting from the release team.
+Please contact them by sending mail to &email-debian-release; if this
+happens to one of your packages.
+
+
+ <sect2>
+ <heading>influence of package in testing</heading>
+ <p>
+Generally, there is nothing that the status of a package in testing means
+for transition of the next version from unstable to testing, with two
+exceptions: If the RC-bugginess of the package goes down, it may go in
+even if it is still RC-buggy. The second exception is if the version
+of the package in testing is out of sync on the different arches: Then
+any arch might just upgrade to the version of the source package;
+however, this can happen only if the package was previously forced
+through, the arch is in fuckedarches, or there was no binary package of that
+arch present in unstable at all during the testing migration.
+ <p>
+In summary this means: The only influence that a package being in testing
+has on a new version of the same package is that the new version might
+go in easier.
+
+ <sect2 id="details">
+ <heading>details</heading>
+ <p>
+If you are interested in details, this is how britney works:
+ <p>
+The packages are looked at to determine whether they are valid
+candidates. This gives the "update excuses". The most common reasons
+why a package is not considered are too young, RC-bugginess, and out of
+date on some arches. For this part, the release managers have hammers
+of any size to force britney to consider a package. (Also, the base
+freeze is coded in that part of britney.) (There is a similar thing
+for binary-only updates, but this is not described here. If you're
+interested in that, please peruse the code.)
+ <p>
+Now, the more complex part happens: Britney tries to update testing with
+the valid candidates; first, each package alone, and then larger and even
+larger sets of packages together. Each try is accepted if unstable is not
+more uninstallable after the update than before. (Before and after this part,
+some hints are processed; but as only release masters can hint, this is
+probably not so important for you.)
+ <p>
+If you want to see more details, you can look it up on
+merkel:/org/ftp.debian.org/testing/update_out/ (or there in
+~aba/testing/update_out to see a setup with a smaller packages file). Via
+web, it's at <url
+id="http://ftp-master.debian.org/testing/update_out_code/">
+ <p>
+The hints are available via <url
+id="http://ftp-master.debian.org/testing/hints/">.
+
+
+ <sect1 id="t-p-u">
+ <heading>Direct updates to testing</heading>
+ <p>
+The testing distribution is fed with packages from unstable according to the rules
+explained above. However, in some cases, it is necessary to upload
+packages built only for testing. For that, you may want to
+upload to <em>testing-proposed-updates</em>.
+ <p>
+Keep in mind that packages uploaded there are not automatically processed, they
+have to go through the hands of the release manager. So you'd better have a good
+reason to upload there. In order to know what a good reason is in the
+release managers' eyes, you should read the instructions that they regularly
+give on &email-debian-devel-announce;.
+ <p>
+You should not upload to <em>testing-proposed-updates</em> when you can update your
+packages through <em>unstable</em>. If you can't (for example because you have a
+newer development version in unstable), you may use this facility,
+but it is recommended that you ask for authorization from
+the release manager first.
+Even if a package is
+frozen, updates through unstable are possible, if the upload via unstable
+does not pull in any new dependencies.
+ <p>
+Version numbers are usually selected by adding the codename of the testing
+distribution and a running number, like 1.2sarge1 for the first upload
+through testing-proposed-updates of package version 1.2.
+ <p>
+Please make sure you didn't miss any of these items in your upload:
+<list>
+<item> Make sure that your package really needs to go through
+<em>testing-proposed-updates</em>, and can't go through unstable;
+<item> Make sure that you included only the minimal amount of changes;
+<item> Make sure that you included an appropriate explanation in the
+changelog;
+<item> Make sure that you've written <em>testing</em> or
+<em>testing-proposed-updates</em> into your target distribution;
+<item> Make sure that you've built and tested your package in
+<em>testing</em>, not in <em>unstable</em>;
+<item> Make sure that your version number is higher than the version in
+<em>testing</em> and <em>testing-proposed-updates</em>, and lower than in
+<em>unstable</em>;
+<item> After uploading and successful build on all platforms, contact the
+release team at &email-debian-release; and ask them to approve your upload.
+</list>
+
+
+ <sect1 id="faq">
+ <heading>Frequently asked questions</heading>
+ <p>
+
+ <sect2 id="rc">
+ <heading>What are release-critical bugs, and how do they get counted?</heading>
+ <p>
+All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave, and serious bugs.
+ <p>
+Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".
+ <p>
+The unstable bug count are all release-critical bugs
+without either any release-tag (such as potato, woody) or with release-tag sid;
+also, only if they are neither fixed nor set to sarge-ignore.
+The "testing" bug count for a package is considered to be roughly the bug of unstable count at the last point when the "testing" version equalled the "unstable" version.
+ <p>
+This will change post-sarge, as soon as we have versions in the bug tracking system.
+
+
+ <sect2>
+ <heading>How could installing a package into "testing" possibly break other packages?</heading>
+ <p>
+The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So when the source package acmefoo is installed into "testing", along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed.
+ <p>
+However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages which depend on it.
+ <p>
+Evidently, this mainly affects packages which provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.
+ <p>
+When the set of binary packages provided by a source package change in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into "testing" breaks all the packages that depended on it in "testing", some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.
+ <p>
+If you are having problems with complicated groups of packages like this, contact debian-devel or debian-release for help.
+ </sect>