Re: Announcement: New bugs pages, status of renaming
On Thu, 13 Nov 2008, Chris Walker wrote:
That's true, though if the although a normal bug fixed The reason IYes, that's true. The rationale behind suggesting it was that it
... ups this paragraph is unfinished ...
After lenny is released would be a better time to tune the number - at
the moment there is, quite rightly, some relectance to upload new
packages.
This "after lenny" remark brings up another issue: The current bug
pages do not respect any stable / frozen / testing / unstable differentiation.
This might be interesting, but currently I do see more urgent problems
to solve - feel free to spend some time on it if you regard this as
an urgent problem. A bit more interesting might be to leave out
bugs tagged "wontfix" (and it is simpler to implement).
That's true, but there is a difference between not meeting policy
requirments and breaking the whole system and causing severe data
loss.
Sure.
I did wonder about suggesting:
A B C
wishlist: 1 1 1
minor: 2 3 4
normal: 4 9 16
important: 8 27 64
serious: 16 81 256
grave: 32 243 1024
critical: 64 729 4096
ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on.
Understand the principle. The much higher score of the critical ones
also might reduce the influence of a lot of minor / normal bugs in a
metapackage with much dependencies. Do you have any suggestions for
the limits that fit these scores.
PS if you added an "orange" level, you would have one more level to
play with. I'm assuming here bug severity goes in the order of
colours of the rainbow.
Well, any volunteer to work on a proper css file. I wished some
people would start working in SVN on this stuff. Testing is easy
by just doing
rsync -a alioth.debian.org:/var/lib/gforge/chroot/home/groups/cdd/htdocs .
and you have your local copy of the result. Than you can play with
the CSS file (which differentiates those bugs). Then you can
check in the new css if you are happy about it.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: