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.
Attachment:
pgpjTWjPx338T.pgp
Description: PGP signature