[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Announcement: New bugs pages, status of renaming



Andreas Tille <tillea@rki.de> writes:

> On Thu, 13 Nov 2008, Chris Walker wrote:
> 
> 
> > You might also want to ignore, or reduce the weight of bugs under a
> > certain age - perhaps an absolute cut off of 28 days, or perhaps a
> > sliding scale depending upon severity - with critical bugs becoming
> > important immediately. This might not be worth the effort of
> > implementing though.
> 
> I do not think that the age of a bug should have an influence on the
> result.  Open bugs are just open bugs and should be fixed.  Help is
> needed for old and new bugs.

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 

> 
> > With the exception of Mathematics-dev and biology, all the tasks have
> > the "red" status, and biology would too if it reflected the state of
> > the underlying tasks. I think therfore you're too harsh - and should
> > make it easier to obtain satisfactory status (but if/when we get good
> > at fixing bugs you could change it).
> 
> Yes, I realised that my measure is quite harsh and I see the problem
> that if people who are willing to work on the bugs will not see any
> result on the status might loose interest.  So we should take this
> serious.  So if enybody wants to make suggestions on better limits
> for the assessments (see Legend on overview page) I keen on hearing
> 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.

> 
> Moreover I wonder whether I should make theses limits configurable
> per Blend.  There is a configuration file per Blend anyway - putting
> the limits there to adapt to the specific blend (metapackages with less
> dependencies will be easier to get into shape than those with more).

That's probably a good idea. 

> 
> > I don't think you should give different severities the same score - as
> > you do for critical grave and serious, but I'm not sure I can come up
> > with a better set of numbers than you have.
> 
> I agraa this was a rough estimate for the first shot.  I was guided by
> the fact that all of these three are release critical and so all of them
> should be fixxed immediately.  

That's true, but there is a difference between not meeting policy
requirments and breaking the whole system and causing severe data
loss.

> So what would be the proper score for
> "even more immediately"???

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.

Chris

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.


Reply to: