mathieu wrote:
I have some question about the purpose of
severity / priority
resolution / status
severity / priority :
if a bug is severe, he should get a high priority. If not, he should
get a low priority, no ? The priority is totally relative to the bug
severity, no ?
Sometimes yes, sometimes no.
- the severity tells you what the impact of the bug is on the system: it
can have a minimal effect or it can make the system crash.
- the priority is a timing information: it says how quickly a bug must
be fix.
You are right that most bugs with Severity 'Blocker' are likely to have
Priority 'Immediate'. But for all the rest it is up to the project team
to decide how to prioritize bugs with one another.
For instance a problem that is Average but is an obscure module that is
rarely used , priority will probably be low.
One of the reaon why you don;t clearly see the difference between the 2
is also becasue we have very few bugs on the SAvannah project. But on
large projects these 2 attributes are absolutely fundamental. Ask the
Mozilla people for instance :-)
resolution / status :
if I'm not mistaking, the resolution is a form of « status ». If it
is "wont fixed", or "fixed", or "invalid", it is closed, no ?
That's right
I understand that close/open permit easy browsing of open bugs, bug
some status setting should be automatically set the resolution to close
(the one I've listed above)
The problem is that these attributes are entirely configurable and it is
impossible to know what is the semantic associated with the new label
defined by each project. All the bug tracking system that tries to
implement a transition state diagrams are a nightmare to manage.
It's a little bit confusing to me but it mays have many reasons
explaining this.
I've looked as the Debian bug system and bugzilla. In Debian bug system,
it seems that there not two severity / priority solution, but in
bugzilla there is the same thing.
Debian seems to be a large project so I'd be curious to know how they
manage the priority in which bug will be fixed when they have several
tens in the queue...
This being said since we have little bugs on Savannah it is perfectly
possible to de-activate the Priority field if a majority of the team
members agree to do so. I still think it is a good practice to
decorrelate the impact information from the timing information.
A+
LJ
