Hi as I just modified parts of my code generating the removals overview page to deal with more kinds of broken bug titles for removal bugs, a small mail about it:
Please use a bug title format of ($PACKAGE is the source package) RM: $PACKAGE -- REASON for a full removal request or RM: $PACKAGE [$ARCHLIST] -- REASON for a partial removal. The arch list should be enclosed in [] and separated by a space. If the removal is meant to be done in a suite other than unstable add the suite to the package name, separated with a / only. REASON should start with one or more of the acronyms listed on [1] or [2], whichever fits best, followed by a short but descriptive text explaining why the package should be removed. That text should be self-contained, ie. one should not need to read the body of the request to see why the removal should be done, as this text will end up in the removal logfile. (But of course the body can *and* *should* contain much more details than this short subject). Every package that should be removed has to have its own bug report. An example would be "RM: foo -- RoQA: bar is better" for a full removal or "RM: bar/experimental [i386 alpha] -- superseded by foo" for a removal of bar from experimental, i386 and alpha binaries only. If you want to remove an orphaned package - reassign the bug and retitle it, do not file new bugs (someone would have to manually deal with the O: bug). Also - feel free to retitle every removal bug that does not follow this format. And, as a last thing, if you see removal bugs tagged with moreinfo - feel free to handle them. Ie. look into them why they are moreinfo[3] and do whatever is neccessary to make the package removable (or find out that it cant/shouldnt be removed and close the bug). When thats done and the package finally can be removed - remove the moreinfo tag to reflect the state change. If you are a DD you can run "dak rm -nR PACKAGE" on merkel to see if a reverse dependency (still) applies. The above will help me a lot in processing removal bugs. Ah, while Im at it: There are some kinds of removals where we do not need a bug for, namely those detected by the cruft report script (formerly called rene): - NBS - Not Built from Source, aka you stopped building a binary package from your source package. - NVIU - Never Version In Unstable, aka you have a package in experimental and uploaded a newer version to unstable. - Obsolete Source Package - the source package does not have any binary package in the archive anymore. Possibly because they are moved into different source packages. [1] http://ftp-master.debian.org/removals.html [2] http://ftp-master.debian.org/removals.txt (large, contains a log of all removals ever done) [3] usually because the package can't be removed yet due to a reverse dependency -- bye Joerg Definition of Cabal: <lamont> Those people, who, when they do something currently outside of the official rules for behavior [your choice here] 1) are exempted from censure, or 2) (more accurately) by their actions define a new set of rules for acceptable behavior in such context.
pgpmeIvCaHkvk.pgp
Description: PGP signature
