Andreas Tille <[EMAIL PROTECTED]> writes: > 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 ... What I meant to say is: As the aim of these pages is to encourage people to take an overview of where help is required, packages where the maintainer deals with bugs in a timely manner are much less in need of help than packages where the bugs have built up over time. But, as you say, a bug is a bug, so it's not clear how much advantage there is in implementing this. > > > 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). Yes, that makes sense. > > > 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. An immediately attractive idea would be the value of one "critical" bug - in which case, suggestion "B" might be better than A. Then perhaps a linear spacing: red: 729 *4/4 (80+ normal bugs) yellow: 729*3/4 (60+ normal bugs) green: 729*2/4 (40+ normal bugs) blue: 729*1/4 (20+ normal bugs) but I haven't actually tried it to see if it would work. > > > 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. I'll see if I can make time to have a look, but don't hold your breath. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
