[Cc'ed to RA's for the shock value] Hi guys, This week's assignment is to pick between 10 and 20 source packages each to be removed from testing and/or unstable. Assignments are due next Monday (25th), and should look like: Package: pretzel Testing: 2.0n-1.1 Unstable: 2.0n-1.1 Bugs: 196579 Suggestion: remove-from-testing Analysis: Bug has been open for over two months, has had a patch for about a month and a half, no comments from the maintainer. No indication it'll be solved anytime soon. You should be looking at: http://bugs.debian.org/release-critical http://ftp-master.debian.org/testing/testing_probs.html You should be fairly gung-ho about recommending removal from testing if the version in testing is unreleasable (ie, has RC bugs), but be warned that the testing_probs page is more indicative than accurate. So do make sure that you can find an actual bug number that's legitimately RC and applies to the version in testing. At worst, removing the package from testing won't make it any harder to get a new, fixed version from unstable in. As far as removing packages from unstable, be more conservative. This should only happen if the bugs seem to be difficult to fix, the package isn't particular useful (eg, there are better packages that do the same thing), and the package is orphaned or the maintainer is completely inactive -- no maintainer uploads for a year, open RC bugs for four months or more, that sort of thing. Good candidates for packages to be removed are those that have been sitting around at the bottom of update_excuses for ages; packages that're orphaned; packages that have outstanding RC bugs filed more than eight months ago. If you come across things we can do that don't involve making new uploads to fix RC bugs, please feel free to suggest them, too. For example: Package: astrolog Testing: - Unstable: 5.40-2 Bugs: not-filed Suggestion: remove-outdated-binaries Analysis: non-free pacakge with old binaries (5.40-1) on ia64 and sparc. They should be removed. Feel free to use ftp-master:~ajt/release-assistants/claims/ to avoid duplication of work. List both packages that should be removed and ones you've looked at and think shouldn't be removed there, but only include packages about which something should be done in your mail to this list. Cheers, aj -- Anthony Towns <firstname.lastname@example.org> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
Description: PGP signature