Debian - Removing packages from testing (FAQ)

Hi.

During the Bug Squashing Party happening last weekend the release team
also hinted a lot of packages for removal from testing. Since this is
something that can happen to all maintainers at any point of the release
process, we want to refresh why and how testing removals happen.
(Attached to the mail you can also find a list of all packages removed
from testing during the weekend)

Please note that due to the transition to gcc 4.0 a lot of old bugs
were upgraded to an RC severity lately, a fact which could have easily
slip your attention. This is probably a good time to check your package
overview (http://qa.debian.org/developer.php) to see if some of your
packages have RC bugs and/or were removed from testing.


Q: Why do you remove packages from testing?

A: Because we can't fix them all. While the release team feels certainly
responsible to bring Debian as a whole in a releasable state we cannot
fix each individual package. This is the maintainer's responsibility.
If a package is not in a releasable state and if there aren't any reasons
to give it special attention (e.g. it has a lot of packages depending on
it) then it should not be part of testing.


Q: When do you remove packages from testing?

A: We remove packages when they are not in a releasable state, i.e. when
they have RC bugs (that affect the version in testing). Of course it
doesn't make sense to immediately remove each and every package that
gets an RC bug therefor we usually ignore "new" bugs. What we define
as "new" depends on where we are in the release process, shortly
before sarge release we usually used a week, currently this is more
like three to four weeks.

There are some factors that can hinder us from removing a package, though:
 - if it is essential (obviously ;)
 - if it has a lot of reverse (build-)dependencies

And there are some factors that let us usually refrain from removing a
package:
 - if the maintainer can't do anything about the RC bug(s), because he
   has to wait on other packages (e.g. all packages that depend on Qt
   currently)
 - if the maintainer is obviously actively working on fixing the bug
   and just needs some more time
 - if the package has a really large user base and we fear the
   negative effects on users of the package in testing would
   outweight the positive effects on the release

Also, please note that removing packages from testing happens on a
case-by-case-basis, means: it happens that some packages that meet
our criteria for removal from testing are already removed, while
others are not.


Q: My package was removed from testing, what should I do?

A: Fix the RC bugs. At the current point in the release process there should
be enough time for any package to get back to testing in time.
(If the freeze gets nearer and you have fixed your RC bugs and the
package still can't get back to testing because of reasons you don't have
any influence on, please contact debian-release@lists.debian.org to
make us aware of the issue)


Q: How can I keep my package from being removed from testing?

A: Fix your RC bugs, fix them fast. Remember that as the maintainer,
you are the person responsible for keeping the package in a releasable
state. If you find yourself unable to fix a release critical bug in
your package, then

 - document the reasons you can't fix the bug in the bug report
 - tag the bug help and ask for patches and/or NMUs
 - get some co-maintainers

This doesn't guarantee that the package won't be removed from testing,
but it is the best way to ensure that a *fixed* package enters testing 
quickly.


Q: You removed my package from testing without notifying me. Why?

A: Because we simply don't have the time. Please make sure you get
notified when one of your packages gets an RC bug and try to investigate
them as fast as possible. If you can't fix them right away document that
in the bug report. Document anything we should know in the bug report!

If you aren't able to ensure that you can react to RC bugs (at least by
mail, not necessarily with an upload) within one or two weeks please
consider finding some co-maintainers or to try to identify some people
you could ask to do an NMU in case you're busy.


Q: But the bug was trivial to fix and/or there was already a patch
available. Why didn't you just NMU the package instead of removing it?

A: Because there are 300 other bugs like yours. Doing a NMU for a trivial
RC bug usually takes 15-30 minutes depending on the package (with the
most time going into testing the result before uploading). Multiply
that by the number of RC bugs we currently have... Hinting a package
for removal usually takes about one minute (with the most time going
into reading the bug report and checking the reverse dependencies).


Q: How can I find who removed my package and why?

A: As long there is an active removal hint for any version of your package
this information is available on the PTS page of your package
(packages.qa.debian.org) and in the current output of the testing scripts
(see http://www.debian.org/devel/testing for the links). Older hints are
only available in the hints files themself, which are accessible at
http://ftp-master.debian.org/testing/hints/. There you should usually
find a short reason for the removal, too (but in most cases this will just
be the bug numbers of your RC bugs).

Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
Release Team
This mail is also available at
http://release.debian.org/removing-packages-from-testing

Marco Presi (Zufus) <zufus@debian.org>
   linesrv
   xlc

Jacek ¦liwerski (rzyjontko) <rzyj@plusnet.pl>
   elmo

Ian Lynagh (wibble) <igloo@debian.org>
   alex
   haddock
   happy

Vikram Aggarwal <aragorn@infofin.com>
   slpim

Bradley Alexander <storm@debian.org>
   scandetd

Michael Banck <mbanck@debian.org>
   ghemical

Carlos Barros <cbf@debian.org>
   tac-plus

Dima Barsky <dima@debian.org>
   xwit

Brian Bassett <brianb@debian.org>
   roy

Andreas Bombe <aeb@debian.org>
   rockdodger

Adrian Bridgett <bridgett@debian.org>
   xonix

Daniel Burrows <dburrows@debian.org>
   criticalmass
   heroes

Marcus Crafter <crafterm@debian.org>
   libproc-process-perl

Tinguaro Barreno Delgado <tbarreno@debian.org>
   saoimage

Debian Octave Group <pkg-octave-devel@lists.alioth.debian.org>
   octaviz

Debian QA Group <packages@qa.debian.org>
   vrweb
   xpvm

Michael Holzt <kju@debian.org>
   obexserver

Shaun Jackman <sjackman@debian.org>
   robotour

Oliver Kiddle <okiddle@yahoo.co.uk>
   ksh

Tibor Koleszar <oldw@debian.org>
   nsmon

Alexander Kotelnikov <sacha@debian.org>
   xlander

Mario Lang <mlang@debian.org>
   oleo

Robert Luberda <robert@debian.org>
   fenris

Mike Markley <mike@markley.org>
   scrollz

Daniel Martin <fizbin@debian.org>
   tkdesk

Dale E Martin <dmartin@cliftonlabs.com>
   tyvis
   warped

Pablo Martin <caedes@sindominio.net>
   pdp

Thomas Maurer <tma@hispeed.ch>
   helix-player

Brian Mays <brian@debian.org>
   wterm

Gopal Narayanan <gopal@debian.org>
   yacas

Thimo Neubauer <thimo@debian.org>
   xmcpustate

Masahito Omote <omote@debian.org>
   sumika

Samuel Ortiz <samuel@sortiz.org>
   sjog

Patrick Ouellette <pouelle@debian.org>
   seesat5

Alexandre Pineau <alexandre.pineau@free.fr>
   liquidwar

David Pye <dmp@davidmpye.dyndns.org>
   libxbox

KELEMEN Péter <fuji@debian.org>
   whowatch

Filip Van Raemdonck <mechanix@debian.org>
   nurbs++

Andrés Roldán <aroldan@debian.org>
   amap

Piotr Roszatycki <dexter@debian.org>
   squashfs

Andres Salomon <dilinger@voxel.net>
   libxslt-ruby

Taketoshi Sano <sano@debian.org>
   xpostit

Thomas Scheffczyk <thomas.scheffczyk@verwaltung.uni-mainz.de>
   ttt

Michiel Sikkes <michiel@eyesopened.nl>
   beep-media-player

Stephen Stafford <bagpuss@debian.org>
   pfe

David Starner <dvdeug@debian.org>
   display-dhammapada

Masato Taruishi <taru@debian.org>
   ecos
   redboot

Debian VBA Team <vba-maint@triplehelix.org>
   visualboyadvance

Matthias Urlichs <smurf@debian.org>
   libvideo-capture-v4l-perl

Norbert Veber <nveber@debian.org>
   radiusd-cistron

Matthew Vernon <matthew@debian.org>
   bible-kjv

Hanno 'Rince' Wagner <wagner@debian.org>
   qps

Torsten Werner <twerner@debian.org>
   sourcenav

Jamie Wilkinson <jaq@debian.org>
   osiris
   quake2

Oohara Yuuma <oohara@debian.org>
   mpatrol

James R. Van Zandt <jrv@debian.org>
   pspp

Alen Zekulic <azekulic@fesb.hr>
   felt

Debian ACE+TAO maintainers <pkg-ace-devel@lists.alioth.debian.org>
   ace

Maintainers of GStreamer packages <pkg-gstreamer-maintainers@lists.alioth.debian.org>
   gst-plugins0.8
   gstreamer0.8

Sam Hocevar (Debian packages) <sam+deb@zoy.org>
   allegro4.1
   tmview
   vls