Re: Announcement: New bugs pages, status of renaming
Andreas Tille <tillea@rki.de> 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
Reply to: